Azure Kubernetes Service (AKS) kümesi için temel mimari

Bu başvuru mimarisi, Azure'da Bir Azure Kubernetes Service (AKS) kümesi dağıtmak için önerilen bir temel altyapı mimarisi sağlar. Tasarım ilkelerimizi kullanır ve bu genel amaçlı altyapının dağıtılması yoluyla ağ, güvenlik ve kimlik gibi disiplinler arası veya birden çok farklı takıma rehberlik etmek için Azure İyi Tasarlanmış Çerçeve'nin mimari en iyi deneyimlerini temel alır.

Bu mimari bir iş yüküne odaklanmaz, AKS kümesinin kendisine odaklanır. Buradaki bilgiler, AKS kümelerinin çoğu için önerilen en düşük taban çizgisidir. Çok bölgeli büyümeyi destekleyen ve küme içi trafiğin güvenliğini sağlayan bir ağ topolojisi olan gözlemlenebilirlik sunan Azure hizmetleriyle tümleştirilir.

Hedef mimari, iş gereksinimlerinizden etkilenir ve sonuç olarak farklı uygulama bağlamları arasında farklılık gösterebilir. Ön üretim ve üretim aşamaları için başlangıç noktanız olarak düşünülmelidir.

Bu mimarinin bir uygulaması GitHub'da da kullanılabilir: Azure Kubernetes Service (AKS) Temel Başvuru Uygulaması. Bunu alternatif bir başlangıç noktası olarak kullanabilir ve gereksinimlerinize göre yapılandırabilirsiniz.

Ağ yapılandırması

Ağ topolojisi
IP adreslerini planlama
Giriş kaynaklarını dağıtma

Küme işlem

Temel küme için işlem
Kapsayıcı görüntüsü başvurusu
İlke yönetimi

Kimlik yönetimi

Küme için Microsoft Entra Kimliğini tümleştirme
İş yükü için Microsoft Entra Kimliğini tümleştirme

Güvenli veri akışı

Ağ akışının güvenliğini sağlama
Gizli dizi yönetimi ekleme

İş sürekliliği

Ölçeklenebilirlik
Küme ve düğüm kullanılabilirliği
Kullanılabilirlik ve çok bölgeli destek

Operations

Küme ve iş yükü CI/CD işlem hatları
Küme durumu ve ölçümleri
Maliyet yönetimi ve raporlama

Ağ topolojisi

Bu mimaride merkez-uç ağ topolojisi kullanılır. Merkez ve uçlar, eşleme aracılığıyla bağlanan ayrı sanal ağlara dağıtılır. Bu topolojinin bazı avantajları şunlardır:

• Ayrılmış yönetim. İdareyi uygulamak ve en az ayrıcalık ilkesine uymak için bir yol sağlar. Ayrıca görev ayrımı içeren bir Azure giriş bölgesi kavramını da destekler.

• Azure kaynaklarının genel İnternet'e doğrudan maruz kalmasını en aza indirir.

• Kuruluşlar genellikle bölgesel merkez-uç topolojileriyle çalışır. Merkez-uç ağ topolojileri gelecekte genişletilebilir ve iş yükü yalıtımı sağlayabilir.

• Tüm web uygulamaları, HTTP trafik akışını yönetmeye yardımcı olmak için bir web uygulaması güvenlik duvarı (WAF) hizmeti gerektirmelidir.

• Birden çok aboneliğe yayılan iş yükleri için doğal bir seçimdir.

• Mimariyi genişletilebilir hale getirir. Yeni özellikleri veya iş yüklerini barındırmak için ağ topolojisini yeniden tasarlamak yerine yeni uçlar eklenebilir.

• Güvenlik duvarı ve DNS gibi belirli kaynaklar ağlar arasında paylaşılabilir.

• Azure kurumsal ölçekli giriş bölgeleriyle uyumlu hale getirme.

Bu mimarinin bir Visio dosyasını indirin.

Daha fazla bilgi için bkz . Azure'da merkez-uç ağ topolojisi.

AKS temel başvuru mimarisinde Windows kapsayıcılarına dahil edilen ağ tasarımı değişikliklerini gözden geçirmek için yardımcı makaleye bakın.

Hub

Merkez sanal ağı, bağlantının ve gözlemlenebilirliğin merkezi noktasıdır. Merkez her zaman kuruluş genelinde güvenlik duvarı ilkesini zorlamak için merkezi BT ekipleriniz tarafından tanımlanan genel güvenlik duvarı ilkelerine sahip bir Azure Güvenlik Duvarı, VPN bağlantısı için bir ağ geçidi alt ağı olan Azure Bastion'ı ve ağ gözlemlenebilirliği için Azure İzleyici'yi içerir.

Ağ içinde üç alt ağ dağıtılır.

Azure Güvenlik Duvarı barındıracak alt ağ

Azure Güvenlik Duvarı hizmet olarak güvenlik duvarıdır. Güvenlik duvarı örneği giden ağ trafiğinin güvenliğini sağlar. Bu güvenlik katmanı olmadan, bu trafik hassas şirket verilerini silerek kötü amaçlı bir üçüncü taraf hizmetiyle iletişim kurabilir. Azure Güvenlik Duvarı Yöneticisi, birden çok Azure Güvenlik Duvarı örneğini merkezi olarak dağıtmanıza ve yapılandırmanıza ve bu merkez sanal ağ ağ mimarisi türü için Azure Güvenlik Duvarı ilkelerini yönetmenize olanak tanır.

Ağ geçidi barındırmak için alt ağ

Bu alt ağ, VPN veya ExpressRoute ağ geçidi için yer tutucudur. Ağ geçidi, şirket içi ağınızdaki yönlendiricilerle sanal ağ arasında bağlantı sağlar.

Azure Bastion'ı barındırmak için alt ağ

Bu alt ağ, Azure Bastion için bir yer tutucudur. Bastion'ı kullanarak kaynakları İnternet'e göstermeden Azure kaynaklarına güvenli bir şekilde erişebilirsiniz. Bu alt ağ yalnızca yönetim ve işlemler için kullanılır.

Konuştu

Uç sanal ağı AKS kümesini ve diğer ilgili kaynakları içerir. Uç dört alt ağa sahiptir:

Azure Uygulaması Lication Gateway'i barındıracak alt ağ

Azure Application Gateway , Katman 7'de çalışan bir web trafiği yük dengeleyicidir. Başvuru uygulaması, Web Uygulaması Güvenlik Duvarı (WAF) sağlayan Application Gateway v2 SKU'yu kullanır. WAF, botlar da dahil olmak üzere yaygın web trafiği saldırılarından gelen trafiğin güvenliğini sağlar. Örneğin kullanıcı isteklerini alan bir genel ön uç IP yapılandırması vardır. Tasarım gereği Application Gateway için ayrılmış bir alt ağ gerekir.

Giriş kaynaklarını barındırmak için alt ağ

Trafiği yönlendirmek ve dağıtmak için Traefik, Kubernetes giriş kaynaklarını yerine getiren giriş denetleyicisidir. Azure iç yük dengeleyicileri bu alt ağda bulunur. Daha fazla bilgi için bkz . Azure Kubernetes Service (AKS) ile iç yük dengeleyici kullanma.

Küme düğümlerini barındırmak için alt ağ

AKS iki ayrı düğüm grubu (veya düğüm havuzları) tutar. Sistem düğümü havuzu, çekirdek küme hizmetlerini çalıştıran podları barındırıyor. Kullanıcı düğümü havuzu , iş yüküne gelen iletişimi etkinleştirmek için iş yükünüzü ve giriş denetleyicisini çalıştırır.

Özel Bağlantı uç noktalarını barındırmak için alt ağ

Azure Özel Bağlantı bağlantıları Azure Container Registry ve Azure Key Vault, bu hizmetlere uç sanal ağı içindeki özel uç nokta kullanılarak erişilebilir. Özel uç noktalar ayrılmış bir alt ağ gerektirmez ve hub sanal ağına da yerleştirilebilir. Temel uygulamada bunlar uç sanal ağı içindeki ayrılmış bir alt ağa dağıtılır. Bu yaklaşım eşlenen ağ bağlantısını geçen trafiği azaltır, kümeye ait kaynakları aynı sanal ağda tutar ve ağ güvenlik gruplarını kullanarak alt ağ düzeyinde ayrıntılı güvenlik kuralları uygulamanızı sağlar.

Daha fazla bilgi için bkz. Özel Bağlantı dağıtım seçenekleri.

IP adreslerini planlayın

Bu mimarinin bir Visio dosyasını indirin.

Sanal ağın adres alanı tüm alt ağları barındıracak kadar büyük olmalıdır. Trafik alacak tüm varlıkların hesabı. Bu varlıkların IP adresleri alt ağ adres alanından ayrılır. Bu noktaları göz önünde bulundurun.

• Yükseltme

  AKS, temel alınan sanal makinelerin güvenlik özellikleri ve diğer sistem düzeltme ekleri hakkında güncel olduğundan emin olmak için düğümleri düzenli olarak güncelleştirir. Yükseltme işlemi sırasında AKS, podları geçici olarak barındıran bir düğüm oluştururken yükseltme düğümü kordonlanır ve boşaltılır. Bu geçici düğüme küme alt ağından bir IP adresi atanır.

  Podlar için stratejinize bağlı olarak ek adreslere ihtiyacınız olabilir. Sıralı güncelleştirmeler için, gerçek podlar güncelleştirilirken iş yükünü çalıştıran geçici podların adreslerine ihtiyacınız olacaktır. Değiştirme stratejisini kullanırsanız podlar kaldırılır ve yenileri oluşturulur. Bu nedenle, eski podlarla ilişkili adresler yeniden kullanılır.

• Ölçeklenebilirlik

  Tüm sistem ve kullanıcı düğümlerinin düğüm sayısını ve bunların en yüksek ölçeklenebilirlik sınırını dikkate alın. Ölçeği %400 genişletmek istediğinizi varsayalım. Tüm bu ölçeklendirilen düğümler için adres sayısının dört katı gerekir.

  Bu mimaride, her podla doğrudan bağlantı kurulabilir. Bu nedenle, her pod için ayrı bir adres gerekir. Pod ölçeklenebilirliği, adres hesaplamasını etkiler. Bu karar, büyütmek istediğiniz pod sayısıyla ilgili seçiminize bağlıdır.

• Azure Özel Bağlantı adresleri

  Özel Bağlantı üzerinden diğer Azure hizmetleriyle iletişim için gereken adresleri dikkate alır. Bu mimaride, Azure Container Registry ve Key Vault bağlantıları için atanmış iki adresimiz vardır.

• Belirli adresler Azure tarafından kullanılmak üzere ayrılmıştır . Bunlar atanamaz.

Yukarıdaki liste kapsamlı değildir. Tasarımınızda kullanılabilir IP adreslerinin sayısını etkileyecek başka kaynaklar varsa bu adresleri kabul edin.

Bu mimari tek bir iş yükü için tasarlanmıştır. Birden çok iş yükü için kullanıcı düğümü havuzlarını birbirinden ve sistem düğümü havuzundan yalıtmak isteyebilirsiniz. Bu seçim boyutu daha küçük olan daha fazla alt ağa neden olur. Ayrıca, giriş kaynağı daha karmaşık olabilir ve sonuç olarak ek IP adresleri gerektiren birden çok giriş denetleyicisine ihtiyacınız olabilir.

Bu mimariyle ilgili dikkat edilmesi gerekenlerin tamamı için bkz . AKS temel Ağ Topolojisi.

AKS kümesinin IP'sini planlamayla ilgili bilgi için bkz . Kümeniz için IP adresleme planlama.

AKS temel başvuru mimarisinde Windows kapsayıcılarına dahil edilen IP adresi planlama konularını gözden geçirmek için yardımcı makaleye bakın.

Eklentiler ve önizleme özellikleri

Kubernetes ve AKS, şirket içi ortamlar için yazılımlardan daha hızlı yayın döngüleri ile sürekli gelişen ürünlerdir. Bu temel mimari, belirli AKS önizleme özelliklerine ve AKS eklentilerine bağlıdır. İkisi arasındaki fark şunlardır:

• AKS ekibi önizleme özelliklerini gönderim ve geliştirme olarak açıklar. Bunun nedeni, önizleme özelliklerinin çoğunun genel sürüm (GA) aşamasına geçmeden önce yalnızca birkaç ay boyunca bu durumda kalmasıdır.
• AKS eklentileri ve uzantıları ek, desteklenen işlevler sağlar. Yükleme, yapılandırma ve yaşam döngüsü AKS tarafından yönetilir.

