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

Bu makalede Azure Kubernetes Service (AKS) kümesi dağıtmak için önerilen temel altyapı mimarisi sağlanır. Tasarım ilkelerimizi kullanır ve Azure İyi Tasarlanmış Çerçeve'nin AKS mimari en iyi yöntemlerini temel alır. Bu makale, bu genel amaçlı altyapıyı dağıtırken ağ, güvenlik ve kimlik ekipleri gibi farklı disiplinler arası gruplara yol göstermesine yardımcı olur.

Bu mimari bir iş yüküne odaklanmıyor. AKS kümesinin kendisine odaklanır. Bu bilgiler, AKS kümelerinin çoğu için önerilen en düşük temeldir. Gözlemlenebilirlik sağlayan, çok bölgesel büyümeyi destekleyen bir ağ topolojisi sağlayan ve küme içi trafiğin güvenliğini sağlayan Azure hizmetleriyle tümleştirilir.

İş gereksinimleriniz hedef mimariyi etkiler ve farklı uygulama bağlamları arasında farklılık gösterebilir. Mimariyi üretim öncesi ve üretim aşamaları için başlangıç noktanız olarak düşünün.

Kubernetes, Azure ve Microsoft teknolojilerinin ötesine uzanan güçlü bir ekosistemdir. AKS kümesini dağıttığınızda, kümenizin nasıl tasarlanması ve çalıştırılması gerektiği hakkında çok sayıda kararın sorumluluğunu alırsınız. AKS kümesini çalıştırmak, Microsoft dahil olmak üzere çeşitli satıcıların kapalı kaynak bileşenlerinin bir karışımını içerir; ve Kubernetes ekosisteminden açık kaynak bileşenleri. Manzara sık sık değişir ve kararları düzenli olarak yeniden ziyaret etmeniz gerekebilir. Kubernetes'i benimseyerek, iş yükünüzün özelliklerine ihtiyacı olduğunu ve iş yükü ekibinin sürekli olarak yatırım yapmaya hazır olduğunu kabul ediyor olursunuz.

GitHub'da bu mimarinin bir uygulamasını kullanabilirsiniz: AKS temel başvuru uygulaması. Bunu alternatif bir başlangıç noktası olarak kullanın ve başvuru mimarisini gereksinimlerinize göre yapılandırın.

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. Hub'ı ve uçları, sanal ağ eşlemesi aracılığıyla bağlanan ayrı sanal ağlara dağıtın. Bu topolojinin çeşitli avantajları vardır. Bu topolojiyi kullanarak:

• Ayrılmış yönetimi etkinleştirin. İdare uygulayabilir ve en az ayrıcalık ilkesine bağlı kalabilirsiniz. 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 indirin.

• Bölgesel merkez ve uç topolojileri sağlayın. Gelecekte merkez-uç ağ topolojilerini genişletebilir ve iş yükü yalıtımı sağlayabilirsiniz.

• Tüm web uygulamaları için HTTP trafik akışını incelemeye yardımcı olması için bir web uygulaması güvenlik duvarı hizmeti kullanın.

• Birden çok aboneliğe yayılan iş yükleri için destek sağlayın.

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

• Güvenlik duvarı ve Etki Alanı Adı Sistemi (DNS) bölgeleri gibi kaynakların ağlar arasında paylaşılması destekleniyor.

• Azure kurumsal ölçekli giriş bölgesiyle 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 mimarisindeki Windows kapsayıcılarına dahil edilen ağ tasarımı değişiklikleri hakkında daha fazla bilgi için bkz . AKS üzerinde Windows kapsayıcıları.

Merkez sanal ağı

Merkez sanal ağı, bağlantının ve gözlemlenebilirliğin merkezi noktasıdır. Bu mimaride hub şunları içerir:

• Kuruluş genelinde güvenlik duvarı ilkesini zorunlu kılmak için merkezi BT ekipleriniz tarafından tanımlanan genel güvenlik duvarı ilkeleriyle Azure Güvenlik Duvarı.
• Sanal makinelere (VM) uzaktan erişim için Azure Bastion.
• VPN bağlantısı için bir ağ geçidi alt ağı.
• Ağ gözlemlenebilirliği için Azure İzleyici.

Ağ içinde mimarinin üç alt ağı vardır.

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

Azure Güvenlik Duvarı yönetilen güvenlik duvarı hizmetidir. Azure Güvenlik Duvarı örneği giden ağ trafiğinin güvenliğini sağlar. Bu güvenlik katmanı olmadan trafik, hassas iş yükü verilerini dışarı aktarabilecek kötü amaçlı, Microsoft dışı bir hizmetle iletişim kurabilir. Birden çok Azure Güvenlik Duvarı örneğini merkezi olarak dağıtmak ve yapılandırmak ve bu merkez sanal ağ mimarisi türü için Azure Güvenlik Duvarı ilkelerini yönetmek için Azure Güvenlik Duvarı Yöneticisi'ni kullanın.

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

Bu alt ağ, VPN ağ geçidi veya Azure 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. Kaynakları İnternet'e göstermeden Azure kaynaklarına güvenli bir şekilde erişmek için Azure Bastion'ı kullanabilirsiniz. Bu alt ağ yalnızca yönetim ve işlemler içindir.

Uç sanal ağı

Uç sanal ağı AKS kümesini ve diğer ilgili kaynakları içerir. Uç aşağıdaki alt ağlara sahiptir.

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

Application Gateway , Katman 7'de çalışan bir web trafiği yük dengeleyicidir. Başvuru uygulaması, Azure Web Uygulaması Güvenlik Duvarı etkinleştiren Application Gateway v2 SKU'yu kullanır. Web Uygulaması Güvenlik Duvarı, 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 genel bir ö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 . AKS ile iç yük dengeleyici kullanma.

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

AKS, ayrı düğüm grupları olan iki düğüm havuzu 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.

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

Kullanıcıların uç sanal ağındaki özel bir uç nokta aracılığıyla bu hizmetlere erişebilmesi için Azure Container Registry ve Azure Key Vault için Özel Bağlantı bağlantıları oluşturun. Özel uç noktalar için ayrılmış alt ağ gerekmez. Hub sanal ağına özel uç noktalar da yerleştirebilirsiniz. Temel uygulamada uç noktalar uç sanal ağı içindeki ayrılmış bir alt ağa dağıtılır. Bu yaklaşım, eşlenen ağ bağlantısından geçen trafiği azaltır. Kümeye ait kaynakları aynı sanal ağda tutar. Ağ güvenlik gruplarını kullanarak alt ağ düzeyinde ayrıntılı güvenlik kuralları da uygulayabilirsiniz.

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.

Bu başvuru mimarisi, her biri bir IP adresi alanı gerektiren birden çok ağ yaklaşımı kullanır:

• Küme düğümleri, özel uç noktalar ve Application Gateway gibi kaynaklar için kullanılan Azure sanal ağınız.
• Küme, Azure sanal ağınıza ayrı bir adres alanından podlara IP adresleri ayıran Azure CNI Yer Paylaşımı'nı kullanır.

Sanal ağ IP adresi alanı

Azure sanal ağınızın adres alanı tüm alt ağlarınızı barındıracak kadar büyük olmalıdır. Trafik alan tüm varlıkların hesabı. Kubernetes, alt ağ adres alanından bu varlıklar için IP adresleri ayırır. Azure sanal ağınızın IP adreslerini planlarken bu noktaları göz önünde bulundurun.

• Yükseltmeler: AKS, temel alınan VM'lerin 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. Bu geçici düğüm IP adresleri için yeterli adres alanınız olduğundan emin olun.

  Bu mimaride podlar, sıralı güncelleştirmeler de dahil olmak üzere Azure CNI Katman pod adres alanının içinden IP adresleri ayrılır. Bu yaklaşım, diğer Kubernetes ağ yaklaşımlarına kıyasla Azure sanal ağınızdan kullanılan IP adreslerinin toplam sayısını azaltı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 Azure CNI Katmanı kullanıldığı için podlarınızın ölçeklenebilirliği sanal ağınızın adres alanını etkilemez.

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

• Ayrılmış IP adresleri: Azure belirli adresleri kullanımları için ayırır. Bunlar atanamaz.

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

Bu mimari tek bir iş yükü için tasarlanmıştır. Üretim AKS kümesinde sistem düğümü havuzunu her zaman kullanıcı düğümü havuzundan ayırın. Kümede birden çok iş yükü çalıştırdığınızda, kullanıcı düğümü havuzlarını birbirinden yalıtmak isteyebilirsiniz. Bunu yaptığınızda, boyutu daha küçük olan daha fazla alt ağ elde edilir. Ayrıca, giriş kaynağı daha karmaşık olabilir ve sonuç olarak ek IP adresleri gerektiren birden çok giriş denetleyicisine ihtiyacınız olabilir.

Pod IP adresi alanı

Azure CNI Yer Paylaşımı, sanal ağınızda kullandığınız adres alanından ayrı bir ayrılmış adres alanı kullanarak podlara IP adresleri atar. Sanal ağınızla veya eşlenmiş sanal ağlarla çakışmayan bir IP adresi alanı kullanın. Ancak, birden çok AKS kümesi oluşturursanız, her kümede aynı pod adres alanını güvenle kullanabilirsiniz.

