Azure Kubernetes Service (AKS) hakkında sık sorulan sorular

Makale
11/06/2023

Bu makalede Azure Kubernetes Service (AKS) hakkında sık sorulan sorular ele alınır.

Şu anda HANGI Azure bölgeleri AKS sağlıyor?

Kullanılabilir bölgelerin tam listesi için bkz . AKS bölgeleri ve kullanılabilirlik.

AKS kümesini bölgelere yayabilir miyim?

Hayır AKS kümeleri bölgesel kaynaklardır ve bölgelere yayılamaz. Birden çok bölge içeren bir mimari oluşturma yönergeleri için bkz . iş sürekliliği ve olağanüstü durum kurtarma için en iyi yöntemler.

Aks kümesini kullanılabilirlik alanlarına yayabilir miyim?

Evet. AKS kümesini destekleyen bölgelerdeki bir veya daha fazla kullanılabilirlik alanınadağıtabilirsiniz.

Kubernetes API sunucusuna erişimi olan kişileri sınırlayabilir miyim?

Evet. API sunucusuna erişimi sınırlamak için iki seçenek vardır:

API sunucusu için genel bir uç nokta korumak ancak erişimi bir dizi güvenilen IP aralığıyla kısıtlamak istiyorsanız API Server Yetkili IP Aralıkları'nı kullanın.
API sunucusunu yalnızca sanal ağınızdan erişilebilir olacak şekilde sınırlamak istiyorsanız özel küme kullanın.

Tek bir kümede farklı VM boyutlarına sahip olabilir miyim?

Evet, birden çok düğüm havuzu oluşturarak AKS kümenizde farklı sanal makine boyutları kullanabilirsiniz.

GÜVENLIK güncelleştirmeleri AKS aracı düğümlerine uygulanıyor mu?

AKS, her hafta "satıcı düzeltmesi" olan CV'lere düzeltme eki ekler. Düzeltmesi olmayan CV'ler düzeltilmeden önce "satıcı düzeltmesi" bekliyor. AKS görüntüleri 30 gün içinde otomatik olarak güncelleştirilir. En son düzeltme eki uygulanmış görüntülerin ve işletim sistemi düzeltme eklerinin uygulandığından ve güncel olduğundan emin olmak için düzenli bir tempoda güncelleştirilmiş bir Düğüm Görüntüsü uygulamanızı öneririz. Bunu aşağıdaki yöntemlerden birini kullanarak yapabilirsiniz:

El ile, Azure portalı veya Azure CLI aracılığıyla.
AKS kümenizi yükselterek. Küme, cordon ve drain düğümlerini otomatik olarak yükseltir ve ardından en son Ubuntu görüntüsü ve yeni bir yama sürümü ya da küçük bir Kubernetes sürümüyle yeni bir düğümü çevrimiçi ortama getirir. Daha fazla bilgi edinmek için bkz. Bir AKS kümesini yükseltme.
Düğüm görüntüsü yükseltmeyi kullanarak.

AKS'de kapsayıcı görüntüsünde boyut sınırı nedir?

AKS, kapsayıcı görüntüsü boyutuna bir sınır ayarlamaz. Ancak, görüntü ne kadar büyük olursa bellek talebinin o kadar yüksek olduğunu anlamak önemlidir. Daha büyük bir boyut, kaynak sınırlarını veya çalışan düğümlerinin genel kullanılabilir belleğini aşabilir. Varsayılan olarak, AKS kümesi için VM boyutu Standard_DS2_v2 belleği 7 GiB olarak ayarlanır.

Terabayt (TB) aralığında olduğu gibi bir kapsayıcı görüntüsü aşırı büyük olduğunda, kubelet disk alanı olmaması nedeniyle kapsayıcı kayıt defterinizden bir düğüme çekemeyebilir.

Windows Server düğümleri

Windows Server düğümleri için Windows Update otomatik olarak çalışmaz ve en son güncelleştirmeleri uygulamaz. Windows Update yayın döngüsü ve kendi doğrulama işleminiz etrafında düzenli bir zamanlamaya göre, aks kümenizdeki kümede ve Windows Server düğüm havuzlarında bir yükseltme gerçekleştirmeniz gerekir. Bu yükseltme işlemi, en son Windows Server görüntüsünü ve düzeltme eklerini çalıştıran düğümler oluşturur ve ardından eski düğümleri kaldırır. Bu işlem hakkında daha fazla bilgi için bkz . AKS'de düğüm havuzunu yükseltme.