Bu temel mimari her önizleme özelliğini veya eklentiyi içermez, bunun yerine yalnızca genel amaçlı bir kümeye önemli değer katanlar dahil edilir. Bu özellikler önizleme aşamasından çıktıkçe, bu temel mimari uygun şekilde düzeltilecektir. Güvenlik, yönetilebilirlik veya diğer gereksinimlerinizi arttıran üretim öncesi kümelerde değerlendirmek isteyebileceğiniz bazı ek önizleme özellikleri veya AKS eklentileri vardır. Üçüncü taraf eklentilerle, kullanılabilir sürümleri izleme ve bir kümenin Kubernetes sürümünü yükselttikten sonra güncelleştirmeleri yükleme de dahil olmak üzere bunları yükleyip korumanız gerekir.

Kapsayıcı görüntüsü başvurusu

Küme, iş yüküne ek olarak giriş denetleyicisi gibi birkaç görüntü daha içerebilir. Bu görüntülerden bazıları genel kayıt defterlerinde bulunabilir. Kümenize çekerken bu noktaları göz önünde bulundurun.

• Görüntüyü çekmek için kümenin kimliği doğrulanır.

• Genel görüntü kullanıyorsanız, bunu SLO'nuzla uyumlu kapsayıcı kayıt defterinize içeri aktarmayı göz önünde bulundurun. Aksi takdirde, görüntü beklenmeyen kullanılabilirlik sorunlarına maruz kalabilir. Bu sorunlar, ihtiyacınız olduğunda görüntü kullanılamıyorsa işlem sorunlarına neden olabilir. Genel kayıt defteri yerine kapsayıcı kayıt defterinizi kullanmanın bazı avantajları şunlardır:

  • Resimlerinize yetkisiz erişimi engelleyebilirsiniz.
  • Genel kullanıma yönelik bağımlılıklarınız olmayacaktır.
  • Etkinlikleri izlemek ve bağlantı sorunlarını önceliklendirmek için görüntü çekme günlüklerine erişebilirsiniz.
  • Tümleşik kapsayıcı tarama ve görüntü uyumluluğundan yararlanın.

  Bir seçenek Azure Container Registry (ACR) seçeneğidir.

• Yetkili kayıt defterlerinden görüntüleri çekin. Bu kısıtlamayı Azure İlkesi aracılığıyla uygulayabilirsiniz. Bu başvuru uygulamasında, küme yalnızca mimarinin bir parçası olarak dağıtılan ACR'den görüntüleri çeker.

Temel küme için işlem yapılandırma

AKS'de her düğüm havuzu bir Sanal Makine Ölçek Kümesi ile eşlenir. Düğümler, her düğüm havuzundaki VM'lerdir. Maliyetleri en aza indirmek için sistem düğümü havuzu için daha küçük bir VM boyutu kullanmayı göz önünde bulundurun. Bu başvuru uygulaması, sistem düğümü havuzunu üç DS2_v2 düğümle dağıtır. Bu boyut, sistem podlarının beklenen yükünü karşılamak için yeterlidir. İşletim sistemi diski 512 GB'tır.

Kullanıcı düğümü havuzu için dikkat edilmesi gereken bazı noktalar şunlardır:

• Bir düğümde ayarlanan en fazla pod sayısını paketlemek için daha büyük düğüm boyutları seçin. İzleme ve günlüğe kaydetme gibi tüm düğümlerde çalışan hizmetlerin ayak izini en aza indirir.

• En az iki düğüm dağıtın. Bu şekilde, iş yükü iki çoğaltma ile yüksek kullanılabilirlik düzenine sahip olur. AKS ile kümeyi yeniden oluşturmadan düğüm sayısını değiştirebilirsiniz.

• İş yükünüz için gerçek düğüm boyutları, tasarım ekibi tarafından belirlenen gereksinimlere bağlıdır. İş gereksinimlerine bağlı olarak, üretim iş yükü için DS4_v2 seçtik. Maliyetleri düşürmek için boyutu en düşük öneri olan DS3_v2 düşürebilir.

• Kümenizin kapasitesini planlarken, iş yükünüzün her düğümün %80'ine kadar tüketebileceğini varsayalım; kalan %20 AKS hizmetleri için ayrılmıştır.

• Kapasite planlamanıza göre düğüm başına en fazla pod sayısını ayarlayın. Kapasite temeli oluşturmaya çalışıyorsanız, 30 değeriyle başlayın. bu değeri iş yükünün gereksinimlerine, düğüm boyutuna ve IP kısıtlamalarınıza göre ayarlayın.

Küme için Microsoft Entra Kimliğini tümleştirme

Kümeye ve kümeden erişimin güvenliğini sağlamak kritik önem taşır. Güvenlik seçimleri yaparken kümenin perspektifinden düşünün:

• İçeriden dışarı erişim. Ağ altyapısı, Azure Container Registry ve Azure Key Vault gibi Azure bileşenlerine AKS erişimi. Yalnızca kümenin erişimine izin verilen kaynakları yetkileyin.
• Dışarıdan erişim. Kubernetes kümesine kimlik erişimi sağlama. Yalnızca Kubernetes API sunucusuna ve Azure Resource Manager'a erişim izni olan dış varlıkları yetkilendirir.

Azure'a AKS erişimi

Microsoft Entra ID aracılığıyla AKS'yi Azure'a erişimi yönetmenin iki yolu vardır: Hizmet sorumluları veya Azure kaynakları için yönetilen kimlikler.

Bu iki yöntemden yönetilen kimlikler önerilir. Hizmet sorumluları ile gizli dizileri el ile veya program aracılığıyla yönetmek ve döndürmek sizin sorumluluğundadır. Yönetilen kimliklerle, Microsoft Entra Id sizin için kimlik doğrulamasını ve gizli dizileri zamanında döndürmeyi yönetir ve gerçekleştirir.

Kümenin Microsoft Entra Id aracılığıyla dış Azure kaynaklarıyla etkileşim kurabilmesi için yönetilen kimliklerin etkinleştirilmesi önerilir. Bu ayarı yalnızca küme oluşturma sırasında etkinleştirebilirsiniz. Microsoft Entra Kimliği hemen kullanılmasa bile daha sonra ekleyebilirsiniz.

Varsayılan olarak, küme tarafından kullanılan iki birincil kimlik vardır: küme kimliği ve kubelet kimliği. Küme kimliği , AKS denetim düzlemi bileşenleri tarafından giriş yük dengeleyicileri, AKS tarafından yönetilen genel IP'ler gibi küme kaynaklarını yönetmek için kullanılır. Kubelet kimliği , Azure Container Registry (ACR) ile kimlik doğrulaması yapmak için kullanılır. Bazı eklentiler yönetilen kimlik kullanarak kimlik doğrulamayı da destekler.

İçten dışa örnek olarak, kümenin kapsayıcı kayıt defterinden görüntü çekmesi gerektiğinde yönetilen kimliklerin kullanımını inceleyelim. Bu eylem için kümenin kayıt defterinin kimlik bilgilerini alması gerekir. Bunun bir yolu, bu bilgileri Kubernetes Gizli Dizileri nesnesi biçiminde depolamak ve gizli diziyi almak için kullanmaktır imagePullSecrets . Güvenlik karmaşıklıkları nedeniyle bu yaklaşım önerilmez. Gizli dizi hakkında önceden bilgi sahibi olmanıza ek olarak DevOps işlem hattı aracılığıyla bu gizli diziyi açığa çıkması da gerekir. Bir diğer neden de gizli dizi rotasyonunu yönetmenin operasyonel yüküdür. Bunun yerine, kümenin kubelet yönetilen kimliğine kayıt defterinize erişim verin acrPull . Bu yaklaşım bu endişeleri giderir.

Bu mimaride küme, Microsoft Entra Id ile güvenliği sağlanan Azure kaynaklarına erişir ve yönetilen kimlikleri destekleyen işlemler gerçekleştirir. Kümenin yapmak istediği işlemlere bağlı olarak azure rol tabanlı erişim denetimi (Azure RBAC) ve kümenin yönetilen kimliklerine izinler atayın. Küme, Microsoft Entra Kimliği'nde kimliğini doğrular ve atandığı rollere göre erişime izin verilir veya erişim reddedilir. Azure yerleşik rollerinin kümeye atandığı bu başvuru uygulamasından bazı örnekler aşağıda verilmiştir:

• Ağ Katkıda Bulunanı. Kümenin uç sanal ağını denetleme özelliği. Bu rol ataması, AKS küme sistemi tarafından atanan kimliğin İç Giriş Denetleyicisi hizmetleri için ayrılmış alt ağ ile çalışmasını sağlar.
• Ölçüm Yayımcısı'nın izlenmesi. Kümenin Azure İzleyici'ye ölçüm gönderebilmesi.
• AcrPull. Kümenin belirtilen Azure Container Kayıt Defterlerinden görüntü çekme özelliği.

Küme erişimi

Microsoft Entra tümleştirmesi, dışarıdan erişim için güvenliği de kolaylaştırır. Bir kullanıcının kubectl kullanmak istediğini varsayalım. İlk adım olarak, kümenin az aks get-credentials kimlik bilgilerini almak için komutunu çalıştırırlar. Microsoft Entra Id, küme kimlik bilgilerini almasına izin verilen Azure rollerinde kullanıcının kimliğini doğrular. Daha fazla bilgi için bkz . Kullanılabilir küme rolleri izinleri.

AKS, Microsoft Entra Id kullanarak Kubernetes erişimine iki şekilde izin verir. Birincisi, yerel Kubernetes RBAC sistemiyle tümleştirilmiş bir kimlik sağlayıcısı olarak Microsoft Entra Id'yi kullanmaktır. Diğeri ise küme erişimini denetlemek için yerel Azure RBAC kullanıyor. Her ikisi de aşağıda ayrıntılı olarak yer almaktadır.

Kubernetes RBAC'yi Microsoft Entra Id ile ilişkilendirme

Kubernetes, aşağıdakiler aracılığıyla rol tabanlı erişim denetimini (RBAC) destekler:

• Bir dizi izin. Küme genelinde izinler için bir Role veya ClusterRole nesnesi tarafından tanımlanır.

• Eylemleri gerçekleştirmesine izin verilen kullanıcıları ve grupları atayan bağlamalar. Bir RoleBinding veya ClusterRoleBinding nesnesi tarafından tanımlanır.

Kubernetes'te küme yöneticisi, düzenleme, görüntüleme gibi bazı yerleşik roller vardır. Erişimi yönetmek için kurumsal dizini kullanmak üzere bu rolleri Microsoft Entra kullanıcılarına ve gruplarına bağlayın. Daha fazla bilgi için bkz . Microsoft Entra tümleştirmesi ile Kubernetes RBAC kullanma.

Küme ve ad alanı erişimi için kullanılan Microsoft Entra gruplarınızın Microsoft Entra erişim gözden geçirmelerinize eklendiğinden emin olun.

Kubernetes yetkilendirmesi için Azure RBAC kullanma

Tümleşik Microsoft Entra kimlik doğrulamasıyla yetkilendirme için Kubernetes yerel RBAC (ClusterRoleBindings ve RoleBindings) kullanmak yerine, kümede yetkilendirme denetimlerini zorunlu kılmak için Azure RBAC ve Azure rol atamalarını kullanmanız önerilir. Bu rol atamaları abonelik veya kaynak grubu kapsamlarına bile eklenebilir, böylece kapsam altındaki tüm kümeler Kubernetes kümesindeki nesnelere erişme izinlerine sahip olan kişilere göre tutarlı bir rol atamaları kümesini devralır.

Daha fazla bilgi için bkz . Kubernetes Için Azure RBAC Yetkilendirmesi.

Yerel hesaplar

AKS, yerel Kubernetes kullanıcı kimlik doğrulamayı destekler. Bu yöntemi kullanarak kümelere kullanıcı erişimi önerilmez. Sertifika tabanlıdır ve birincil kimlik sağlayıcınız dışında gerçekleştirilir; merkezi kullanıcı erişim denetimini ve idareyi zorlaştırma. Microsoft Entra Id kullanarak kümenize erişimi her zaman yönetin ve yerel hesap erişimini açıkça devre dışı bırakmak için kümenizi yapılandırın.

Bu başvuru uygulamasında, küme dağıtıldığında yerel küme hesapları aracılığıyla erişim açıkça devre dışı bırakılır.