Her düğüme podları için bir /24 adres alanı atanır, bu nedenle pod adres alanının kümenizdeki düğüm sayısı için gereken sayıda /24 bloğuna izin verecek kadar büyük olduğundan emin olmak önemlidir. Yükseltmeler veya ölçeği genişletme işlemleri sırasında oluşturulan geçici düğümleri eklemeyi unutmayın. Örneğin, CIDR aralığınız için /16 adres alanı kullanırsanız kümeniz en fazla 250 düğüme kadar büyüyebilir.

Her düğüm en fazla 250 pod destekler ve bu sınır yükseltmeler sırasında geçici olarak oluşturulan podları içerir.

Daha fazla bilgi için bkz . Azure CNI Yer Paylaşımı için IP adresi planlaması hakkında yönergeler

Diğer IP adresi alanı konuları

Bu mimariye ilişkin ağ konuları kümesinin tamamı için bkz . AKS temel ağ topolojisi. AKS kümesi için IP adreslemini planlamayla ilgili bilgi için bkz . Kümeniz için IP adresleme planlama.

AKS temel başvuru mimarisindeki Windows kapsayıcılarına dahil edilen IP adresi planlama konuları hakkında daha fazla bilgi için bkz . AKS üzerinde Windows kapsayıcıları.

Eklentiler ve önizleme özellikleri

Kubernetes ve AKS, şirket içi ortamlar için yazılımdan daha hızlı yayın döngüleriyle sürekli olarak gelişir. Bu temel mimari, belirli AKS önizleme özelliklerine ve AKS eklentilerine bağlıdır. İkisi arasındaki fark şu şekildedir:

• ÖNIZLEME özelliklerinin çoğu genel kullanılabilirlik (GA) aşamasına geçmeden önce yalnızca birkaç ay boyunca bu durumda kaldığı için AKS ekibi önizleme özelliklerini gönderildi ve geliştirildi olarak tanımlar.

• AKS eklentileri ve uzantıları ek, desteklenen işlevler sağlar. AKS, yükleme, yapılandırma ve yaşam döngüsünü yönetir.

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ı içerir. Bu özellikler önizleme sürümünden çıktıkçe, bu temel mimari uygun şekilde düzeltilir. Üretim öncesi kümelerde değerlendirmek isteyebileceğiniz başka önizleme özellikleri veya AKS eklentileri de vardır. Bu özellikler güvenliğinizi, yönetilebilirliğinizi veya diğer gereksinimlerinizi iyileştirebilir. Microsoft dışı eklentilerle, kullanılabilir sürümleri izleme ve kümenin Kubernetes sürümünü yükselttikten sonra güncelleştirmeleri yükleme 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. Görüntüleri kümenize çekerken bu noktaları göz önünde bulundurun.

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

• Genel görüntü kullanıyorsanız, hizmet düzeyi hedefinizle (SLO) uyumlu bir genel görüntüyü kapsayıcı kayıt defterine aktarın. Aksi takdirde, görüntü beklenmeyen kullanılabilirlik sorunlarına maruz kalabilir. İhtiyacınız olduğunda görüntü kullanılamıyorsa, bu işlem sorunlarına neden olabilir. Genel kayıt defteri yerine Azure Container Registry gibi özel bir kapsayıcı kayıt defteri kullanmanın bazı avantajları şunlardır:

  • Resimlerinize yetkisiz erişimi engelleyebilirsiniz.
  • Genel kullanıma yönelik bağımlılıklarınız yoktur.
  • 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 yararlanabilirsiniz.

• 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 dağıtan Container Registry örneğinden 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ümesine 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. Büyük düğümler, izleme ve günlüğe kaydetme gibi tüm düğümlerde çalışan hizmetlerin ayak izini en aza indirir.

• Belirli iş yükü gereksinimleriniz varsa uygun VM türünü seçin. Örneğin, bazı iş yükleri için bellek için iyileştirilmiş bir ürüne veya diğerleri için GPU hızlandırmalı bir ürüne ihtiyacınız olabilir. Daha fazla bilgi için bkz . Azure'da sanal makinelerin boyutları.

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

• Tasarım ekibiniz tarafından belirlenen gereksinimlere göre iş yükünüz için gerçek düğüm boyutlarını planlayın. bu mimari, iş gereksinimlerine bağlı olarak üretim iş yükü için DS4_v2 kullanır. Maliyetleri düşürmek için boyutu en düşük öneri olan DS3_v2 bırakabilirsiniz.

• Kümenizin kapasitesini planlarken iş yükünüzün her düğümün %80'ine kadar tükettiği varsayılır. 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.

İşletim sistemi seçme

AKS kümelerinin çoğu düğüm havuzları için işletim sistemi olarak Linux kullanır. Bu başvuru uygulamasında, Azure için ayarlanmış basit, sağlamlaştırılmış bir Linux dağıtımı olan Azure Linux'ı kullanacağız. İsterseniz veya Azure Linux'un karşılayabildiği gereksinimleriniz varsa Ubuntu gibi başka bir Linux dağıtımı kullanmayı seçebilirsiniz.

AKS, Windows Server işletim sistemini çalıştıran düğüm havuzlarını da destekler. Windows çalıştıran bir kümenin bazı yönleri için özel gereksinimler vardır. Windows düğüm havuzu mimarisi hakkında daha fazla bilgi edinmek için bkz . AKS üzerinde Windows kapsayıcılarını çalıştırma.

Teknolojilerin bir karışımından oluşan bir iş yükünüz varsa farklı düğüm havuzlarında farklı işletim sistemleri kullanabilirsiniz. Ancak, iş yükünüz için farklı işletim sistemlerine ihtiyacınız yoksa, tüm iş yükünüzün düğüm havuzları için tek bir işletim sistemi kullanmanızı öneririz.

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. Bunu, güvenlik seçimleri yaparken kümenin perspektifinden düşünün:

• İçeriden dışarı erişim. Ağ altyapısı, Container Registry ve Key Vault gibi Azure bileşenlerine AKS erişimini göz önünde bulundurun. Yalnızca kümenin erişmesine izin verilmesi gereken kaynakları yetkileyin.
• Dışarıdan erişim. Kubernetes kümesine kimlik erişimi sağlayın. 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.

Azure'a AKS erişimini yönetmeye yönelik iki yöntemden yönetilen kimlikler öneririz. Hizmet sorumlularıyla gizli dizileri el ile veya program aracılığıyla yönetmeniz ve döndürmeniz gerekir. 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 kimlikleri etkinleştirmenizi ve kullanmanızı öneririz. Microsoft Entra ID tümleştirmesini hemen kullanmasanız bile daha sonra dahil edebilirsiniz.

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

Kümenin kapsayıcı kayıt defterinden görüntü çekmesi gerektiğinde yönetilen kimlikleri kullanmanız gerekir. Bu eylem için kümenin kayıt defterinin kimlik bilgilerini alması gerekir. Yönetilen kimlik kullanmıyorsanız, bu bilgileri Kubernetes gizli dizisi nesnesi biçiminde depolayabilir ve gizli diziyi almak için kullanabilirsiniz imagePullSecrets . Güvenlik karmaşıklıkları nedeniyle bu yaklaşımı önermiyoruz. Gizli dizi hakkında önceden bilgi sahibi olmanıza ek olarak, bu gizli diziyi DevOps işlem hattında da depolamanız gerekir. Bu yaklaşımı önermemenin bir diğer nedeni de gizli dizi rotasyonunu yönetmenin operasyonel ek yüküdür. Bunun yerine, kümenin kubelet yönetilen kimliğine kayıt defterinize erişim verin AcrPull . Bu yaklaşım, endişeleri ele alır.

Bu mimaride küme, Microsoft Entra ID'nin güvenli olduğu Azure kaynaklarına erişir ve küme yönetilen kimlikleri destekleyen işlemler gerçekleştirir. Kümenin yaptığı 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 ardından kendisine atanan rollere göre erişim izni 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ı rolü. Kümenin uç sanal ağını denetleme becerisini yönetir. Bu rol atamasıyla AKS kümesi sistem tarafından atanan kimlik, iç giriş denetleyicisi hizmeti için ayrılmış alt ağ ile çalışabilir.

• Ölçüm Yayımcısı rolünü izleme. Kümenin Azure İzleyici'ye ölçüm gönderme özelliğini yönetir.

• AcrPull rolü. Kümenin belirtilen Azure Container Registry örneklerinden görüntü çekme özelliğini yönetir.

Küme erişimi

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

AKS, Microsoft Entra ID'yi iki şekilde kullanarak Kubernetes erişimini destekler. Birincisi, yerel Kubernetes RBAC sistemiyle tümleştirilmiş bir kimlik sağlayıcısı olarak Microsoft Entra Id'yi kullanmaktır. Diğer yöntem, küme erişimini denetlemek için yerel Azure RBAC kullanır. Aşağıdaki bölümlerde her iki yaklaşım da ayrıntılı olarak yer almaktadır.

Kubernetes RBAC'yi Microsoft Entra Id ile ilişkilendirme

Kubernetes aşağıdakiler aracılığıyla RBAC'i destekler:

• Küme genelindeki izinler için bir Role veya ClusterRole nesnesi kullanarak tanımladığınız bir izin kümesi.

• Eylemleri yapma izni olan kullanıcıları ve grupları atayan bağlamalar. Bir veya ClusterRoleBinding nesnesi kullanarak RoleBinding bağlamaları tanımlayın.

Kubernetes'in küme yöneticisi, düzenleme ve görüntüleme gibi bazı yerleşik rolleri 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 Microsoft Entra gruplarını Microsoft Entra erişim gözden geçirmelerinize eklediğinizden emin olun.

Kubernetes yetkilendirmesi için Azure RBAC kullanma

Kubernetes'in yerel RBAC'sini ClusterRoleBindings kullanmak ve RoleBindings tümleşik Microsoft Entra kimlik doğrulamasıyla yetkilendirmek için Azure RBAC ve Azure rol atamalarını kullanmanızı öneririz. Bu yaklaşım, kümede yetkilendirme denetimlerini zorunlu tutuyor. Bu rolleri yönetim grubu, abonelik veya kaynak grubu kapsamlarında bile atayabilirsiniz. Kapsam altındaki tüm kümeler, Kubernetes kümesindeki nesnelere erişim iznine sahip olan kişilere göre tutarlı bir rol ataması kümesini devralır.

Daha fazla bilgi için bkz . Kubernetes yetkilendirmesi için Azure RBAC.

Yerel hesaplar

AKS, yerel Kubernetes kullanıcı kimlik doğrulamayı destekler. Kümelere kullanıcı erişimi sağlamak için bu yöntemi kullanmanızı önermeyiz. Bu yöntem sertifika tabanlıdır ve merkezi kullanıcı erişim denetiminizi ve idarenizi zorlaştıran birincil kimlik sağlayıcınız dışında gerçekleştirilir. Microsoft Entra Id kullanarak kümenize erişimi her zaman yönetin ve kümenizi yerel hesap erişimini açıkça devre dışı bırakacak şekilde yapılandırın.

Bu başvuru uygulamasında, sistem kümeyi dağıttığında yerel küme hesaplarına 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 Id aracılığıyla kaynaklara erişmesini sağlar. Örneğin, iş yükü dosyaları Azure Depolama'da 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 podlar için yönetilen kimlikleri sağlar. Bu yaklaşım, dış kimlik sağlayıcılarıyla federasyona yönelik Kubernetes yerel özellikleriyle tümleşir. Microsoft Entra İş Yükü Kimliği federasyonu hakkında daha fazla bilgi için bkz. İş yükü kimlik federasyonu.

Ağ modeli seçme

AKS, kubenet, CNI ve Azure CNI Yer Paylaşımı dahil olmak üzere birden çok ağ modeli destekler. CNI modelleri daha gelişmiş modellerdir ve yüksek performanslıdır. Podlar arasında iletişim kurarken, CNI'nin performansı sanal ağdaki VM'lerin performansına benzer. CNI, Azure ağ ilkesinin kullanılmasını sağladığından gelişmiş güvenlik denetimi de sunar. CNI tabanlı bir ağ modeli öneririz.

Katman olmayan CNI modelinde, her pod alt ağ adres alanından bir IP adresi alır. Aynı ağdaki kaynaklar (veya eşlenen kaynaklar) podlara doğrudan KENDI IP adresleri üzerinden erişebilir. Bu trafiği yönlendirmek için Ağ Adresi Çevirisi (NAT) gerekli değildir.

Bu başvuru uygulamasında, düğümler için yalnızca düğüm havuzu alt ağından IP adresleri ayıran ve pod IP'leri için yüksek oranda iyileştirilmiş bir katman katmanı kullanan Azure CNI Yer Paylaşımı'nı kullanacağız. Azure CNI Yer Paylaşımı diğer birçok yaklaşımdan daha az sanal ağ IP adresi kullandığından, IP adresi kısıtlanmış dağıtımlar için bunu öneririz.

Modeller hakkında bilgi için bkz . Kullanılacak Kapsayıcı Ağı Arabirimi ağ modelini seçme ve Kubenet ile Azure Container Networking Interface ağ modellerini karşılaştırma.

Giriş kaynaklarını dağıtın

Kubernetes giriş kaynakları, kümeye gelen trafik için yönlendirmeyi ve dağıtmayı işler. Giriş kaynaklarının iki bölümü vardır:

• AKS tarafından yönetilen iç yük dengeleyici. 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. Load Balancer, giriş kaynakları için ayrılmış bir alt ağda kümenin dışındadır. Application Gateway'den trafik alır ve iletişim aktarım katmanı güvenliği (TLS) üzerinden gerçekleştirilir. Gelen trafik için TLS şifrelemesi hakkında daha fazla bilgi için bkz . Giriş trafiği akışı.

• Giriş denetleyicisi. Bu örnekte Traefik kullanılır. 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 aşağıdaki noktaları göz önünde bulundurun.

• Giriş denetleyicisini tasarım kararlarınızın bir parçası olarak belirli bir işlem kapsamıyla sınırlandırın. Ö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 başarısız olursa iş sürekliliğini sağlamaya yardımcı olmak 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ıtıyor.

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

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

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

Temel başvuru mimarisinde AKS üzerindeki Windows kapsayıcıları için giriş tasarımı hakkında daha fazla bilgi için bkz . AKS üzerinde Windows kapsayıcıları.

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 seçenekleri yolların HTTPS üzerinden sunulduğunun göstergesidir. middlewares seçeneği yalnızca Application 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 mimaride ağ akışı şunları içerir:

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

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

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

• İstemci ile Kubernetes API sunucusu arasındaki yönetim trafiği .

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ı eşleştirme etkinleştirildi. Aşağıdaki diyagramda gösterildiği gibi uçtan uca TLS, 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, Application Gateway'in genel IP adresine bir DNS A kaydıyla ilişkilendirilir. Bu trafik, istemci tarayıcısı ve ağ geçidi arasındaki trafiğin denetlenmesini veya değiştirilememesini sağlamaya yardımcı olmak için şifrelenir.

2. Application Gateway tümleşik bir web uygulaması güvenlik duvarına sahiptir ve için bicycle.contoso.comTLS el sıkışması anlaşması yaparak yalnızca güvenli şifrelemelere izin verir. Application Gateway bir TLS sonlandırma noktasıdır. Bu nokta, Application Gateway'in web uygulaması güvenlik duvarının düz metin yanıtını incelemesi gerektiğinden önemlidir. Key Vault TLS sertifikasını depolar. Küme, Application Gateway ile tümleştirilmiş kullanıcı tarafından atanan yönetilen kimlikle bu kümeye erişir. Daha fazla bilgi için bkz. Key Vault sertifikalarıyla TLS sonlandırma.

   Application Gateway, web uygulaması güvenlik duvarı denetim kurallarını işler ve trafiği yapılandırılan arka uca ileden yönlendirme kurallarını çalıştırır.

3. Application Gateway'den arka uca giden trafik, iç yük dengeleyiciye iletildiği için *.aks-ingress.contoso.comiçin joker karakter olan başka bir TLS sertifikasıyla yeniden şifrelenir. Bu yeniden şifreleme, güvenli olmayan trafiğin küme alt ağından akmamasını sağlamaya yardımcı olur.

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

İş yükü podunun her atlamasına uçtan uca TLS trafiği uygulayabilirsiniz. Poddan poda trafiğin güvenliğini sağlamaya karar verirken performansı, gecikme süresini ve operasyonel etkileri ö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ğu için, TLS'nin giriş denetleyicisine kadar şifrelemesi ve Web Uygulaması Güvenlik Duvarı ile korunması yeterlidir. Bu yaklaşım, düşük ağ performansı nedeniyle iş yükü yönetimi ve ek yük yükünü en aza indirir. İş yükünüz ve uyumluluk gereksinimleriniz, TLS sonlandırma işlemini nerede gerçekleştirebileceğinizi belirler.

Çıkış trafik akışı

Bu mimaride, kümeden gelen tüm çıkış trafiğinin Azure Güvenlik Duvarı üzerinden iletişim kurmasını öneririz. İsterseniz kendi benzer ağ sanal gerecinizi de kullanabilirsiniz. Azure NAT Gateway veya HTTP ara sunucusu gibi diğer çıkış seçeneklerinin kullanılması önerilmez çünkü bunlar ağ trafiği denetimi sağlamaz. Sıfır Güven denetimi ve trafiği inceleyebilmek için kümeden gelen tüm çıkış trafiği Güvenlik Duvarı'ndan geçer. Bu yapılandırmayı kullanıcı tanımlı yollar (UDR) ile uygulayabilirsiniz. Yolun sonraki atlaması, Azure Güvenlik Duvarı özel IP adresidir. 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ımladığınız belirli kuralları temel alır.

Azure Güvenlik Duvarı alternatifi, AKS HTTP proxy özelliğini kullanmaktır. Kümeden ayrılan tüm trafik HTTP ara sunucusunun IP adresine gider ve bu da trafiği iletir veya bırakır.

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