AKS'yi hedefleyen ve dikkate alınması gereken güvenlik tehditleri var mı?

Microsoft, Kapsayıcılar için Microsoft Defender gibi hizmetler aracılığıyla iş yüklerinizin güvenliğini sağlamak için gerçekleştirebileceğiniz diğer eylemler için rehberlik sağlar. Aşağıdaki güvenlik tehdidi, aks ve Kubernetes ile ilgilidir ve bilmeniz gerekir:

Yeni büyük ölçekli kampanya Kubeflow'ı hedefler (8 Haziran 2021).

Yönetilen Denetim Düzlemi Düğümlerimle nasıl iletişim kurar?

AKS, api-server ve tek düğüm kubelet'lerinin ayrı sanal ağlarda bile iletişim kurmasını sağlamak için güvenli bir tünel iletişimi kullanır. Tünelin güvenliği mTLS şifrelemesi ile sağlanır. AKS tarafından kullanılan geçerli ana tünel, daha önce apiserver-network-proxy olarak bilinen Konnectivity'dir. Tüm ağ kurallarının Azure için gerekli ağ kurallarına ve FQDN'lere uygun olduğunu doğrulayın.

Podlarım küme IP'si yerine API sunucusu FQDN'sini kullanabilir mi?

Evet, değişkeni küme içi hizmet IP'sinin yerine API sunucusunun etki alanı adına ayarlamak KUBERNETES_SERVICE_HOST için podlara ek açıklama kubernetes.azure.com/set-kube-service-host-fqdn ekleyebilirsiniz. Bu, küme çıkışınızın 7. katman güvenlik duvarı üzerinden yapıldığı durumlarda (örneğin, Uygulama Kuralları ile Azure Güvenlik Duvarı kullanırken) kullanışlıdır.

AKS ile neden iki kaynak grubu oluşturulur?

AKS, Sanal Makine Ölçek Kümeleri, sanal ağlar ve yönetilen diskler dahil olmak üzere birçok Azure altyapısı kaynağını kullanır. Bu tümleştirmeler, AKS tarafından sağlanan yönetilen Kubernetes ortamında Azure platformunun birçok temel özelliğini uygulamanızı sağlar. Örneğin, çoğu Azure sanal makine türü doğrudan AKS ile kullanılabilir ve Azure Rezervasyonları bu kaynaklarda otomatik olarak indirim almak için kullanılabilir.

Bu mimariyi etkinleştirmek için her AKS dağıtımı iki kaynak grubuna yayılmıştır:

İlk kaynak grubunu oluşturursunuz. Bu grup yalnızca Kubernetes hizmet kaynağını içerir. AKS kaynak sağlayıcısı dağıtım sırasında ikinci kaynak grubunu otomatik olarak oluşturur. İkinci kaynak grubuna örnek olarak MC_myResourceGroup_myAKSCluster_eastus. Bu ikinci kaynak grubunun adını belirtme hakkında bilgi için sonraki bölüme bakın.
Düğüm kaynak grubu olarak bilinen ikinci kaynak grubu, kümeyle ilişkili tüm altyapı kaynaklarını içerir. Bu kaynaklar Kubernetes düğüm VM'lerini, sanal ağı ve depolamayı içerir. Varsayılan olarak, düğüm kaynak grubunun MC_myResourceGroup_myAKSCluster_eastus gibi bir adı vardır. Kümeyi her sildiğinizde AKS düğüm kaynak grubunu otomatik olarak siler. Bu kümeyi yalnızca kümenin yaşam döngüsünü paylaşan kaynaklar için kullanmalısınız.

Not

AKS kümesindeki düğüm kaynak grubu altındaki herhangi bir kaynağı değiştirmek desteklenmeyen bir eylemdir ve küme işlemi hatalarına neden olur. Kullanıcıların AKS kümesi tarafından yönetilen kaynakları değiştirmesini engelleyerek düğüm kaynak grubunda değişiklik yapılmasını engelleyebilirsiniz.

AKS düğümü kaynak grubu için kendi adımı sağlayabilir miyim?

Evet. Varsayılan olarak, AKS düğüm kaynak grubunu MC_resourcegroupname_clustername_location adlandırabilir, ancak kendi adınızı da sağlayabilirsiniz.