İş yükü için Microsoft Entra Kimliğini tümleştirme

Kümenin tamamı için Azure sistem tarafından atanan yönetilen kimliğe sahip olmak gibi, yönetilen kimlikleri pod düzeyinde atayabilirsiniz. İş yükü kimliği, barındırılan iş yükünün Microsoft Entra Kimliği aracılığıyla kaynaklara erişmesini sağlar. Örneğin, iş yükü dosyaları Azure Depolama'de depolar. Bu dosyalara erişmesi gerektiğinde pod, azure tarafından yönetilen bir kimlik olarak kaynakta kimliğini doğrular.

Bu başvuru uygulamasında, AKS'deki Microsoft Entra İş Yükü Kimliği aracılığıyla podlar için yönetilen kimlikler sağlanır. Bu, dış kimlik sağlayıcılarıyla federasyona yönelik Kubernetes yerel özellikleriyle tümleşir. Microsoft Entra İş Yükü Kimliği federasyon hakkında daha fazla bilgi için aşağıdaki genel bakışa bakın.

Giriş kaynaklarını dağıtma

Kubernetes Giriş kaynakları gelen trafiği kümeye yönlendirir ve dağıtır. Giriş kaynaklarının iki bölümü vardır:

• İç yük dengeleyici. AKS tarafından yönetilir. Bu yük dengeleyici, giriş denetleyicisini özel bir statik IP adresi aracılığıyla kullanıma sunar. Gelen akışları alan tek bir iletişim noktası görevi görür.

  Bu mimaride Azure Load Balancer kullanılır. Giriş kaynakları için ayrılmış bir alt ağa kümenin dışına yerleştirilir. Azure Uygulaması lication Gateway'den trafik alır ve bu iletişim TLS üzerinden yapılır. Gelen trafik için TLS şifrelemesi hakkında bilgi için bkz . Giriş trafiği akışı.

• Giriş denetleyicisi. Traefik'i seçtik. Kümedeki kullanıcı düğümü havuzunda çalışır. İç yük dengeleyiciden trafik alır, TLS'yi sonlandırır ve HTTP üzerinden iş yükü podlarına iletir.

Giriş denetleyicisi kümenin kritik bir bileşenidir. Bu bileşeni yapılandırırken bu noktaları göz önünde bulundurun.

• Tasarım kararlarınızın bir parçası olarak, giriş denetleyicisinin çalışmasına izin verilecek bir kapsam seçin. Örneğin, denetleyicinin yalnızca belirli bir iş yükünü çalıştıran podlarla etkileşim kurmasına izin vekleyebilirsiniz.

• Yükü yaymak ve bir düğüm kesintiye uğradıysa iş sürekliliğini sağlamak için çoğaltmaları aynı düğüme yerleştirmekten kaçının. Bu amaçla kullanın podAntiAffinity .

• kullanarak nodeSelectorspodları yalnızca kullanıcı düğümü havuzunda zamanlanacak şekilde kısıtlayın. Bu ayar iş yükünü ve sistem podlarını yalıtacaktır.

• Belirli varlıkların giriş denetleyicisine trafik göndermesine izin veren bağlantı noktalarını ve protokolleri açın. Bu mimaride Traefik yalnızca Azure Uygulaması lication Gateway'den trafik alır.

• Giriş denetleyicisi, podların durumunu gösteren sinyaller göndermelidir. Belirtilen aralıkta podların sistem durumunu izleyecek ve livenessProbe ayarlarını yapılandırınreadinessProbe.

• Giriş denetleyicisinin belirli kaynaklara erişimini ve belirli eylemleri gerçekleştirme becerisini kısıtlamayı göz önünde bulundurun. Bu kısıtlama Kubernetes RBAC izinleri aracılığıyla uygulanabilir. Örneğin, bu mimaride Traefik'e Kubernetes ClusterRole nesnesindeki kuralları kullanarak hizmetleri ve uç noktaları izleme, alma ve listeleme izinleri verilmiştir.

AKS temel başvuru mimarisinde Windows kapsayıcılarında kullanılan giriş tasarımını gözden geçirmek için yardımcı makaleye bakın.

Yönlendirici ayarları

Giriş denetleyicisi, trafiğin nereye gönderileceğini belirlemek için yolları kullanır. Yollar, trafiğin alındığı kaynak bağlantı noktasını ve hedef bağlantı noktaları ve protokoller hakkındaki bilgileri belirtir.

İşte bu mimariden bir örnek:

Traefik, yolları yapılandırmak için Kubernetes sağlayıcısını kullanır. annotations, tlsve entrypoints yolların HTTPS üzerinden hizmet alınacağını belirtir. yalnızca middlewares Azure Uygulaması lication Gateway alt ağından gelen trafiğe izin verildiğini belirtir. İstemci kabul ederse yanıtlar gzip kodlamasını kullanır. Traefik TLS sonlandırması yaptığı için arka uç hizmetleriyle iletişim HTTP üzerinden yapılır.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

Ağ akışının güvenliğini sağlayın

Bu bağlamda ağ akışı şu şekilde kategorilere ayrılmış olabilir:

• Giriş trafiği. İstemciden kümede çalışan iş yüküne.

• Çıkış trafiği. Kümedeki bir pod veya düğümden dış hizmete.

• Poddan poda trafik. Podlar arasındaki iletişim. Bu trafik, giriş denetleyicisi ile iş yükü arasındaki iletişimi içerir. Ayrıca, iş yükünüz kümeye dağıtılan birden çok uygulamadan oluşuyorsa, bu uygulamalar arasındaki iletişim bu kategoriye girer.

• Yönetim trafiği. İstemci ile Kubernetes API sunucusu arasında giden trafik.

Bu mimarinin bir Visio dosyasını indirin.

Bu mimari, tüm trafik türlerinin güvenliğini sağlamak için çeşitli güvenlik katmanlarına sahiptir.

Giriş trafik akışı

Mimari yalnızca istemciden gelen TLS şifreli isteklerini kabul eder. TLS v1.2, kısıtlı bir şifre kümesine sahip izin verilen en düşük sürümdür. Sunucu Adı Göstergesi (SNI) katı etkinleştirildi. Uçtan uca TLS, bu görüntüde gösterildiği gibi Application Gateway aracılığıyla iki farklı TLS sertifikası kullanılarak ayarlanır.

Bu mimarinin bir Visio dosyasını indirin.

1. İstemci, etki alanı adına bir HTTPS isteği gönderir: bicycle.contoso.com. Bu ad, Azure Uygulaması lication Gateway'in genel IP adresine dns A kaydı aracılığıyla ilişkilendirilir. Bu trafik, istemci tarayıcısı ve ağ geçidi arasındaki trafiğin denetlenemediğinden veya değiştirilemediğinden emin olmak için şifrelenir.

2. Application Gateway tümleşik bir web uygulaması güvenlik duvarına (WAF) sahiptir ve bicycle.contoso.com için TLS el sıkışması anlaşması yaparak yalnızca güvenli şifrelemelere olanak sağlar. Application Gateway, WAF denetim kurallarını işlemek ve trafiği yapılandırılan arka uça ileden yönlendirme kurallarını yürütmek için gerekli olduğundan bir TLS sonlandırma noktasıdır. TLS sertifikası Azure Key Vault'ta depolanır. Application Gateway ile tümleştirilmiş kullanıcı tarafından atanan yönetilen kimlik kullanılarak erişilir. Bu özellik hakkında bilgi için bkz . Key Vault sertifikalarıyla TLS sonlandırma.

3. Application Gateway'den arka uça giden trafik, iç yük dengeleyiciye iletilirken başka bir TLS sertifikasıyla (*.aks-ingress.contoso.com joker karakteri) yeniden şifrelenir. Bu yeniden şifreleme, güvenli olmayan trafiğin küme alt asına akmamasını sağlar.

4. Giriş denetleyicisi, şifrelenmiş trafiği yük dengeleyici aracılığıyla alır. Denetleyici, *.aks-ingress.contoso.com için başka bir TLS sonlandırma noktasıdır ve trafiği HTTP üzerinden iş yükü podlarına iletir. Sertifikalar Azure Key Vault'ta depolanır ve Kapsayıcı Depolama Arabirimi (CSI) sürücüsü kullanılarak kümeye bağlanır. Daha fazla bilgi için bkz . Gizli dizi yönetimi ekleme.

İş yükü podunun üzerinden her atlamada uçtan uca TLS trafiği uygulayabilirsiniz. Poddan poda trafiğin güvenliğini sağlamaya karar verirken performansı, gecikme süresini ve operasyonel etkiyi ölçmeyi unutmayın. Uygun denetim düzlemi RBAC ve olgun Yazılım Geliştirme Yaşam Döngüsü uygulamalarıyla tek kiracılı kümelerin çoğunda, TLS'nin giriş denetleyicisine kadar şifrelemesi ve Web Uygulaması Güvenlik Duvarı (WAF) ile korunması yeterlidir. Bu, iş yükü yönetimi ve ağ performansı üzerindeki etkileri en aza indirir. İş yükünüz ve uyumluluk gereksinimleriniz, TLS sonlandırma işlemini nerede gerçekleştireceğinize karar verecek.

Çıkış trafik akışı

Bu mimaride, kümeden gelen tüm çıkış trafiğinin NAT Ağ Geçidi veya HTTP ara sunucusu gibi diğer seçenekler üzerinden Azure Güvenlik Duvarı veya kendi benzer ağ sanal gereciniz üzerinden iletişim kurmasını öneririz. Sıfır güven denetimi ve trafiği inceleyebilmek için kümeden gelen tüm çıkış trafiği Azure Güvenlik Duvarı geçer. Bu seçimi kullanıcı tanımlı yolları (UDR) kullanarak uygulayabilirsiniz. Yolun sonraki atlaması, Azure Güvenlik Duvarı özel IP adresidir. Burada Azure Güvenlik Duvarı çıkış trafiğinin engellenip engellenmeyeceğine veya izin verilip verilmeyeceğine karar verir. Bu karar, Azure Güvenlik Duvarı veya yerleşik tehdit bilgileri kurallarında tanımlanan belirli kurallara dayanır.

Azure Güvenlik Duvarı kullanmanın bir alternatifi, AKS'nin HTTP Ara Sunucusu özelliğini kullanmaktır. Kümenin tüm trafik çıkışı, trafiği iletmeye veya bırakmaya karar veren HTTP Proxy'sinin IP adresine ayarlanır.

Her iki yöntemden biriyle AKS için gerekli çıkış ağ kurallarını gözden geçirin.

Sıfır güven denetiminin bir istisnası, kümenin diğer Azure kaynaklarıyla iletişim kurması gerektiği durumlardır. Örneğin, kümenin kapsayıcı kayıt defterinden güncelleştirilmiş bir görüntüyü veya Azure Key Vault'tan gizli dizileri çekmesi gerekir. Önerilen yaklaşım, Azure Özel Bağlantı kullanmaktır. Bunun avantajı, belirli alt ağların küme ile İnternet üzerinden giden hizmetler arasındaki trafik yerine doğrudan hizmete ulaşmasıdır. Dezavantajı, Özel Bağlantı hedef hizmeti genel uç noktası üzerinden kullanmak yerine ek yapılandırmaya ihtiyacı olmasıdır. Ayrıca, tüm Azure hizmetleri veya SKU'ları Özel Bağlantı desteklemez. Bu gibi durumlarda, hizmete erişmek için alt ağda bir Sanal Ağ hizmet uç noktasını etkinleştirmeyi göz önünde bulundurun.

Özel Bağlantı veya hizmet uç noktaları bir seçenek değilse, diğer hizmetlere ortak uç noktaları aracılığıyla ulaşabilir ve Azure Güvenlik Duvarı kuralları ve hedef hizmette yerleşik güvenlik duvarı aracılığıyla erişimi denetleyebilirsiniz. Bu trafik güvenlik duvarının statik IP adreslerinden geçeceği için bu adresler hizmetin IP izin verilenler listesine eklenebilir. Bunun bir dezavantajı, Azure Güvenlik Duvarı yalnızca belirli bir alt ağdan gelen trafiğe izin verildiğinden emin olmak için ek kurallara sahip olması gerektiğidir. Azure Güvenlik Duvarı ile çıkış trafiği için birden çok IP adresi planlarken bu adresleri dikkate alırsınız, aksi takdirde bağlantı noktası tükenmeye ulaşabilirsiniz. Birden çok IP adresi planlaması hakkında daha fazla bilgi için bkz . Giden trafiği kısıtlama ve denetleme.