kümenin diğer Azure kaynaklarıyla iletişim kurması gerektiğinde Sıfır Güven denetiminin bir istisnası vardır. Örneğin, kümenin kapsayıcı kayıt defterinden güncelleştirilmiş bir görüntüyü veya Key Vault'tan gizli dizileri çekmesi gerekebilir. Bu senaryolarda Özel Bağlantı kullanmanızı öneririz. Bunun avantajı, belirli alt ağların hizmete doğrudan ulaşması ve küme ile hizmetler arasındaki trafiğin İnternet üzerinden gitmemesidir. 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 ürünleri Ö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 olarak bulunan güvenlik duvarı aracılığıyla erişimi denetleyebilirsiniz. Bu trafik güvenlik duvarının statik IP adreslerinden geçtiğinden, bu adresleri hizmetin IP izin verilenler listesine ekleyebilirsiniz. Bunun bir dezavantajı, Azure Güvenlik Duvarı yalnızca belirli bir alt ağdan gelen trafiğe izin verdiğinden emin olmak için daha fazla kurala ihtiyacı olmasıdır. 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 planlama hakkında daha fazla bilgi için bkz. Birden çok IP adresiyle Azure Güvenlik Duvarı oluşturma.

AKS temel başvuru mimarisindeki Windows kapsayıcılarında Windows'a özgü çıkış konuları hakkında bilgi için bkz . AKS üzerinde Windows kapsayıcıları.

Poddan poda trafik

Varsayılan olarak, pod kümedeki diğer podlardan gelen trafiği kabul edebilir. Podlar arasındaki ağ trafiğini kısıtlamak için Kubernetes'i NetworkPolicy kullanın. İlkeleri yanlışlıkla uygulayın veya kritik bir 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.

Daha sonra ekleyemediğiniz için kümeyi sağlarken ağ ilkesini etkinleştirin. uygulayan NetworkPolicyteknolojiler için birkaç seçeneğiniz vardır. Azure Container Networking Interface (CNI) gerektiren Azure ağ ilkesi önerilir. Daha fazla bilgi için aşağıdaki nota bakın. Diğer seçenekler arasında iyi bilinen bir açık kaynak seçeneği olan Calico ağ ilkesi 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ğ ilkesi altyapıları arasındaki farklar.

Yönetim trafiği

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

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

Başka bir denetim katmanı için, ek karmaşıklık karşılığında özel bir AKS kümesi sağlayabilirsiniz. Özel küme kullanarak API sunucunuz ile düğüm havuzlarınız arasındaki ağ trafiğinin yalnızca özel ağda kaldığından ve hiçbir zaman İnternet'e sunulmadığından emin olmanıza yardımcı olabilirsiniz. Daha fazla bilgi için bkz . AKS özel kümeleri.

Gizli dizi yönetimi ekleyin

Gizli dizileri Key Vault gibi yönetilen bir anahtar deposunda depolayın. Bunun avantajı, yönetilen anahtar deposunun gizli dizilerin döndürmesini işlemesidir. Güçlü şifreleme ve erişim denetim günlüğü sağlar. Ayrıca temel gizli dizileri dağıtım işlem hattının dışında tutar. Bu mimaride bir Key Vault güvenlik duvarı etkinleştirilip yapılandırılır ve Azure'da gizli dizilere ve sertifikalara erişmesi gereken kaynaklardan bağlanırken Özel Bağlantı kullanılır.

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. Application Gateway'in giriş akışı için TLS sertifikalarına nasıl eriştiği hakkında daha fazla bilgi 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ızı ve gizli dizilere erişmenizi sağlar. Daha fazla bilgi için bkz . RBAC kullanarak 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 bir 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 bir gizli dizi 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 uygulama, gizli dizi deposu CSI sürücüsü ile Key Vault kullanır. Eklenti, Key Vault'tan TLS sertifikasını alır ve sürücüyü giriş denetleyicisini çalıştıran poda yükler. Bu işlem pod oluşturma sırasında gerçekleşir ve birim hem genel hem de özel anahtarları depolar.

İş yükü depolama

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

Daha fazla bilgi için bkz . AKS'deki uygulamalar için depolama seçenekleri.

İlke yönetimi

AKS kümesini yönetmenin etkili bir yolu, ilkeler aracılığıyla idareyi zorunlu kılmaktır. Kubernetes, Açık İlke Aracısı (OPA) Ağ Geçidi Denetleyicisi aracılığıyla ilkeler uygular. AKS için ilkeleri Azure İlkesi aracılığıyla teslim edin. Her ilke, kapsamındaki tüm kümeler için geçerlidir. OPA Gatekeeper, kümede ilke zorlamayı işler ve tüm ilke denetimlerini günlüğe kaydeder. İlke değişiklikleri kümenize hemen yansıtılır, bu nedenle bazı gecikmeler bekleyebilirsiniz.

AKS kümelerinizi yönetmek için Azure İlkesi kullanabilirsiniz:

• Bir kaynak grubu veya abonelikte AKS kümelerinin dağıtımını engelleyin veya kısıtlayın. Kuruluşunuz için standartlar uygulayın. Örneğin, bir adlandırma kuralını izleyebilir veya bir etiket belirtebilirsiniz.
• 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:

• Girişimler olarak da adlandırılan bir ilke koleksiyonu 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. Kümeyle etkileşimde bulunan Container Registry, Application Gateway veya Key Vault gibi küme ve kaynaklar için bir girişim seçmenizi ve diğer ilkeleri seçmenizi öneririz. Kuruluşunuzun gereksinimlerine göre ilkeler seçin.

• Eylemi denetlemek veya reddetmek istiyor musunuz? Denetim modunda, eyleme izin verilir ancak Uyumlu Değil olarak işaretlenir. Uyumlu olmayan durumları düzenli bir tempoda 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. Daha fazla bilgi 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şunuzda genel ilkeler olsa bile kümenizin kendi iş yüküne özgü ilkeleri de ataması gerekir.

• Azure ilkelerini belirli kapsamlara atar mısınız? Ü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 katmadığınız beklenmedik ek kısıtlamalarla karşılaşabilirsiniz.

Bu başvuru uygulaması, AKS kümesi oluşturulduğunda Azure İlkesi etkinleştirir. Kısıtlayıcı girişim, uyumsuzluğun görünürlüğünü elde etmek için Denetim modunda atanır.

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 Container Registry örneğinden ç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 işlevinin 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ında ve azure-policy-webhook podlarının günlüklerine azure-policy kube-system erişebilirsiniz.

Windows'a özgü Azure İlkesi konuları hakkında daha fazla bilgi için AKS ilke yönetimindeki Windows kapsayıcıları makalesine bakın.

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

Talebin artmasıyla Kubernetes, yatay pod otomatik ölçeklendirmesi aracılığıyla mevcut düğümlere daha fazla pod ekleyerek ölçeği genişletebilir. Kubernetes artık daha fazla pod zamanlayamadığı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.

Hem otomatik ölçeklendirme hem de el ile yaklaşım, CPU kullanımı veya özel ölçümler hakkında uyarılar izlemenizi ve ayarlamanızı gerektirir. Pod ölçeklendirme için uygulama operatörünüz 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, Kubernetes zamanlayıcı başarısız olduğunda bir yöntem bildirilir. Bir diğer yol da bekleyen podları zaman içinde izlemektir. Düğüm sayısını Azure CLI veya Azure portalı üzerinden ayarlayabilirsiniz.

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

Genel bir yöntem 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 birleşimini kullanın. Son olarak, otomatik ölçeklendirme parametrelerini ayarlamak için bu verileri kullanın. AKS kullanan bir performans ayarlama senaryosu hakkında daha fazla 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ı ayarlamanızı öneririz. 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. Tanım, HorizontalPodAutoscaler ölçümler için hedef değerleri belirtir. Örneğin, belirtim hedef CPU kullanımını 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.

HPA'nın ölçeklendirme işlemi tamamlanmadan önce denetlediği bir yarış durumu olabilir. Sonuç yanlış bir oran hesaplaması olabilir. Daha fazla bilgi 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 Kubernetes olay odaklı otomatik ölçeklendirme (KEDA) seçeneğidir. İleti kuyruğu gibi bir olay kaynağı, iş yükünüzün CPU'ya veya belleğe bağlı olması yerine iş yükünüzü yönlendiriyorsa KEDA'yı göz önünde bulundurun. KEDA birçok olay kaynağını veya ölçeklendiriciyi destekler. KEDA ölçekleyicilerinde KEDA'nın ölçeklendirebileceği olay kaynaklarının listesini kullanın. Liste, KeDA iş yüklerini Azure İzleyici ölçümlerine göre ölçeklendirmenin kullanışlı bir yolu olan Azure İzleyici ölçeklendiricisini içerir.

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 ekleyin. Her kullanıcı düğümü havuzu için ayrı bir küme otomatik ölçeklendiricisi gerekir.

Kubernetes zamanlayıcı, küme otomatik ölçeklendiricisini tetikler. 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 basitliği nedeniyle minimum değer iki olarak ayarlanır.

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

Bu temel başvuru mimarisinde yer alan Windows'a özgü ölçeklendirme konuları hakkında bilgi için AKS üzerinde Windows kapsayıcıları makalesine bakın.

İş sürekliliği kararları