Kendi kaynak grubu adınızı belirtmek için aks-preview Azure CLI uzantısı sürüm 0.3.2 veya üzerini yükleyin. komutunu kullanarak az aks create bir AKS kümesi oluşturduğunuzda parametresini --node-resource-group kullanın ve kaynak grubu için bir ad belirtin. AKS kümesi dağıtmak için Azure Resource Manager şablonu kullanıyorsanız nodeResourceGroup özelliğini kullanarak kaynak grubu adını tanımlayabilirsiniz.

Azure kaynak sağlayıcısı otomatik olarak ikincil kaynak grubunu oluşturur.
Özel kaynak grubu adını yalnızca kümeyi oluştururken belirtebilirsiniz.

Düğüm kaynak grubuyla çalışırken şunları yapamazsınız:

Düğüm kaynak grubu için mevcut bir kaynak grubunu belirtin.
Düğüm kaynak grubu için farklı bir abonelik belirtin.
Küme oluşturulduktan sonra düğüm kaynak grubu adını değiştirin.
Düğüm kaynak grubu içindeki yönetilen kaynakların adlarını belirtin.
Düğüm kaynak grubu içindeki yönetilen kaynakların Azure tarafından oluşturulan etiketlerini değiştirin veya silin. Sonraki bölümde ek bilgilere bakın.

Düğüm kaynak grubundaki AKS kaynaklarının etiketlerini ve diğer özelliklerini değiştirebilir miyim?

Düğüm kaynak grubundaki Azure tarafından oluşturulan etiketleri ve diğer kaynak özelliklerini değiştirir veya silerseniz beklenmeyen ölçeklendirme ve yükseltme hataları alabilirsiniz. AKS, son kullanıcılar tarafından oluşturulan özel etiketleri oluşturmanıza ve değiştirmenize olanak tanır ve düğüm havuzu oluştururken bu etiketleri ekleyebilirsiniz. Örneğin, bir iş birimi veya maliyet merkezi atamak için özel etiketler oluşturmak veya değiştirmek isteyebilirsiniz. Bir diğer seçenek de yönetilen kaynak grubunda kapsamı olan Azure İlkeleri oluşturmaktır.

Azure tarafından oluşturulan etiketler ilgili Azure Hizmetleri için oluşturulur ve her zaman izin verilmelidir. AKS için ve k8s-azure etiketleri vardıraks-managed. AKS kümesindeki düğüm kaynak grubu altındaki kaynaklarda Azure tarafından oluşturulan etiketleri değiştirmek, hizmet düzeyi hedefini (SLO) bozan desteklenmeyen bir eylemdir. Daha fazla bilgi için bkz. AKS hizmet düzeyi sözleşmesi sunuyor mu?

Not

Geçmişte"Sahip" etiket adı AKS'ye yük dengeleyicinin ön uç IP'sinde atanan genel IP'yi yönetmesi için ayrılmıştı. Şimdi, hizmetler ön ekini aks-managed kullanır. Eski kaynaklar için Azure ilkelerini kullanarak "Sahip" etiket adını uygulamayın. Aksi takdirde AKS kümesi dağıtım ve güncelleştirme işlemlerinizdeki tüm kaynaklar bozulacaktır. Bu, yeni oluşturulan kaynaklar için geçerli değildir.

AKS hangi Kubernetes erişim denetleyicilerini destekler? Erişim denetleyicileri eklenebilir veya kaldırılabilir mi?

AKS aşağıdaki erişim denetleyicilerini destekler:

NamespaceLifecycle
LimitRanger
ServiceAccount
DefaultIngressClass
Varsayılan Depolama Class
DefaultTolerationSeconds
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
ResourceQuota
PodNodeSelector
PodTolerationRestriction
ExtendedResourceToleration

Şu anda AKS'deki erişim denetleyicileri listesini değiştiremezsiniz.

AKS'de erişim denetleyicisi web kancalarını kullanabilir miyim?

Evet, AKS'de erişim denetleyicisi web kancalarını kullanabilirsiniz. Denetim düzlemi etiketiyle işaretlenmiş iç AKS ad alanlarını dışlamanız önerilir. Örneğin:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS, API sunucusu çıkışını güvenlik duvarıyla güvenlik duvarı oluşturur, böylece erişim denetleyicisi web kancalarınızın küme içinden erişilebilir olması gerekir.

Erişim denetleyicisi web kancaları kube-system ve iç AKS ad alanlarını etkileyebilir mi?

Sistemin kararlılığını korumak ve özel erişim denetleyicilerinin kube-system içindeki iç hizmetleri etkilemesini önlemek için AKS ad alanı, kube-system ve AKS iç ad alanlarını otomatik olarak dışlayan bir Erişim Uygulayıcısına sahiptir. Bu hizmet, özel erişim denetleyicilerinin kube-system içinde çalışan hizmetleri etkilememesini sağlar.