AKS temel başvuru mimarisindeki Windows kapsayıcılarında kullanılan Windows'a özgü çıkış konularını gözden geçirmek için yardımcı makaleye bakın.

Poddan poda trafik

Varsayılan olarak, pod kümedeki diğer podlardan gelen trafiği kabul edebilir. Kubernetes NetworkPolicy , podlar arasındaki ağ trafiğini kısıtlamak için kullanılır. İlkeleri yargısal olarak uygulayın; aksi takdirde kritik ağ akışının engellendiği bir durumla karşınıza çıkabilir. Yalnızca gerektiğinde giriş denetleyicisi ile iş yükü arasındaki trafik gibi belirli iletişim yollarına izin verin. Daha fazla bilgi için bkz . Ağ ilkeleri.

Küme sağlandığında ağ ilkesini etkinleştirin çünkü daha sonra eklenemez. uygulayan NetworkPolicyteknolojiler için birkaç seçenek vardır. Azure Container Networking Interface (CNI) gerektiren Azure Ağ İlkesi önerilir. Aşağıdaki nota bakın. Diğer seçenekler arasında iyi bilinen bir açık kaynak seçeneği olan Calico Ağ İlkesi yer alır. Küme genelinde ağ ilkelerini yönetmeniz gerekiyorsa Calico'ya göz atabilirsiniz. Calico standart Azure desteği kapsamında değildir.

Daha fazla bilgi için bkz . Azure Ağ İlkesi ile Calico ilkeleri arasındaki farklar ve bunların özellikleri.

Yönetim trafiği

Kümeyi çalıştırmanın bir parçası olarak Kubernetes API sunucusu, kaynak oluşturma istekleri veya kümeyi ölçeklendirme gibi kümede yönetim işlemleri yapmak isteyen kaynaklardan gelen trafiği alır. Bu kaynaklara örnek olarak DevOps işlem hattındaki derleme aracısı havuzu, Bastion alt ağı ve düğüm havuzları verilebilir. Tüm IP adreslerinden gelen bu yönetim trafiğini kabul etmek yerine, YALNıZCA yetkili IP aralıklarınızdan API sunucusuna giden trafiğe izin vermek için AKS'nin Yetkili IP Aralıkları özelliğini kullanın.

Daha fazla bilgi için bkz . API sunucusu yetkili IP aralıklarını tanımlama.

Ek bir denetim katmanı için, ek karmaşıklık karşılığında özel bir AKS kümesi sağlayabilirsiniz. Özel küme kullanarak, API sunucunuzla düğüm havuzlarınız arasındaki ağ trafiğinin yalnızca özel ağda kaldığından, İnternet'te gösterilmediğinden emin olabilirsiniz. Daha fazla bilgi için bkz . AKS Özel Kümeleri.

Gizli dizi yönetimi ekleyin

Gizli dizileri Azure Key Vault gibi yönetilen bir anahtar deposunda depolayın. Bunun avantajı, yönetilen deponun gizli dizilerin döndürüldüğünü işlemesi, güçlü şifreleme sağlaması, erişim denetim günlüğü sağlaması ve çekirdek gizli dizileri dağıtım işlem hattı dışında tutmasıdır. Bu mimaride, Azure Key Vault güvenlik duvarı azure'da gizli dizilere ve sertifikalara erişmesi gereken kaynaklara yönelik özel bağlantı bağlantılarıyla etkinleştirilir ve yapılandırılır.

Azure Key Vault, diğer Azure hizmetleriyle iyi tümleştirilmiştir. Gizli dizilere erişmek için bu hizmetlerin yerleşik özelliğini kullanın. Azure Uygulaması lication Gateway'in giriş akışı için TLS sertifikalarına nasıl eriştiği hakkında bir örnek için Giriş trafik akışı bölümüne bakın.

Key Vault için Azure RBAC izin modeli, iş yükü kimliklerini Key Vault Gizli Dizileri Kullanıcısı veya Key Vault Okuyucusu rol atamasına atamanıza ve gizli dizilere erişmenize olanak tanır. Daha fazla bilgi için bkz . RBAC kullanarak Azure Key Vault'a erişme.

Küme gizli dizilerine erişme

Podların belirli bir depodan gizli dizilere erişmesine izin vermek için iş yükü kimliklerini kullanmanız gerekir. Alma işlemini kolaylaştırmak için Gizli Dizi Deposu CSI sürücüsü kullanın. Pod bir gizli diziye ihtiyaç duyduğunda, sürücü belirtilen depoya bağlanır, bir birimde gizli diziyi alır ve bu birimi kümeye bağlar. Pod daha sonra birim dosya sisteminden gizli diziyi alabilir.

CSI sürücüsünün çeşitli yönetilen depoları desteklemek için birçok sağlayıcısı vardır. Bu uygulamada, Azure Key Vault'tan TLS sertifikasını almak ve giriş denetleyicisini çalıştıran pod'a yüklemek için eklentiyi kullanarak Gizli Dizi deposu CSI Sürücüsü ile Azure Key Vault'un seçilmesini sağladık. Pod oluşturma sırasında yapılır ve birim hem genel hem de özel anahtarları depolar.

İş yükü depolama

Bu mimaride kullanılan iş yükü durum bilgisi yok. Durumu depolamanız gerekiyorsa kümenin dışında kalıcı hale getirmek önerilir. İş yükü durumu kılavuzu bu makalenin kapsamı dışındadır.

Depolama seçenekleri hakkında daha fazla bilgi edinmek için bkz. Azure Kubernetes Service'te (AKS) uygulamalar için Depolama seçenekleri.

İlke yönetimi

AKS kümesini yönetmenin etkili bir yolu, ilkeler aracılığıyla idareyi zorlamaktır. Kubernetes, OPA Gatekeeper aracılığıyla ilkeler uygular. AKS için ilkeler Azure İlkesi aracılığıyla sunulur. Her ilke, kapsamındaki tüm kümelere uygulanır. Azure İlkesi zorlama sonunda kümedeki OPA Gatekeeper tarafından işlenir ve tüm ilke denetimleri günlüğe kaydedilir. İlke değişiklikleri kümenize hemen yansıtılmaz, bazı gecikmeler görmeyi bekler.

AKS kümelerinizi yönetmek için Azure İlkesi iki farklı senaryo sunar:

• Kuruluşunuzun standartlarını değerlendirerek bir kaynak grubu veya abonelikte AKS kümelerinin dağıtımını engelleme veya kısıtlama. Örneğin, bir adlandırma kuralını izleyin, etiket belirtin vb.
• Kubernetes için Azure İlkesi aracılığıyla AKS kümenizin güvenliğini sağlayın.

İlkeleri ayarlarken iş yükünün gereksinimlerine göre uygulayın. Şu faktörleri göz önünde bulundurun:

• İlke koleksiyonu (girişimler olarak adlandırılır) ayarlamak mı yoksa tek tek ilkeler mi seçmek istiyorsunuz? Azure İlkesi iki yerleşik girişim sağlar: temel ve kısıtlı. Her girişim, AKS kümesi için geçerli olan yerleşik ilkelerden oluşan bir koleksiyondur. Kuruluşunuzun gereksinimlerine göre kümeyle etkileşim kuran küme ve kaynaklar (ACR, Application Gateway, Key Vault ve diğerleri) için bir girişim seçmeniz ve ek ilkeler seçmeniz önerilir.

• Eylemi denetlemek veya reddetmek istiyor musunuz? Denetim modunda, eyleme izin verilir ancak Uyumlu Değil olarak işaretlenir. Uyumlu olmayan durumları düzenli aralıklarla denetlemek ve gerekli işlemleri yapmak için süreçlere sahip olun. Reddetme modunda, ilkeyi ihlal ettiği için eylem engellenir. İş yükünün çalışması çok kısıtlayıcı olabileceğinden bu modu seçerken dikkatli olun.

• İş yükünüzde tasarım gereği uyumlu olmaması gereken alanlarınız var mı? Azure İlkesi, ilke zorlamasından muaf olan Kubernetes ad alanlarını belirtme özelliğine sahiptir. Bu örneklerin farkında olmanız için denetim modunda ilkeler uygulamaya devam etmeniz önerilir.

• Yerleşik ilkeler kapsamında olmayan gereksinimleriniz var mı? Özel OPA Ağ Geçidi Denetleyicisi ilkelerinizi uygulayan özel bir Azure İlkesi tanımı oluşturabilirsiniz. Özel ilkeleri doğrudan kümeye uygulamayın. Özel ilke oluşturma hakkında daha fazla bilgi edinmek için bkz . Özel ilke tanımları oluşturma ve atama.

• Kuruluş genelinde gereksinimleriniz var mı? Öyleyse, bu ilkeleri yönetim grubu düzeyinde ekleyin. Kuruluşunuzun genel ilkeleri olsa bile kümenizin kendi iş yüküne özgü ilkeleri de ataması gerekir.

• Azure ilkeleri belirli kapsamlara atanır. Üretim ilkelerinin üretim öncesi ortamınızda da doğrulandığından emin olun. Aksi takdirde üretim ortamınıza dağıtım yaparken, üretim öncesi ortamda hesaba katılmayan beklenmeyen ek kısıtlamalarla karşılaşabilirsiniz.

Bu başvuru uygulamasında, AKS kümesi oluşturulduğunda Azure İlkesi etkinleştirilir ve uyumsuzluğa görünürlük sağlamak için Denetim modunda kısıtlayıcı girişimi atar.

Uygulama ayrıca yerleşik girişimlerin parçası olmayan ek ilkeler de ayarlar. Bu ilkeler Reddetme modunda ayarlanır. Örneğin, görüntülerin yalnızca dağıtılan ACR'den çekildiğinden emin olmak için bir ilke vardır. Kendi özel girişimlerinizi oluşturmayı göz önünde bulundurun. İş yükünüz için geçerli olan ilkeleri tek bir atamada birleştirin.

Azure İlkesi kümenizin içinden nasıl çalıştığını gözlemlemek için, ad alanı içindeki gatekeeper-system tüm podların pod günlüklerine ve ad alanı içindeki kube-system podların azure-policy-webhook günlüklerine azure-policy erişebilirsiniz.

AKS temel başvuru mimarisindeki Windows kapsayıcılarında yer alan Windows'a özgü Azure İlkesi konuları gözden geçirmek için yardımcı makaleye bakın.

Düğüm ve pod ölçeklenebilirliği

Talebin artmasıyla Kubernetes, yatay pod otomatik ölçeklendirme (HPA) aracılığıyla mevcut düğümlere daha fazla pod ekleyerek ölçeği genişletebilir. Ek podlar artık zamanlanmadığında, AKS kümesi otomatik ölçeklendirmesi aracılığıyla düğüm sayısı artırılmalıdır. Eksiksiz bir ölçeklendirme çözümünün hem pod çoğaltmalarını hem de kümedeki düğüm sayısını ölçeklendirme yolları olmalıdır.

İki yaklaşım vardır: otomatik ölçeklendirme veya el ile ölçeklendirme.

El ile veya programlı yöntem, CPU kullanımı veya özel ölçümler hakkında uyarılar izlemenizi ve ayarlamanızı gerektirir. Pod ölçeklendirme için uygulama operatörü Kubernetes API'leri aracılığıyla ayarlayarak ReplicaSet pod çoğaltmalarının sayısını artırabilir veya azaltabilir. Küme ölçeklendirme için bir yol, Kubernetes zamanlayıcı başarısız olduğunda bildirim almaktır. Bir diğer yol da bekleyen podları zaman içinde izlemektir. Düğüm sayısını Azure CLI veya portal aracılığıyla ayarlayabilirsiniz.

Bu el ile gerçekleştirilen mekanizmalardan bazıları otomatik ölçeklendiricide yerleşik olduğundan, önerilen yaklaşım otomatik ölçeklendirmedir.

Genel bir yaklaşım olarak, en az sayıda pod ve düğümle performans testi yaparak başlayın. Temel beklentiyi oluşturmak için bu değerleri kullanın. Ardından performans sorunlarını bulmak ve uygulamanın ölçeklendirmeye verdiği yanıtı anlamak için performans ölçümlerinin ve el ile ölçeklendirmenin bir bileşimini kullanın. Son olarak, otomatik ölçeklendirme parametrelerini ayarlamak için bu verileri kullanın. AKS kullanan bir performans ayarlama senaryosu hakkında bilgi için bkz . Performans ayarlama senaryosu: Dağıtılmış iş işlemleri.