İş sürekliliğini korumak için altyapının ve uygulamanızın SLO'sunu tanımlayın. Daha fazla bilgi için bkz . Güvenilirlik hedeflerini tanımlama önerileri. çevrimiçi hizmetler için en son SLA makalesinde AKS için hizmet düzeyi sözleşmesi (SLA) koşullarını gözden geçirin.

Küme düğümleri

İş yüklerinin en düşük kullanılabilirlik düzeyini karşılamak için bir düğüm havuzunda birden çok düğüme ihtiyacınız vardır. Bir düğüm başarısız olursa, aynı düğüm havuzundaki ve kümedeki başka bir düğüm uygulamayı çalıştırmaya devam edebilir. Güvenilirlik için sistem düğümü havuzu için üç düğüm öneririz. Kullanıcı düğümü havuzu için ikiden az düğümle başlayın. Daha yüksek kullanılabilirliğe ihtiyacınız varsa daha fazla düğüm sağlayın.

Uygulamanı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. Düğüm havuzunu tanımlamak ve iş yükünüzü zamanlamak için etiketler, etiketler ve renk tonları kullanmanızı öneririz. Sistem düğümü havuzunuzun renk tonuyla boyandığından CriticalAddonsOnlyemin olun.

Kümenizde düzenli bakım (zamanında güncelleştirmeler gibi) güvenilirlik açısından çok önemlidir. Ayrıca, yoklamalar aracılığıyla podların durumunu izlemenizi öneririz.

Pod kullanılabilirliği

Pod kaynak gereksinimlerini belirtin: Dağıtımlarınızda pod kaynağı gereksinimlerini belirtmeniz önerilir. Zamanlayıcı daha sonra uygun şekilde pod zamanlayabilir. Podlarınız zamanlanamazsa güvenilirlik büyük ölçüde azalır.

Pod kesintisi bütçelerini ayarlama: 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 olunmasında yardımcı olabilir.

İş yükü ad alanları üzerinde kaynak kotaları ayarlama: Bir ad alanı üzerindeki kaynak kotası, pod isteklerinin ve sınırlarının dağıtımda düzgün ayarlanmasına yardımcı olur. Daha fazla bilgi için bkz . Kaynak kotalarını zorlama.

Pod isteklerini ve sınırlarını ayarlama: İstekleri ve sınırları ayarlamak Kubernetes'in podlara verimli bir şekilde CPU ve bellek kaynakları ayırmasını sağlar ve düğümde daha yüksek kapsayıcı yoğunluğuna sahip olmanıza olanak tanır. İstekler ve sınırlar, daha iyi donanım kullanımı nedeniyle maliyetlerinizi düşürürken güvenilirliğinizi de artırabilir.

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

Dağıtım bildirimlerinizde istekleri ve sınırları belirtebilirsiniz. Daha fazla bilgi için bkz . Pod isteklerini ve sınırlarını ayarlama.

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

Bazı kesinti türlerine karşı koruma sağlamak için, bölge bunları destekliyorsa kullanılabilirlik alanlarını kullanın. 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. AKS hizmeti ölçek kümesi işlemlerini ve yapılandırmasını yönetir. Birden çok bölgeyi 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. Çalışma süresi SLA'sına sahip olmak için Standart veya Premium katmanını seçmeniz gerekir. Kullanılabilirlik alanları kullanılırken çalışma süresi SLA'sı daha büyüktür.

• Küme: Kullanılabilirlik alanlarını yalnızca düğüm havuzunu oluştururken ayarlayabilirsiniz. Daha sonra değiştirilemezler. 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.

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

• 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 oluştuğunda düğüm başka bir bölgeye taşınabilir, ancak yönetilen disk düğümle birlikte bu bölgeye taşınmaz.

Bu mimaride kolaylık sağlamak için AKS, kullanılabilirlik alanları bir, iki ve üç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 aynı bölgeye birden fazla bölge desteğiyle dağıtılır. Container Registry için coğrafi çoğaltma etkinleştirildi.

Birden çok bölge

Kullanılabilirlik alanlarını etkinleştirdiğinizde, bölgenin tamamının başarısız olması olasılığı düşük olduğunda yeterli kapsama alanı olmaz. Daha yüksek kullanılabilirlik elde etmek için farklı bölgelerde birden çok AKS kümesi çalıştırın.

• Kullanılabilir durumdayken eşleştirilmiş bölgeleri tercih edin. Eşleştirilmiş bölgeleri kullanmanın bir avantajı, platform güncelleştirmeleri sırasında güvenilirliktir. Azure, aynı anda çiftteki yalnızca bir bölgenin güncelleştirilmesini sağlar. Bazı bölgelerin çiftleri yoktur. Bölgeniz eşlenmemişse, kullanılacak diğer bölgeleri seçerek çok bölgeli bir çözüm dağıtmaya devam edebilirsiniz. Bir bölge hatasından kurtarmayı yönetmek için yapılandırdığınız sürekli tümleştirme ve sürekli teslim (CI/CD) işlem hattı kullanmayı göz önünde bulundurun. 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 örneğine sahip olduğu konumu belirtin. Örneğin, Container Registry için coğrafi çoğaltmayı etkinleştirerek resimleri otomatik olarak seçili Azure bölgelerine çoğaltır. Ayrıca, birincil 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 Load Balancer'ı dağıtır. Trafiği bölgeler arasında dağıtmanız gerekiyorsa Azure Front Door'a göz önünde bulundurun. Diğer seçenekler için bkz . Yük dengeleyici seçme.

Olağanüstü durum kurtarma

Birincil bölgede bir hata olursa, ideal olarak başka bir bölgede hızla yeni bir örnek oluşturabilirsiniz. İşte birkaç öneri:

• Birden çok bölge kullanın. Birincil bölgenizin eşleştirilmiş bir bölgesi varsa bu çifti kullanın. Aksi takdirde, veri yerleşimi ve gecikme süresi gereksinimlerinize göre bölgeleri seçin.

• Verimli bir şekilde çoğaltabileceğiniz, durum bilgisi olmayan bir iş yükü kullanın. Kümede durum depolamanız gerekiyorsa ve bunu yapmanızı önermiyoruz, verileri sık sık başka bir bölgede yedeklediğinizden emin olun.

• SLO'nuzu 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.

• Olağanüstü durum kurtarmayı destekleyen özellikleri kullanarak her Azure hizmetini sağlayın. Örneğin, bu mimaride Container Registry coğrafi çoğaltma için etkinleştirilir. Bölge başarısız olursa yine de çoğaltılan bölgeden görüntü çekebilirsiniz.

• AKS kümeniz ve ihtiyacınız olan diğer bileşenler dahil olmak üzere altyapınızı kod olarak dağıtın. Başka bir bölgeye dağıtmanız gerekiyorsa, aynı örneği oluşturmak için betikleri veya şablonları yeniden kullanabilirsiniz.

Küme yedekleme

Birçok mimari için, git işlemleri tabanlı küme önyüklemesi ve ardından uygulama dağıtımı aracılığıyla yeni bir küme sağlayabilir ve bu kümeyi işletim durumuna döndürebilirsiniz. Ancak yapılandırma eşlemeleri, işler ve gizli diziler gibi önyükleme işleminizde yakalanamaz kritik kaynak durumu varsa kurtarma stratejinizi göz önünde bulundurun. Kubernetes'te durum bilgisi olmayan iş yükleri çalıştırmanızı öneririz. 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 Velero , doğrudan yükleyip yönetebileceğiniz yaygın bir Kubernetes yedekleme çözümü örneğidir. İsterseniz, yönetilen bir Velero uygulaması sağlamak için AKS yedekleme uzantısını da kullanabilirsiniz. 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 işlem, yönetmek, izlemek, satın almak ve güvenliğini sağlamak için ek Azure kaynakları içerir. Bu kaynaklar arasında Azure Depolama hesabı, Azure Backup kasası ve yapılandırması ve güvenilir erişim özelliği yer alabilir. Bunun yerine, durum bilgisi olmayan iş yükünü çalıştırma amacı ile birleştirilen Git işlemleri kurtarma çözümüdür.

Tanımlı kurtarma noktası hedefiniz ve kurtarma süresi hedefiniz dahil olmak üzere iş hedefinize uygun bir yedekleme çözümü seçin ve doğrulayın. Kurtarma işleminizi bir ekip runbook'unda tanımlayın ve iş açısından kritik tüm iş yükleri için alıştırma yapın.

Kubernetes API sunucusu SLA'sı

AKS'yi ücretsiz hizmet olarak kullanabilirsiniz, ancak bu katman finansal olarak destekli bir SLA sunmaz. SLA elde etmek için Standart katmanı seçmeniz gerekir. Tüm üretim kümelerinin Standart katmanı kullanmasını öneririz. Ücretsiz katmanını üretim öncesi kümeler için, Premium katmanını ise yalnızca görev açısından kritik iş yükleri için ayırın. Azure kullanılabilirlik alanlarını kullandığınızda Kubernetes API sunucusu SLA'sı daha yüksektir. Düğüm havuzlarınız ve diğer kaynaklarınız kendi SLA'ları kapsamındadır. Her hizmet için belirli SLA'lar hakkında daha fazla bilgi için bkz. çevrimiçi hizmetler için SLA.