Özel erişim web kancanızı desteklemek için kube-system üzerinde bir şey dağıtmak için kritik bir kullanım örneğiniz varsa (önerilmez), Kabul Uygulayıcısı'nın bunu yoksayması için aşağıdaki etiketi veya ek açıklamayı ekleyebilirsiniz.

Etiket: "admissions.enforcer/disabled": "true" veya Ek Açıklama: "admissions.enforcer/disabled": true

Azure Key Vault AKS ile tümleştirilmiş mi?

Gizli Dizi Deposu için Azure Key Vault Sağlayıcısı CSI Sürücüsü , Azure Key Vault'un AKS ile yerel tümleştirmesini sağlar.

AKS üzerinde Windows Server kapsayıcıları çalıştırabilir miyim?

Evet, Windows Server kapsayıcıları AKS'de kullanılabilir. AKS'de Windows Server kapsayıcılarını çalıştırmak için konuk işletim sistemi olarak Windows Server çalıştıran bir düğüm havuzu oluşturursunuz. Windows Server kapsayıcıları yalnızca Windows Server 2019 kullanabilir. Başlamak için bkz . Windows Server düğüm havuzuyla AKS kümesi oluşturma.

Düğüm havuzu için Windows Server desteği, Kubernetes'te yukarı akış Windows Server projesinin parçası olan bazı sınırlamalar içerir. Bu sınırlamalar hakkında daha fazla bilgi için bkz . AKS sınırlamalarında Windows Server kapsayıcıları.

AKS hizmet düzeyi sözleşmesi sunuyor mu?

AKS, Çalışma Süresi SLA özelliğiyle Standart fiyatlandırma katmanında SLA garantileri sağlar.

Ücretsiz fiyatlandırma katmanının ilişkili bir Hizmet Düzeyi Sözleşmesi yoktur, ancak %99,5 Hizmet Düzeyi Hedefi vardır. Bir yükseltme, iyi durumda olmayan alt katman düğümleri, platform bakımı, bir uygulamanın API Server'ı isteklerle bunaltma vb. varsa geçici bağlantı sorunları gözlemlenir. Görev açısından kritik iş yükleri ve üretim iş yükleri için veya iş yükünüz API Server yeniden başlatmalarını tolere etmiyorsa, Çalışma Süresi SLA'sını içeren Standart katmanı kullanmanızı öneririz.

AKS aracısı düğümlerime Azure rezervasyon indirimleri uygulayabilir miyim?

AKS aracı düğümleri standart Azure sanal makineleri olarak faturalandırılır. AKS'de kullandığınız VM boyutu için Azure rezervasyonları satın aldıysanız bu indirimler otomatik olarak uygulanır.

Kümemi Azure kiracıları arasında taşıyabilir/geçirebilir miyim?

AKS kümenizi kiracılar arasında taşıma işlemi şu anda desteklenmiyor.

Kümemi abonelikler arasında taşıyabilir/geçirebilir miyim?

Abonelikler arasında kümelerin taşınması şu anda desteklenmiyor.

AKS kümelerimi geçerli Azure aboneliğinden diğerine taşıyabilir miyim?

AKS kümenizi ve ilişkili kaynaklarını Azure abonelikleri arasında taşıma desteklenmez.

AKS kümemi veya AKS altyapı kaynaklarımı diğer kaynak gruplarına taşıyabilir veya yeniden adlandırabilir miyim?

AKS kümenizi ve ilişkili kaynaklarını taşıma veya yeniden adlandırma desteklenmez.

Kümemin silinmesi neden bu kadar uzun sürüyor?

Çoğu küme, kullanıcı isteği üzerine silinir. Bazı durumlarda, özellikle de kendi Kaynak Grubunuzu getirdiğiniz veya çapraz RG görevleri gerçekleştirdiğiniz durumlarda silme işlemi daha uzun sürebilir, hatta başarısız olabilir. Silme işlemleriyle ilgili bir sorununuz varsa, RG üzerinde kilitleriniz olmadığını, RG dışındaki tüm kaynakların RG ile ilişkilendirildiğini vb. bir kez daha denetleyin.

Kümemin oluşturulması/güncelleştirilmesi neden bu kadar uzun sürüyor?