Yatay Pod Otomatik Ölçeklendiricisi

Yatay Pod Otomatik Ölçeklendiricisi (HPA), pod sayısını ölçeklendirin bir Kubernetes kaynağıdır.

HPA kaynağında en düşük ve en yüksek çoğaltma sayısının ayarlanması önerilir. Bu değerler otomatik ölçeklendirme sınırlarını kısıtlar.

HPA, CPU kullanımına, bellek kullanımına ve özel ölçümlere göre ölçeklendirilebilir. Kutudan yalnızca CPU kullanımı sağlanır. HorizontalPodAutoscaler tanımı, bu ölçümler için hedef değerleri belirtir. Örneğin, belirtim bir hedef CPU kullanımı ayarlar. Podlar çalışırken HPA denetleyicisi, her pod'un CPU kullanımını denetlemek için Kubernetes Metrics API'sini kullanır. Bu değeri hedef kullanımla karşılaştırır ve bir oran hesaplar. Daha sonra podların fazla yüklenmiş mi yoksa az mı ayrılmış olduğunu belirlemek için oranı kullanır. Düğümlere yeni podlar atamak veya düğümlerden podları kaldırmak için Kubernetes zamanlayıcısını kullanır.

Ölçeklendirme işlemi tamamlanmadan önce (HPA) tarafından kontrol edilen bir yarış durumu olabilir. Sonuç yanlış bir oran hesaplaması olabilir. Ayrıntılar için bkz . Ölçeklendirme olaylarının bekleme süresi.

İş yükünüz olay odaklıysa, popüler bir açık kaynak seçeneği KEDA'dır. İş yükünüz CPU veya belleğe bağlı olmak yerine ileti kuyruğu gibi bir olay kaynağı tarafından yönlendiriliyorsa KEDA'yı göz önünde bulundurun. KEDA birçok olay kaynağını (veya ölçekleyiciyi) destekler. Azure İzleyici ölçeklendiricisi de dahil olmak üzere desteklenen KEDA ölçeklendiricilerinin listesini burada bulabilirsiniz. Bu, KEDA iş yüklerini Azure İzleyici ölçümlerine göre ölçeklendirmenin kullanışlı bir yoludur.

Küme otomatik ölçeklendiricisi

Küme otomatik ölçeklendiricisi , bir düğüm havuzundaki düğüm sayısını ölçeklendirin bir AKS eklentisi bileşenidir. Küme sağlama sırasında eklenmelidir. Her kullanıcı düğümü havuzu için ayrı bir küme otomatik ölçeklendiricisi gerekir.

Küme otomatik ölçeklendiricisi Kubernetes zamanlayıcı tarafından tetiklenir. Kubernetes zamanlayıcı kaynak kısıtlamaları nedeniyle bir pod zamanlayamazsa, otomatik ölçeklendirici düğüm havuzunda otomatik olarak yeni bir düğüm sağlar. Buna karşılık, küme otomatik ölçeklendiricisi düğümlerin kullanılmayan kapasitesini denetler. Düğüm beklenen kapasitede çalışmıyorsa podlar başka bir düğüme taşınır ve kullanılmayan düğüm kaldırılır.

Otomatik ölçeklendiriciyi etkinleştirdiğinizde en yüksek ve en düşük düğüm sayısını ayarlayın. Önerilen değerler iş yükünün performans beklentisine, kümenin ne kadar büyümesini istediğinize ve maliyet etkilerine bağlıdır. En düşük sayı, bu düğüm havuzu için ayrılmış kapasitedir. Bu başvuru uygulamasında, iş yükünün basit yapısı nedeniyle minimum değer 2 olarak ayarlanır.

Sistem düğümü havuzu için önerilen en düşük değer 3'dür.

AKS temel başvuru mimarisinde Windows kapsayıcılarına dahil edilen ölçeklendirme konularını gözden geçirmek için yardımcı makaleye bakın.

İş sürekliliği kararları

İş sürekliliğini korumak için altyapı ve uygulamanız için Hizmet Düzeyi Sözleşmesi'ni tanımlayın. Aylık çalışma süresi hesaplaması hakkında bilgi için bkz . Azure Kubernetes Service (AKS) için SLA.

Küme düğümleri

İş yüklerinin en düşük kullanılabilirlik düzeyini karşılamak için düğüm havuzundaki birden çok düğüm gereklidir. Bir düğüm devre dışı kalırsa, aynı kümedeki düğüm havuzundaki başka bir düğüm uygulamayı çalıştırmaya devam edebilir. Güvenilirlik için sistem düğümü havuzu için üç düğüm önerilir. Kullanıcı düğümü havuzu için en az iki düğümle başlayın. Daha yüksek kullanılabilirliğe ihtiyacınız varsa daha fazla düğüm sağlayın.

Uygulamalarınızı, kullanıcı düğümü havuzu olarak adlandırılan ayrı bir düğüm havuzuna yerleştirerek sistem hizmetlerinden yalıtın. Bu şekilde Kubernetes hizmetleri ayrılmış düğümlerde çalışır ve iş yükünüzle rekabet etmez. İş yükünüzü zamanlamak için düğüm havuzunu tanımlamak ve sistem düğüm havuzunuzun CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools) ile boyandığından emin olmak için etiketlerin, etiketlerin ve renk tonlarının kullanılması önerilir.

Kümenizin zamanında güncelleştirmeler gibi düzenli bakımları güvenilirlik açısından çok önemlidir. Ayrıca yoklamalar aracılığıyla podların durumunun izlenmesi önerilir.

Pod kullanılabilirliği

Pod kaynaklarının olduğundan emin olun. Dağıtımların pod kaynak gereksinimlerini belirtmesi kesinlikle önerilir. Zamanlayıcı daha sonra uygun şekilde pod zamanlayabilir. Podlar zamanlanamıyorsa güvenilirlik önemli ölçüde kullanımdan kaldırılacaktır.

Pod kesintisi bütçelerini ayarlayın. Bu ayar, bir güncelleştirme veya yükseltme olayı sırasında dağıtımda kaç çoğaltmanın gelebileceğini belirler. Daha fazla bilgi için bkz . Pod kesintisi bütçeleri.

Donanım hataları gibi kesintileri işlemek için dağıtımda birden çok çoğaltma yapılandırın. Güncelleştirmeler ve yükseltmeler gibi planlı olaylar için kesinti bütçesi, beklenen uygulama yükünü işlemek için gerekli sayıda pod çoğaltmasının mevcut olduğundan emin olabilir.

İş yükü ad alanları üzerinde kaynak kotaları ayarlayın. Bir ad alanı üzerindeki kaynak kotası, pod isteklerinin ve sınırlarının dağıtımda düzgün şekilde ayarlanmasını sağlar. Daha fazla bilgi için bkz . Kaynak kotalarını zorlama.

Pod isteklerini ve sınırlarını ayarlayın. Bu sınırların ayarlanması Kubernetes'in podlara verimli bir şekilde CPU ve/veya bellek kaynakları ayırmasını ve bir düğümde daha yüksek kapsayıcı yoğunluğuna sahip olmasını sağlar. Sınırlar, daha iyi donanım kullanımı nedeniyle düşük maliyetlerle güvenilirliği de artırabilir.

Sınırları tahmin etmek için bir taban çizgisi sınayın ve oluşturun. İstekler ve sınırlar için eşit değerlerle başlayın. Ardından, kümede istikrarsızlığa neden olabilecek bir eşik oluşturana kadar bu değerleri aşamalı olarak ayarlayın.

Bu sınırlar dağıtım bildirimlerinizde belirtilebilir. Daha fazla bilgi için bkz . Pod isteklerini ve sınırlarını ayarlama.

Kullanılabilirlik alanları ve çok bölgeli destek

SLA'nız daha yüksek çalışma süresi gerektiriyorsa kullanılabilirlik alanlarını kullanarak kesintilere karşı koruma sağlayın. Bölge bunları destekliyorsa kullanılabilirlik alanlarını kullanabilirsiniz. Ardından hem denetim düzlemi bileşenleri hem de düğüm havuzlarındaki düğümler bölgelere yayılabilir. Bölgenin tamamı kullanılamıyorsa, bölge içindeki başka bir bölgedeki bir düğüm kullanılabilir durumda kalır. Her düğüm havuzu, düğüm örneklerini ve ölçeklenebilirliği yöneten ayrı bir Sanal Makine Ölçek Kümesine eşlenir. Ölçek kümesi işlemleri ve yapılandırması AKS hizmeti tarafından yönetilir. Çoklu dilimi etkinleştirirken dikkat edilmesi gereken bazı noktalar şunlardır:

• Tüm altyapı. Kullanılabilirlik alanlarını destekleyen bir bölge seçin. Daha fazla bilgi için bkz . Sınırlamalar ve bölge kullanılabilirliği. Çalışma Süresi SLA'sı satın almak istiyorsanız bu seçeneği destekleyen bir bölge seçin. Kullanılabilirlik alanları kullanılırken Çalışma Süresi SLA'sı daha büyüktür.

• Küme. Kullanılabilirlik alanları yalnızca düğüm havuzu oluşturulduğunda ayarlanabilir ve daha sonra değiştirilemez. Beklenen dağıtımın mümkün olması için düğüm boyutları tüm bölgelerde desteklenmelidir. Temel alınan Sanal Makine Ölçek Kümesi, bölgeler arasında aynı donanım yapılandırmasını sağlar.

  Çok bölgeli destek yalnızca düğüm havuzları için değil, aynı zamanda kontrol düzlemi için de geçerlidir. AKS denetim düzlemi, düğüm havuzları gibi istenen bölgelere yayılacaktır. Kümenizde bölge desteği kullanmıyorsanız, denetim düzlemi bileşenlerinin kullanılabilirlik alanlarına yayılması garanti edilmemektedir.

• Bağımlı kaynaklar. Tüm bölgesel avantaj için tüm hizmet bağımlılıklarının bölgeleri de desteklemesi gerekir. Bağımlı bir hizmet bölgeleri desteklemiyorsa, bölge hatası bu hizmetin başarısız olmasına neden olabilir.

Örneğin, yönetilen disk, sağlandığı bölgede kullanılabilir. Bir hata durumunda düğüm başka bir bölgeye taşınabilir, ancak yönetilen disk düğümle bu bölgeye taşınmaz.

Kolaylık olması için bu mimaride AKS, kullanılabilirlik alanları 1, 2 ve 3'e yayılan düğüm havuzlarına sahip tek bir bölgeye dağıtılır. Altyapının Azure Güvenlik Duvarı ve Application Gateway gibi diğer kaynakları da çok bölgeli destekle aynı bölgeye dağıtılır. Azure Container Registry için coğrafi çoğaltma etkinleştirilir.

Birden çok bölge

Tüm bölge çökerse kullanılabilirlik alanlarının etkinleştirilmesi yeterli olmaz. Daha yüksek kullanılabilirliğe sahip olmak için farklı bölgelerde birden çok AKS kümesi çalıştırın.

• Eşleştirilmiş bölgeleri kullanın. Bölge hatalarından kurtarmak için eşleştirilmiş bölge kullanmak üzere yapılandırılmış bir CI/CD işlem hattı kullanmayı göz önünde bulundurun. Eşleştirilmiş bölgeleri kullanmanın bir avantajı, güncelleştirmeler sırasında güvenilirliktir. Azure, aynı anda çiftteki yalnızca bir bölgenin güncelleştirilmesini sağlar. Flux gibi bazı DevOps araçları çok bölgeli dağıtımları kolaylaştırabilir.

• Azure kaynağı coğrafi olarak yedekliliği destekliyorsa, yedekli hizmetin ikincil hizmeti olacağı konumu belirtin. Örneğin, Azure Container Registry için coğrafi çoğaltmayı etkinleştirmek resimleri seçili Azure bölgelerine otomatik olarak çoğaltır ve bir bölgede kesinti yaşansa bile görüntülere sürekli erişim sağlar.

• Gereksinimlerinize bağlı olarak trafiği bölgeler veya bölgeler arasında dağıtabilecek bir trafik yönlendiricisi seçin. Bu mimari, web dışı trafiği bölgeler arasında dağıtabildiğinden Azure Load Balancer'ı dağıtır. Trafiği bölgeler arasında dağıtmanız gerekiyorsa Azure Front Door dikkate alınmalıdır. Diğer önemli noktalar için bkz . Yük dengeleyici seçme.

Olağanüstü durum kurtarma