Tradeoff

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

Ayrıca bölgeler veya bölgeler arasındaki düğüm iletişiminde ek ağ gecikme süresi 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

Simülasyon kesintileriyle zorlamalı yük devretme testi ile çözümünüzün güvenilirliğini test edin. Benzetimler bir düğümü durdurmayı, belirli bir bölgedeki tüm AKS kaynaklarını indirerek bölgesel hata benzetimini veya dış bağımlılık hatasını çağırmayı içerebilir. Azure'da ve kümede çeşitli kesinti türlerinin benzetimini yapmak için Azure Chaos Studio'yu da kullanabilirsiniz.

Daha fazla bilgi için bkz . Chaos Studio.

Ölçümleri izleme ve toplama

Olayları gerçek zamanlı olarak görüntüleyebildiğiniz için kapsayıcı iş yüklerinin performansını izlemek için Azure İzleyici kapsayıcı içgörüleri öneririz. Ç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 kapsayıcı içgörülerini de kullanabilirsiniz. Toplanan verilerin izlenmesi, analizi ve görselleştirmesi için kritik öneme sahip telemetri verilerini içerir. Kapsayıcı içgörüleri eğilimleri tanımlar ve kritik sorunlar hakkında proaktif bildirimler almak için uyarı yapılandırmanızı sağlar.

Podlarda barındırılan iş yüklerinin çoğu Prometheus ölçümlerini gösterir. Kapsayıcı içgörüleri Prometheus ile tümleştirebilir. Düğümlerden ve Kubernetes'ten toplanan uygulama ve iş yükü ölçümlerini görüntüleyebilirsiniz.

Microsoft dışı bazı çözümler Datadog, Grafana veya New Relic gibi Kubernetes ile tümleştirilir. Bu nedenle, kuruluşunuz bu çözümleri zaten kullanıyorsa, bunlardan yararlanabilirsiniz.

AKS ile Azure bazı temel Kubernetes hizmetlerini yönetir. Azure, AKS denetim düzlemi bileşenlerinin günlüklerini kaynak günlükleri olarak uygular. Çoğu kümede aşağıdaki seçenekleri etkinleştirmenizi öneririz. Seçenekler küme sorunlarını gidermenize yardımcı olabilir ve günlük yoğunluğu nispeten düşük olabilir.

• ClusterAutoscaler: günlüğe kaydetme ile ölçeklendirme işlemlerine gözlemlenebilirlik kazandırır. 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 kazandırın.
• kube-audit-admin: kümenizi değiştiren etkinliklere gözlemlenebilirlik kazandırın. Hem hem de kube-audit kube-audit-admin etkin olması için bir neden yoktur. kube-audit , değiştirilmemiş (okuma) işlemleri de içeren bir üst kümesidir kube-audit-admin .
• guard: Microsoft Entra Id ve Azure RBAC denetimlerini yakalayın.

Erken küme veya iş yükü yaşam döngüsü geliştirme sırasında veya kube-auditgibi KubeScheduler diğer günlük kategorilerini etkinleştirmeniz yararlı olabilir. Eklenen küme otomatik ölçeklendirme, pod yerleştirme ve zamanlama ile benzer veriler, küme veya iş yükü işlemleriyle ilgili sorunları gidermenize yardımcı olabilir. Ancak, sorun giderme gereksinimleriniz sona erdikten sonra genişletilmiş sorun giderme günlüklerini tam zamanlı olarak tutarsanız, verileri Azure İzleyici'de almak ve depolamak için gereksiz maliyetler doğurabilirsiniz.

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 durumu ve performansı konusunda daha fazla gözlemlenebilirlik sağlar. SLO'larınıza ulaşmayı destekler.

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

Windows'a özgü izleme konuları hakkında daha fazla bilgi için bkz . AKS üzerinde Windows kapsayıcıları.

Ağ ölçümleri

Temel, küme düzeyinde ağ ölçümleri yerel platform ve Prometheus ölçümleri aracılığıyla kullanılabilir. Ağ ölçümlerini düğüm düzeyinde kullanıma açmak için Ağ Gözlemlenebilirliği eklentisini daha fazla kullanabilirsiniz. Çoğu küme, ek ağ sorun giderme özellikleri sağlamak ve düğüm düzeyinde beklenmeyen ağ kullanımı veya sorunlarını algılamak için Ağ Gözlemlenebilirliği eklentisini kullanmalıdır.

İletim Denetimi Protokolü (TCP) veya Kullanıcı Veri Birimi Protokolü (UDP) paket kaybı, gecikme süresi veya DNS baskısına karşı son derece hassas olan iş yükleri için pod düzeyinde ağ ölçümleri önemlidir. AKS'de, Gelişmiş Ağ Gözlemlenebilirliği özelliğiyle bu ayrıntı düzeyini bulabilirsiniz. Çoğu iş yükü, bu ağ gözlemlenebilirliği derinliğini gerektirmez. Podlarınız paket düzeyine kadar duyarlılık düzeyine kadar yüksek oranda iyileştirilmiş bir ağ talep etmediği sürece Gelişmiş Ağ Gözlemlenebilirliği eklentisini yüklememelisiniz.

Kendi kendini iyileştirmeyi etkinleştirme

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

AKS kümeleri için rutin güncelleştirmeler

Kubernetes kümeleri için 2. gün işlemlerinin bir parçası, rutin platform ve işletim sistemi güncelleştirmeleri gerçekleştirmektir. Her AKS kümesinde ele alınması gereken üç güncelleştirme katmanı vardır:

• Kubernetes sürümü (örneğin, Kubernetes 1.30.3 - 1.30.7 veya Kubernetes 1.30.7 - 1.31.1), Kubernetes API değişiklikleri ve kullanımdan kaldırmaları ile birlikte gelebilir. Bu katmandaki sürüm değişiklikleri tüm kümeyi etkiler.
• İşletim sistemi güncelleştirmelerini ve AKS bileşen güncelleştirmelerini birleştiren her düğümdeki sanal sabit disk (VHD) görüntüsü. Bu güncelleştirmeler kümenin Kubernetes sürümüne göre test edilir. Bu katmandaki sürüm değişiklikleri düğüm havuzu düzeyinde uygulanır ve Kubernetes sürümünü etkilemez.
• İşletim sisteminin Windows Update veya aptgibi kendi yerel güncelleştirme işlemi. İşletim sistemi satıcısı bu güncelleştirmeleri doğrudan sağlar ve kümenin Kubernetes sürümüne göre test edilmedi. Bu katmandaki sürüm değişiklikleri tek bir düğümü etkiler ve Kubernetes sürümünü etkilemez.

Bu katmanların her biri bağımsız olarak denetlenmektedir. İş yükünüzün kümeleri için her katmanın nasıl işleneceğini siz karar verirsiniz. Her AKS kümesinin, düğüm havuzlarının veya düğümlerinin ne sıklıkta güncelleştirileceğini ( tempo) seçin. Ayrıca, güncelleştirmelerin uygulanacağı günleri veya saatleri (bakım pencereniz) seçin. Güncelleştirmelerin el ile mi yoksa otomatik olarak mı yükleneceğini yoksa hiç yüklenmeyeceğini seçin. Kümenizde çalışan iş yükünün güvenli bir dağıtım uygulamasına ihtiyacı olduğu gibi, kümelerinizdeki güncelleştirmeler de aynı şekilde yapılır.

Düzeltme eki uygulama ve yükseltme hakkında kapsamlı bir bakış açısı için AKS 2. gün işlemleri kılavuzundaki AKS düzeltme eki ve yükseltme kılavuzuna bakın. Bu mimariyle ilgili temel öneriler için aşağıdaki bilgileri kullanın.

Değişmez altyapı

AKS kümelerini sabit altyapı olarak çalıştıran iş yükleri, kümelerini otomatik olarak veya el ile güncelleştirmez. Düğüm görüntüsü yükseltmesini olaraknone, küme otomatik yükseltmesini olarak noneayarlayın. Bu yapılandırmada, tüm katmanlardaki tüm yükseltmelerden yalnızca siz sorumlu olursunuz. İstediğiniz bir güncelleştirme kullanılabilir olduğunda, güncelleştirmeyi bir üretim öncesi ortamda test etmeniz ve yeni bir kümede uyumluluğunu değerlendirmeniz gerekir. Bundan sonra, güncelleştirilmiş AKS sürümünü ve düğüm havuzu VHD'lerini içeren bir üretim çoğaltma damgası dağıtın. Yeni üretim kümesi hazır olduğunda eski küme boşaltılır ve sonunda kullanımdan kaldırılır.

Düzenli yeni altyapı dağıtımlarına sahip sabit altyapı, üretim kümesinde yerinde yükseltme stratejisinin uygulanmaması gereken tek durumdur. Diğer tüm kümelerin yerinde yükseltme stratejisi olmalıdır.

Yerinde yükseltmeler

AKS kümelerini sabit altyapı olarak çalıştırmayen iş yükleri, çalışan kümelerini her üç katmanı da ele almak için düzenli olarak güncelleştirmelidir. Güncelleştirme işleminizi iş yükünüzün gereksinimlerine uygun hale getirme. Rutin güncelleştirme işleminizi tasarlamak için başlangıç noktası olarak aşağıdaki önerileri kullanın.