Küme oluşturma ve güncelleştirme işlemleriyle ilgili sorunlarınız varsa AKS kümenizin VM'ler, yük dengeleyiciler, etiketler vb. kaynakları yönetmesini engelleyebilecek atanmış ilkeler veya hizmet kısıtlamaları olmadığından emin olun.

Kümemi sildikten sonra geri yükleyebilir miyim?

Hayır, kümenizi sildikten sonra geri yükleyemezsiniz. Kümenizi sildiğinizde düğüm kaynak grubu ve tüm kaynakları da silinir. İkinci kaynak grubuna örnek olarak MC_myResourceGroup_myAKSCluster_eastus.

Kaynaklarınızdan herhangi birini tutmak istiyorsanız, kümenizi silmeden önce bunları başka bir kaynak grubuna taşıyın. Yanlışlıkla silmelere karşı koruma sağlamak istiyorsanız, Düğüm kaynak grubu kilitlemesini kullanarak küme kaynaklarınızı barındıran AKS yönetilen kaynak grubunu kilitleyebilirsiniz.

Platform desteği nedir ve neler içerir?

Platform desteği, desteklenmeyen "N-3" sürüm kümeleri için azaltılmış bir destek planıdır. Platform desteği yalnızca Azure altyapı desteğini içerir. Platform desteği aşağıdakiler ile ilgili hiçbir şey içermez:

Kubernetes işlevselliği ve bileşenleri
Küme veya düğüm havuzu oluşturma
Düzeltmeler
Hata düzeltmeleri
Güvenlik düzeltme ekleri
Kullanımdan kaldırılacak bileşenler

Kısıtlamalar hakkında daha fazla bilgi için platform destek ilkesine bakın.

AKS, yalnızca üç ikincil sürümden oluşan kayan bir pencereyi destekleyen bir Açık Kaynak projesi olan Kubernetes'ten gelen sürümlere ve düzeltme eklerine dayanır. AKS yalnızca bu sürümlere yukarı akış hizmeti sağlanırken tam desteği garanti edebilir. Yukarı akışta başka yama üretilmediğinden AKS bu sürümleri eşleşmemiş veya çatalsız bırakabilir. Bu sınırlama nedeniyle platform desteği, kubernetes yukarı akışına güvenmeyi desteklemez.

AKS desteklenmeyen kümelerimi otomatik olarak yükselter mi?

AKS, desteklenmeyen kümeler için otomatik yükseltmeler başlatır. n-3 sürümündeki bir küme (burada n desteklenen en son AKS GA ikincil sürümüdür) n-4'e düşmek üzereyken AKS, aks destek ilkesinde kalmak için kümeyi otomatik olarak n-2 sürümüne yükselter. Platform tarafından desteklenen bir kümeyi desteklenen bir sürüme otomatik olarak yükseltme varsayılan olarak etkinleştirilir.

Örneğin, kubernetes v1.25, v1.29 GA sürümü sırasında v1.26'ya yükseltir. Kesintileri en aza indirmek için bakım pencerelerini ayarlayın. Otomatik yükseltme kanallarıyla ilgili ayrıntılar için bkz. otomatik yükseltme.

'NodeLost' veya 'Bilinmiyor' durumunda pod /dağıtımlarım varsa kümemi yükseltmeye devam edebilir miyim?

Yapabilirsiniz, ancak bunu önermiyoruz. Kümenin durumu bilinen ve iyi durumda olduğunda güncelleştirmeler gerçekleştirmelisiniz.

İyi durumda olmayan veya kapatılmış bir veya daha fazla düğüme sahip bir kümem varsa yükseltme gerçekleştirebilir miyim?

Hayır, yükseltmeden önce başarısız durumdaki veya kümeden başka bir şekilde düğümleri silin/kaldırın.

Bir küme silme işlemi çalıştırdım, ancak hatayı görüyorum `[Errno 11001] getaddrinfo failed`

En yaygın olarak, kümeyle ilişkilendirilmiş bir veya daha fazla Ağ Güvenlik Grubunuz (NSG) hala kullanılıyorsa bu hata oluşur. Bunları kaldırın ve silmeyi yeniden deneyin.

Yükseltme çalıştırdım, ancak artık podlarım kilitlenme döngülerinde ve hazırlık yoklamaları başarısız oluyor mu?

Hizmet sorumlunuzun süresinin dolmadığından emin olun. Bkz. AKS hizmet sorumlusu ve AKS güncelleştirme kimlik bilgileri.

Kümem çalışıyordu, ancak aniden LoadBalancer sağlayamaz, PVC'leri bağlayamaz, vb.