Birincil bölgede hata olması durumunda, başka bir bölgede hızla yeni bir örnek oluşturabilmeniz gerekir. İşte birkaç öneri:

• Eşleştirilmiş bölgeleri kullanın.

• Durum bilgisi olmayan bir iş yükü verimli bir şekilde çoğaltılabilir. Kümede durum depolamanız gerekiyorsa (önerilmez), eşleştirilmiş bölgede verileri sık sık yedeklediğinizden emin olun.

• Hizmet Düzeyi Hedeflerinizi (SLO) karşılamak için DevOps işlem hattının bir parçası olarak başka bir bölgeye çoğaltma gibi kurtarma stratejisini tümleştirin.

• Her Azure hizmetini sağlarken olağanüstü durum kurtarmayı destekleyen özellikleri seçin. Örneğin, bu mimaride Azure Container Registry coğrafi çoğaltma için etkinleştirilmiştir. Bir bölge devre dışı kalırsa yine de çoğaltılan bölgeden görüntü çekebilirsiniz.

Küme yedekleme

Birçok mimaride, yeni bir küme sağlama ve kümeyi işletim durumuna döndürme işlemleri GitOps tabanlı [Küme önyüklemesi}(#cluster-bootstrapping) ve ardından uygulama dağıtımı aracılığıyla gerçekleştirilebilir. Ancak, yapılandırma eşlemeleri, işler ve gizli diziler gibi bazı nedenlerden dolayı önyükleme işleminizde yakalanamaz gibi kritik kaynak durumu varsa kurtarma stratejinizi göz önünde bulundurun. Kubernetes'te durum bilgisi olmayan iş yüklerinin çalıştırılması genellikle önerilir, ancak mimariniz disk tabanlı durum içeriyorsa bu içerik için kurtarma stratejinizi de göz önünde bulundurmanız gerekir.

Küme yedeklemesinin kurtarma stratejinizin bir parçası olması gerektiğinde, küme içindeki iş gereksinimlerinizle eşleşen bir çözüm yüklemeniz gerekir. Bu aracı, küme kaynak durumunu seçtiğiniz bir hedefe göndermekten ve Azure Disk tabanlı kalıcı birim anlık görüntülerini koordine etmekten sorumludur.

VMware'in Velero's , doğrudan yükleyip yönetebildiğiniz yaygın bir Kubernetes yedekleme çözümü örneğidir. Alternatif olarak, AKS yedekleme uzantısı yönetilen bir Velero uygulaması sağlamak için kullanılabilir. AKS yedekleme uzantısı, Azure Backup'ta kasa yapılandırması olarak dışlanmış zamanlamalar ve yedekleme kapsamı ile hem Kubernetes kaynaklarını hem de kalıcı birimleri yedeklemeyi destekler.

Başvuru uygulaması yedekleme uygulamaz; bu da mimaride yönetmek, izlemek, ödeme yapmak ve güvenliğini sağlamak için ek Azure kaynakları içerir; Azure Depolama hesabı, Azure Backup kasası ve yapılandırması ve Güvenilen Erişim gibi. GitOps, durum bilgisi olmayan iş yükünü çalıştırma amacı ile birlikte uygulanan kurtarma çözümüdür.

Tanımlı kurtarma noktası hedefiniz (RPO) ve kurtarma süresi hedefiniz (RTO) dahil olmak üzere iş hedefinize uygun bir çözüm seçin ve doğrulayın. Bu kurtarma işlemini bir ekip runbook'unda tanımlayın ve iş açısından kritik tüm iş yükleri için uygulayın.

Kubernetes API Sunucusu SLA'sı

AKS ücretsiz hizmet olarak kullanılabilir, ancak bu katman finansal olarak destekli bir SLA sunmaz. Bu SLA'yı edinmek için Standart katman'ı seçmeniz gerekir. Tüm üretim kümelerinin Standart katmanı kullanmasını öneririz. Üretim öncesi kümeler için Ücretsiz katman kümeleri ayırın. Azure Kullanılabilirlik Alanları ile birleştirildiğinde Kubernetes API sunucusu SLA'sı %99,95'e çıkarılır. Düğüm havuzlarınız ve diğer kaynaklar kendi SLA'ları kapsamındadır.

Tradeoff

Mimariyi bölgelere ve özellikle bölgelere dağıtmak için kullanılabilirlik maliyeti dengelemesi vardır. Azure Container Registry'de coğrafi çoğaltma gibi bazı çoğaltma özellikleri daha pahalı olan premium SKU'larda kullanılabilir. Trafik bölgeler ve bölgeler arasında hareket ettiğinde uygulanan bant genişliği ücretleri nedeniyle maliyet de artar.

Ayrıca bölgeler veya bölgeler arasındaki düğüm iletişiminde ek ağ gecikmesi olmasını da bekleyebilirsiniz. Bu mimari kararın iş yükünüz üzerindeki etkisini ölçün.

Simülasyonlar ve zorlamalı yük devretme işlemleriyle test etme

Düğümü durdurma, bölgesel hata benzetimi yapmak için belirli bir bölgedeki tüm AKS kaynaklarını azaltma veya dış bağımlılık hatası çağırma gibi sanal kesintilerle zorlamalı yük devretme testi ile güvenilirliği sağlayın. Azure Chaos Studio, Azure'da ve kümede çeşitli kesinti türlerinin benzetimini yapmak için de kullanılabilir.

Daha fazla bilgi için bkz . Azure Chaos Studio.

Ölçümleri izleme ve toplama

Azure İzleyici Kapsayıcı içgörüleri , olayları gerçek zamanlı olarak görüntüleyebildiğiniz için kapsayıcı iş yüklerinin performansını izlemek için önerilen araçtır. Çalışan podlardan kapsayıcı günlüklerini yakalar ve görüntülemek üzere toplar. Ayrıca çalışan kaynakların ve iş yüklerinin durumunu izlemek için Ölçümler API'sinden bellek ve CPU kullanımı hakkında bilgi toplar. Podlar ölçeklendirildikçe performansı izlemek için de kullanabilirsiniz. Bu, eğilimleri belirlemek için toplanan verilerin izlenmesi, analiz edilmesi ve görselleştirmesi için kritik telemetri verilerinin toplanmasını ve kritik sorunlardan proaktif olarak bildirilecek şekilde uyarıların yapılandırılmasını içerir.

Podlarda barındırılan iş yüklerinin çoğu Prometheus ölçümlerini gösterir. Kapsayıcı içgörüleri, düğümlerden ve Kubernetes'ten topladığı uygulama ve iş yükü ölçümlerini görüntülemek için Prometheus ile tümleştirme yapabilir.

Kuruluşunuzda zaten kullanılıyorsa, Kubernetes ile tümleştirilebilen Datadog, Grafana veya New Relic gibi bazı üçüncü taraf çözümler vardır.

AKS ile Azure bazı temel Kubernetes hizmetlerini yönetir ve AKS denetim düzlemi bileşenlerinin günlükleri Azure'da kaynak günlükleri olarak uygulanır. Küme sorunlarını gidermenize ve nispeten düşük günlük yoğunluğuna sahip olmanıza yardımcı olabileceğinden çoğu kümenin her zaman aşağıdakileri etkinleştirmesi önerilir:

• Ölçeklendirme işlemlerinde gözlemlenebilirlik kazanmak için ClusterAutoscaler'da günlüğe kaydetme. Daha fazla bilgi için bkz . Küme otomatik ölçeklendiricisi günlüklerini ve durumunu alma.
• KubeControllerManager , Kubernetes ile Azure denetim düzlemi arasındaki etkileşime gözlemlenebilirlik sağlar.
• KubeAudit Yönetici kümenizi değiştiren etkinliklerde gözlemlenebilir olması. Hem KubeAudit hem de KubeAudit'in etkinleştirilmesi için bir neden yoktur Yönetici çünkü KubeAudit, değiştirme (okuma) olmayan işlemleri de içeren bir KubeAudit Yönetici üst kümesidir.
• Guard , Microsoft Entra Id ve Azure RBAC denetimlerini yakalar.

KubeScheduler veya KubeAudit gibi diğer günlük kategorileri, küme otomatik ölçeklendirme, pod yerleştirme ve zamanlama gibi ek verilerin küme veya iş yükü işlemleriyle ilgili sorunları gidermeye yardımcı olabileceği erken küme veya iş yükü yaşam döngüsü geliştirme sırasında etkinleştirme konusunda çok yararlı olabilir. Sorun giderme gereksinimleri sona erdikten sonra genişletilmiş sorun giderme günlüklerini tam zamanlı olarak tutmak, Azure İzleyici'yi almak ve depolamak için gereksiz bir maliyet olarak kabul edilebilir.

Azure İzleyici başlangıç olarak mevcut günlük sorguları kümesine sahip olsa da, bunları kendi sorgularınızı oluşturmanıza yardımcı olmak için temel olarak da kullanabilirsiniz. Kitaplığınız büyüdükçe, bir veya daha fazla sorgu paketi kullanarak günlük sorgularını kaydedebilir ve yeniden kullanabilirsiniz. Özel sorgu kitaplığınız AKS kümelerinizin sistem durumu ve performansında ek gözlemlenebilirlik sağlamaya yardımcı olur ve hizmet düzeyi hedeflerinizi (SLO' lar) destekler.

AKS için izleme en iyi yöntemlerimiz hakkında daha fazla bilgi için bkz . Azure İzleyici ile Azure Kubernetes Service'i (AKS) izleme.

AKS temel başvuru mimarisinde Windows kapsayıcılarına dahil edilen Windows'a özgü izleme konularını gözden geçirmek için yardımcı makaleye bakın.

Kendi kendini iyileştirmeyi etkinleştirme

Canlılık ve Hazırlık yoklamaları ayarlayarak podların durumunu izleyin. Yanıt vermeyen bir pod algılanırsa Kubernetes podu yeniden başlatır. Canlılık araştırması podun iyi durumda olup olmadığını belirler. Yanıt vermezse Kubernetes podu yeniden başlatır. Hazır olma yoklaması, podun istekleri/trafiği almaya hazır olup olmadığını belirler.

AKS kümesi güncelleştirmeleri

İş gereksinimleriyle tutarlı bir güncelleştirme stratejisi tanımlamak çok önemlidir. AKS kümesi sürümünün veya düğümlerinin güncelleştirileceği tarih ve saat için öngörülebilirlik düzeyini ve belirli görüntü veya ikili dosyaların yüklenişi üzerinde istenen denetim derecesini anlamak, AKS kümesi güncelleştirme şemanızı gösteren temel unsurlardır. Tahmin edilebilirlik, güncelleştirme temposu ve bakım penceresi olan iki ana AKS kümesi güncelleştirme özelliğine bağlıdır. Denetim, güncelleştirmelerin el ile mi yoksa otomatik olarak mı yükleneceğidir. Katı bir güvenlik düzenlemesi kapsamında olmayan AKS kümelerine sahip kuruluşlar haftalık ve hatta aylık güncelleştirmeleri göz önünde bulundurabilirken, geri kalanın güvenlik etiketli düzeltme eklerini en kısa sürede (günlük) güncelleştirmeleri gerekir. AKS kümelerini sabit altyapı olarak çalıştıran kuruluşlar bunları güncelleştirmiyor. Bu, otomatik veya el ile güncelleştirmelerin gerçekleştirilmediğinden anlamına gelir. Bunun yerine, istenen bir güncelleştirme kullanılabilir olduğunda bir çoğaltma damgası dağıtılır ve yalnızca yeni altyapı örneği hazır olduğunda eskisi boşaltılır ve en yüksek denetim düzeyi sağlanır.

AKS kümesi güncelleştirme şeması belirlendikten sonra, aks düğümleri ve AKS kümesi sürümü için kullanılabilir güncelleştirme seçenekleriyle kolayca eşlenebilir:

• AKS düğümleri:

  1. Yok/El ile güncelleştirmeler: Bu, sabit altyapı için veya el ile yapılan güncelleştirmeler tercih edilir. Bu, AKS düğümleri güncelleştirmeleri üzerinde daha yüksek düzeyde tahmin edilebilirlik ve denetim sağlar.
  2. Otomatik Katılımsız güncelleştirmeler: AKS yerel işletim sistemi güncelleştirmelerini yürütür. Bu, işletme için iyi olanlarla uyumlu bakım pencerelerini yapılandırarak öngörülebilirlik sağlar. Yoğun saatleri ve operasyon açısından en iyi olanı temel alabilir. Aks düğümünde özel olarak nelerin yükleneceğini önceden bilmek mümkün olmadığından denetim düzeyi düşüktür.
  3. Otomatik Düğüm görüntüsü güncelleştirmeleri: Yeni sanal sabit diskler (VHD) kullanılabilir olduğunda AKS düğümü görüntülerinin otomatik olarak güncelleştirilmiş olması önerilir. Bakım pencerelerini iş gereksinimleriyle mümkün olduğunca uyumlu olacak şekilde tasarlayın. Güvenlik etiketli VHD güncelleştirmeleri için en düşük tahmin edilebilirliği sağlayan günlük bakım pencerelerinin yapılandırılması önerilir. Normal VHD güncelleştirmeleri, her iki haftada bir, hatta aylık olarak haftalık bakım penceresiyle yapılandırılabilir. Zamanlanmış bakım penceresiyle birlikte güvenlik etiketli ve normal VHD'ler için gerekli olup olmadığına bağlı olarak, tahmin edilebilirlik dalgalanmaları iş gereksinimleriyle uyumlu hale getirilebilmek için daha fazla veya daha az esneklik sunar. Bunu her zaman iş gereksinimlerine bırakmak ideal olsa da, gerçeklik kuruluşların bahşiş noktasını bulmalarını zorunlu bırakır. Yeni bir VHD'ye hangi ikili dosyaların dahil olduğunu önceden bilmek mümkün olmadığından denetim düzeyi düşüktür ve yine de bu tür otomatik güncelleştirmeler önerilir, çünkü görüntüler kullanıma sunulmadan önce izlenir.

  Not

  Otomatik AKS düğümleri güncelleştirmelerini yapılandırma hakkında daha fazla bilgi için lütfen Otomatik yükseltme düğümü işletim sistemi görüntülerine göz atın.

• AKS kümesi sürümü:

  1. Yok/El ile güncelleştirmeler: Bu, sabit altyapı için veya el ile yapılan güncelleştirmeler tercih edilir. Bu, AKS kümesi sürüm güncelleştirmeleri üzerinde daha yüksek düzeyde tahmin edilebilirlik ve denetim sağlar. Üretime geçmeden önce daha düşük ortamlarda yeni bir AKS kümesi sürümünü (örneğin 1.14.x - 1.15.x) test etme şansı veren tam denetime sahip olduğundan, bunun için katılım önerilir.
  2. Otomatik güncelleştirmeler: Bir üretim kümesinin, düşük ortamlarda düzgün bir şekilde test edilmeden kullanılabilir yeni AKS kümesi sürümüne herhangi bir şekilde (1.16.x ile 1.16.y) otomatik olarak yamalanması veya güncelleştirilmesi önerilmez. Kubernetes yukarı akış sürümleri ve AKS kümesi sürüm güncelleştirmeleri düzenli bir tempoyla eşgüdümlü olsa da, yine de tahmin edilebilirliği ve güncelleştirme işlemi üzerindeki denetimi artıran üretimdeki AKS kümelerine karşı savunma yapılması önerilmektedir. Operasyonel Mükemmellik'in bir parçası olarak düşük ortamlar için bu yapılandırmayı göz önünde bulundurarak olası sorunları mümkün olan en erken şekilde algılamak için proaktif rutin test yürütmelerine olanak tanır.

Desteklenen N-2 sürümleriyle Kubernetes sürümünü güncel tutun. Yeni sürümler sık sık yayınlandığından Kubernetes'in en son sürümüne yükseltmek kritik önem taşır.

Daha fazla bilgi için bkz . Kubernetes'in en son sürümüne düzenli olarak güncelleştirme ve Azure Kubernetes Service (AKS) kümesini yükseltme.

Kümeniz için yeni AKS sürümü kullanılabilirliği gibi kümeniz tarafından tetiklenen olayların bildirimi, Azure Event Grid için AKS Sistem Konusu aracılığıyla elde edilebilir. Başvuru uygulaması, olay akışı bildirim çözümünüzden olaya abone olabilmeniz için Microsoft.ContainerService.NewKubernetesVersionAvailable bu Event Grid Sistem Konusunu dağıtır.

Haftalık güncelleştirmeler

AKS, en son işletim sistemi ve çalışma zamanı güncelleştirmelerine sahip yeni düğüm görüntüleri sağlar. Bu yeni görüntüler otomatik olarak uygulanmaz. Görüntülerin ne sıklıkta güncelleştirilmesi gerektiğine karar vermek sizin sorumluluğundadır. Düğüm havuzlarınızın temel görüntüsünü haftalık olarak yükseltme işleminiz olması önerilir. Daha fazla bilgi için bkz. Azure Kubernetes Service (AKS) düğümü görüntüsünü AKS Sürüm Notları'nı yükseltme.

Günlük güncelleştirmeler

Görüntü yükseltmeleri arasında AKS düğümleri işletim sistemi ve çalışma zamanı düzeltme eklerini tek tek indirip yükler. Yükleme, düğüm VM'lerinin yeniden başlatılmasını gerektirebilir. BEKLEYEN güncelleştirmeler nedeniyle AKS düğümleri yeniden başlatmaz. Yeniden başlatma gerektiren ve bu düğümlerin yeniden başlatılmasını denetimli bir şekilde gerçekleştiren uygulanan güncelleştirmeler için düğümleri izleyen bir işleme sahip olun. Açık kaynak seçeneği Kured 'dir (Kubernetes yeniden başlatma daemon'ı).

Düğüm görüntülerinizi en son haftalık sürümle eşitlenmiş durumda tutmak, gelişmiş bir güvenlik duruşu sağlarken bu zaman zaman yeniden başlatma isteklerini en aza indirir. Yalnızca düğüm görüntüsü yükseltmelerini kullanırsanız AKS uyumluluğu ve haftalık güvenlik düzeltme eki uygulama sağlanır. Günlük güncelleştirmelerin uygulanması güvenlik sorunlarını daha hızlı çözse de AKS'de test edilmiş olmaları gerekmez. Mümkün olduğunda, birincil haftalık güvenlik düzeltme eki uygulama stratejiniz olarak düğüm görüntüsü yükseltmesini kullanın.

Güvenlik izleme

Kapsayıcı altyapınızı hem etkin tehditler hem de olası güvenlik riskleri için izleyin:

• Kapsayıcı görüntüleriniz için Bulut için Defender önerileri tanımlamak ve düzeltmek için Kapsayıcılar için Microsoft Defender'ı etkinleştirin.
• Kapsayıcılar için Microsoft Defender kapsayıcı görüntülerinizi düzenli olarak güvenlik açıklarına karşı tarar.
• Kapsayıcılar için Microsoft Defender, şüpheli etkinlikler için gerçek zamanlı güvenlik uyarıları da oluşturur.
• AKS sanal makine konaklarına uygulanan güvenlik sağlamlaştırma hakkında bilgi için bkz . Konak işletim sisteminde Güvenlik Sağlamlaştırma.

Küme ve iş yükü işlemleri (DevOps)

Dikkat edilmesi gereken bazı noktalar aşağıdadır. Daha fazla bilgi için operasyonel mükemmellik sütununa bakın.

Küme önyüklemesi

Sağlama tamamlandıktan sonra çalışan bir kümeniz olur, ancak iş yüklerini dağıtmadan önce hala gerekli adımlar olabilir. Kümenizi hazırlama işlemine bootstrapping adı verilir ve önkoşul görüntülerini küme düğümlerine dağıtma, ad alanları oluşturma ve kullanım örneğinizin veya kuruluşunuzun gereksinimlerini karşılayan diğer eylemlerden oluşabilir.

Sağlanan küme ile düzgün yapılandırılmış bir küme arasındaki boşluğu azaltmak için, küme operatörleri benzersiz önyükleme işlemlerinin nasıl görüneceğini düşünmeli ve ilgili varlıkları önceden hazırlamalıdır. Örneğin, uygulama iş yüklerini dağıtmadan önce her düğümde Kured'in çalıştırılması önemliyse, küme operatörü kümeyi sağlamadan önce hedef Kured görüntüsünü içeren bir ACR'nin zaten var olduğundan emin olmak ister.

Önyükleme işlemi aşağıdaki yöntemlerden biri kullanılarak yapılandırılabilir:

• Flux veya Argo CD gibi bir şey kullanarak kendi kendine yapılandırma
• Pipelines
• GitOps Flux v2 küme uzantısı

AKS için GitOps Flux v2 küme uzantısını kullanmanın temel avantajlarından biri, sağlanan küme ile önyüklenmiş küme arasında etkili bir boşluk olmamasıdır. Ortamı daha sonra sağlam bir yönetim temeli ile ayarlar ve IaC stratejinizle uyumlu hale getirmek için bu önyüklemenin kaynak şablonları olarak eklenmesini de destekler.

Son olarak, uzantıyı kullanırken önyükleme kubectl işleminin herhangi bir parçası için gerekli değildir ve acil durum onarımı durumları için tabanlı erişim kullanımı kubectlayrılabilir. Azure Kaynak tanımları için şablonlar ile GitOps uzantısı aracılığıyla bildirimlerin önyüklemesi arasında, tüm normal yapılandırma etkinlikleri kullanılmaya kubectlgerek kalmadan gerçekleştirilebilir.

İş yükü sorumluluklarını yalıtma

Her bölümü ayrı ayrı yönetmek için iş yükünü ekiplere ve kaynak türlerine bölün.

Temel bileşenleri içeren temel bir iş yüküyle başlayın ve temel bileşenleri oluşturun. İlk görev, ağı yapılandırmaktır. Hub ve uç ile bu ağların içindeki alt ağlar için sanal ağlar sağlayın. Örneğin uç, sistem ve kullanıcı düğümü havuzları ve giriş kaynakları için ayrı alt ağlara sahiptir. Hub'da Azure Güvenlik Duvarı için bir alt ağ.

Bir diğer bölüm de temel iş yükünü Microsoft Entra Id ile tümleştirmek olabilir.

Kod Olarak Altyapı (IaC) Kullanma

Mümkün olduğunda kesinlik temelli bir yaklaşım yerine etkili bildirim temelli bir yöntem seçin. Yapılandırma seçeneklerini belirten bir komut dizisi yazmak yerine, kaynakları ve bunların özelliklerini açıklayan bildirim temelli söz dizimini kullanın. Seçeneklerden biri Azure Resource Manager (ARM) şablonlarıdır. Bir diğeri terraform.

kaynakları idare ilkelerine göre sağladığınızdan emin olun. Örneğin, doğru VM boyutlarını seçerken, uygulamanızın gereksinimlerini karşılamak için maliyet kısıtlamaları ve kullanılabilirlik alanı seçeneklerinden haberdar olun.

Bir komut dizisi yazmanız gerekiyorsa Azure CLI kullanın. Bu komutlar çeşitli Azure hizmetlerini kapsar ve betik oluşturma yoluyla otomatikleştirilebilir. Azure CLI, Windows ve Linux'ta desteklenir. Platformlar arası bir diğer seçenek de Azure PowerShell'dir. Seçiminiz tercih edilen beceri kümesine bağlıdır.

Betikleri ve şablon dosyalarını kaynak denetim sisteminizde depolayın ve sürüme alın.

İş Yükü CI/CD

İş akışı ve dağıtım işlem hatlarının sürekli olarak uygulama oluşturma ve dağıtma özelliğine sahip olması gerekir. Güncelleştirmeler güvenli ve hızlı bir şekilde dağıtılmalı ve sorun olması durumunda geri alınmalıdır.

Dağıtım stratejiniz güvenilir ve otomatik bir sürekli teslim (CD) işlem hattı içermelidir. İş yükü kapsayıcı görüntülerinizdeki değişiklikler otomatik olarak kümeye dağıtılmalıdır.

Bu mimaride iş akışını ve dağıtımı yönetmek için GitHub Actions'ı seçtik. Diğer popüler seçenekler arasında Azure DevOps Services ve Jenkins yer alır.

Küme CI/CD

Bu mimarinin bir Visio dosyasını indirin.

kubectl gibi kesinlik temelli bir yaklaşım kullanmak yerine küme ve depo değişikliklerini otomatik olarak eşitleyen araçları kullanın. Yeni bir sürümün yayımlanması ve üretime dağıtmadan önce bu sürümün doğrulanması gibi iş akışını yönetmek için bir GitOps akışı düşünün.

CI/CD akışının önemli bir parçası, yeni sağlanan bir kümenin önyüklemesidir. GitOps yaklaşımı bu son için yararlıdır ve işleçlerin IaC stratejisinin bir parçası olarak önyükleme işlemini bildirimli olarak tanımlamasına ve yapılandırmanın kümeye otomatik olarak yansıtılmış olduğunu görmesine olanak tanır.

GitOps kullanılırken, kümenin durumunun özel Git deponuzda depolanan yapılandırmayla eşgüdümlü olduğundan emin olmak için kümede bir aracı dağıtılır. Bu tür bir aracı , Kubernetes içinde dağıtımları tetikleme amacıyla kümedeki bir veya daha fazla işleci kullanan flux aracıdır. Flux şu görevleri yapar:

• Yapılandırılmış tüm depoları izler.
• Yeni yapılandırma değişikliklerini algılar.
• Dağıtımları tetikler.
• bu değişikliklere göre istenen çalışan yapılandırmayı Güncelleştirmeler.

Ayrıca, bu değişikliklerin nasıl dağıtıldığını yöneten ilkeler de ayarlayabilirsiniz.

GitOps ve flux ile küme yapılandırmasını otomatikleştirmeyi gösteren bir örnek aşağıda verilmişti:

Bu mimarinin bir Visio dosyasını indirin.

1. Geliştirici, git deposunda depolanan yapılandırma YAML dosyaları gibi kaynak kodunda değişiklikleri işler. Değişiklikler daha sonra bir git sunucusuna gönderilir.

2. Flux, iş yüküyle birlikte podda çalışır. Flux, Flux'un yalnızca geliştiriciler tarafından istenen değişiklikleri uyguladığından emin olmak için git deposuna salt okunur erişime sahiptir.

3. Flux, yapılandırmadaki değişiklikleri tanır ve kubectl komutlarını kullanarak bu değişiklikleri uygular.

4. Geliştiricilerin kubectl aracılığıyla Kubernetes API'sine doğrudan erişimi yoktur.

5. Git sunucunuzda dal ilkelerine sahip olun. Bu şekilde, birden çok geliştirici bir değişikliği üretime uygulanmadan önce çekme isteği aracılığıyla onaylayabilir.

GitOps ve Flux el ile yapılandırılabilir ancak AKS için Flux v2 küme uzantısına sahip GitOps önerilir.

İş yükü ve küme dağıtım stratejileri

Herhangi bir değişikliği (mimari bileşenleri, iş yükü, küme yapılandırması) üretim öncesi en az bir AKS kümesine dağıtın. Bunun yapılması, değişikliğin benzetimini yapmak, üretime dağıtmadan önce sorunların çözülmesine neden olabilir.

Güncelleştirmeleri yüksek denetimli bir şekilde üretim ortamına gönderebildiğinizden ve tahmin edilmeyen dağıtım sorunlarından kaynaklanan kesintiyi en aza indirdiğinizden emin olmak için sonraki aşamaya geçmeden önce her aşamada testleri/doğrulamaları çalıştırın. Bu dağıtım, aynı GitHub Actions işlem hattı veya Flux işleçlerini kullanarak üretimle benzer bir desen izlemelidir.

Mavi-yeşil dağıtım, A/B testi ve Kanarya sürümleri gibi gelişmiş dağıtım teknikleri için ek işlem ve potansiyel araçlar gerekir. Flagger , gelişmiş dağıtım senaryolarınızın çözümüne yardımcı olan popüler bir açık kaynak çözümüdür.

Maliyet yönetimi

Başlangıç olarak, AKS için İyi Tasarlanmış Çerçeve'de özetlenen maliyet iyileştirme tasarım denetim listesini ve önerilerin listesini gözden geçirin. Mimaride kullanılan hizmetlerin maliyetlerini tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Diğer en iyi yöntemler, Microsoft Azure İyi Tasarlanmış Çerçeve'nin Maliyet İyileştirme bölümünde açıklanmıştır.

Kubernetes'e özgü yapılar tarafından ayrıntılı küme altyapısı maliyet ayırması için AKS maliyet analizini etkinleştirmeyi göz önünde bulundurun.

AKS temel başvuru mimarisinde Windows kapsayıcılarına dahil edilen Windows tabanlı iş yüklerine özgü maliyet yönetimi konularını gözden geçirmek için yardımcı makaleye bakın.

uygulamasını hazırlama

• Kubernetes kümesinin dağıtım, yönetim ve işlemlerinde AKS ile ilişkili herhangi bir maliyet yoktur. Maliyeti etkileyen şey, küme tarafından kullanılan sanal makine örnekleri, depolama alanı, günlük verileri ve ağ kaynaklarıdır. Sistem düğümü havuzları için daha ucuz VM'ler seçmeyi göz önünde bulundurun. DS2_v2 SKU'su, sistem düğümü havuzu için tipik bir VM türüdür.

• Geliştirme/test ve üretim ortamları için aynı yapılandırmaya sahip değilsiniz. Üretim iş yüklerinin yüksek kullanılabilirlik için ek gereksinimleri vardır ve genellikle daha pahalıdır. Geliştirme/test ortamında bu yapılandırma gerekli değildir.

• Üretim iş yükleri için bir Çalışma Süresi SLA'sı ekleyin. Ancak, kullanılabilirlik garantisinin gerekli olmadığı geliştirme/test veya deneysel iş yükleri için tasarlanmış kümeler için tasarruf sağlanır. Örneğin, SLO yeterlidir. Ayrıca, iş yükünüz destekliyorsa Spot VM'leri çalıştıran ayrılmış spot düğüm havuzlarını kullanmayı göz önünde bulundurun.

  AKS iş yükü mimarisinin parçası olarak Azure SQL Veritabanı veya Azure Uygulaması Hizmeti içeren üretim dışı iş yükleri için hizmet indirimleri almak için Azure Geliştirme/Test aboneliklerini kullanmaya uygun olup olmadığınızı değerlendirin.

• Ölçeklendirme gereksinimlerini karşılamak için büyük bir kümeyle başlamak yerine, en az sayıda düğüm içeren bir küme sağlayın ve küme otomatik ölçeklendiricisinin izlemesini ve boyutlandırma kararları almasını sağlayın.

• Kubernetes'in daha yüksek yoğunluğa sahip düğüm kaynaklarını ayırarak donanımın kapasitede kullanılmasına izin vermek için pod isteklerini ve sınırlarını ayarlayın.

• Kümede tanılamayı etkinleştirmek maliyeti artırabilir.

• İş yükünüz uzun bir süre için mevcut olması bekleniyorsa, düğüm maliyetlerini azaltmak için bir veya üç yıllık Ayrılmış Sanal Makine Örneklerine bağlanabilirsiniz. Daha fazla bilgi için bkz . Ayrılmış VM'ler.

• Düğüm havuzları oluştururken etiketleri kullanın. Etiketler, tahakkuk eden maliyetleri izlemek için özel raporlar oluştururken kullanışlıdır. Etiketler, giderlerin toplamını izleme ve herhangi bir maliyeti belirli bir kaynak veya ekiple eşleme olanağı sağlar. Ayrıca küme ekipler arasında paylaşılıyorsa, paylaşılan bulut hizmetlerinin tarifeli maliyetlerini belirlemek için tüketici başına geri ödeme raporları oluşturun. Daha fazla bilgi için bkz . Düğüm havuzu için renk tonu, etiket veya etiket belirtme.

• Bir bölgedeki kullanılabilirlik alanları arasındaki veri aktarımları ücretsiz değildir. İş yükünüz çok bölgeliyse veya kullanılabilirlik alanları arasında aktarımlar varsa ek bant genişliği maliyeti bekleyebilirsiniz. Daha fazla bilgi için bkz . Faturalama bölgeleri ve bölgeleri arasındaki trafik.

• Kuruluş tarafından tanımlanan maliyet kısıtlamalarının içinde kalmak için bütçeler oluşturun. Bunun bir yolu, Azure Maliyet Yönetimi aracılığıyla bütçe oluşturmaktır. Belirli eşikler aşıldığında bildirim almak için uyarılar da oluşturabilirsiniz. Daha fazla bilgi için bkz . Şablon kullanarak bütçe oluşturma.

İzleyici

Tüm kümenin maliyetini ve işlem maliyetini izlemek için depolama, bant genişliği, güvenlik duvarı ve günlükler hakkında maliyet bilgilerini de toplayın. Azure, maliyeti izlemek ve analiz etmek için çeşitli panolar sağlar:

• Azure Danışmanı

• Azure Maliyet Yönetimi

İdeal olan, maliyetlerin zaten hesaplanmış olduğu ay sonundan önce işlem yapmak için maliyeti gerçek zamanlı olarak veya en azından düzenli bir tempoda izlemektir. Ayrıca bütçede kalmak için zaman içindeki aylık eğilimi izleyin.

Veri odaklı kararlar almak için, en fazla maliyetin hangi kaynağın (ayrıntılı düzey) yansıtıldığına karar verin. Ayrıca, her kaynağın kullanımını hesaplamak için kullanılan ölçümleri de iyi anlayabilirsiniz. Ölçümleri analiz ederek platformun örneğin fazla boyutlandırılıp boyutlandırılamadığını belirleyebilirsiniz. Azure İzleyici ölçümlerinde kullanım ölçümlerini görebilirsiniz.

Optimize Et

Azure Danışmanı tarafından sağlanan önerilere göre hareket edin. İyileştirmenin başka yolları da vardır:

• Düğüm havuzundaki az kullanılan düğümleri algılamak ve kaldırmak için küme otomatik ölçeklendiricisini etkinleştirin.

• İş yükünüz destekliyorsa düğüm havuzları için daha düşük bir SKU seçin.

• Uygulama ani ölçeklendirme gerektirmiyorsa, zaman içindeki performans ölçümlerini analiz ederek kümeyi yalnızca doğru boyuta boyutlandırmayı göz önünde bulundurun.

• İş yükünüz destekliyorsa, kullanıcı düğümü havuzlarınızı çalıştırılma beklentisi olmadığında 0 düğüme ölçeklendirin. Ayrıca, kümenizde çalıştırılacak zamanlanmış iş yükü kalmadıysa, sistem düğüm havuzunuzu ve AKS denetim düzlemini içeren tüm işlemleri kapatmak için AKS Başlat/Durdur özelliğini kullanmayı göz önünde bulundurun.

Maliyetle ilgili diğer bilgiler için bkz . AKS fiyatlandırması.

Sonraki adımlar

AKS temel mimarisini öğrenmeye devam edin:

• AKS temelinde Mikro hizmetleri barındırma hakkında bilgi edinmek için bkz . Gelişmiş Azure Kubernetes Service (AKS) mikro hizmetler mimarisi.
• AKS temelini birden çok bölgeye dağıtmak için bkz . Çok bölgeli kümeler için AKS temeli.
• AKS temelini bir PCI-DSS 3.2.1 ortamına dağıtmak için bkz . PCI-DSS 3.2.1 için AKS tarafından düzenlenen küme.
• Başvuru mimarisine Windows kapsayıcıları ekleme konusunda dikkat edilmesi gerekenler hakkında bilgi edinmek için yardımcı makaleye bakın: AKS temel başvuru mimarisinde Windows kapsayıcıları

AKS hakkında daha fazla bilgi edinin

• AKS ürün yol haritasını gözden geçirin, bkz . GitHub'da Azure Kubernetes Service Yol Haritası.
• Kubernetes'te yenileyiciye ihtiyacınız varsa Kubernetes'e Giriş ve Kubernetes'te uygulama geliştirme ve dağıtma öğrenme yollarını tamamlayın.

İlgili kaynaklar

Aşağıdaki ilgili kılavuzlara bakın:

• Azure Kubernetes Service (AKS) için Azure İyi Tasarlanmış Çerçeve incelemesi
• Bu mimariyi temel alan kurumsal ölçekli bir uygulama olan AKS Giriş Bölgesi Hızlandırıcısı. Hızlandırıcı, Azure Kubernetes Service (AKS) dağıtımı için Kod Olarak Altyapı (IaC) kullanarak Azure ortamınızı tutarlı ve tekrarlanabilir bir şekilde ayarlamanıza yardımcı olur.
• Azure Kubernetes Services (AKS) 2. gün işlem kılavuzu

Aşağıdaki ilgili mimarilere bakın:

• Azure Kubernetes Service'te mikro hizmetler mimarisi
• Azure Kubernetes Service (AKS) kümesini korumaya yardımcı olmak için Azure Güvenlik Duvarı kullanma
• Azure Kubernetes Service için GitOps
• AKS ile veri akışı