• Kümenizdeki yükseltmeleri denetleyebilmeniz için AKS'nin planlı bakım özelliğini zamanlayın. Bu özellik, beklenmeyen bir hatanın etkisini azaltmak için doğal olarak riskli bir işlem olan güncelleştirmeleri denetimli bir zamanda gerçekleştirmenizi sağlar.
• Sıralı yükseltmeler sırasında uygulamanızın kararlı kalması için pod kesintisi bütçelerini yapılandırın. Ancak çoğu yükseltme için her düğümde bir kordon ve boşaltma işlemi gerektiğinden, bütçeleri düğüm yükseltmelerinin gerçekleşmesini engelleyecek kadar agresif olacak şekilde yapılandırmayın.
• Azure kaynak kotası ve kaynak kullanılabilirliğini onaylayın. Yerinde yükseltmeler, eski düğümler kaldırılmadan önce aşırı gerilim düğümleri olarak bilinen yeni düğüm örneklerini dağıtır. Bu, yeni düğümler için Azure kotası ve IP adresi alanının kullanılabilir olması gerektiği anlamına gelir. %33'lük bir artış değeri, çoğu iş yükü için iyi bir başlangıç noktasıdır.
• Kümenize eklediğiniz hizmet kafesleri veya güvenlik aracıları gibi araçlarla uyumluluğu test edin. Giriş denetleyicileri, hizmet kafesleri ve iş yükü podlarınız gibi iş yükü bileşenlerinizi test edin. Testleri üretim öncesi ortamda yapın.

Düğümler için yerinde yükseltmeler

Düğüm işletim sistemi NodeImage görüntü yükseltmeleri için otomatik yükseltme kanalını kullanın. Bu kanal, kümenizi her düğümdeki VHD'yi düğüm düzeyinde güncelleştirmelerle güncelleştirecek şekilde yapılandırmaktadır. Microsoft, güncelleştirmeleri AKS sürümünüzle test ediyor. Windows düğümleri için güncelleştirmeler ayda yaklaşık bir kez gerçekleşir. Linux düğümleri için bu güncelleştirmeler haftada yaklaşık bir kez gerçekleşir.

• Yükseltmeler AKS veya Kubernetes sürümünüzü hiçbir zaman değiştirmez, bu nedenle Kubernetes API uyumluluğu önemli değildir.
• Yükseltme kanalı olarak kullandığınızda NodeImage , haftada en az bir kez ayarlamanız gereken planlı bakım pencerenize uygun olur. Uygulamanın zamanında çalıştığından emin olmak için hangi düğüm görüntüsü işletim sistemini kullanırsanız kullanın ayarlayın.
• Bu güncelleştirmeler işletim sistemi düzeyinde güvenlik, uyumluluk ve işlevsel güncelleştirmeler, işletim sistemi yapılandırma ayarları ve AKS bileşen güncelleştirmelerini içerir.
• Görüntü sürümleri ve bunların dahil edilen bileşen sürüm numaraları AKS yayın izleyicisi kullanılarak izlenir.

Kümenizin güvenlik gereksinimleri daha agresif bir düzeltme eki uygulama temposu istiyorsa ve kümeniz olası kesintileri tolere edebilirse, bunun yerine yükseltme kanalını SecurityPatch kullanın. Microsoft bu güncelleştirmeleri de test ediyor. Güncelleştirmeler yalnızca Microsoft'un bir sonraki zamanlanmış düğüm görüntüsü yükseltmeden önce yayınlanması için yeterli öneme sahip olduğunu düşündüğü güvenlik yükseltmeleri varsa yayımlanır. Kanalı kullandığınızda SecurityPatch , kanalın aldığı güncelleştirmeleri NodeImage de alırsınız. Kanal SecurityPatch seçeneği bakım pencerelerinizi kullanmaya devam eder, bu nedenle bu beklenmeyen güvenlik güncelleştirmelerini desteklemek için bakım pencerenizde daha sık boşluklar (günlük veya her gün gibi) olduğundan emin olun.

Yerinde yükseltmeler gerçekleştiren kümelerin çoğu ve Unmanaged düğüm görüntüsü yükseltme kanalı seçeneklerinden None kaçınmalıdır.

Kümeye yerinde güncelleştirmeler

Kubernetes hızla gelişen bir platformdur ve düzenli güncelleştirmeler önemli güvenlik düzeltmeleri ve yeni özellikler getirir. Kubernetes güncelleştirmeleriyle güncel kalmanız önemlidir. En son iki sürümde veya N-2 sürümünde kalmalısınız. Yeni sürümler sık sık yayımlandığından Kubernetes'in en son sürümüne yükseltmek kritik önem taşır.

Kümelerin çoğu yerinde AKS sürüm güncelleştirmelerini yeterince dikkatli ve titiz bir şekilde gerçekleştirebilmelidir. Yerinde AKS sürüm yükseltmesi gerçekleştirme riski çoğunlukla yeterli ön üretim testi, kota doğrulaması ve pod kesintisi bütçe yapılandırmasıyla azaltılabilir. Ancak herhangi bir yerinde yükseltme beklenmeyen davranışa neden olabilir. Yerinde yükseltmeler iş yükünüz için çok riskli kabul edilirse, kalan önerileri izlemek yerine AKS kümelerinin mavi-yeşil dağıtım yaklaşımını kullanmanızı öneririz.

Kubernetes kümesini ilk kez dağıtırken küme otomatik yükseltme özelliğinden kaçınmanızı öneririz. Güncelleştirmeler üretim ortamınıza ulaşmadan önce üretim öncesi ortamlarınızda yeni bir AKS kümesi sürümünü test etme zamanı sağlayan el ile bir yaklaşım kullanın. Bu yaklaşım aynı zamanda en yüksek düzeyde tahmin edilebilirlik ve denetim elde eder. Ancak Kubernetes platformuna yönelik yeni güncelleştirmeleri izleme ve kullanıma sunulduklarında yeni sürümleri hızla benimseme konusunda dikkatli olmanız gerekir. Uzun vadeli destek yaklaşımında "güncel kal" yaklaşımını benimsemek daha iyidir.

Azure Event Grid için AKS sistem konusunu kullanarak kümeniz için yeni bir AKS sürümü kullanılabilir olduğunda bildirim alabilirsiniz. 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. Belirli uyumluluk endişeleri, davranış değişiklikleri veya özellik kullanımdan kaldırma işlemleri için AKS sürüm notlarını gözden geçirin.

Otomatik yükseltme özelliğini keşfetmek için Kubernetes sürümleri, AKS sürümleri, kümeniz, küme düzeyi bileşenleri ve iş yükü ile sonunda güven noktasına ulaşabilirsiniz. Üretim sistemleri için, ötesine patchgeçmek nadir olacaktır. Ayrıca AKS sürümünüzü otomatik olarak yükseltirken, eşitlemeden çıkmamaları için kümeniz için kod olarak altyapınızın (IaC) AKS sürümü ayarını da denetleyin. Planlı bakım pencerenizi otomatik yükseltme işlemini destekleyecek şekilde yapılandırın.

Güvenlik izleme

Kapsayıcı altyapınızı hem etkin tehditler hem de olası güvenlik riskleri için izleyin. Bazı kaynaklar şunlardır:

• Kapsayıcı görüntülerinize yönelik Bulut için Defender önerilerini belirlemek ve düzeltmek için Kapsayıcılar için Microsoft Defender.
• Kapsayıcılar için Defender, kapsayıcı görüntülerinizi düzenli aralıklarla güvenlik açıklarına karşı tarar.
• Kapsayıcılar için Defender, şüpheli etkinlikler için gerçek zamanlı güvenlik uyarıları da oluşturur.
• Uygulamalar ve kümeler için AKS Güvenliği kavramları, kapsayıcı güvenliğinin derlemeden AKS'de çalışan uygulama iş yüklerine kadar uçtan uca işlem hattının tamamını nasıl koruduğu hakkında bilgi sağlar.

Küme ve iş yükü işlemleri

Küme ve iş yükü işlemleri (DevOps) ile ilgili dikkat edilmesi gerekenler için operasyonel mükemmellik tasarım ilkeleri sütununa bakın.

Küme önyüklemesi

Sağlamayı yaptıktan sonra çalışan bir kümeniz olur, ancak iş yüklerini dağıtmadan önce bazı gerekli adımlara sahip olabilirsiniz. Kümenizi hazırlama işlemine bootstrapping adı verilir. Bootstrapping, önkoşul görüntülerini küme düğümlerine dağıtma, ad alanları oluşturma ve kuruluşunuzun kullanım örneğinin gereksinimlerini karşılayan diğer görevleri yerine getirme işlemlerinden oluşabilir.

Sağlanan küme ile düzgün yapılandırılmış küme arasındaki boşluğu azaltmak için, küme işleçleri benzersiz önyükleme işlemlerinin nasıl göründüğünü düşünmelidir. İlgili varlıkları önceden hazırlamaları gerekir. Örneğin, uygulama iş yüklerini dağıtmadan önce her düğümde Kured'in çalıştırılması önemliyse, küme işleci, kümeyi sağlamadan önce hedef Kured görüntüsünü içeren bir Container Registry örneğinin zaten var olduğunu doğrulamalıdır.