Hizmet sorumlunuzun süresinin dolmadığından emin olun. Bkz. AKS hizmet sorumlusu ve AKS güncelleştirme kimlik bilgileri.

AKS kümemi sıfıra ölçeklendirebilir miyim?

Çalışan aks kümesini tamamen durdurarak ilgili işlem maliyetlerinden tasarruf edebilirsiniz. Ayrıca, yalnızca gerekli küme yapılandırmasını koruyarak tüm düğüm havuzlarını veya belirli User düğüm havuzlarını 0'a ölçeklendirmeyi veya otomatik ölçeklendirmeyi de seçebilirsiniz.

Sistem düğümü havuzlarını doğrudan sıfıra ölçeklendiremezsiniz.

El ile ölçeklendirmek için Sanal Makine Ölçek Kümesi API'lerini kullanabilir miyim?

Hayır, Sanal Makine Ölçek Kümesi API'lerini kullanarak ölçeklendirme işlemleri desteklenmez. AKS API'lerini ()az aks scale kullanın.

sıfır düğüme el ile ölçeklendirmek için Sanal Makine Ölçek Kümeleri kullanabilir miyim?

Hayır, Sanal Makine Ölçek Kümesi API'lerini kullanarak ölçeklendirme işlemleri desteklenmez. Bunun yerine AKS API'sini kullanarak sıfır sistem dışı düğüm havuzuna ölçeklendirebilir veya kümenizi durdurabilirsiniz.

Tüm VM'lerimi durdurabilir veya ayırabilir miyim?

AKS'nin bu tür bir yapılandırmaya dayanacak ve bu yapılandırmadan kurtulacak dayanıklılık mekanizmaları olsa da, desteklenen bir yapılandırma değildir. Bunun yerine kümenizi durdurun.

Özel VM uzantılarını kullanabilir miyim?

Hayır, AKS yönetilen bir hizmettir ve IaaS kaynaklarının değiştirilmesi desteklenmez. Özel bileşenleri yüklemek için Kubernetes API'lerini ve mekanizmalarını kullanın. Örneğin, gerekli bileşenleri yüklemek için DaemonSets kullanın.

AKS, müşteri verilerini kümenin bölgesinin dışında depolar mı?

Hayır, tüm veriler kümenin bölgesinde depolanır.

AKS görüntülerinin kök olarak çalıştırılması gerekiyor mu?

Aşağıdaki görüntülerin "Kök Olarak Çalıştır" işlevsel gereksinimleri vardır ve tüm ilkeler için özel durumlar dosyalanmalıdır:

mcr.microsoft.com/oss/kubernetes/coredns
mcr.microsoft.com/azuremonitor/containerinsights/ciprod
mcr.microsoft.com/oss/calico/node
mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Azure CNI Saydam Modu ile Köprü Modu karşılaştırması nedir?

Sürüm 1.2.0'dan başlayarak Azure CNI, tek kiracılı Linux CNI dağıtımları için saydam modu varsayılan olarak ayarlar. Saydam mod, köprü modunun yerini alıyor. Aşağıdaki Köprü modu ve Saydam mod bölümlerinde hem modlar arasındaki farklar hem de Azure CNI'de Saydam modun avantajları ve sınırlamaları hakkında daha fazla bilgi acağız.

Köprü modu

Azure CNI Köprüsü modu, "tam zamanında" bir şekilde "azure0" adlı bir L2 köprüsü oluşturur. Tüm konak tarafı pod veth çifti arabirimleri bu köprüye bağlanır. Pod-Pod VM içi iletişim ve kalan trafik bu köprüden geçer. Köprü, bir veya daha fazla gerçek cihazı bağlamadığınız sürece tek başına hiçbir şey almayacak veya iletmeyecek bir katman 2 sanal cihazıdır. Bu nedenle, Linux VM'sinin eth0'unun linux VM'sinde karmaşık bir ağ topolojisi oluşturan "azure0" köprüsüne bir alt köprüye dönüştürülmesi gerekir. Bir belirti olarak, CNI'nin DNS sunucusu güncelleştirmeleri gibi diğer ağ işlevlerini işlemesi gerekiyordu.

Bridge mode topology

Aşağıdaki örnek, ip yolu kurulumunun Köprü modunda nasıl göründüğünü gösterir. Düğümde kaç pod olduğuna bakılmaksızın, yalnızca iki yol vardır. İlk yol, trafiğin (azure0'da yerel hariç) ip "src 10.240.0.4" olan ve Node birincil IP'sine sahip arabirimi aracılığıyla alt ağın varsayılan ağ geçidine gittiğini söyler. İkincisinde ise çekirdeğin karar vermesine yönelik "10.20.x.x" pod alanı yer alır.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Saydam mod

Saydam mod, Linux ağını ayarlamak için basit bir yaklaşım benimser. Bu modda Azure CNI, Linux VM'deki eth0 arabiriminin özelliklerini değiştirmez. Linux ağ özelliklerini değiştirme yaklaşımı, kümelerin Köprü modunda karşılaşabileceği karmaşık köşe durumu sorunlarını azaltmaya yardımcı olur. Saydam modda Azure CNI, konak ağına eklenen konak tarafı pod veth çifti arabirimleri oluşturur ve ekler. VM Pod'undan Pod'a iletişimi CNI tarafından eklenen ip yollarından geçer. Temelde, Pod-Pod iletişimi katman 3'ün üzerindedir ve L3 yönlendirme kuralları pod trafiğini yönlendirir.

Transparent mode topology

Aşağıdaki örnekte Saydam modun ip yolu kurulumu gösterilmektedir. Her Pod'un arabirimine statik bir yol eklendiğinden, Pod doğrudan Pod'un ana bilgisayar yan veth çifti arabirimine gönderilirken DEST IP'sine sahip trafik olur.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Saydam modun avantajları

Dns paralel yarış durumu için conntrack azaltma ve düğüm yerel DNS'sini ayarlamaya gerek kalmadan 5 sn DNS gecikme süresi sorunlarının önlenmesini sağlar (performans nedeniyle düğüm yerel DNS'sini kullanmaya devam edebilirsiniz).
"Tam zamanında" köprü kurulumu nedeniyle CNI köprü modunun bugün tanıtılan ilk 5 saniyelik DNS gecikme süresini ortadan kaldırır.
Köprü modundaki köşe durumlarından biri, Azure CNI'nin kullanıcıların sanal ağa veya NIC'ye ekleyecekleri özel DNS sunucusu listelerini güncelleştirmeye devam etmemesidir. Bu senaryo, CNI'nin YALNıZCA DNS sunucusu listesinin ilk örneğini toplamasını getirir. CNI hiçbir eth0 özelliğini değiştirmediğinden bu sorun Saydam modda çözülür. Daha fazla bilgi için buraya bakın.
ARP zaman aşımına uğradığında UDP taşması için UDP trafiğinin daha iyi işlenmesini ve azaltmayı sağlar. Köprü modunda, köprü VM içi Pod-Pod iletişiminde hedef podun MAC adresini bilmediğinde, tasarım gereği paketin tüm bağlantı noktalarına fırtınayla sonuçlanışına neden olur. Yolda L2 cihazı olmadığından bu sorun Saydam modda çözülür. Daha fazla bilgi için buraya bakın.
Saydam mod, Köprü moduyla karşılaştırıldığında aktarım hızı ve gecikme süresi açısından VM poddan poda iletişiminde daha iyi performans gösterir.

Birimde çok sayıda dosya olduğunda izin sahipliği ayarı yavaş sorunlarından nasıl kaçınabilirsiniz?

Geleneksel olarak podunuz kök olmayan bir kullanıcı olarak çalışıyorsa (bunu yapmalısınız), birimin Pod tarafından okunabilir ve yazılabilir olabilmesi için pod'un güvenlik bağlamı içinde bir fsGroup belirtmeniz gerekir. Bu gereksinim burada daha ayrıntılı olarak ele alınmıştır.

Ayarın fsGroup bir yan etkisi, bir birim her bağlandığında Kubernetes'in yinelemeli olması chown() ve chmod() birim içindeki tüm dosya ve dizinlerin (aşağıda belirtilen birkaç özel durumla birlikte) olmasıdır. Bu senaryo, birimin grup sahipliği istenen fsGroupile zaten eşleşse bile gerçekleşir. Çok sayıda küçük dosya içeren daha büyük birimler için pahalı olabilir ve bu da pod başlatmanın uzun sürmesine neden olabilir. Bu senaryo v1.20 öncesi bilinen bir sorundu ve geçici çözüm Pod çalıştırmasını kök olarak ayarlamaktır:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Sorun Kubernetes sürüm 1.20 ile giderilmiştir. Daha fazla bilgi için bkz . Kubernetes 1.20: Birim İzin Değişikliklerinin Ayrıntılı Denetimi.

AKS'de dağıtımlarla FIPS şifreleme kitaplıklarını kullanabilir miyim?