Aşağıdaki yöntemlerden birini kullanarak önyükleme işlemini yapılandırabilirsiniz:

• GitOps Flux v2 küme uzantısı
• Pipelines
• Flux veya Argo CD ile kendi kendine yapılandırma, örneğin

AKS için GitOps Flux v2 küme uzantısını kullanmanın temel avantajlarından biri, sağlanan kümeyle önyükleme yapılan küme arasında etkili bir boşluk olmamasıdır. Ortamı daha sonra sağlam bir yönetim temeli ile ayarlar ve ayrıca IaC stratejinizle uyumlu hale getirmek için bu önyüklemeyi kaynak şablonları olarak dahil etme desteği sunar.

Son olarak, uzantıyı kullanırken önyükleme işleminin herhangi bir parçası için kubectl gerekli değildir. Acil durum düzeltme durumları için kubectl tabanlı erişimi ayırabilirsiniz. Azure kaynak tanımlarına yönelik şablonlar ile GitOps uzantısı aracılığıyla bildirimlerin önyüklemesi arasında kubectl kullanmanıza gerek kalmadan tüm normal yapılandırma etkinliklerini gerçekleştirebilirsiniz.

İş 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. Merkez ve uçlar ve ayrıca bu ağlar içindeki alt ağlar için sanal ağlar sağlayın. Örneğin, bir 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ğ dağıtın.

Bir diğer görev de temel iş yükünü Microsoft Entra Id ile tümleştirmektir.

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. Bicep, Azure Resource Manager şablonları (ARM şablonları) veya Terraform kullanabilirsiniz.

İdare ilkelerine göre kaynak sağladığından emin olun. Örneğin, VM boyutlarını seçtiğinizde, uygulamanızın gereksinimlerini karşılamak için maliyet kısıtlamaları ve kullanılabilirlik alanı seçeneklerinin içinde kalın. Kuruluşunuzun bu kararlara yönelik ilkelerini zorunlu kılmak için Azure İlkesi de kullanabilirsiniz.

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

Betiklerinizi ve şablon dosyalarınızı kaynak denetim sisteminizde depolayın ve sürüm oluşturun.

İş Yükü CI/CD

İş akışı ve dağıtım işlem hatlarının sürekli olarak uygulama oluşturabilmesi ve dağıtabilmesi gerekir. Güncelleştirmelerin güvenli ve hızlı bir şekilde dağıtılması ve sorun olması durumunda geri alınması gerekir.

Dağıtım stratejinizin güvenilir ve otomatik bir sürekli teslim işlem hattı içermesi gerekir. İş yükü kapsayıcı görüntülerinizdeki değişiklikleri kümeye otomatik olarak dağıtın.

Bu mimaride GitHub Actions iş akışını ve dağıtımı yönetir. Diğer popüler seçenekler arasında Azure DevOps 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. Üretime dağıtmadan önce yeni bir sürümün yayımlanması ve bu sürümde doğrulama 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 kümeyi önyüklemektir. GitOps yaklaşımı, operatörlerin 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ılacağını görmesine olanak sağladığından kullanışlıdır.

GitOps kullandığınızda, 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.
• İstenen çalışan yapılandırmayı bu değişikliklere göre güncelleştirir.

Ayrıca, 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 bir 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.

Git sunucunuzda dal ilkeleriniz olabilir, böylece birden çok geliştirici değişiklik üretime uygulanmadan önce bir çekme isteği aracılığıyla değişiklikleri onaylayabilir.

GitOps ve Flux'u el ile yapılandırabilirsiniz ancak AKS için Flux v2 küme uzantısına sahip GitOps'u öneririz.

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

Mimari bileşenleri, iş yükü ve küme yapılandırması gibi tüm değişiklikleri en az bir üretim öncesi AKS kümesine dağıtın. Bunun yapılması değişikliğin benzetimini yapar ve üretime dağıtılmadan önce sorunları tanımlayabilir.

Sonraki aşamaya geçmeden önce her aşamada testleri ve doğrulamaları çalıştırın. Güncelleştirmeleri üretim ortamına yüksek denetimli bir şekilde gönderebilmenizi ve tahmin edilmeyen dağıtım sorunlarından kaynaklanan kesintiyi en aza indirmenize yardımcı olur. 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şlemler ve potansiyel olarak ek araçlar gerekir. Flagger , gelişmiş dağıtım senaryolarını çözmeye 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 kullandığınız hizmetlerin maliyetlerini tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Diğer en iyi yöntemler için bkz . Maliyet İyileştirme.

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

Windows'a özgü maliyet yönetimi konuları hakkında bilgi için bkz . AKS üzerinde Windows kapsayıcıları.

uygulamasını hazırlama

• Maliyetlerinizin nereden geldiğini anlama. Kubernetes kümesinin dağıtım, yönetim ve işlemlerinde AKS ile ilişkili en düşük maliyetler vardır. Maliyeti etkileyen, küme tarafından kullanılan VM örnekleri, depolama, 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 serisi, 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ı kullanmayı göz önünde bulundurun.

  AKS iş yükü mimarisinin bir 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.

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

• Kubernetes'in kapasiteye donanım kullanabilmeniz için düğüm kaynaklarını daha yüksek yoğunlukta ayırmasına izin vermek için pod isteklerini ve sınırlarını ayarlayın.

• Kümede tanılamayı etkinleştirdiğinizde maliyeti artırabileceğini göz önünde bulundurun.

• İş yükünüz uzun bir süre için mevcut olması gerekiyorsa düğüm maliyetlerini azaltmak için bir veya üç yıllık Azure Ayrılmış Sanal Makine Örneklerine bağlanın. Daha fazla bilgi için bkz . Azure Ayrılmış Sanal Makine Örnekleri ile maliyet tasarrufu yapma.

• Düğüm havuzları oluştururken etiketleri kullanın. Etiketler, tahakkuk eden maliyetleri izlemek için özel raporlar oluşturduğunuzda yardımcı olur. Toplam giderleri izlemek ve herhangi bir maliyeti belirli bir kaynak veya ekiple eşlemek için etiketleri kullanabilirsiniz. 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.

• İş yükünüz çok bölgeliyse ve verileri bölgeler arasında çoğaltıyorsanız ek bant genişliği maliyetleri bekleyebilirsiniz. Daha fazla bilgi için bkz . Bant genişliği fiyatlandırması.

• Kuruluşunuzun belirlediğini maliyet kısıtlamalarının içinde kalmak için bütçeler oluşturun. Microsoft Maliyet Yönetimi aracılığıyla bütçe oluşturabilirsiniz. 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

Kümenin tamamını ve işlem, depolama, bant genişliği, günlükler ve güvenlik duvarının maliyetini izleyebilirsiniz. Azure, maliyetleri izlemek ve analiz etmek için seçenekler sağlar:

• Azure Danışmanı

• Microsoft Maliyet Yönetimi

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

Veri odaklı kararlar almak için, en fazla maliyetin ayrıntılı düzeyde hangi kaynakta olduğunu kesin olarak belirleyin. Ayrıca, kaynak kullanımını hesaplayan ölçümler hakkında da bilgi sahibi olun. Örneğin, ölçümleri analiz ederek platformun fazla büyük olup olmadığı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 kullanılmayan düğümleri algılamak ve kaldırmak için küme otomatik ölçeklendiricisini etkinleştirin.

  Önemli

  Maliyetleri etkilemek için düğüm havuzu için en düşük ve en yüksek düğüm ayarları gibi küme otomatik ölçeklendiricisi ayarlarının agresif bir şekilde değiştirilmesi, ters sonuç verebilir. Örneğin, 10 dakika olarak ayarlanırsa ve en düşük ve en yüksek düğüm ayarları iş yükü özelliklerine göre beş dakikada bir değiştirilirse scale-down-unneeded-time , düğüm sayısı hiçbir zaman azalmaz. Bunun nedeni, küme otomatik ölçeklendirici ayarlarının yenilenmesi nedeniyle her düğüm için gereksiz sürenin hesaplanmasıdır.

• İş 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ırma 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şlatma/durdurma özelliğini kullanmayı göz önünde bulundurun.

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

Sonraki adımlar

• Gelişmiş AKS mikro hizmetler mimarisi
• Çoklu bölge kümeleri için AKS temeli
• PCI-DSS 3.2.1 için AKS tarafından düzenlenen küme
• AKS temel başvuru mimarisinde Windows kapsayıcıları

İlgili kaynaklar

• GitHub'da AKS yol haritası
• Kubernetes'e giriş
• Kubernetes'te uygulama geliştirme ve dağıtma
• AKS için İyi Tasarlanmış Çerçeve gözden geçirmesi
• AKS giriş bölgesi hızlandırıcısı
• AKS 2. gün işlemleri kılavuzu
• AKS'de mikro hizmetler mimarisi
• AKS kümesini korumaya yardımcı olmak için Azure Güvenlik Duvarı kullanma
• AKS için Git işlemleri
• AKS ile veri akışı