FIPS özellikli düğümler artık Linux tabanlı düğüm havuzlarında desteklenmektedir. Daha fazla bilgi için bkz . FIPS özellikli düğüm havuzu ekleme.

AKS ile NSG'leri yapılandırabilir miyim?

AKS, alt ağına Ağ Güvenlik Grupları (NSG) uygulamaz ve bu alt ağ ile ilişkili NSG'lerin hiçbirini değiştirmez. AKS yalnızca ağ arabirimleri NSG ayarlarını değiştirir. CNI kullanıyorsanız, NSG'lerdeki güvenlik kurallarının düğüm ve pod CIDR aralıkları arasında trafiğe izin vermesini de sağlamanız gerekir. Kubenet kullanıyorsanız, NSG'lerdeki güvenlik kurallarının düğüm ile pod CIDR arasında trafiğe izin vermesini de sağlamanız gerekir. Daha fazla bilgi için bkz . Ağ güvenlik grupları.

AKS'de zaman eşitlemesi nasıl çalışır?

AKS düğümleri, localhost'tan zaman alan "chrony" hizmetini çalıştırır. Podlarda çalışan kapsayıcılar AKS düğümlerinden zaman alır. Bir kapsayıcının içinde başlatılan uygulamalar podun kapsayıcısından kullanım süresi.

AKS eklentileri nasıl güncelleştirilir?

Güvenlik düzeltme eki de dahil olmak üzere tüm düzeltme ekleri AKS kümesine otomatik olarak uygulanır. Birincil veya ikincil sürüm değişiklikleri (dağıtılan nesnelerinizde hataya neden olabilecek değişiklikler olabilir) gibi bir düzeltme ekinden daha büyük olan her şey, yeni bir sürüm varsa kümenizi güncelleştirdiğinizde güncelleştirilir. AKS sürüm notlarını ziyaret ederek yeni bir sürümün ne zaman kullanıma sunulduğuna ulaşabilirsiniz.

Linux Sanal Makine Ölçek Kümeleri örneklerimde yüklü olduğunu gördüğüm AKS Linux Uzantısının amacı nedir?

AKS Linux Uzantısı, Kubernetes çalışan düğümlerine izleme araçlarını yükleyen ve yapılandıran bir Azure VM uzantısıdır. Uzantı tüm yeni ve mevcut Linux düğümlerine yüklenir. Aşağıdaki izleme araçlarını yapılandırıyor:

Düğüm veren: Sanal makineden donanım telemetrisi toplar ve bunu bir ölçüm uç noktası kullanarak kullanılabilir hale getirir. Ardından Prometheus gibi bir izleme aracı bu ölçümleri kazıyabiliyor.
Düğüm-sorun algılayıcısı: Çeşitli düğüm sorunlarının küme yönetim yığınındaki yukarı akış katmanlarına görünür olmasını sağlar. Her düğümde çalışan, düğüm sorunlarını algılayan ve Olaylar ve NodeConditions kullanarak bunları kümenin API sunucusuna bildiren sistemli bir birimdir.
ig: Linux ve Kubernetes sistemlerinde hata ayıklama ve gözlemleme için eBPF destekli açık kaynak çerçevesi. Kullanıcıların performans sorunlarının, kilitlenmelerin veya diğer anomalilerin nedenini belirlemesine olanak tanıyarak ilgili bilgileri toplamak için tasarlanmış bir araç (veya araç) kümesi sağlar. Özellikle, Kubernetes'ten bağımsız olması, kullanıcıların denetim düzlemi sorunlarının hatalarını ayıklamak için de bunu kullanmasına olanak tanır.

Bu araçlar, aşağıdakiler gibi düğüm durumuyla ilgili birçok sorunda gözlemlenebilirlik sağlamaya yardımcı olur:

Altyapı daemon sorunları: NTP hizmeti çalışmıyor
Donanım sorunları: Hatalı CPU, bellek veya disk
Çekirdek sorunları: Çekirdek kilitlenmesi, bozuk dosya sistemi
Kapsayıcı çalışma zamanı sorunları: Yanıt vermeyen çalışma zamanı daemon'ları

Uzantı, belgelenen AKS çıkış gereksinimlerini aşan URL'lere, IP adreslerine veya bağlantı noktalarına ek giden erişim gerektirmez. Azure'da özel izinler verilmesi gerekmez. Toplanan izleme verilerini göndermek üzere API sunucusuna bağlanmak için kubeconfig kullanır.