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

Azure Application Gateway

Azure Container Registry

Azure Güvenlik Duvarı

Azure Kubernetes Service (AKS)

Azure Rol tabanlı erişim denetimi

Bu makalede, bir Azure Kubernetes Service (AKS) kümesi dağıtmak için önerilen temel altyapı mimarisi sağlanır. Tasarım ilkelerimizi izler ve Azure Well-Architected Framework'den AKS architectural best practices ile uyumludur. Makale, bu genel amaçlı altyapıyı dağıtırken ağ, güvenlik ve kimlik ekipleri gibi farklı disiplinler arası grupları yönlendirir.

Bu mimari bir iş yüküne odaklanmaz. AKS kümesinin kendisine odaklanır. Bu bilgiler, AKS kümelerinin çoğu için önerilen en düşük temeldir. Gözlemlenebilirlik sunan, ç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 hizmetlerle tümleştirilir.

İş gereksinimleriniz hedef mimariyi etkiler ve 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.

Tip

Bu makalede AKS kümeleri için kapsamlı tasarım konuları ele alınıyor. AKS Otomatik , değerlendirmeniz gereken önemli noktaların sayısını azaltmak ve yaygın kullanım örnekleri için iyileştirmek için birçok tasarım kararı uygular. Örneğin AKS Otomatik, yönetilen bir sistem düğümü havuzu sağlar ve çalıştırır; bu nedenle bu makaledeki sistem düğümü havuzu boyutlandırma, yalıtım ve yükseltme kararları bu platform için geçerli değildir.

İş yükünüz AKS Otomatik ortamında barındırılacak olsa bile, kendi kendine yönetilen aks kümesinin temellerini bilmek, iş yükünüz değiştikçe doğru seçimleri yapmanıza yardımcı olabilir.

Kubernetes, Azure ve Microsoft teknolojilerinin ötesine uzanan geniş bir ekosistemdir. AKS kümesini dağıtırken, kümeyi tasarlama ve çalıştırma hakkında birçok karardan siz sorumlu olursunuz. AKS kümesini çalıştırmak, Microsoft dahil olmak üzere çeşitli satıcıların kapalı kaynak bileşenlerinin yanı sıra Kubernetes ekosisteminden açık kaynak bileşenleri içerir. Ortam sık sık değişir, bu nedenle kararları düzenli olarak gözden geçirin. Kubernetes'i benimsediğinizde, iş yükünüzün özelliklerine ihtiyacı olduğunu ve iş yükü ekibinizin sürekli olarak yatırım yapmaya hazır olduğunu kabul etmiş olursunuz.

Bu mimarinin bir uygulamasını GitHub: AKS temel başvuru uygulaması alternatif bir başlangıç noktası olarak kullanabilir ve gereksinimlerinizi karşılayacak şekilde yapılandırabilirsiniz.

Note

Başvuru mimarisi, Kubernetes ve kavramları hakkında bilgi gerektirir. Eğer bir bilgi tazeleme ihtiyacınız varsa, Kubernetes'e Giriş ve Kubernetes Üzerinde Uygulama Geliştirme ve Dağıtma eğitim yollarına bakın.

Ağ yapılandırması

Ağ topolojisi
IP adreslerini planlama
Uygulama yönlendirme

Küme işlem

Temel küme için işlem
Kapsayıcı görüntü referansı
Politika yönetimi

Kimlik yönetimi

Kümeye Microsoft Entra ID'yi Entegre Edin
İş yükü için Microsoft Entra ID'yi entegre edin

Güvenli veri akışı

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

İş sürekliliği

Düğüm ve pod ölçeklenebilirliği
İş sürekliliği kararları
Availability zonesKultiple bölgeleri

Operations

Küme ve iş yükü işlemleri
Günlükleri ve ölçümleri izleme ve toplama
Maliyet yönetimi

Architecture

Diyagramda iki bağlı sanal ağ gösterilmektedir. Merkez sanal ağı Azure Güvenlik Duvarı, Azure Bastion ve şirket içi ağa bağlı bir ağ geçidi alt ağını içerir. Uç sanal ağ birkaç alt ağ, AKS kümesi ve düğüm havuzları içerir. Virtual network eşlemesi, merkez ve uç sanal ağlarını çift yönlü bir bağlantı üzerinden bağlar. Key Vault ve Container Registry'den Özel Bağlantı uç noktalarının bulunduğu alt ağa oklar işaret eder. Azure Bastion alt ağı (yönetim) ile çevresel sanal ağdaki iç yük dengeleyiciye işaret eden bir ok. Bir ok, şirket içi ağdan şirket içi ağ geçidine işaret eder. Merkez sanal ağdan uzak ofis bağlantısına, sanal ağ eşlemesi etiketli çift yönlü ok. İnternet'ten Azure Application Gateway alt ağa işaret eden bir ok. AKS kümesinden, ölçümleri ve yönetilen Prometheus'u içeren Azure İzleyici çalışma alanı bölümüne bir ok uzanır.

Bu mimarinin Visio dosyasını indirin.

Daha fazla bilgi için, Azure'da Hub-spoke ağ topolojisi bölümüne bakın.

Ağ topolojisi

Bu mimaride merkez-uç ağ topolojisi kullanılır. Hub ve uçları sanal ağ eşleme aracılığıyla bağlanan ayrı sanal ağlarda dağıtın. Bu topolojinin çeşitli avantajları vardır:

• Ayrılmış yönetimi etkinleştirin. İdare uygulayabilir ve en az ayrıcalık ilkesine (PoLP) bağlı kalabilirsiniz. Ayrıca, görev ayrımı ile 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-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ı olmak için bir web application firewall 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ı ağlar arasında paylaşmayı destekler.

• Azure kurumsal ölçekli giriş bölgesi ile hizalayın.

Merkez sanal ağı

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

• Merkezi BT ekiplerinizin kuruluş genelinde kuralları zorunlu kılmak için tanımlamış olduğu genel güvenlik duvarı ilkeleriyle Azure Güvenlik Duvarı

• küme yönetimi işlemlerini gerçekleştirebilmeniz için özel ağ çevresine güvenli bir tünel oluşturan Azure Bastion

• VPN bağlantısı için bir ağ geçidi alt ağı

• Ağ gözlemlenebilirliği için Azure İzleyici

Ağda, mimaride üç alt ağ bulunmaktadır.

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

Azure Güvenlik Duvarı yönetilen bir 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 olmayan bir hizmetle iletişim kurabilir. Birden çok Azure Güvenlik Duvarı örneğini merkezi olarak dağıtmak ve yapılandırmak ve bu hub sanal ağı mimari türü için Azure Güvenlik Duvarı ilkelerini yönetmek için Azure Güvenlik Duvarı Yöneticisi kullanın.

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

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 virtual network arasında bağlantı sağlar.

Azure Bastion'u barındıracak alt ağ

Bu alt ağ Azure Bastion için kullanılır. Azure Bastion kullanarak kaynakları İnternet'e göstermeden Azure kaynaklara güvenli bir şekilde erişebilirsiniz. Bu mimari, yönetim işlemleri için AKS kümesinin API sunucusuna güvenli bir şekilde bağlanmak için Azure Bastion kullanır. Alt ağ yalnızca yönetim işlemleri içindir.

Çıkış sanal ağ

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

Azure Application Gateway’in barındırılması için kullanılan alt ağ

Azure Application Gateway Katman 7'de çalışan bir web trafiği yük dengeleyicidir. Başvuru uygulaması, Azure Web Uygulaması Güvenlik Duvarı'yi 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. Örnek, kullanıcı isteklerini alan genel bir ön uç IP yapılandırmasına sahiptir. Tasarım gereği Application Gateway ayrılmış bir alt ağ gerektirir.

İç yük dengeleyici IP'leri için alt ağ

Bu alt ağ, iç yük dengeleyici ön uç IP'leri için adres alanı sağlar. Application Gateway, trafiği atanan özel iç yük dengeleyici IP'sine gönderir ve yük dengeleyici trafiği kümedeki herhangi bir düğüme dağıtır.

Paketi alan düğümdeki kube-proxy aracı, paketi sistem düğümü havuzundaki ağ geçidi proxy pod'una iletir ve ek bir ağ sıçramasına neden olabilir. Ara sunucu Aktarım Katmanı Güvenliği'ni (TLS) sonlandırır ve istekleri HTTP üzerinden iş yükü podlarına iletir.

Ön uç yük dengeleyici IP'leri için ayrılmış bir alt ağ kullanarak, düğüm alt ağını etkilemeden yük dengeleyiciye gelen trafiğin kapsamını oluşturan ağ güvenlik grubu (NSG) kuralları uygulayabilirsiniz. Daha fazla bilgi için AKS ile bir iç yük dengeleyici kullanma bölümüne bakın.

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

Bu mimaride, ayrı düğüm grupları olan iki düğüm havuzu kullanılır. Sistem düğümü havuzu, trafiği iş yüküne yönlendiren ağ geçidi ara sunucusu da dahil olmak üzere çekirdek küme hizmetlerini çalıştıran podları barındırıyor. Kullanıcı düğüm havuzu iş yükünü çalıştırır.

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

Azure Container Registry ve Azure Key Vault için Azure Özel Bağlantı bağlantıları oluşturun; böylece kullanıcılar uç sanal ağındaki private uç noktası üzerinden bu hizmetlere erişebilir. Özel uç noktalar için ayrılmış alt ağ gerekmez. Hub sanal ağına özel uç noktaları da yerleştirebilirsiniz. Temel uygulamada, uç noktalar konuşlandırılmış sanal ağ içerisindeki ayrılmış bir alt ağa dağıtılır. Bu yaklaşım, eşlenmiş ağ bağlantısından geçen trafiği azaltır ve kümeye ait kaynakları aynı sanal ağda tutar. Ayrıca NSG'leri kullanarak alt ağ düzeyinde ayrıntılı güvenlik kuralları uygulayabilirsiniz.

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

AKS API sunucusu alt ağı

Bir AKS kümesini, API sunucusu sanal ağ tümleştirmesi kullanacak şekilde yapılandırabilirsiniz. Bu, kümenin API sunucusu uç noktasını sanal ağınızdaki bir yetkilendirilmiş alt ağa projelendirir. API sunucusu, düğüm havuzları ve bağlı istemciler arasındaki tüm trafiğin tamamen özel ağınızda kalmasını sağladığından bu yapılandırma özel küme olarak adlandırılır.

AKS tarafından yönetilen Kubernetes API sunucusu ile hem küme içi hem de dış istemciler arasındaki tüm iletişim güvenilen bir ağ ile sınırlıdır.

Özel küme ile ortamınızın güvenliğini sağlamak için NSG'leri ve diğer yerleşik ağ denetimlerini kullanabilirsiniz. Bu yapılandırma, internet ile ortam arasında yetkisiz kamusal erişimi engeller. Daha fazla bilgi için bkz. Özel AKS kümesi oluşturma.

IP adreslerini planlayın

Diyagramda basit bir AKS merkez-uç ağ topolojisi gösterilmektedir. Hub sanal ağı, Azure Güvenlik Duvarı, Azure Bastion ve bir geçit alt ağı içerir. İkincil sanal ağ, Application Gateway, ingress, düğümler, özel uç noktalar ve özel küme için alt ağlar içerir. Oklar, uç ağlardan merkez ağına olan eş ağ bağlantılarını gösterir.

Bu mimarinin Visio dosyasını indirin.

Bu başvuru mimarisi, her biri ayrı bir IP adresi alanı gerektiren aşağıdaki ağ yaklaşımlarını kullanır.

• Küme düğümleri, küme API sunucusu, Azure hizmetleri için özel uç noktalar ve Application Gateway gibi kaynaklar için kullandığınız Azure sanal ağınız.

• Kümenin, Azure sanal ağınızdan ayrı bir adres alanından podlara IP adresleri ayırmak için kullandığı Azure Kapsayıcı Ağı Arabirimi (CNI) Katmanı.

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ı hesaplayın. Kubernetes, alt ağ adres alanından varlıklar için IP adresleri ayırır. Azure sanal ağınızın IP adreslerini planlarken aşağıdaki noktaları göz önünde bulundurun:

• Yükseltmeler: AKS, arka plandaki VM'lerin güvenlik özellikleri ve diğer sistem yamaları açısından 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üğüm, küme alt ağından bir IP adresi alır. 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 Üst Üste Binen pod adres alanının içinden IP adresleri tahsis edilir. Bu yaklaşım, Azure sanal ağınızdan kullanılan IP adreslerinin genel sayısını diğer Kubernetes ağ yaklaşımlarıyla karşılaştırıldığında azaltır.

• Ölçeklenebilir -lik: Sistem ve kullanıcı düğümlerinin toplam sayısını ve bunların en yüksek ölçeklenebilirlik sınırlarını göz önünde bulundurun. Örneğin, %400'lik bir ölçeklendirme istiyorsanız, tüm ölçeklendirilmiş düğümler için adres sayısının dört katına ihtiyacınız vardır.

  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: Diğer Azure hizmetleriyle Özel Bağlantı aracılığıyla iletişim sağlamak için gereken adresleri göz önünde bulundurun. Bu mimari, Container Registry ve Key Vault bağlantıları için atanmış iki adrese sahiptir.

• Özel küme API sunucusu adresleri: API sunucusunun sanal ağ ile entegrasyonu, AKS API sunucusunu sanal ağınız içinde bir uç nokta olarak yansıtmanıza yardımcı olur. Bu özellik için minimum alt ağ boyutu gerekir; bu nedenle ağ planlamanız sırasında bu önkoşulları karşıladığınızdan emin olun.

• Rezerve IP adresleri: Azure, kendi kullanımları için belirli adresleri 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 da isteyebilirsiniz. Bu yalıtım, daha küçük alt ağlara neden olur. Her Ağ Geçidi kaynağı kendi ağ geçidi ara sunucusu dağıtımını ve yük dengeleyici ön uç IP'sini ürettiğinden ağ geçidi topolojisi de genişleyebilir. Alt ağ adres alanını uygun şekilde planlayın.

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ız veya eşlenmiş sanal ağlarınız ile çakışmayan bir IP adres alanı kullanın. Ancak birden çok AKS kümesi oluşturursanız, her kümede aynı pod adres alanını güvenle kullanabilirsiniz.

Azure CNI Overlay her düğüme podları için bir /24 adres alanı atar. Pod adres alanının yeterince büyük olduğundan emin olmak önemlidir. Kümenizdeki düğüm sayısı için gereken sayıda /24 bloğu sağlayın. Yükseltmeler veya ölçeği genişletme işlemleri sırasında oluşturulan geçici düğümleri eklemeyi unutmayın. Örneğin, Sınıfsız Inter-Domain Yönlendirme (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 adreslemeyi planlama hakkında daha fazla bilgi almak için Azure CNI ağını AKS'de yapılandırma'ya bakın.

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. Önizleme özellikleri ve eklentiler arasındaki aşağıdaki farkları göz önünde bulundurun:

• AKS ekibi, önizleme özelliklerini yayınlandı ve geliştiriliyor olarak tanımlar, çünkü birçok önizleme özelliği, genel kullanılabilirlik (GA) aşamasına geçmeden önce yalnızca birkaç ay bu durumda kalır.

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

Temel mimari her önizleme özelliğini veya eklentiyi içermez, 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ümelerdeki diğer bazı önizleme özelliklerini veya AKS eklentilerini değerlendirmek isteyebilirsiniz. Bu özellikler güvenliğinizi, yönetilebilirliğinizi veya diğer gereksinimlerinizi iyileştirebilir. Kullanılabilir sürümleri izleme ve kümenin Kubernetes sürümünü yükseltdikten sonra güncelleştirmeleri yükleme gibi Microsoft olmayan eklentileri yüklemeniz ve korumanız gerekir.

Kapsayıcı imaj başvurusu

Küme, iş yükünü ve kendi kendine yönetilen ağ geçidi altyapısı veya TLS sertifikalarını Key Vault’tan eşitleyen bir yardımcı kapsayıcı gibi başka birkaç imajı içerebilir. Bu görüntülerin bazıları genel kayıt defterlerinde bulunabilir, ancak taranmalarını, denetlenmelerini ve Azure Container Registry gibi özel bir kayıt defterinde depolanmalarını sağlamak iyi bir uygulamadır. Görüntüleri kümenize çekerken aşağıdaki noktaları göz önünde bulundurun:

• Görüntüyü çekmek için kümeyi kimlik doğrulamasından geçir.

• Genel görüntü kullanıyorsanız, görüntüyü hizmet düzeyi hedefinizle (SLO) uyumlu bir 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, işlem sorunları oluşabilir. Genel kayıt defteri yerine Azure Container Registry gibi özel bir kapsayıcı kayıt defteri kullanmanın aşağıdaki avantajlarını göz önünde bulundurun:

  • Resimlerinize yetkisiz erişimi engelleyebilirsiniz.
  • Genel kullanıma yönelik bağımlılıklarınız yoktur.
  • Etkinlikleri izlemek ve bağlantı sorunlarını çözmek 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. Referans uygulamasında küme, görüntüleri yalnızca kümeyle birlikte dağıtılan özel Azure Container Registry örneğinden çeker.

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

AKS'de her düğüm havuzu genellikle bir sanal makine ölçek kümesiyle eşlenir. Düğümler her düğüm havuzunda virtual machines (VM) olur.

Maliyetleri en aza indirmek için sistem düğümü havuzu için daha küçük bir VM boyutu kullanmayı göz önünde bulundurun. Referans uygulama, sistem düğümü havuzunu üç D2dv5 düğümüyle dağıtır. Bu boyut, sistem podlarının beklenen yükünü karşılamak için yeterlidir. İşletim sistemi kısa ömürlü diski 64 GB'tır.

Bir kullanıcı düğümü havuzu için kapasiteyi planlarken aşağıdaki önerileri göz önünde bulundurun:

• 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 etkisini 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'daki VM'ler için Boyutlar.

• İş yükünün iki kopya ile yüksek kullanılabilirlik modelini izleyebilmesi için en az iki düğüm dağıtın. AKS ile kümeyi yeniden oluşturmadan düğüm sayısını değiştirebilirsiniz.

• Planlama ekibinizin belirlediği gereksinimlere göre iş yükünüz için düğüm boyutlarını planlayın. bu mimari, iş gereksinimlerine göre üretim iş yükü için D4dv5 SKU'yu kullanır.

• Kümeniz için kapasiteyi planlarken, iş yükünüzün her düğümün en fazla 80% tükettiği varsayın. Kalan %20 AKS hizmetleri için ayrılmıştır.

• Kapasite planlamanıza göre her düğüm için en yüksek pod sayısını ayarlayın. Kapasite temeli oluşturmaya çalışırsanız 30 değeriyle başlayın. bu değeri iş yükünün gereksinimlerine, düğüm boyutuna ve IP adresi 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. Başvuru uygulaması, Azure için ayarlanmış basit, sağlamlaştırılmış bir Linux dağıtımı olan Azure Linux'ı kullanır. İsterseniz veya Azure Linux gereksinimlerinizi karşılamıyorsa Ubuntu gibi başka bir Linux dağıtımı seçebilirsiniz. Farklı bir işletim sistemi seçerseniz işletim sistemi diskinin bu görüntü için uygun şekilde boyutlandırılmış olduğundan emin olun. Bazı dağıtımlar Azure Linux'tan daha fazla alan gerektirdiğinden, dağıtım veya çalışma zamanıyla ilgili sorunları önlemek için disk boyutunu artırmanız gerekebilir.

İş yükünüz karma teknolojilerden oluşuyorsa farklı düğüm havuzlarında farklı işletim sistemleri kullanabilirsiniz. Farklı işletim sistemlerine ihtiyacınız yoksa, işletim karmaşıklığını azaltmak için tüm iş yükü düğümü havuzları için tek bir işletim sistemi kullanmanızı öneririz.

Küme için Microsoft Entra ID'yi tümleştirin

Kümeye ve kümeden erişim güvenliğini sağlamak kritik önem taşır. içten dışa ve dıştan içe trafik arasındaki farkı anlamak için kümenin bakış açısından yararlanın.

• Inside-out access: 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ı yetkilendirin.

• Dışarıdan erişim: Kubernetes kümesine erişimi olan kimlikler sağlayın. Yalnızca Kubernetes API sunucusuna ve Azure Resource Manager erişimine izin verilen dış varlıkları yetkilendirir.

Azure bileşenlerine AKS erişimi

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

Azure'da AKS erişimini yönetmek için iki yöntemden birisi olarak yönetilen kimlikleri öneririz. Hizmet sorumluları için gizli dizileri el ile veya program aracılığıyla yönetmeniz ve döndürmeniz gerekir. Yönetilen kimlikler için Microsoft Entra ID, kimlik doğrulamayı ve gizli anahtarların zamanında yenilenmesini yönetir ve gerçekleştirir.

Kümenin Microsoft Entra ID aracılığıyla dış Azure kaynaklarıyla etkileşim kurabilmesi için AKS yönetilen kimlikleri etkinleştirmenizi ve kullanmanızı öneririz. Microsoft Entra ID tümleştirmesini hemen kullanmıyorsanız daha sonra ekleyebilirsiniz.

Varsayılan olarak, küme iki birincil kimlik kullanı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 adresleri de 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 kimlik kullanmalısınız. Bu eylem, kümenin kayıt defteri kimlik bilgilerini almasını gerektirir; buna, kümenin kubelet tarafından yönetilen kimliğine AcrPull kayıt defterinize erişim vererek izin verirsiniz. Yönetilen bir kimlik kullanmıyorsanız, bu bilgiyi bir Kubernetes secret'ında depolayabilir ve bunu almak için imagePullSecrets kullanabilirsiniz. Gizli diziyi önceden bilmek ve DevOps işlem hattında depolamak gibi güvenlik karmaşıklıkları içerdiğinden bu yaklaşımı önermeyiz. Ayrıca, sırrı güncellemeniz gerektiğinden operasyonel yük de artar.

Bu mimaride küme, Microsoft Entra ID güvenli Azure kaynaklara 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) rollerini ve izinlerini kümenin yönetilen kimliklerine atayın. Küme, Microsoft Entra ID için kimliğini doğrular ve kendisine atanan rollere göre erişim izni verilir veya erişim reddedilir. Başvuru uygulamasından alınan aşağıdaki örnekler, kümeye atanmış Azure yerleşik rolleri gösterir:

• Network Katılımcı rolü kümenin uç sanal ağ denetleme yeteneğini yönetir. Bu rol atamasıyla, AKS kümesinin sistem tarafından atanan kimliği, ağ geçidi ara sunucusuna ve AKS özel API sunucusuna hizmet veren iç yük dengeleyici için ayrılmış alt ağla etkileşim kurabilir.

• Özel DNS Bölge Katılımcısı rolü, kümenin bölgeyi doğrudan kümeyi barındıran uç sanal ağına bağlama becerisini yönetir. Özel küme, özel dns bölgesi kullanarak DNS kayıtlarını genel İnternet'in dışında tutar, ancak yine de genel DNS adresiyle özel bir AKS kümesi oluşturmak mümkündür. Kontrol düzleminizin özel IP adresinin ifşa edilmesini önlemek için, enablePrivateClusterPublicFQDN değerini false olarak ayarlayarak bu özelliği açıkça devre dışı bırakmanızı öneririz. Genel DNS kayıtları olmadan özel kümelerin kullanımını zorlamak için Azure İlkesi kullanmayı göz önünde bulundurun.

• Monitoring Metrics Publisher rolü kümenin Azure İzleyici ölçüm gönderme özelliğini yönetir.

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

İki AKS eklentisi, rol atamaları gerektiren ek yönetilen kimlikler sağlar. Secrets Store CSI Driver eklentisinin kimliği, TLS sertifikalarını Key Vault'tan alır. Uygulama yönlendirme eklentisi kimliği, DNS kayıtlarını ve Ağ Geçidi mutabakatını yönetir.

Bu iki kimlikle etkileşime geçtikleri kaynaklara aşağıdaki erişimi verin:

• Secrets Store CSI Driver eklentisi tarafından yönetilen kimliğin, sürücünün TLS sertifikalarını alabilmesi için anahtar kasanızda Key Vault Certificate User rolüne sahip olması gerekir.

  Note

  Alternatif olarak, CSI Sürücüsü eklentisi yönetilen kimliğini Key Vault erişim için Microsoft Entra İş Yükü Kimliği ile değiştirebilirsiniz. İş Yükü Kimliği'ni kullandığınızda, federasyon kimlik bilgilerini kullanarak kullanıcı tarafından atanan yönetilen kimliği Kubernetes ServiceAccount'a bağlar ve ağ geçidi dinleyicisinin TLS seçeneklerinde ServiceAccount'a başvurursunuz. Uygulama yönlendirme eklentisi daha sonra SecretProviderClass'ı otomatik olarak oluşturur.

  CSI sürücüsü aracılığıyla Key Vault erişim için genellikle eklentinin yönetilen kimliğini veya İş Yükü Kimliğini seçersiniz. İş Yükü Kimliği, ad alanı düzeyinde kimlik yalıtımı sağlar ve federe kimlik bilgileri yoluyla ek kimlik güçlendirmesi getirmesi pahasına manuel kaynak yönetimini azaltır.

• Uygulama yönlendirme eklentisinin yönetilen kimliği, anahtar kasanızda Key Vault Secrets User ve Key Vault Okuyucusu rollerine ihtiyaç duyar. Yerleşik DNS bileşeninin ağ geçidi kaynaklarını eşitleyebilmesi için, bu kimliğin giriş özel DNS bölgesinde de Özel DNS Bölgesi Katkıda Bulunanı rolüne sahip olması gerekir.

  Note

  Eklentiyle dağıtılan yerleşik DNS bileşeni, DNS kayıtlarını otomatik olarak uzlaştırmaz. Ağ Geçidi API'si kayıtları için İş Yükü Kimliği yaklaşımını kullanın.

Daha fazla bilgi için bkz. Azure DNS ve TLS'yi uygulama yönlendirme Ağ Geçidi API uygulamasıyla yapılandırma.

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. Mevcut küme rol izinleri.

AKS, yerel Kubernetes RBAC ile tümleştirilmiş bir kimlik sağlayıcısı olarak Microsoft Entra ID kullanarak veya küme erişimini denetlemek için yerel Azure RBAC kullanarak Microsoft Entra ID aracılığıyla Kubernetes erişimini destekler. Aşağıdaki bölümlerde her iki yaklaşım da ayrıntılı olarak yer almaktadır.

Kubernetes RBAC'i Microsoft Entra ID ile ilişkilendirme

Kubernetes, aşağıdaki API nesneleri aracılığıyla RBAC'yi destekler:

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

• Eylemleri gerçekleştirme iznine sahip kullanıcıları ve grupları atayan bağlamalar. RoleBinding veya ClusterRoleBinding nesnesi kullanarak 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 kuruluş dizinini kullanmak üzere bu rolleri Microsoft Entra kullanıcılara ve gruplara bağlayın. Daha fazla bilgi için Microsoft Entra entegrasyonu ile Kubernetes RBAC kullanma konusuna bakın.

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

Kümede yetkilendirme denetimlerini zorunlu kılmak için Azure RBAC ve Azure rol atamaları kullanmanızı öneririz. Bu yetkilendirme yaklaşımı Microsoft Entra kimlik doğrulamasıyla tümleşir. Yönetim grubu, abonelik veya kaynak grubu gibi çeşitli kapsamlarda roller atayabilirsiniz. Kapsam altındaki tüm kümeler, Kubernetes kümesindeki nesnelere erişim izinlerine sahip olan kişilere göre tutarlı bir rol atamaları kümesini devralır.

ClusterRoleBindings ve RoleBindings ile Kubernetes-native RBAC kullanmanızı önermiyoruz.

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

Yerel hesaplar

AKS, yerel Kubernetes kullanıcı kimlik doğrulama destekler. Kümelere kullanıcı access sağlamak için bu yöntemi kullanmanızı önermiyoruz. Bu yöntem sertifika tabanlıdır ve birincil kimlik sağlayıcınıza dışarıdan gerçekleştirilir, bu da merkezi kullanıcı erişim kontrolü ve yönetimini zorlaştırır. Microsoft Entra ID kullanarak kümenize erişimi her zaman yönetin ve kümenizi yerel hesap erişimini açıkça yasaklaacak şekilde yapılandırın.

Başvuru uygulamasında, sistem kümeyi dağıttığında yerel küme hesaplarına erişim açıkça yasaktır.

İş yükü için Microsoft Entra ID'yi tümleştirin.

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 depolayabilir. Pod’un bu dosyalara erişmesi gerektiğinde, kaynağa karşı Azure yönetilen kimliğiyle kimlik doğrulaması yapar.

Referans uygulamada, AKS üzerinde Microsoft Entra İş Yükü Kimliği, pod’lar için yönetilen kimlikler sağlar. Bu yaklaşım, dış kimlik sağlayıcılarıyla federasyona yönelik Kubernetes yerel özellikleriyle tümleşir. Daha fazla bilgi için İş yükü kimlik federasyonu sayfasına bakın.

Ağ modeli seçme

AKS iki ağ modelinde CNI eklentileri sağlar: katman ve düz. Her iki model de küme içi trafik denetimi için ağ ilkelerini destekler.

Azure CNI Pod Alt Ağı gibi düz bir ağ eklentisiyle, her pod sanal ağ alt ağından bir IP adresi alır. Aynı ağdaki veya eşlenen ağlardaki kaynaklar, ağ adresi çevirisi (NAT) olmadan podlara doğrudan IP adresleriyle erişebilir. İş yükünüz podların sanal ağdan doğrudan yönlendirilebilir olmasını gerektirdiğinde düz ağ modeli kullanın.

Bu uygulama, sanal ağ IP adreslerini yalnızca düğümlere ayıran ve ayrı bir CIDR aralığından pod IP'leri atayan bir katman ağ eklentisi olan Azure CNI Yer Paylaşımını kullanır. Azure CNI Yer Paylaşımı düz modellerden çok daha az sanal ağ IP adresi tükettiğinden, çoğu dağıtım için bunu öneririz.

Modeller hakkında daha fazla bilgi için bkz . AKS CNI ağına genel bakış ve AKS'de ağ bağlantısı ve güvenliği için en iyi yöntemler.

Uygulama yönlendirme

Bu mimari , Kubernetes Gateway API'siyle uygulama yönlendirme eklentisini kullanır. Uygulama yönlendirme eklentisi, kümenin yönetilen ağ geçidi altyapısı içermesi gerektiğini bildiren bir AKS kümesi yapılandırmasıdır. Ağ Geçidi API'si, , , GatewayClassGatewayve diğerleri dahil olmak üzere HTTPRoutekubernetes özel kaynak tanımları (CRD) kümesidir. Kubernetes topluluğu, Ağ Geçidi API'sini önceki Giriş API'sinin ardılı olarak belirlemiştir. Ağ Geçidi API'si, trafik yönetimi için standartlaştırılmış, rol odaklı ve genişletilebilir bir çerçeve sağlar.

Ağ Geçidi API bileşenleri aşağıdaki yaşam döngüsü aşamalarında dağıtılır:

• Küme tasarımı. Uygulama ekibi, hangi ağ geçidi denetleyicisinin giriş trafiğini yönetmesi gerektiğine ve bu denetleyicinin yaşam döngüsünü nasıl yöneteceğine karar verir. Ağ geçidi denetleyicileri genellikle veri düzlemi proxy'lerini bir araya getirir, bu nedenle bu karar trafik yolunu hangi proxy'nin işlediğini de belirler. Bu mimari, yönetilen Gateway API CRD'lerine olanak tanır. Eklentiyi, ağ geçidi denetleyicisi olarak yönetilen Istio'yu kullanacak ve ağ geçidi ara sunucusu olarak Envoy ile eşleşecek şekilde yapılandırır. Istio'yu bir hizmet ağı olarak da kullanabilirsiniz, ancak bu mimari yalnızca ağ geçidi denetleyicisi olarak Istio kullanır ve hizmet ağı özelliklerini etkinleştirmez.

  Ekip farklı bir uygulama gerektiriyorsa NGINX Gateway Fabric, Envoy Gateway ve Traefik gibi diğer Ağ Geçidi API denetleyicilerini kullanabilir. Bu denetleyicilerin kendi kendine yönetilmesi için bildirimlere sahip olmak, benzeşim önleme, düğüm yerleştirme, yoklamalar, RBAC kapsamını belirleme, ölçeklendirme ilkeleri, kaynak IP kısıtlamaları ve sürüm yaşam döngüsü gerekir. Buna karşılık, takımlar ara sunucu davranışı, küme yükseltmelerinden bağımsız sürüm sabitleme ve kısıtlanmamış yapılandırma üzerinde tam idare elde eder.

• Küme oluşturma. Bu aşamada tasarım kararı alınmaz. AKS, Ağ Geçidi API'leri CRD'lerini, Istio ağ geçidi denetleyicisi podlarını aks-istio-system ad alanına ve GatewayClass'ı approuting-istio yükler. Bu aşamada, ağ geçidi proxy’si için veri düzlemi podları bulunmamaktadır.

• Küme önyüklemesi. İş yükü ekibi, ağ geçidi proxy’sinin iç veya dış yük dengeleyici üzerinden erişime açılıp açılmayacağını, yük dengeleyicinin ön uç IP’sine hangi alt ağın ev sahipliği yaptığını ve ağ geçidi proxy’sinin hangi ad alanında çalışacağını belirler. Bu mimaride, ağ geçidi proxy'si bir iç yük dengeleyici üzerinden yayımlanır. Yük dengeleyici IP'leri için ayrılmış bir alt ağ vardır ve ağ geçidi ara sunucusu a0008iş yükü ad alanına dağıtılmıştır.

  approuting-istio GatewayClass’a referans veren bir Ağ Geçidi kaynağı bu kararları ifade eder. Ağ geçidi denetleyicisi, kaynağı Gateway kaynağıyla aynı ad alanında Envoy Gateway proxy dağıtımları, bir LoadBalancer hizmeti, bir HorizontalPodAutoscaler ve bir PodDisruptionBudget hâline gelecek şekilde uzlaştırır.

  Eklentiye özel bir DNS bölgesi eklendiğinde, eklentinin DNS bileşeni DNS A kayıtlarını yönetebilir, böylece kod olarak altyapı (IaC) şablonlarınızda statik kayıtları tutmanız gerekmez. Bootstrapping, Access kümesi gizli dizilerinde açıklanan TLS sertifika eşitleme kaynaklarını da dağıtır.

  Note

  Eklentiyle dağıtılan yerleşik DNS bileşeni, Ağ Geçidi API'si kaynaklarını kullandığınızda DNS kayıtlarını otomatik olarak uzlaştırmaz. Otomatik özel DNS kaydı mutabakatı etkinleştirmek için bir ClusterExternalDNS veya ExternalDNS özel kaynağı dağıtın. Uygulama yönlendirme operatörü bileşeni daha sonra, Gateway ve HTTPRoute kaynaklarını izleyen ve A kayıtlarını bağlı DNS bölgesine yayımlayan yönetilen bir external-dns örneği dağıtır.

  DNS bölgesine yazma işlemi RBAC izinleri gerektirdiğinden, bu tümleştirme; hedef bölgede DNS Bölgesi Katkıda Bulunanı rolüne sahip kullanıcı tarafından atanan bir yönetilen kimliği, kümenin OpenID Connect (OIDC) yayımlayıcısına güvenen federasyon kimlik bilgilerini ve özel bir Kubernetes Hizmet Hesabını içeren Microsoft Entra İş Yükü Kimliği gerektirir. Ek kimlik altyapısı gereksinimlerini güvenlik ve operasyonel gereksinimlerinize göre değerlendirin.

• İş yükü dağıtımı. Uygulama ekibi hangi konak adlarının, yolların ve arka uçların trafik alması gerektiğini tanımlar. Ağ geçidine bağlanan HTTPRoute kaynakları bu yönlendirme kararlarını gösterir. Ağ geçidi denetleyicisi bildirilen yönlendirme davranışını Envoy podlarına iletir.

• Devam eden bakım: Eklenti, Istio ağ geçidi denetleyicisi sürümünü AKS kümesi sürümüyle bağlar, bu nedenle yükseltmeler bağımsız yaşam döngüsü yönetimi gerektirmek yerine küme yükseltmeleri ile birlikte gerçekleşir. Bu eklenti, Istio'yu yalnızca ağ geçidi ara sunucusu yönetimi için kullanır. Sidecar enjeksiyonunu veya ayrı bir eklenti olan tam Istio servis ağını etkinleştirmez.

Note

İş yükünüz, eklentinin henüz desteklemediği özellikler gerektiriyorsa — örneğin Sunucu Adı Göstergesi (SNI) geçişi için TLSRoute, özel Lua veya Wasm eklentileriyle gelişmiş trafik dönüştürmeleri ya da uyumluluk gereksinimleri belirli bir vekil sunucu ürününü zorunlu kılıyorsa — öz yönetimi tercih edin. Ayrıca, proxy'yi küme yükseltmelerinden bağımsız olarak sürüme almanız gerekiyorsa veya iki eklenti birlikte mevcut olmadığından kümeniz zaten Istio hizmet mesh eklentisini kullanıyorsa kendi kendine yönetimi seçin.

Ağ Geçidi ve HTTPRoute kaynaklarını uygulama

Bu mimari, giriş trafiği yönetimi için Kubernetes Gateway API'siyle uygulama yönlendirme eklentisini kullanır. Bu bölüm, önceki bölümde açıklanan küme önyükleme ve iş yükü dağıtım aşamalarını kapsar. Bu noktada ağ geçidi denetleyicisi çalışıyor ve Ağ Geçidi API'sinin kaynaklarının uzlaştırmasını bekliyor.

Ağ Geçidi API'si, uygulamaya özgü ek açıklamalar yerine TLS ilkesini, üst bilgi tabanlı yönlendirmeyi ve trafiğin yerel API alanları olarak bölünmesini ifade eden, satıcıdan bağımsız bir standarttır. Yönlendirme yapılandırmanız belirli bir ara sunucu teknolojisine bağlı olmadığından, temel alınan uygulamayı daha sonra yeniden yazmadan değiştirebilirsiniz. Uygulama yönlendirme eklentisi, ağ geçidi denetleyicisinin ve proxy’nin yaşam döngüsünü yöneterek yükseltmeleri, güvenlik yamalarını, ölçeklendirme yapılandırmasını ve RBAC kapsamlandırmasını yönetme gereksinimini ortadan kaldırır.

Ağ Geçidi API'si girişi birbirinden bağımsız olarak değişen iki kaynağa ayırır:

• Ağ Geçidi kaynağı , kullanıma sunulan bağlantı noktaları ve protokoller, TLS sertifikaları ve iç yük dengeleyici için alt ağ dahil olmak üzere ağ yüzeyini bildirir. Bu kaynak sık değişmez ve kendisine bağlı tüm yolları etkiler.

• HTTPRoute kaynağı yönlendirme mantığını veya hangi konakların, yolların ve üst bilgilerin hangi arka uç hizmetleriyle eşlendiğini bildirir. Bu kaynak her dağıtımda değişir ve kapsamı tek tek hizmetler olarak belirlenmiştir.

Bu mimari, her kaynağın farklı bir değişiklik temposu ve patlama yarıçapı olduğundan, yönlendirme değişikliğinin ağ yapılandırmasını kesintiye uğratması veya tam tersi riskini azaltır. Ayrıca çeşitli bağımlılıkları kaldırır.

• Yönlendirme yapılandırmanız belirli bir ara sunucu teknolojisine bağlı değil.
• Proxy sürümü, bağımsız izleme gerektirmek yerine AKS küme sürümünüzle birlikte taşınır.
• Her Ağ Geçidi kaynağı, tüm yollarda tek bir denetleyici paylaşmak yerine kendi proxy dağıtımını alır.

Yaşam döngüsü aşamaları bölümünde açıklandığı gibi, yapılandırılmış GatewayClass’ı referans alan bir Gateway kaynağı uyguladığınızda, gateway denetleyicisi onu gateway proxy dağıtım kaynaklarına ve destekleyici kaynaklara dönüştürür. Ağ geçidi kaynağındaki altyapı ek açıklamaları aracılığıyla alt ağ yerleşimini denetleyebilirsiniz.

Bu bildirim temelli model, ara sunucu için Helm grafiklerini, kapsayıcı görüntülerini veya dağıtım bildirimlerini yönetme gereksinimini ortadan kaldırır. Niyetinizi Gateway API kaynak yapılandırması aracılığıyla ifade edersiniz ve ağ geçidi denetleyicisi proxy’yi istediğiniz duruma yakınsatır.

Yönetilen bir ağ geçidi denetleyicisi genellikle ağ geçidi proxy’sini, hazır olma ve canlılık yoklamaları, RBAC izinleri, CPU tabanlı otomatik ölçeklendirmeyle replika ölçeklendirmesi ve gönüllü kesintiler sırasında en az bir podun kullanılabilir kalmasını sağlayan bir PodDisruptionBudget dahil olmak üzere, üretim odaklı varsayılanlarla yapılandırır.

Eklenti zamanlama topolojisi

AKS eklentileri, uygulama ekibinin denetlemediği zamanlama kararlarını temel alarak yönetilen bileşenleri düğüm havuzlarına yerleştirir. Sistem ve kullanıcı düğümü havuzlarını boyutlandırmadan önce, etkinleştirilen her eklentinin podlarını zamanladığı yeri belirleyin. Bazı eklentiler sistem düğüm havuzunun taint’lerini tolere eder ve bu nedenle yalnızca sistem havuzunda çalışır. Diğer eklentiler kullanıcı havuzlarını hedefler. Bu topoloji, her havuzda gerekli olan kapasiteyi doğrudan etkiler.

Yönetilen Envoy ağ geçidi ara sunucusu, kullanıcı düğümü havuzunda değil, tasarım gereği sistem düğümü havuzunda çalışır. Proxy'nin ek kaynak ayak izini hesaba katıp sistem havuzunu boyutlandırın. Bu varsayılan topoloji kuruluşunuzun gereksinimlerini karşılamıyorsa (örneğin maliyet yalıtımı, ağ segmentasyonu veya uyumluluk nedeniyle kullanıcı havuzlarında ara sunucuya ihtiyacınız varsa), düğüm yerleştirme kararları almak için kendi kendine yönetilen bir ağ geçidi denetleyicisine geçin.

Yönetilen bir ağ geçidi denetleyicisiyle bile uygulama ekibi, proxy replikalarını düğümler arasında dağıtmak için pod anti-eğilimini yapılandırabilir. Bu ayarları izin verilenler listesine alınan ağ geçidi özelleştirme ayarları aracılığıyla yapılandırabilirsiniz. Daha fazla bilgi için Ağ geçidi kaynağını özelleştirme konusuna bakın.

Ağ geçidi ara sunucusu sistem düğümü havuzunda ve iş yükü kullanıcı düğümü havuzunda çalıştığından, zamanlayıcı bunları bağımsız zamanlama etki alanları olarak ele alır. Her gelen istek iş yüküne ulaşmadan önce ara sunucu üzerinden aktığı için ağ geçidi ara sunucusu ve iş yükü hizmetleri sık sık iletişim kurar. Farklı düğüm havuzlarındaki podlar arasında bölge yerleşimini ilişkilendiren yerleşik bir mekanizma yoktur. Açık bir yönlendirme olmadan zamanlayıcı, iş yükü podlarını proxy replikasının bulunmadığı erişilebilirlik alanlarına yerleştirebilir; bu da trafiğin bir erişilebilirlik alanı sınırını aşmasına neden olarak gecikmeye ve alanlar arası veri aktarım maliyetlerine yol açabilir.

Bu bölgeler arası trafiği azaltmak için, iş yükünüzde, bölge düzeyinde proxy replikalarıyla aynı yerde konumlandırılmasını sağlayacak şekilde tercih edilen pod yakınlığını yapılandırın. Proxy ile iş yükü ayrı düğüm havuzlarında çalıştığında, düğüm düzeyindeki yakınlık havuzlar arasında etki etmediğinden, sağlayabileceğiniz en yakın birlikte konumlandırma budur. Interpod benşiminin zamanlayıcıya işlem yükü eklediğini ve büyük kümelerde zamanlamayı yavaşlatabileceğini unutmayın.

İdare ilkelerindeki eklenti kaynak gereksinimleri

AKS eklentileri, kaynak gereksinimleri uygulama ekibi tarafından değil AKS tarafından tanımlanan ve denetlenen yönetilen bileşenleri dağıtır. Küme, Azure İlkesi ve Open Policy Agent (OPA) Gatekeeper aracılığıyla kapsayıcı kaynak sınırı ilkelerini Deny modunda zorunlu kıldığında, ilkelerin etkin olan tüm eklentileri hesaba katması gerekir. Aksi takdirde Gatekeeper, yönetilen podların oluşturulmasını sessizce engeller; bu da herhangi bir belirgin dağıtım hatası göstermeden ingress, gizli bilgilerin eşitlenmesi ve gözlemlenebilirlik gibi platform özelliklerini devre dışı bırakır.

İlke yazmanın önkoşulu olarak eklenti kaynak profili oluşturmayı değerlendirin. Kapsayıcı CPU'sunu, belleği, birim türünü veya güvenlik bağlamı kısıtlamalarını tanımlamadan önce, etkinleştirilen her eklentinin envanterini oluşturun ve çalışma zamanı kaynak gereksinimlerini belirleyin. Gerçekçi trafik koşullarında gerçek kaynak tüketimini yakalamak için üretim öncesi ortamda yük testi veya denetimli dağıtımları kullanın. Ardından ilke sınırlarınızı hem eklenti bileşenlerine hem de iş yükü kapsayıcılarınıza uyacak şekilde ayarlayın. Bu yaklaşım, idare korumalarınızın platform tarafından yönetilen altyapıya müdahale etmeden kümeyi korumasını sağlar.

Örneğin, yönetilen Envoy ağ geçidi ara sunucusu, kopya başına en fazla 2 CPU çekirdeği ve 1 GiB bellek gerektirir. Bu değerler büyük olasılıkla küçük veya düşük kaynak iş yükünün gereksinimlerini aşıyor. İlke sınırlarınızı, uygulama kapsayıcılarınızla birlikte ağ geçidi proxy’sini de barındıracak şekilde ayarlayın. Bu ayarlama olmadan, Ağ Geçidi Denetleyicisi ağ geçidi ara sunucu podlarını reddeder ve giriş işlem hattının tamamı gerçekleşmez.

Küme içi ağ geçidi TLS sonlandırması ve HTTPS zorlaması

Bu mimari, ağ geçidini 443 numaralı bağlantı noktasında, Key Vault’tan eşitlenen bir TLS sertifikasıyla HTTPS kullanacak şekilde ve yeniden yönlendirme için 80 numaralı bağlantı noktasında bir HTTP dinleyicisiyle yapılandırır. Ağ geçidindeki altyapı ek açıklamaları, yük dengeleyiciyi ingress alt ağına yerleştirir ve onu iç yük dengeleyici olarak yapılandırır. HTTP dinleyicisine bağlı bir yeniden yönlendirme HTTPRoute’u, tüm HTTP isteklerini HTTPS’ye yükseltmek için 301 Moved Permanently döndürür. HTTPRoute uygulaması HTTPS dinleyicisine bağlanır ve trafiği HTTP üzerinden iş yükü hizmetine yönlendirir. Ağ geçidi ara sunucusu TLS sonlandırması gerçekleştirdiğinden, arka uç hizmetleriyle iletişim şifrelenmemiştir.

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

Bu mimaride ağ akışı aşağıdaki trafik türlerini 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ı trafik; buna ağ geçidi proxy’si ile iş yükü arasındaki iletişim de dahildir. İş 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.

Diyagramda mimari içindeki dört farklı trafik deseni gösterilmektedir. Bir kutu, Azure Güvenlik Duvarı içeren bir alt ağ kutusu içeren merkez ağını içerir. Ayrı bir kutu spoke ağını içerir ve içinde Web Uygulaması Güvenlik Duvarı (WAF), AKS tarafından yönetilen iç yük dengeleyicisi ve AKS için alt ağ kutuları bulunur. İki yönlü siyah ok, iki ağ arasındaki sanal ağ eşlemesini gösterir. Kesintisiz yeşil oklar, genel internetten uç ağdaki WAF’a, WAF alt ağından iç yük dengeleyici alt ağına ve oradan AKS alt ağına yönelen, kullanıcının başlattığı istek trafiğini gösterir. Düz turuncu oklar, spoke ağındaki AKS alt ağından hub ağa kümenin başlattığı istek trafiğini ve hub ağındaki Azure Güvenlik Duvarı alt ağından genel internete giden çıkış trafiğini gösterir. Noktalı turuncu oklar, herkese açık internetten merkez ağın Azure Güvenlik Duvarı alt ağına ve merkez ağdan uç ağın AKS alt ağına geri dönen yanıt trafiğini gösterir. Yeşil noktalı oklar AKS alt ağından yük dengeleyici alt ağına ve ardından uç ağının WAF alt ağına ve uç ağının WAF alt ağından genel İnternet'e gelen yanıt trafiğini gösterir.

Bu mimarinin 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 ile şifrelenmiş istekleri kabul eder. TLS v1.2 izin verilen en düşük sürümdür ve kısıtlı bir şifreleme kümesine izin verir. SNI katı eşleştirme etkinleştirildi. Uçtan uca TLS, aşağıdaki diyagramda gösterildiği gibi iki farklı TLS sertifikası kullanılarak Application Gateway aracılığıyla ayarlanır.

Diyagramda istemciden iş yüküne uçtan uca TLS trafik akışı gösterilir. 1. adım, Application Gateway'e HTTPS trafiği gönderen bir kullanıcıyı gösterir. 2. adımda, Application Gateway'den AKS kümesindeki Envoy proxy'sine bir ok geçer. 3. adım, Envoy proxy'sinden AKS kümesindeki iş yüküne işaret eden bir ok gösterir. 4. adım, Application Gateway ve Envoy proxy'sinden Key Vault giden satırları gösterir. Bu satırlar bicycle.contoso.com ve *.aks-ingress.contoso.com olmak üzere iki sertifika içerir. Her TLS sonlandırma noktası bir kilit simgesiyle işaretlenir.

Bu mimarinin Visio dosyasını indirin.

1. İstemci, etki alanı adına bir HTTPS isteği gönderir: bicycle.contoso.com, Application Gateway'in genel IP adresine DNS A kaydıyla ilişkilendirilmiş bir ad. 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. Application Gateway tümleşik bir web application firewall sahiptir ve bicycle.contoso.com için TLS el sıkışması anlaşması yaparak yalnızca güvenli şifrelere izin verir.

   Application Gateway, düz metin istek ve yanıtlarını incelemesi gereken Application Gateway web uygulama güvenlik duvarı için önemli olan bir TLS sonlandırma noktasıdır.

2. Application Gateway, web application firewall denetim kurallarını işler ve trafiği yapılandırılan arka uca ileden yönlendirme kurallarını çalıştırır.

   Application Gateway'den arka uca trafik taşınırken, iç load balancer'a yönlendirildiğinden *.aks-ingress.contoso.com için bir joker TLS sertifikası kullanılarak yeniden şifrelenir. Bu yeniden şifreleme, güvenli olmayan trafiğin küme alt ağından akmamasını sağlamaya yardımcı olur.

3. Ağ geçidi ara sunucusu, şifrelenmiş trafiği yük dengeleyici aracılığıyla alır. Proxy, *.aks-ingress.contoso.com için başka bir TLS sonlandırma noktasıdır ve trafiği HTTP üzerinden iş yükü pod’larına iletir.

4. Her iki TLS sertifikası da Key Vault depolanır.

   Küme, Application Gateway ile tümleştirilen kullanıcı tarafından atanan yönetilen kimlikle bicycle.contoso.com sertifikaya erişir. Daha fazla bilgi için bkz. Key Vault sertifikalarıyla TLS sonlandırma. *.aks-ingress.contoso.com için TLS sertifikası, Gateway kaynağının başvurduğu bir Kubernetes Secret'ı olarak küme içine eşitlenir. Daha fazla bilgi için bkz Gizli yönetim ekleme.

Her atlamada uçtan uca TLS trafiği uygulayabilirsiniz. Poddan poda trafiğin güvenliğini sağlamaya ilişkin tüm kararların performansını, gecikme süresini ve operasyonel etkilerini dikkate almayı unutmayın. Uygun denetim düzlemi RBAC ve olgun yazılım geliştirme yaşam döngüsü uygulamalarına sahip tek kiracılı kümelerin çoğunda TLS'nin ağ geçidi ara sunucusuna kadar şifrelemesi ve Web Uygulaması Güvenlik Duvarı ile korunması yeterlidir. Bu yaklaşım, iş yükü yönetimi ve düşük ağ performansı ek yükünü en aza indirir. İş yükünüz ve uyumluluk gereksinimleriniz, TLS sonlandırma gerçekleştireceğiniz yeri belirler.

Çıkış trafik akışı

Bu mimaride, kümeden gelen tüm çıkış trafiğinin Azure Güvenlik Duvarı gitmesini öneririz. Kendi benzer ağ sanal gerecinizi de kullanabilirsiniz. Azure NAT Gateway veya HTTP proxy gibi diğer çıkış seçeneklerini önermiyoruz çünkü bunlar ağ trafiği denetimi sağlamaz. Sıfır Güven denetimi ve trafiği inceleyebilme özelliği için tüm çıkış trafiğini Azure Güvenlik Duvarı aracılığıyla gönderin. Bu yapılandırmayı kullanıcı tanımlı yollar (UDR) ile uygulayın. Yolun bir sonraki atlaması, Azure Güvenlik Duvarı'nın özel IP adresidir. Azure Güvenlik Duvarı, tanımladığınız kurallara veya yerleşik tehdit bilgileri kurallarına göre çıkış trafiğinin engellenip engellenmeyeceğine veya izin verilip verilmeyeceğine karar verir.

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 egress ağ trafiği kurallarını gözden geçirin.

Note

Azure Güvenlik Duvarı üzerinden UDR'leri kullanarak giriş ve çıkış trafiği için genel noktanız olarak bir genel yük dengeleyici kullanıyorsanız, asimetrik yönlendirme senaryosu görebilirsiniz. Bu mimaride, Application Gateway arkasındaki ayrılmış bir giriş alt akında iç yük dengeleyiciler kullanılır. Bu tasarım seçimi güvenliği artırır ve ayrıca asimetrik yönlendirme endişelerini ortadan kaldırır. Veya Application Gateway önce veya sonra giriş trafiğini Güvenlik Duvarı üzerinden yönlendirebilirsiniz, ancak bu yaklaşım çoğu durumda gerekli değildir ve bunu önermiyoruz. Asimetrik yönlendirme hakkında daha fazla bilgi için bkz. Azure standart yük dengeleyici ile Güvenlik Duvarını Entegre Etme.

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üncellenmiş bir imajı veya Key Vault'tan gizli bilgileri çekmesi gerekebilir. Bu senaryolarda Özel Bağlantı kullanmanızı öneririz.

Özel Bağlantı kullanmanın 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 hizmetler veya ürünler Özel Bağlantı desteklemez. Bu gibi durumlarda, hizmete erişmek için alt ağda sanal ağ hizmet uç noktasını etkinleştirmeyi düşünün.

Container Registry için özel olarak ayrılmış veri uç noktalarını kullanın. Bunlar olmadan, görüntü katmanı indirmeleri kayıt defterinin özel uç noktası yerine bir *.blob.core.windows.net uç noktaya yönlendirilir ve çıkış güvenlik duvarı kurallarınızın tehlikeli bir Blob depolama joker karakterine izin vermesi gerekir. Bu kural, düğümden any Azure Depolama hesabına giden trafiğe izin verir. Ayrılmış veri uç noktaları, joker karakteri kayıt defterinize özgü ve Özel Bağlantı üzerinden özel uç noktanıza çözümlenen FQDN'lerle (<registry>.<region>.data.azurecr.io) değiştirerek görüntü katmanı trafiğini özel yol üzerinde tutar ve çıkış kurallarını kümenizin kayıt defteriyle sınırlamanızı sağlar.

Ö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. Güvenlik duvarı çıkış akışlarına kaynak ağ adresi çevirisi (SNAT) uygular ve pod IP'sini akış başına ekli genel IP adreslerinden biriyle değiştirir ve seçim belirleyici değildir. Ekli genel IP kümesinin tamamını hedef hizmetin IP izin verilenler listesine ekleyin veya bu kümeyi bitişik aralık olarak ifade etmek için bir genel IP adresi ön eki kullanın.

Genel uç noktalar aracılığıyla Azure hizmetlere bağlanmanın 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. Ekli genel IP sayısı SNAT bağlantı noktası havuzunu ve dolayısıyla kümenin eşzamanlı giden bağlantı tavanını da kapsıyor. Planlı bir şekilde çoklu IP adreslerini Azure Güvenlik Duvarı üzerinde kullanmaya başlayın ve bu sayede bağlantı noktası tükenmesine ulaşmadan önce hazırlıklı olun. Çok sayıda eşzamanlı giden bağlantı açan kümelerde, SNAT bağlantı noktası havuzunu önemli ölçüde genişletmek ve tüm çıkış trafiğini güvenlik duvarı denetimi altında tutmak için kümeye bir Azure NAT Gateway ekleyin.

Podlar arası 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. Kritik ağ akışlarının engellenmesini önlemek için ilkeleri dikkatli bir şekilde uygulayın. Gerektiğinde yalnızca ağ geçidi ara sunucusu ile iş yükü arasındaki trafik gibi belirli iletişim yollarına izin verin. Ağ geçidi ara sunucusu iş yüküyle aynı ad alanında çalıştığından, bunu ad alanı seçicisi yerine pod etiketiyle hedefle. Daha fazla bilgi için bkz. Ağ ilkeleri.

Kümeyi oluştururken ağ ilkesini etkinleştirin, çünkü kümeyi daha sonra eklemek düğüm havuzlarınızı yeniden oluşturabilir. uygulayan NetworkPolicyteknolojiler için birkaç seçeneğiniz vardır. Azure ağ ilkesi için Azure CNI gerekir. 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, çeşitli operasyonlar gerçekleştirmek 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 özel bir AKS kümesi ayarlamanızı öneririz.

Daha fazla bilgi için bkz. API sunucusu tarafından yetkilendirilmiş IP aralıklarını tanımlama.

AKS kümenizi özel küme olarak dağıtmanızı öneririz. Tüm denetim düzlemi ve düğüm havuzu trafiği özel ağınızda kalır ve genel İnternet'e açık değildir. Başvuru uygulaması, API sunucusu sanal ağ tümleştirmesini kullanarak özel bir küme ayarlar. Düşük ortamlar kolaylık sağlamak için bu özel küme önerisini gevşetmeyi düşünebilir, ancak üretim AKS kümeleri her zaman güvenli bir dağıtım temeli için özel kümeler olarak dağıtılmalıdır.

Özel bir AKS kümesine yönelik özel trafik, konuşma sanal ağından, eşlenmiş ağlardan veya uzak ağlardaki özel uç noktalardan kaynaklanabilir. AKS düğümleri doğal olarak uç noktada bulunsa da, yönetim görevlerini yapan yöneticiler, AKS API sunucusuna özel bir şekilde ulaşmak için ayrılmış bir ağ yoluna ihtiyaç duyar. Bu bağlantıyı aşağıdaki yollarla kurabilirsiniz:

• Tünel: Azure Bastion kullanarak doğrudan kümenin API sunucusuna bir tünel açın.
• Atlama kutusu: Sıçrama kutusu VM'sini sağlayın ve SSH veya RDP aracılığıyla bağlanmak için Azure Bastion kullanın. Operatör, özel IP adresini kullanarak kümenin API sunucusuna yönelik isteklerde bulunur.

Bu mimari, bir operatörün yerel makinesini Azure CLI komutlar aracılığıyla özel AKS API sunucusuna bağlamak için Azure Bastion yerel istemci tünelini kullanır. Tünel, atlama kutusu olmadan doğrudan kubectl ve Helm iş akışlarını destekler. Bu yaklaşım, AKS API uç noktasının özel kalmasını sağlarken bir atlama kutusuna göre daha basit ve daha az maliyetli kalmasını sağladığından önerilir. Birden çok işleç arasında koordinasyon sağlamak da daha az karmaşıktır.

Ancak, şu gereksinimlerden herhangi birine sahipseniz bir atlama kutusu kullanmayı seçebilirsiniz:

• Operatörler güvenli olmayan cihazlar kullanır. İstemci cihazlarınıza güvenilmiyorsa atlama kutusu daha güçlü güvenlik sağlamlaştırması sağlayabilir.

• Operatörler kararsız ağlar üzerinden bağlanır. Atlama kutusu, özellikle uzun süre çalışan veya toplu yönetim işlemleri için kümeye daha kararlı bir bağlantı sağlayabilir.

• Operatörler gelişmiş tanılama araçlarını kullanır. Paket yakalama gibi bazı tanılama araçları, tünel yaklaşımlarıyla iyi çalışmayabilir.

Gizli yönetimi ekleyin

Gizli bilgileri Key Vault gibi yönetilen bir anahtar deposunda depolayın. Bunun avantajları, yönetilen anahtar deposunun gizli dizi döndürmeyi işlemesi, güçlü bir şifreleme ve erişim denetim günlüğü sağlaması ve çekirdek gizli dizileri dağıtım işlem hattı dışında tutmasıdır. Bu mimaride, bir Key Vault güvenlik duvarı etkinleştirilir ve yapılandırılır ve gizli dizilere ve sertifikalara erişme gibi Azure kaynaklara bağlanmak için Özel Bağlantı kullanılır.

Key Vault diğer Azure hizmetleriyle iyi tümleştirilmiştir. Bu hizmetlerin yerleşik özelliğini sırları erişmek için kullanın. Application Gateway giriş akışı için TLS sertifikalarına nasıl eriştiği hakkında daha fazla bilgi için Giriş trafiği akışı bölümüne bakın.

Key Vault için Azure RBAC izin modeli, gizli dizilere erişmek üzere iş yükü kimliklerine Key Vault Gizli Dizi Kullanıcısı veya Key Vault Okuyucusu rollerinden birini atamanıza olanak tanır. Daha fazla bilgi için bkz. Azure RBAC kullanarak Key Vault'a Erişme.

Küme gizli bilgilerine erişim

Belirli bir mağazadan gizli bilgilere erişmek için bir podun iş yükü kimliklerini kullanması gerekir. Geri getirme işlemini kolaylaştırmak için gizli bilgileri depolamak için bir CSI çekme 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 volüm dosya sisteminden gizli veriyi 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, manuel TLS yapılandırma yaklaşımıyla Secrets Store CSI sürücüsüne sahip Key Vault'u kullanır. SecretProviderClass kaynağı, hangi Key Vault sertifikalarının Kubernetes Gizli Öğeleri olarak kümede eşitleneceğini tanımlar. CSI sürücüsü, eşitlenmiş Secret’ı oluşturmak ve sürdürmek için en az bir pod’un ilgili CSI birimini bağlamasını gerektirir. Tüm bağlanmış podları silerseniz, sürücü Secret nesnesini çöp toplama işlemiyle kaldırır; bu da ağ geçidinin TLS sertifikasını kaybetmesine neden olur. Bunu önlemek için, CSI biriminin iş yükü pod’larınızın yaşam döngülerinden bağımsız olarak bağlı kalmasını sağlayan, adanmış ve sürekli çalışan bir pod dağıtın.

Bu mimaride, göstermelik bir görevle hafif bir kapsayıcı çalıştıran busybox kapsayıcı görüntüsü kullanılır. Flux bunu önyükleme sırasında dağıttığı için, kapsayıcı görüntüsünü küme oluşturulmadan önce Azure Container Registry’ye içe aktarın. CSI eklentisinde gizli dizi rotasyonunu etkinleştirin ve Key Vault sertifika yenilemelerinin otomatik olarak yansıtılması için örneğin iki dakikalık bir rotasyon yoklama aralığı ayarlayın. Ağ Geçidi kaynağı, HTTPS sonlandırma için senkronize edilmiş TLS Secret öğesine referans verir. Daha fazla bilgi için bkz. Uygulama yönlendirmesinin Gateway API uygulamasıyla gelen trafiğin güvenliğini sağlama.

AKS'nin Azure bileşenlerine erişiminde belirtildiği gibi, bu el ile yapılandırmayı operatör tarafından yönetilen TLS yaklaşımıyla değiştirebilirsiniz. Bu yaklaşımla, Key Vault sertifika URI’sini ve bir Workload Identity ServiceAccount’ını doğrudan ağ geçidi dinleyicisinde tanımlarsınız. Uygulama yönlendirme işleci daha sonra SecretProviderClass'ı oluşturur ve Ağ Geçidi sertifika başvurusuna otomatik olarak düzeltme eki uygular; bu da küme önyüklemesi sırasında bu kaynakları yazma gereksinimini ortadan kaldırır veya ayrılmış bir TLS eşitleme pod'u oluşturur. Her iki yaklaşım da, sertifika yenilemelerini Key Vault’tan almak için CSI sürücüsünün rotasyon mekanizmasına dayanır.

İş yükü depolama

Bu mimaride iş yükü durumsuzdur. Durum depolamanız gerekiyorsa, onu kümenin dışında kalıcı hale getirmenizi öneririz. İş yükü durumu kılavuzu bu makalenin kapsamı dışındadır.

Daha fazla bilgi için bkz. AKS'teki 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, OPA Gatekeeper 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ümedeki ilke uygulamasını yönetir ve tüm ilke denetimlerini günlüğe kaydeder. İlke değişiklikleri kümenize hemen yansıtılmaz, bu nedenle bazı gecikmeler bekleyebilirsiniz.

AKS kümelerinizi yönetmek için Azure İlkesi çeşitli yollarla 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.

Politikaların yararlı olabileceği sık görülen bir durum, kapsayıcı görüntülerin yönetimi ve doğrulanmasıdır. Kapsayıcı görüntüleri güvenlik açıklarının kaynağı olabilir ve bazı kuruluşlar, güvenilmeyen kapsayıcı görüntülerinin bir kapsayıcı görüntüsü tarama aracı kullanılarak doğrulanması ve ardından bir üretim kümesinde kullanılmadan önce onaylanmasını gerektirir. Azure İlkesi kullanarak bu işlemi zorunlu kılabilir ve güvenilmeyen kapsayıcı görüntülerinin kümeye dağıtılmasını engelleyebilirsiniz. Daha fazla bilgi için bkz. Quarantine deseni.

İlkeler ayarladığınızda, bunları iş yükünün gereksinimlerine göre uygulayın. Şu faktörleri göz önünde bulundurun:

• Politikalar topluluğu olarak bilinen girişimleri ayarlamaya veya tek tek politika seçmeye karar verin. 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şim kuran 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 mi yoksa reddetmek mi istediğinize karar verin. 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 Reddetme modunu seçtiğinizde dikkatli olun.

• İş yükünüzde tasarım gereği uyumlu olmaması gereken alanlarınız olup olmadığını belirleyin. Azure İlkesi, ilke zorlamasından muaf tutulan Kubernetes ad alanlarını belirtebilir. Bu örneklerin farkında olmanız için denetim modunda ilkeler uygulamaya devam etmeniz önerilir.

• Yerleşik ilkeler kapsamında olmayan gereksinimleriniz olup olmadığını belirleyin. Ö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 olup olmadığını belirleyin. Ö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.

• belirli kapsamlara Azure ilkeleri atamanız gerekip gerekmediğini belirleyin. Üretim ilkelerinin üretim öncesi ortamınızda da doğrulandığından emin olun. Aksi takdirde, üretim ortamınıza dağıttığınızda, ön üretimde hesaba katmadığınız beklenmedik ek kısıtlamalarla karşılaşabilirsiniz.

Başvuru uygulaması, AKS kümesi oluşturulduğunda Azure İlkesi etkinleştirir. Kısıtlayıcı ilke, uyumsuzlukları görünür kılmak 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.

Kümenizin içinden Azure İlkesi işlevlerini gözlemlemek için gatekeeper-system ad alanında tüm podların pod günlüklerine ve azure-policy ad alanında azure-policy-webhook ve kube-system podlarının günlüklerine erişebilirsiniz.

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

Artan taleple birlikte, Kubernetes mevcut düğümlere daha fazla pod ekleyerek, yatay pod otomatik ölçeklendirme aracılığıyla ölçeklendirme yapabilir. Kubernetes daha fazla pod planlayamaz hale geldiğinde, düğüm sayısı AKS kümesi otomatik ölçeklendirme ile artırılmak zorundadı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 aracılığıyla ReplicaSet ayarlayarak pod çoğaltma 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.

El ile gerçekleştirilen mekanizmalardan bazıları otomatik ölçeklendiricide yerleşik olduğundan otomatik ölçeklendirme yaklaşımını kullanmanızı ö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.

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. Yalnızca CPU kullanımı yerel olarak 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ı tahsis edilmiş 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, ölçeklendirme işlemi tamamlanmadan önce denetlediğinde bir yarış durumu oluşabilir. Bu nedenle, sonuç yanlış bir oran hesaplaması olabilir. Daha fazla bilgi için bakınız ölçeklendirme olaylarının soğuma periyodu.

İş 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çümlere göre ölçeklendirmenin kullanışlı bir yolu olan Azure İzleyici ölçekleyici içerir.

Küme otomatik ölçeklendiricisi

cluster otomatik ölçeklendiricisi bir düğüm havuzundaki düğüm sayısını ölçeklendirin bir AKS eklentisi bileşenidir. Küme oluşturma sırasında onu 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 pod zamanlayamazsa, otomatik ölçeklendirici düğüm havuzunda otomatik olarak yeni bir düğüm ayarlar. Buna karşılık, küme otomatik ölçeklendiricisi düğümlerin kullanılmayan kapasitesini denetler. Düğüm beklenen kapasitede çalışmazsa 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. 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.

İş 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ımlamaya yönelik öneriler. En son çevrimiçi hizmetler için SLA makalesinde AKS 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ılabilirlik veya kapasiteye ihtiyacınız varsa, daha fazla düğüm eklemek için ölçeklendirme yapı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 kısıtlar kullanmanızı öneririz. Sistem düğüm havuzlarına uygulama podlarının zamanlanmasını önlemek için, sistem düğüm havuzunuzun CriticalAddonsOnly taint ile işaretlendiğinden emin olun.

Zamanında güncelleştirmeler gibi kümenizdeki düzenli bakım görevleri güvenilirlik açısından çok önemlidir. Ayrıca, yoklamalar aracılığıyla podların durumunu izlemenizi öneririz.

Pod kullanılabilirliği

• Pod kaynağı gereksinimlerini belirtin: Dağıtımlarınızda pod kaynağı gereksinimlerini belirtmenizi öneririz. Zamanlayıcı, ardından pod'u uygun şekilde 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ımdaki kaç replikasının inebileceğini belirler. Daha fazla bilgi için bkz. Pod kesinti bütçeleri.

  Dağıtımda, donanım hataları gibi kesintilerle baş etmek için birden çok kopya yapılandırın. Güncellemeler ve yükseltmeler gibi planlı olaylar için, kesinti bütçesi beklenen uygulama yükünü karşılayabilecek gerekli sayıda pod kopyasının mevcut olmasını sağlamada yardımcı olabilir.

• İş yükü ad alanları üzerinde kaynak kotaları ayarlayın: Ad alanı üzerindeki kaynak kotası, pod isteklerinin ve sınırlarının dağıtımda düzgün ayarlandığından emin olunmasını sağlar. Daha fazla bilgi için bkz. Kaynak kotalarını uygula.

  Note

  Kaynak kotalarını küme düzeyinde ayarlarsanız, uygun isteklere ve sınırlara sahip olmayan dış iş yüklerini dağıtırsanız sorunlarla karşılaşabilirsiniz. Kotaları ad alanı düzeyinde ayarladığınızda, bunların yalnızca iş yükü bileşenlerinize uygulanmasını sağlar.

• Pod isteklerini ve sınırlarını ayarlayın: Kubernetes'in podlara CPU ve bellek kaynaklarını verimli bir şekilde ayırmasını sağlamak için istekleri ve sınırları ayarlayın. Bir düğümde daha yüksek konteyner yoğunluğu sağlar. İ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 dengesizlik yaratan eşiği 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.

Erişilebilirlik bölgeleri

Bazı kesinti türlerine karşı koruma sağlamak için bölge bunları destekliyorsa availability zones kullanın. Hem denetim düzlemi bileşenleri hem de düğüm havuzlarındaki düğümler alanlar arası yedekli hale gelir ve bu da birden çok bölgeye yayıldığı anlamına gelir. 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ı: Availability zones destekleyen bir bölge seçin. Daha fazla bilgi için bkz. Limitations. Çalışma süresi SLA'sına sahip olmak için Standart veya Premium katmanını seçmeniz gerekir. Kullanılabilirlik bölgelerini kullandığınızda kullanılabilirlik SLA'sı daha yüksek olur.

• 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 sanal makine ölçek kümesi, bölgeler genelinde aynı donanım yapılandırmasını sağlar.

  Bölge yedekliliğ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 bölgeleri arasında dağıtılması garanti edilmez.

• Bağımlı kaynaklar: Availability zones kullanmanın dayanıklılık avantajını elde etmek için, tüm servis bağımlılıklarının da bu bölgeleri desteklemesi gerekir. Bağımlı bir hizmet bölgeleri desteklemiyorsa, bölge hatası bu hizmetin başarısız olmasına neden olabilir.

  Örneğin, iş yükünüzün alanlar arası dayanıklı olmayan bir veritabanı kullandığını varsayalım. Bir hata oluşursa AKS düğümü başka bir bölgeye geçebilir, ancak veritabanı düğümle birlikte bu bölgeye taşınmaz, bu nedenle iş yükünüz kesintiye uğrar.

Bu mimaride basitlik sağlamak için AKS, üç Kullanılabilirlik Bölgesine 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

Availability zones'u etkinleştirdiğinizde, tüm bir bölgenin başarısız olması durumunda yeterli kapsama alanı sağlanmaz. Daha yüksek kullanılabilirlik elde etmek için farklı bölgelerde birden çok AKS kümesi çalıştırın.

• Kullanılabilir olduklarında 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ölgelerde çiftler 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 belirli DevOps araçları çok bölgeli dağıtımları kolaylaştırabilir.

• bir 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ölgelere çoğaltır. Ayrıca, birincil bölgede kesinti yaşansa bile görüntülere sürekli access 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 trafiği olmayan trafiği bölgeler arasında dağıtabildiğinden Load Balancer kullanır. Trafiği bölgeler arasında dağıtmanız gerekiyorsa Azure Front Door göz önünde bulundurun. Diğer seçenekler için bkz. Yük dengeleyici seçme.

Note

Çok bölgeli kümeler için AKS temeli örnek senaryosu bu makaledeki mimariyi etkin-etkin ve yüksek oranda kullanılabilir bir yapılandırmaya birden çok bölge içerecek şekilde genişletir.

Felaket kurtarma

İdeal olarak, birincil bölgede bir hata oluşursa, hızla başka bir bölgedeki bir örneğe geçebilirsiniz. Bir kümeyi önceden oluşturabilir veya gerekli olana kadar kümeyi oluşturmayı bekleyebilirsiniz. Aşağıdaki önerileri gözden geçirin:

• Birden çok bölge kullanın. Birincil bölgenizin eşleştirilmiş bir bölgesi varsa, o eşleşmeyi 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 kurtarma stratejisini, örneğin başka bir bölgeye çoğaltmayı, DevOps işlem hattına entegre edin.

• Olağanüstü durum kurtarmayı destekleyen özellikleri kullanarak her Azure hizmetini ayarlayın. Örneğin, bu mimaride Container Registry coğrafi çoğaltma için etkinleştirilir. Bir bölge kullanılamaz hale gelirse, ACR'nin sistem durumuna duyarlı yük devretme özelliği, kümenizin yapılandırmasında değişiklik yapmayı gerektirmeden çekme isteklerini genel uç nokta üzerinden otomatik olarak sağlıklı bir çoğaltmaya yönlendirir.

• 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 yeni bir küme ayarlayabilir ve GitOps tabanlı küme önyüklemesi ve ardından uygulama dağıtımı aracılığıyla bu kümeyi çalışma durumuna döndürebilirsiniz. Ancak yapılandırma haritaları, işler ve gizli anahtarlar gibi başlangıç işleminizde yakalanamayan kritik kaynak durumları varsa, kurtarma stratejinizi gözden geçirin. 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 yedeklemesi kurtarma stratejinizin bir parçası olması gerektiğinde, küme içindeki iş gereksinimlerinize uygun bir çözüm yüklemeniz gerekir. Bu etken, küme kaynak durumunu seçtiğiniz bir hedefe gönderir ve Azure üzerinde disk tabanlı, kalıcı hacim anlık görüntülerini koordine edip yönetmekten sorumludur.

VMware Velero , doğrudan yükleyip yönetebileceğiniz yaygın bir Kubernetes yedekleme çözümü örneğidir. Ya da yönetilen bir Velero uygulaması sağlamak için AKS yedekleme uzantısı kullanabilirsiniz. AKS yedekleme uzantısı, hem Kubernetes kaynaklarını hem de kalıcı birimleri yedekleyebilme özelliğine sahiptir; zamanlamalar ve yedekleme kapsamı, Azure Backup kasası yapılandırması olarak dışa aktarılır.

Referans uygulaması yedekleme yapmaz ve bu, yönetmek, izlemek, satın almak ve güvenliğini sağlamak için ek Azure kaynakları gerektirir. Bu kaynaklar bir Azure Depolama hesabı, bir Azure Backup kasası ve yapılandırması ile güvenilir erişim özelliği içerebilir. Bunun yerine GitOps, durum bilgisi olmayan iş yükünü çalıştırma amacı ile birlikte kurtarma çözümüdür.

Tanımlı kurtarma noktası hedefinizi ve kurtarma süresi hedefinizi içeren 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.

Durum bilgisi olan iş yüklerini desteklemeniz ve AKS Backup benimsemeniz gerekiyorsa, kümenizde bu yedeklemenin yapılandırılmasını zorunlu kılmak için Azure İlkesi kullanın. Azure İzleyici, yedekleme işinin durumunu bu mimaride önceden oluşturulmuş olan gözlemlenebilirlik yığını aracılığıyla ortaya çıkar. Bu idarenin ötesinde tasarımınızda aşağıdaki mimari konuları dikkate alın:

• Yedekleme kapsamı. Kümenin tamamını mı yoksa belirli ad alanlarını mı yedeklediğinize karar verin. AKS Backup, verileri bir blob kapsayıcısında ve disk veya dosya anlık görüntüleri olarak depolar. İşletimsel kurtarma, ortam kopyalama ve küme yükseltmeleri gibi senaryolar için depolama hesabı boyutlandırmanızı, bekletme ilkelerinizi ve kurtarma ayrıntı düzeyini belirlediğinden bu kapsamı erken tanımlayın.
• Güvenilir erişim. AKS Backup, kümenin genel, özel veya IP kısıtlı olmasına bakılmaksızın Backup kasası ile AKS kümesi arasında güvenilir erişim gerektirir.
• RBAC izinleri. Backup kasasının yönetilen kimliği, yedeklemeleri yapılandırmak ve yürütmek için AKS kümesinde bir dizi izin gerektirir. Yedekleme uzantısı, yedeklemelerin depolandığı depolama hesabında izinlere sahip bir kullanıcı kimliği de oluşturur.
• Ağdan çıkış Yedekleme uzantısı, kümenin içinden Azure Backup hizmetlerle iletişim kurar. Azure Güvenlik Duvarı ve NSG kurallarınızda gerekli giden uç noktaları hesap edin.
• Küme içi ayak izi. Uzantı, düğümlerinize pod dağıtır. Düğüm kaynak bütçelerinizde ek işlem yükü ve bellek tüketimini hesaba katın ve uzantı ad alanını ağ ilkesi yönetiminize dahil edin.

Kubernetes API sunucusu SLA'sı

AKS'yi ücretsiz hizmet olarak kullanabilirsiniz, ancak bu katman finansal olarak desteklenmiş bir SLA sağlamaz. SLA elde etmek için Standard katmanını seçmeniz gerekir. Tüm üretim kümelerinin Standart katmanı kullanmasını öneririz. Ücretsiz katmanı ön üretim kümeleri için, Premium katmanını ise yalnızca mission-critical 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.

Taviz

Mimariyi bölgeler ve özellikle bölgeler arasında dağıtmak için maliyet ve kullanılabilirlik arasında bir dengeleme 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 arasındaki düğüm iletişiminde az miktarda ek ağ gecikmesi ve bölgeler arasındaki iletişimde daha önemli gecikme süresi 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üle edilen kesintilerle zorunlu yük devretme testi yaparak çözümünüzün dayanıklılığını test edin. Benzetimler bir düğümü durdurmayı, bir bölge hatasının benzetimini yapmak için belirli bir bölgedeki tüm AKS kaynaklarını azaltmayı veya dış bağımlılık hatasını çağırmayı içerebilir. Azure ve kümedeki çeşitli kesinti türlerinin benzetimini yapmak için Azure Chaos Studio de kullanabilirsiniz.

Daha fazla bilgi için bkz. Chaos Studio.

Günlükleri ve ö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 Kubernetes izleme hizmetlerini öneririz. Azure İzleyici, çalışmakta olan podlardan kapsayıcı günlüklerini yakalar ve görüntüleme amacıyla 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 Azure İzleyici de kullanabilirsiniz. Toplanan verilerin izlenmesi, analizi ve görselleştirmesi için kritik öneme sahip telemetri verilerini içerir.

Podlardan günlük toplamayı etkinleştir

ContainerLogV2 günlük şeması, Kubernetes podlarından kapsayıcı günlüklerini verimli bir şekilde yakalamak için tasarlanmıştır. Günlük kayıtları bir Azure Log Analytics çalışma alanında ContainerLogV2 tablosunda birleştirilir.

AKS kümesinde pod günlüğü koleksiyonunu yapılandırmak için iki birincil yöntem vardır. Her iki yaklaşım da ayarları özelleştirmenize olanak sağlar. Ad alanlarını filtreleyebilir, koleksiyon aralıklarını ayarlayabilir, belirli özellikleri (veya ContainerLogV2gibiContainerLogV2-HighScale) etkinleştirebilir veya yasaklayabilir ve hangi veri akışlarının toplanmasını belirtebilirsiniz.

• Birden çok kümede merkezi, yeniden kullanılabilir izleme yapılandırmalarına ihtiyacınız varsa veya küme yapılandırmasının Azure yerel kaynaklarda dışlanmasını tercih ediyorsanız, data toplama kurallarını (DCR) kullanın. DCR'ler, Azure Resource Manager denetim düzleminin yerel olarak yönettiği Azure kaynaklardır ve bunları Bicep dosyalarına ekleyebilirsiniz. Referans uygulaması DCR'leri kullanır.

• Alternatif olarak, Kubernetes API denetim düzlemi aracılığıyla yapılandırılan, uygun olmayan Kubernetes YAML nesneleri olan ConfigMap'leri kullanarak izleme tanımlayabilirsiniz. Azure İzleyici Aracısı, kümede çalışarak ConfigMap nesnelerini izler. Hangi verilerin topleneceğini belirlemek için önceden tanımlanmış ayarları kullanır.

Her iki yöntem de etkinleştirildiğinde, ConfigMap ayarları DCR'lerden önceliklidir. Kapsayıcı günlüğü koleksiyonu için ConfigMap ve DCR yapılandırmasını karıştırmaktan kaçının çünkü günlük sorunlarının giderilmesi zor olabilir.

Uyarılar ve Prometheus ölçümleri

Kesintiler ve arızalar iş yükü uygulamaları için önemli riskler oluşturur ve bu da altyapınızın sistem durumu ve performansıyla ilgili sorunları proaktif olarak belirlemeyi önemli hale getirir. Ortamınızı izleyip öğrendikleriniz üzerinde işlem yaptığınızda kesintileri azaltır ve çözümünüzün güvenilirliğini artırırsınız. Kümenizdeki olası hata koşullarını tahmin etmek için Kubernetes için önerilen Prometheus uyarı kurallarını etkinleştirin.

Podlarda barındırılan iş yüklerinin çoğu Prometheus ölçümlerini gösterir. Azure İzleyici Prometheus ile tümleştirebilir. Kapsayıcılardan, podlardan, düğümlerden ve kümeden toplanan uygulama ve iş yükü ölçümlerini görüntüleyebilirsiniz.

Microsoft olmayan 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.

Azure altyapısı ve Kubernetes denetim düzlemi günlükleri

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. Bu seçenekler küme sorunlarını gidermenize yardımcı olabilir ve nispeten düşük günlük yoğunluğuna sahiptir. Çoğu kümede aşağıdaki seçenekleri etkinleştirmenizi öneririz:

• ClusterAutoscaler: Günlüğe kaydetme yoluyla ölçeklendirme işlemlerine gözlemlenebilirlik kazandırın. Daha fazla bilgi için bkz.Küme otomatik ölçekleyici günlükleri ve durumu.

• KubeControllerManager: Kubernetes ile Azure kontrol düzlemi arasındaki etkileşime gözlemlenebilirlik kazandırın.

• kube-audit-admin: Kümenizi değiştiren etkinliklerde gözlemlenebilirlik elde edin. Her iki kube-audit ve kube-audit-admin'i etkinleştirmeye gerek yoktur çünkü kube-audit değiştirme yapılmayan (okuma) işlemlerini de içeren bir üst kümedir.

• 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, KubeScheduler veya kube-audit gibi diğer günlük kategorilerini etkinleştirmeniz de 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 sürekli olarak açık tutarsanız, verileri Azure İzleyici'a aktarıp depolamak için gereksiz maliyetlere neden olabilirsiniz.

Azure İzleyici, başlangıç olarak kullanabileceğiniz bir dizi günlük sorgusu içerir, ancak bunları kendi sorgularınızı oluşturmanıza yardımcı olması için temel olarak da kullanabilirsiniz. Kitaplığınız büyüdükçe, bir veya daha fazla query paketi kullanarak günlük sorgularını kaydedebilir ve yeniden kullanabilirsiniz. Özel sorgu kitaplığınız AKS kümelerinizin sistem durumu ve performansı konusunda daha fazla gözlemlenebilirlik sağlar. SLO'larınıza ulaşmanıza yardımcı olur.

AKS için en iyi yöntemleri izleme hakkında daha fazla bilgi için bkz. monitor AKS with Azure İzleyici.

Ağ ölçümleri

Temel, küme düzeyinde ağ ölçümleri yerel platform ve Prometheus ölçümleri aracılığıyla kullanılabilir. Prometheus ölçümlerini kullanarak ağ ölçümlerini düğüm düzeyinde kullanıma açmak için AKS ağ ölçümlerini 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ğini içermelidir.

Başvuru uygulaması, ağ ile ilgili bazı ölçümleri de toplayan Azure İzleyici kullanır. Başvuru uygulaması, Azure İzleyici bazı ağ ölçümlerini doğrudan toplamayı yasaklar ve bunun yerine managed Prometheus ile bir Azure İzleyici çalışma alanı kullanarak ağ gözlemlenebilirlik ölçümlerini toplar.

İ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ş Kapsayıcı Ağ Hizmetleri özelliğini kullanarak bu ayrıntılı ölçümlere erişebilirsiniz. Çoğu iş yükü, bu ağ gözlemlenebilirliği derinliğini gerektirmez. Podlarınızın paket düzeyine kadar duyarlılığa sahip yüksek düzeyde optimize edilmiş bir ağ talep etmediği sürece, gelişmiş ağ izlemeyi etkinleştirmemelisiniz.

Loglama için maliyet optimizasyonu

Başvuru uygulaması, ContainerLogV2 tablosunu Başlangıç noktası olarak Temel planı kullanacak şekilde yapılandırır. Kapsayıcılar için Microsoft Defender ve başvuru uygulaması için oluşturulan uyarılar bu tabloyu sorgulamaz, bu nedenle Temel plan alım maliyetlerini azalttığı için uygun maliyetli olabilir.

Günlük hacminiz ve sorgu gereklilikleriniz geliştikçe, ihtiyaçlarınıza en uygun maliyetli olan tablo planını seçin. Çözüm, sorguların tablo verilerini sık sık taradığı okuma yoğunluklu hale gelirse, varsayılan Analytics planı daha uygun olabilir. Analiz planı sorgu ücretlerini ortadan kaldırır ve bu da sorgu etkinliğinin alım maliyetlerine ağır bastığı senaryolar için iyileştirir. Kullanım düzenlerini izlediğinizde ve tablo planlarını gerektiği gibi ayarladığınızda, izleme çözümünüz için maliyet ve işlevsellik arasında bir denge elde edebilirsiniz.

Daha fazla bilgi için bkz. Log Analytics çalışma alanında veri kullanımına göre tablo planı seçme.

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.

Note

AKS' nin altyapı düğümleri için yerleşik kendi kendine düzeltme sağlayan otomatik düğüm onarım özelliği vardır.

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 API değişiklikleri ve kaldırılan özelliklerle birlikte gelebilen Kubernetes sürümü (Kubernetes 1.32.3'ten 1.32.7'ye veya Kubernetes 1.32.7'den 1.33.1'e gibi). 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 yerleşik güncelleme işlemi, Windows Update veya apt gibi. İş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 düzeltme eki ve yükseltme kılavuzu'na, AKS 2. gün işlemleri kılavuzu'nda bakınız. Bu mimariyle ilgili temel öneriler için aşağıdaki bilgileri kullanın.

Sabit altyapı

AKS kümelerini sabit altyapı olarak çalıştıran iş yükleri, kümelerini otomatik olarak veya el ile güncelleştirmez. node görüntü yükseltme değerini none ve cluster otomatik yükseltme değerini none olarak ayarlayı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 aşağıdaki adımları gerçekleştirmeniz gerekir:

1. Güncelleştirmeyi bir üretim öncesi ortamda test edin ve yeni bir kümede uyumluluğunu değerlendirin.

2. Güncelleştirilmiş AKS sürümünü ve node pool VHD'lerini içeren bir prodüksiyon replika instance dağıtın.

3. Yeni üretim kümesi hazır olduğunda, eski kümeyi boşaltın ve sonunda devreden çıkarın.

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ümeler için bir yerinde yükseltme stratejisi bulunmalı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.

• Aşamalı güncellemeler 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ını 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 kota ve IP adresi alanının kullanılabilir olması gerektiği anlamına gelir. 33% surge 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. Ayrıca giriş denetleyicileri, hizmet kafesleri ve iş yükü podlarınız gibi iş yükü bileşenlerinizi test edin. Testleri bir üretim öncesi ortamda çalıştırı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üğümler için güncelleştirmeler ayda yaklaşık bir kez gerçekleşir. Linux düğümleri için 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.

• NodeImage'yi yükseltme kanalı olarak kullandığınızda, haftada en az bir kez ayarlamanız gereken planlı bakım pencerenize uyum sağlar. Hangi düğüm görüntüsü işletim sistemini kullanırsanız kullanın, güncellemelerin zamanında uygulanmasını sağlamak için bunu 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 sıkı bir yamalama temposu istiyorsa ve kümeniz olası kesintileri tolere edebilirse, bunun yerine SecurityPatch yükseltme kanalını kullanın. Microsoft bu güncellemeleri de test eder. Güncelleştirmeler, yalnızca Microsoft'un zamanlanmış bir sonraki düğüm görüntüsü yükseltmesinden önce yayımlanması gerektiğini düşündüğü kadar önemli güvenlik yükseltmeleri varsa yayımlanır. Kanalı SecurityPatch kullandığınızda, NodeImage kanalının aldığı güncelleştirmeleri de alırsınız. SecurityPatch kanal seçeneği, bakım pencerelerinizi kullanmaya devam eder; bu nedenle, bu beklenmeyen güvenlik güncellemelerini desteklemek için bakım pencerenizde daha sık zaman aralıkları (günlük veya iki günde bir) olduğundan emin olun.

Çoğu yerinde yükseltme yapan küme, None ve Unmanaged düğüm görüntüsü yükseltme kanal seçeneklerinden 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üm (N-2) içinde 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 blue-green dağıtımı yaklaşımını kullanmanızı öneririz.

Kubernetes kümesini ilk kez dağıtırken cluster 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ı yerine 'güncel olma' yaklaşımını benimsemek daha iyidir.

Warning

Bu güncelleştirmeleri önce alt ortamlarınızda test etmediğiniz sürece, küçük sürüm güncellemeleri söz konusu olsa bile, üretim AKS kümesine otomatik olarak düzeltme eki veya güncelleme uygulamanızı önermeyiz. Daha fazla bilgi için bkz. Kubernetes'i en son sürümüne düzenli olarak güncelleştirme ve AKS kümesini yükseltme.

Azure Event Grid için AKS sistemini kullanarak kümeniz için yeni bir AKS sürümü kullanılabilir olduğunda bildirim alabilirsiniz. Referans uygulaması, olay akışı bildirim çözümünüzdeki Microsoft.ContainerService.NewKubernetesVersionAvailable olayına abone olabilmeniz için bu Event Grid sistemini 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 sistemlerinde patch'nin ötesine geçmek nadirdir. AKS sürümünüzü otomatik olarak güncellediğinizde, uyumsuzluk olmaması için kod olarak altyapınızda (IaC) AKS sürüm ayarını kontrol edin. Planlı bakım pencerenizi otomatik güncelleme 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. Daha fazla bilgi için aşağıdaki kaynaklara bakın:

• Kapsayıcılar için Microsoft Defender kapsayıcı görüntüleriniz için Defender for Cloud önerileri tanımlar ve düzeltir.
• Kapsayıcılar için Defender, düzenli olarak kapsayıcı görüntülerinizi güvenlik açıklarına karşı tarar.
• Kapsayıcılar için Defender ayrıca şüpheli etkinlikler için gerçek zamanlı güvenlik uyarıları da oluşturur.
• AKS'deki uygulamalar ve kümeler için güvenlik 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 ayrıntılı bilgiler.

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

Küme ve iş yükü işlemleri (DevOps) ile ilgili dikkat edilmesi gerekenler için bkz. Operational Excellence tasarım ilkeleri sütunu.

Küme başlatma

Kümenizi ayarladıktan sonra, bu çalışan bir kümedir, ancak iş yüklerini dağıtmadan önce yapmanız gereken daha fazla adım olabilir. Kümenizi hazırlama işlemine bootstrapping adı verilir. Önyükleme genellikle önkoşul görüntülerini küme düğümlerine dağıtmak, ad alanları oluşturmak ve kuruluşunuzun kullanım örneğinin gereksinimlerini karşılayan diğer görevleri gerçekleştirmektir.

Yeni ayarlanmış bir kümeden düzgün yapılandırılmış bir kümeye geçişi hızlandırmak için benzersiz önyükleme işleminizi tanımlamanız ve ilgili varlıkları önceden hazırlamanız gerekir. Örneğin, Linkerd veya Consul Connect gibi bir hizmet ağı kullanıyorsanız, uygulama iş yüklerinin zamanlanmasından önce genellikle ağı dağıtırsınız. Kümeyi ayarlamadan önce, hizmet ağı görüntülerinin önceden oluşturulmuş bir kapsayıcı kayıt defterinde mevcut olduğunu doğrulamanız gerekir. Bu doğrulama, dağıtım gecikmelerini veya hatalarını önlemeye yardımcı olur.

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

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

Note

Bu yöntemlerden herhangi biri herhangi bir küme topolojisiyle çalışır, ancak tekdüzenlik ve büyük ölçekte daha kolay idare nedeniyle filolar için GitOps Flux v2 küme uzantısını öneririz. Yalnızca birkaç küme çalıştırdığınızda GitOps aşırı karmaşık olabilir. Bunun yerine, önyüklemenin gerçekleştirildiğinden emin olmak için işlemi bir veya daha fazla dağıtım hatlarına entegre etmeyi tercih edebilirsiniz. Kuruluşunuz ve ekip hedeflerinize en uygun yöntemi kullanın.

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. İleride güçlü bir yönetim temeli oluşturacak şekilde ortamı kurar ve aynı zamanda kaynak şablonları olarak 'bootstrapping'i dahil etmeyi destekleyerek IaC stratejinizle uyumlu hale getirir.

Önyükleme bildirimleri yalnızca dağıtım zamanında bilinen kapsayıcı kayıt defteri URL'si, Key Vault adı veya kimlik istemci kimliği gibi değerler gerektirdiğinde kustomization yapılandırmasında Flux değişken değiştirmesini kullanın. Bir Kustomization, Git deposundaki hangi yolun eşzamanlanacağını ve derleme sonrasında hangi değişken ikamelerinin uygulanacağını tanımlar. Kustomization’ları, IaC şablonunuzdaki Flux uzantısı dağıtımının bir parçası olarak yapılandırır; küme oluşturulurken değerlerin dağıtılan kaynaklardan çözümlenmesini sağlamak için ikame değişkenlerini burada tanımlarsınız. Bu yaklaşım, bir ConfigMap'in ilk eşitlemeden önce mevcut olmasının gerektiği durumlarda ortaya çıkan zamanlama sorunlarını ortadan kaldırır ve kullanıcıların yalnızca ortama özel değerleri özelleştirmek için depoyu çatallamak zorunda kalmasını da önler. Flux uzantısı aracısı, bu IaC yapılandırmasını Flux Kustomize denetleyicisinin uzlaştıracağı Kubernetes özel kaynaklarına çevirir ve her yolu işlerken değişken değişikliklerini uygular.

Son olarak, GitOps Flux v2 küme uzantısını kullandığınızda, önyükleme işleminin herhangi bir parçası için kubectl gerekli değildir. Acil durumlarda düzeltmeler için kubectl tabanlı erişim 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 bir iş yüküyle başlayın ve bunun üzerine inşa edin. İlk görev, ağı yapılandırmaktır. Merkez ve uçlar için sanal ağları ve bu ağların içindeki alt ağları ayarlayın. Örneğin, bir uç sistem ve kullanıcı düğümü havuzları, giriş kaynakları ve özel AKS API sunucusu 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 kullanın

Mümkün olduğunda emredici bir yaklaşım yerine idempotent 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. Başvuru uygulaması Bicep kullanır, ancak bunun yerine Terraform veya Azure Resource Manager şablonları (ARM şablonları) kullanmayı seçebilirsiniz.

İdare ilkelerine göre kaynakları ayarladığınızdan 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. Ayrıca Azure İlkesi kullanarak kuruluşunuzun bu kararlara yönelik ilkelerini zorunlu kılabilirsiniz.

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. 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çin Pipelines sürekli olarak uygulama oluşturabilmeli ve dağıtabilmelidir. 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 Services ve Jenkins bulunur.

Küme CI/CD

Diyagramda ci/CD iş akışı soldan sağa gösterilir. Sol tarafta Kod olarak altyapı simgesi, kaynak denetiminde depolanan bildirim temelli yapılandırmayı temsil eder. Kod olarak altyapıdan 'Dağıt' etiketli yatay bir ok, 'GitOps' etiketli merkezi bir kutuya yönelir. Bu kutu Azure Pipelines, GitHub Actions ve Jenkins İşlem Hatlarını içerir. GitOps kutusundan, Eşitle etiketli bir ok AKS simgesine işaret eder.

Bu mimarinin 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 aşağıdaki 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.

Aşağıdaki örnek diyagramda GitOps ve Flux ile küme yapılandırmasını otomatikleştirme gösterilmektedir.

Diyagramda, soldan sağa dört numaralandırılmış adımla GitOps iş akışı gösterilmektedir. En solda, dizüstü bilgisayar içeren bir geliştirici simgesi, kullanıcının IaC değişikliklerini Git deposuna gönderdiği 1. Adım olarak görünür. 2. adım, "git clone --mirror" etiketiyle belirtilmiş bir ok aracılığıyla bağlanan Git deposunu, AKS kümesi sınırının içindeki bir Flux simgesine göstermek için gösterir. 3. adım, Flux simgesinden küme içindeki Kubernetes API sunucusu simgesine işaret eden kubectl apply etiketli bir ok gösterir. 4. adım, geliştirici ile Kubernetes API sunucusu arasında diyagonal çizgi içeren ve üzeri çizili kubectl etiketine sahip kırmızı bir daire görüntüler.

Bu mimarinin 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, 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 access yoktur.

Git sunucunuzda, değişikliklerin üretime uygulanmadan önce birden çok geliştirici tarafından bir pull request aracılığıyla onaylanabilmesi için dal politikaları oluşturabilirsiniz.

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. Bu işlem değişikliğin simülasyonunu oluşturur 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

AKS için Well-Architected Framework'te özetlenen maliyet optimizasyonu tasarım denetim listesini ve öneriler listesini gözden geçirerek başlayın. Genel iş yükü önerileri için, Maliyet Optimizasyonu için Tasarım inceleme kontrol listesine bakınız.

Bu temel mimaride kullanılan bileşenler için maliyet tahminini Azure fiyatlandırma hesaplayıcısı bulabilirsiniz. Tahmininizi, kullanım örneğiniz için gereken bileşenleri içerecek şekilde değiştirin. Bu tahmin, kümeyle doğrudan ilişkili uç düzeyindeki kaynakları kapsar. Azure Güvenlik Duvarı, hub sanal ağları ve Azure Özel DNS bölgeleri gibi paylaşılan hub altyapısı, genellikle merkezi bir platform ekibine ait ve yönetilen kaynaklar olduğundan dahil değildir.

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

Provision

• 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, storage, 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. Ddv5 serisi sistem düğümü havuzu için tipik bir VM türüdür ve başvuru uygulaması Standard_D2d_v5 SKU'yu kullanır.

• Geliştirme/test ve üretim ortamları için aynı yapılandırmayı kullanmayın. Ü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, yüksek kullanılabilirlik garantisinin gerekmediği geliştirme/test veya deneysel iş yükleri için tasarlanmış kümelerle tasarruf sağlanabilir. Örneğin, SLO'nuz yeterli olabilir. Ayrıca, iş yükünüz destekliyorsa, spot VM çalıştıran ayrılmış spot düğüm havuzlarını kullanmayı göz önünde bulundurun.

  AKS iş yükü mimarisinin bir parçası olarak Azure SQL Veritabanı veya Azure App Service içeren üretim dışı iş yükleri için Azure Geliştirme/Test aboneliklerini kullanmaya ve hizmet indirimleri almaya 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 düğümlerin tüm kapasitesini 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.

• Uzun bir süre mevcut olması gereken iş yükleriniz için düğüm maliyetlerini azaltmak amacıyla bir veya üç yıllık Azure Ayrılmış Sanal Makine Örneklerine taahhütte bulunun. Daha fazla bilgi için bkz. Save costs with Azure Reserved Virtual Machine Instances.

• 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. Küme ekipler arasında paylaşılıyorsa, paylaşılan bulut hizmetlerinin ölçülen maliyetlerini belirlemek için her tüketici için ücretlendirme raporları oluşturun. Daha fazla bilgi için bkz. Düğüm havuzu için leke, etiket veya işaret belirleme.

• İş 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. Bandwidth pricing.

• 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.

Monitor

Kümenin tamamını ve işlem maliyetini, storage, bant genişliğini, günlükleri ve güvenlik duvarını izleyebilirsiniz. Azure maliyetleri izlemek ve analiz etmek için aşağıdaki seçenekleri sağlar:

• Azure Danışmanı
• Maliyet Yönetimi

Maliyetlerinizi gerçek zamanlı olarak veya düzenli bir zamanlamaya göre izleyerek, maliyetlerin zaten hesaplandığı ay sonundan önce işlem yapabilirsiniz. Bütçenin içinde 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. Kullanım ölçümlerini Azure İzleyici ölçümlerde görebilirsiniz.

Optimize

Azure Danışmanı önerilerini izleyin. İyileştirmenin diğer yollarını keşfedin:

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

  Important

  Maliyetleri denetlemek için bir düğüm havuzu için en düşük ve en yüksek düğüm sayısı gibi küme otomatik ölçeklendiricisi ayarlarında hızlı veya sık değişiklikler yapmak istenmeyen veya karşı üretim sonuçlarına neden olabilir. Örneğin, 10 dakika olarak ayarlanırsa ve en düşük ve en yüksek düğüm ayarları iş yükü özelliklerine göre 5 dakikada bir değiştirilirse scale-down-unneeded-time , düğüm sayısı hiçbir zaman azalmaz. Bunun nedeni, küme otomatik ölçeklendiricisi ayarları yenilendiğinde her düğüm için gereksiz sürenin hesaplanması sıfırlanı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 haklarınızı belirlemeyi göz önünde bulundurun.

• İş yükünüz destekliyorsa, kullanıcı düğümü havuzlarınızı çalıştırılma beklentisi olmadığında sıfır düğüme ölçekleyin. 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.

Daha fazla bilgi için bkz. AKS fiyatlandırması.

Sonraki Adımlar

• GitHub'daki AKS yol haritası

İlgili kaynaklar

• Geldirilmiş AKS mikro hizmetler mimarisi
• AKS üzerinde Mikro Hizmetler mimarisi
• AKS kümesini korumaya yardımcı olmak için Azure Güvenlik Duvarı kullanın
• AKS için GitOps
• AKS kullanarak veri akışı

Bu makalede, bir Azure Kubernetes Service (AKS) kümesi dağıtmak için önerilen temel altyapı mimarisi sağlanır. Tasarım ilkelerimizi izler ve Azure Well-Architected Framework'den AKS architectural best practices ile uyumludur. Makale, bu genel amaçlı altyapıyı dağıtırken ağ, güvenlik ve kimlik ekipleri gibi farklı disiplinler arası grupları yönlendirir.

Bu mimari bir iş yüküne odaklanmaz. AKS kümesinin kendisine odaklanır. Bu bilgiler, AKS kümelerinin çoğu için önerilen en düşük temeldir. Gözlemlenebilirlik sunan, ç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 hizmetlerle tümleştirilir.

İş gereksinimleriniz hedef mimariyi etkiler ve 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.

Tip

Bu makalede AKS kümeleri için kapsamlı tasarım konuları ele alınıyor. AKS Otomatik , değerlendirmeniz gereken önemli noktaların sayısını azaltmak ve yaygın kullanım örnekleri için iyileştirmek için birçok tasarım kararı uygular. Örneğin AKS Otomatik, yönetilen bir sistem düğümü havuzu sağlar ve çalıştırır; bu nedenle bu makaledeki sistem düğümü havuzu boyutlandırma, yalıtım ve yükseltme kararları bu platform için geçerli değildir.

İş yükünüz AKS Otomatik ortamında barındırılacak olsa bile, kendi kendine yönetilen aks kümesinin temellerini bilmek, iş yükünüz değiştikçe doğru seçimleri yapmanıza yardımcı olabilir.

Kubernetes, Azure ve Microsoft teknolojilerinin ötesine uzanan geniş bir ekosistemdir. AKS kümesini dağıtırken, kümeyi tasarlama ve çalıştırma hakkında birçok karardan siz sorumlu olursunuz. AKS kümesini çalıştırmak, Microsoft dahil olmak üzere çeşitli satıcıların kapalı kaynak bileşenlerinin yanı sıra Kubernetes ekosisteminden açık kaynak bileşenleri içerir. Ortam sık sık değişir, bu nedenle kararları düzenli olarak gözden geçirin. Kubernetes'i benimsediğinizde, iş yükünüzün özelliklerine ihtiyacı olduğunu ve iş yükü ekibinizin sürekli olarak yatırım yapmaya hazır olduğunu kabul etmiş olursunuz.

Bu mimarinin bir uygulamasını GitHub: AKS temel başvuru uygulaması alternatif bir başlangıç noktası olarak kullanabilir ve gereksinimlerinizi karşılayacak şekilde yapılandırabilirsiniz.

Note

Başvuru mimarisi, Kubernetes ve kavramları hakkında bilgi gerektirir. Eğer bir bilgi tazeleme ihtiyacınız varsa, Kubernetes'e Giriş ve Kubernetes Üzerinde Uygulama Geliştirme ve Dağıtma eğitim yollarına bakın.

Ağ yapılandırması

Ağ topolojisi
IP adreslerini planlama
Uygulama yönlendirme

Küme işlem

Temel küme için işlem
Kapsayıcı görüntü referansı
Politika yönetimi

Kimlik yönetimi

Kümeye Microsoft Entra ID'yi Entegre Edin
İş yükü için Microsoft Entra ID'yi entegre edin

Güvenli veri akışı

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

İş sürekliliği

Düğüm ve pod ölçeklenebilirliği
İş sürekliliği kararları
Availability zonesKultiple bölgeleri

Operations

Küme ve iş yükü işlemleri
Günlükleri ve ölçümleri izleme ve toplama
Maliyet yönetimi

Architecture

Diyagramda iki bağlı sanal ağ gösterilmektedir. Merkez sanal ağı Azure Güvenlik Duvarı, Azure Bastion ve şirket içi ağa bağlı bir ağ geçidi alt ağını içerir. Uç sanal ağ birkaç alt ağ, AKS kümesi ve düğüm havuzları içerir. Virtual network eşlemesi, merkez ve uç sanal ağlarını çift yönlü bir bağlantı üzerinden bağlar. Key Vault ve Container Registry'den Özel Bağlantı uç noktalarının bulunduğu alt ağa oklar işaret eder. Azure Bastion alt ağı (yönetim) ile çevresel sanal ağdaki iç yük dengeleyiciye işaret eden bir ok. Bir ok, şirket içi ağdan şirket içi ağ geçidine işaret eder. Merkez sanal ağdan uzak ofis bağlantısına, sanal ağ eşlemesi etiketli çift yönlü ok. İnternet'ten Azure Application Gateway alt ağa işaret eden bir ok. AKS kümesinden, ölçümleri ve yönetilen Prometheus'u içeren Azure İzleyici çalışma alanı bölümüne bir ok uzanır.

Bu mimarinin Visio dosyasını indirin.

Daha fazla bilgi için, Azure'da Hub-spoke ağ topolojisi bölümüne bakın.

Ağ topolojisi

Bu mimaride merkez-uç ağ topolojisi kullanılır. Hub ve uçları sanal ağ eşleme aracılığıyla bağlanan ayrı sanal ağlarda dağıtın. Bu topolojinin çeşitli avantajları vardır:

• Ayrılmış yönetimi etkinleştirin. İdare uygulayabilir ve en az ayrıcalık ilkesine (PoLP) bağlı kalabilirsiniz. Ayrıca, görev ayrımı ile 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-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ı olmak için bir web application firewall 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ı ağlar arasında paylaşmayı destekler.

• Azure kurumsal ölçekli giriş bölgesi ile hizalayın.

Merkez sanal ağı

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

• Merkezi BT ekiplerinizin kuruluş genelinde kuralları zorunlu kılmak için tanımlamış olduğu genel güvenlik duvarı ilkeleriyle Azure Güvenlik Duvarı

• küme yönetimi işlemlerini gerçekleştirebilmeniz için özel ağ çevresine güvenli bir tünel oluşturan Azure Bastion

• VPN bağlantısı için bir ağ geçidi alt ağı

• Ağ gözlemlenebilirliği için Azure İzleyici

Ağda, mimaride üç alt ağ bulunmaktadır.

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

Azure Güvenlik Duvarı yönetilen bir 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 olmayan bir hizmetle iletişim kurabilir. Birden çok Azure Güvenlik Duvarı örneğini merkezi olarak dağıtmak ve yapılandırmak ve bu hub sanal ağı mimari türü için Azure Güvenlik Duvarı ilkelerini yönetmek için Azure Güvenlik Duvarı Yöneticisi kullanın.

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

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 virtual network arasında bağlantı sağlar.

Azure Bastion'u barındıracak alt ağ

Bu alt ağ Azure Bastion için kullanılır. Azure Bastion kullanarak kaynakları İnternet'e göstermeden Azure kaynaklara güvenli bir şekilde erişebilirsiniz. Bu mimari, yönetim işlemleri için AKS kümesinin API sunucusuna güvenli bir şekilde bağlanmak için Azure Bastion kullanır. Alt ağ yalnızca yönetim işlemleri içindir.

Çıkış sanal ağ

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

Azure Application Gateway’in barındırılması için kullanılan alt ağ

Azure Application Gateway Katman 7'de çalışan bir web trafiği yük dengeleyicidir. Başvuru uygulaması, Azure Web Uygulaması Güvenlik Duvarı'yi 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. Örnek, kullanıcı isteklerini alan genel bir ön uç IP yapılandırmasına sahiptir. Tasarım gereği Application Gateway ayrılmış bir alt ağ gerektirir.

İç yük dengeleyici IP'leri için alt ağ

Bu alt ağ, iç yük dengeleyici ön uç IP'leri için adres alanı sağlar. Application Gateway, trafiği atanan özel iç yük dengeleyici IP'sine gönderir ve yük dengeleyici trafiği kümedeki herhangi bir düğüme dağıtır.

Paketi alan düğümdeki kube-proxy aracı, paketi sistem düğümü havuzundaki ağ geçidi proxy pod'una iletir ve ek bir ağ sıçramasına neden olabilir. Ara sunucu Aktarım Katmanı Güvenliği'ni (TLS) sonlandırır ve istekleri HTTP üzerinden iş yükü podlarına iletir.

Ön uç yük dengeleyici IP'leri için ayrılmış bir alt ağ kullanarak, düğüm alt ağını etkilemeden yük dengeleyiciye gelen trafiğin kapsamını oluşturan ağ güvenlik grubu (NSG) kuralları uygulayabilirsiniz. Daha fazla bilgi için AKS ile bir iç yük dengeleyici kullanma bölümüne bakın.

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

Bu mimaride, ayrı düğüm grupları olan iki düğüm havuzu kullanılır. Sistem düğümü havuzu, trafiği iş yüküne yönlendiren ağ geçidi ara sunucusu da dahil olmak üzere çekirdek küme hizmetlerini çalıştıran podları barındırıyor. Kullanıcı düğüm havuzu iş yükünü çalıştırır.

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

Azure Container Registry ve Azure Key Vault için Azure Özel Bağlantı bağlantıları oluşturun; böylece kullanıcılar uç sanal ağındaki private uç noktası üzerinden bu hizmetlere erişebilir. Özel uç noktalar için ayrılmış alt ağ gerekmez. Hub sanal ağına özel uç noktaları da yerleştirebilirsiniz. Temel uygulamada, uç noktalar konuşlandırılmış sanal ağ içerisindeki ayrılmış bir alt ağa dağıtılır. Bu yaklaşım, eşlenmiş ağ bağlantısından geçen trafiği azaltır ve kümeye ait kaynakları aynı sanal ağda tutar. Ayrıca NSG'leri kullanarak alt ağ düzeyinde ayrıntılı güvenlik kuralları uygulayabilirsiniz.

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

AKS API sunucusu alt ağı

Bir AKS kümesini, API sunucusu sanal ağ tümleştirmesi kullanacak şekilde yapılandırabilirsiniz. Bu, kümenin API sunucusu uç noktasını sanal ağınızdaki bir yetkilendirilmiş alt ağa projelendirir. API sunucusu, düğüm havuzları ve bağlı istemciler arasındaki tüm trafiğin tamamen özel ağınızda kalmasını sağladığından bu yapılandırma özel küme olarak adlandırılır.

AKS tarafından yönetilen Kubernetes API sunucusu ile hem küme içi hem de dış istemciler arasındaki tüm iletişim güvenilen bir ağ ile sınırlıdır.

Özel küme ile ortamınızın güvenliğini sağlamak için NSG'leri ve diğer yerleşik ağ denetimlerini kullanabilirsiniz. Bu yapılandırma, internet ile ortam arasında yetkisiz kamusal erişimi engeller. Daha fazla bilgi için bkz. Özel AKS kümesi oluşturma.

IP adreslerini planlayın

Diyagramda basit bir AKS merkez-uç ağ topolojisi gösterilmektedir. Hub sanal ağı, Azure Güvenlik Duvarı, Azure Bastion ve bir geçit alt ağı içerir. İkincil sanal ağ, Application Gateway, ingress, düğümler, özel uç noktalar ve özel küme için alt ağlar içerir. Oklar, uç ağlardan merkez ağına olan eş ağ bağlantılarını gösterir.

Bu mimarinin Visio dosyasını indirin.

Bu başvuru mimarisi, her biri ayrı bir IP adresi alanı gerektiren aşağıdaki ağ yaklaşımlarını kullanır.

• Küme düğümleri, küme API sunucusu, Azure hizmetleri için özel uç noktalar ve Application Gateway gibi kaynaklar için kullandığınız Azure sanal ağınız.

• Kümenin, Azure sanal ağınızdan ayrı bir adres alanından podlara IP adresleri ayırmak için kullandığı Azure Kapsayıcı Ağı Arabirimi (CNI) Katmanı.

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ı hesaplayın. Kubernetes, alt ağ adres alanından varlıklar için IP adresleri ayırır. Azure sanal ağınızın IP adreslerini planlarken aşağıdaki noktaları göz önünde bulundurun:

• Yükseltmeler: AKS, arka plandaki VM'lerin güvenlik özellikleri ve diğer sistem yamaları açısından 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üğüm, küme alt ağından bir IP adresi alır. 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 Üst Üste Binen pod adres alanının içinden IP adresleri tahsis edilir. Bu yaklaşım, Azure sanal ağınızdan kullanılan IP adreslerinin genel sayısını diğer Kubernetes ağ yaklaşımlarıyla karşılaştırıldığında azaltır.

• Ölçeklenebilir -lik: Sistem ve kullanıcı düğümlerinin toplam sayısını ve bunların en yüksek ölçeklenebilirlik sınırlarını göz önünde bulundurun. Örneğin, %400'lik bir ölçeklendirme istiyorsanız, tüm ölçeklendirilmiş düğümler için adres sayısının dört katına ihtiyacınız vardır.

  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: Diğer Azure hizmetleriyle Özel Bağlantı aracılığıyla iletişim sağlamak için gereken adresleri göz önünde bulundurun. Bu mimari, Container Registry ve Key Vault bağlantıları için atanmış iki adrese sahiptir.

• Özel küme API sunucusu adresleri: API sunucusunun sanal ağ ile entegrasyonu, AKS API sunucusunu sanal ağınız içinde bir uç nokta olarak yansıtmanıza yardımcı olur. Bu özellik için minimum alt ağ boyutu gerekir; bu nedenle ağ planlamanız sırasında bu önkoşulları karşıladığınızdan emin olun.

• Rezerve IP adresleri: Azure, kendi kullanımları için belirli adresleri 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 da isteyebilirsiniz. Bu yalıtım, daha küçük alt ağlara neden olur. Her Ağ Geçidi kaynağı kendi ağ geçidi ara sunucusu dağıtımını ve yük dengeleyici ön uç IP'sini ürettiğinden ağ geçidi topolojisi de genişleyebilir. Alt ağ adres alanını uygun şekilde planlayın.

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ız veya eşlenmiş sanal ağlarınız ile çakışmayan bir IP adres alanı kullanın. Ancak birden çok AKS kümesi oluşturursanız, her kümede aynı pod adres alanını güvenle kullanabilirsiniz.

Azure CNI Overlay her düğüme podları için bir /24 adres alanı atar. Pod adres alanının yeterince büyük olduğundan emin olmak önemlidir. Kümenizdeki düğüm sayısı için gereken sayıda /24 bloğu sağlayın. Yükseltmeler veya ölçeği genişletme işlemleri sırasında oluşturulan geçici düğümleri eklemeyi unutmayın. Örneğin, Sınıfsız Inter-Domain Yönlendirme (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 adreslemeyi planlama hakkında daha fazla bilgi almak için Azure CNI ağını AKS'de yapılandırma'ya bakın.

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. Önizleme özellikleri ve eklentiler arasındaki aşağıdaki farkları göz önünde bulundurun:

• AKS ekibi, önizleme özelliklerini yayınlandı ve geliştiriliyor olarak tanımlar, çünkü birçok önizleme özelliği, genel kullanılabilirlik (GA) aşamasına geçmeden önce yalnızca birkaç ay bu durumda kalır.

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

Temel mimari her önizleme özelliğini veya eklentiyi içermez, 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ümelerdeki diğer bazı önizleme özelliklerini veya AKS eklentilerini değerlendirmek isteyebilirsiniz. Bu özellikler güvenliğinizi, yönetilebilirliğinizi veya diğer gereksinimlerinizi iyileştirebilir. Kullanılabilir sürümleri izleme ve kümenin Kubernetes sürümünü yükseltdikten sonra güncelleştirmeleri yükleme gibi Microsoft olmayan eklentileri yüklemeniz ve korumanız gerekir.

Kapsayıcı imaj başvurusu

Küme, iş yükünü ve kendi kendine yönetilen ağ geçidi altyapısı veya TLS sertifikalarını Key Vault’tan eşitleyen bir yardımcı kapsayıcı gibi başka birkaç imajı içerebilir. Bu görüntülerin bazıları genel kayıt defterlerinde bulunabilir, ancak taranmalarını, denetlenmelerini ve Azure Container Registry gibi özel bir kayıt defterinde depolanmalarını sağlamak iyi bir uygulamadır. Görüntüleri kümenize çekerken aşağıdaki noktaları göz önünde bulundurun:

• Görüntüyü çekmek için kümeyi kimlik doğrulamasından geçir.

• Genel görüntü kullanıyorsanız, görüntüyü hizmet düzeyi hedefinizle (SLO) uyumlu bir 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, işlem sorunları oluşabilir. Genel kayıt defteri yerine Azure Container Registry gibi özel bir kapsayıcı kayıt defteri kullanmanın aşağıdaki avantajlarını göz önünde bulundurun:

  • Resimlerinize yetkisiz erişimi engelleyebilirsiniz.
  • Genel kullanıma yönelik bağımlılıklarınız yoktur.
  • Etkinlikleri izlemek ve bağlantı sorunlarını çözmek 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. Referans uygulamasında küme, görüntüleri yalnızca kümeyle birlikte dağıtılan özel Azure Container Registry örneğinden çeker.

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

AKS'de her düğüm havuzu genellikle bir sanal makine ölçek kümesiyle eşlenir. Düğümler her düğüm havuzunda virtual machines (VM) olur.

Maliyetleri en aza indirmek için sistem düğümü havuzu için daha küçük bir VM boyutu kullanmayı göz önünde bulundurun. Referans uygulama, sistem düğümü havuzunu üç D2dv5 düğümüyle dağıtır. Bu boyut, sistem podlarının beklenen yükünü karşılamak için yeterlidir. İşletim sistemi kısa ömürlü diski 64 GB'tır.

Bir kullanıcı düğümü havuzu için kapasiteyi planlarken aşağıdaki önerileri göz önünde bulundurun:

• 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 etkisini 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'daki VM'ler için Boyutlar.

• İş yükünün iki kopya ile yüksek kullanılabilirlik modelini izleyebilmesi için en az iki düğüm dağıtın. AKS ile kümeyi yeniden oluşturmadan düğüm sayısını değiştirebilirsiniz.

• Planlama ekibinizin belirlediği gereksinimlere göre iş yükünüz için düğüm boyutlarını planlayın. bu mimari, iş gereksinimlerine göre üretim iş yükü için D4dv5 SKU'yu kullanır.

• Kümeniz için kapasiteyi planlarken, iş yükünüzün her düğümün en fazla 80% tükettiği varsayın. Kalan %20 AKS hizmetleri için ayrılmıştır.

• Kapasite planlamanıza göre her düğüm için en yüksek pod sayısını ayarlayın. Kapasite temeli oluşturmaya çalışırsanız 30 değeriyle başlayın. bu değeri iş yükünün gereksinimlerine, düğüm boyutuna ve IP adresi 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. Başvuru uygulaması, Azure için ayarlanmış basit, sağlamlaştırılmış bir Linux dağıtımı olan Azure Linux'ı kullanır. İsterseniz veya Azure Linux gereksinimlerinizi karşılamıyorsa Ubuntu gibi başka bir Linux dağıtımı seçebilirsiniz. Farklı bir işletim sistemi seçerseniz işletim sistemi diskinin bu görüntü için uygun şekilde boyutlandırılmış olduğundan emin olun. Bazı dağıtımlar Azure Linux'tan daha fazla alan gerektirdiğinden, dağıtım veya çalışma zamanıyla ilgili sorunları önlemek için disk boyutunu artırmanız gerekebilir.

İş yükünüz karma teknolojilerden oluşuyorsa farklı düğüm havuzlarında farklı işletim sistemleri kullanabilirsiniz. Farklı işletim sistemlerine ihtiyacınız yoksa, işletim karmaşıklığını azaltmak için tüm iş yükü düğümü havuzları için tek bir işletim sistemi kullanmanızı öneririz.

Küme için Microsoft Entra ID'yi tümleştirin

Kümeye ve kümeden erişim güvenliğini sağlamak kritik önem taşır. içten dışa ve dıştan içe trafik arasındaki farkı anlamak için kümenin bakış açısından yararlanın.

• Inside-out access: 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ı yetkilendirin.

• Dışarıdan erişim: Kubernetes kümesine erişimi olan kimlikler sağlayın. Yalnızca Kubernetes API sunucusuna ve Azure Resource Manager erişimine izin verilen dış varlıkları yetkilendirir.

Azure bileşenlerine AKS erişimi

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

Azure'da AKS erişimini yönetmek için iki yöntemden birisi olarak yönetilen kimlikleri öneririz. Hizmet sorumluları için gizli dizileri el ile veya program aracılığıyla yönetmeniz ve döndürmeniz gerekir. Yönetilen kimlikler için Microsoft Entra ID, kimlik doğrulamayı ve gizli anahtarların zamanında yenilenmesini yönetir ve gerçekleştirir.

Kümenin Microsoft Entra ID aracılığıyla dış Azure kaynaklarıyla etkileşim kurabilmesi için AKS yönetilen kimlikleri etkinleştirmenizi ve kullanmanızı öneririz. Microsoft Entra ID tümleştirmesini hemen kullanmıyorsanız daha sonra ekleyebilirsiniz.

Varsayılan olarak, küme iki birincil kimlik kullanı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 adresleri de 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 kimlik kullanmalısınız. Bu eylem, kümenin kayıt defteri kimlik bilgilerini almasını gerektirir; buna, kümenin kubelet tarafından yönetilen kimliğine AcrPull kayıt defterinize erişim vererek izin verirsiniz. Yönetilen bir kimlik kullanmıyorsanız, bu bilgiyi bir Kubernetes secret'ında depolayabilir ve bunu almak için imagePullSecrets kullanabilirsiniz. Gizli diziyi önceden bilmek ve DevOps işlem hattında depolamak gibi güvenlik karmaşıklıkları içerdiğinden bu yaklaşımı önermeyiz. Ayrıca, sırrı güncellemeniz gerektiğinden operasyonel yük de artar.

Bu mimaride küme, Microsoft Entra ID güvenli Azure kaynaklara 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) rollerini ve izinlerini kümenin yönetilen kimliklerine atayın. Küme, Microsoft Entra ID için kimliğini doğrular ve kendisine atanan rollere göre erişim izni verilir veya erişim reddedilir. Başvuru uygulamasından alınan aşağıdaki örnekler, kümeye atanmış Azure yerleşik rolleri gösterir:

• Network Katılımcı rolü kümenin uç sanal ağ denetleme yeteneğini yönetir. Bu rol atamasıyla, AKS kümesinin sistem tarafından atanan kimliği, ağ geçidi ara sunucusuna ve AKS özel API sunucusuna hizmet veren iç yük dengeleyici için ayrılmış alt ağla etkileşim kurabilir.

• Özel DNS Bölge Katılımcısı rolü, kümenin bölgeyi doğrudan kümeyi barındıran uç sanal ağına bağlama becerisini yönetir. Özel küme, özel dns bölgesi kullanarak DNS kayıtlarını genel İnternet'in dışında tutar, ancak yine de genel DNS adresiyle özel bir AKS kümesi oluşturmak mümkündür. Kontrol düzleminizin özel IP adresinin ifşa edilmesini önlemek için, enablePrivateClusterPublicFQDN değerini false olarak ayarlayarak bu özelliği açıkça devre dışı bırakmanızı öneririz. Genel DNS kayıtları olmadan özel kümelerin kullanımını zorlamak için Azure İlkesi kullanmayı göz önünde bulundurun.

• Monitoring Metrics Publisher rolü kümenin Azure İzleyici ölçüm gönderme özelliğini yönetir.

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

İki AKS eklentisi, rol atamaları gerektiren ek yönetilen kimlikler sağlar. Secrets Store CSI Driver eklentisinin kimliği, TLS sertifikalarını Key Vault'tan alır. Uygulama yönlendirme eklentisi kimliği, DNS kayıtlarını ve Ağ Geçidi mutabakatını yönetir.

Bu iki kimlikle etkileşime geçtikleri kaynaklara aşağıdaki erişimi verin:

• Secrets Store CSI Driver eklentisi tarafından yönetilen kimliğin, sürücünün TLS sertifikalarını alabilmesi için anahtar kasanızda Key Vault Certificate User rolüne sahip olması gerekir.

  Note

  Alternatif olarak, CSI Sürücüsü eklentisi yönetilen kimliğini Key Vault erişim için Microsoft Entra İş Yükü Kimliği ile değiştirebilirsiniz. İş Yükü Kimliği'ni kullandığınızda, federasyon kimlik bilgilerini kullanarak kullanıcı tarafından atanan yönetilen kimliği Kubernetes ServiceAccount'a bağlar ve ağ geçidi dinleyicisinin TLS seçeneklerinde ServiceAccount'a başvurursunuz. Uygulama yönlendirme eklentisi daha sonra SecretProviderClass'ı otomatik olarak oluşturur.

  CSI sürücüsü aracılığıyla Key Vault erişim için genellikle eklentinin yönetilen kimliğini veya İş Yükü Kimliğini seçersiniz. İş Yükü Kimliği, ad alanı düzeyinde kimlik yalıtımı sağlar ve federe kimlik bilgileri yoluyla ek kimlik güçlendirmesi getirmesi pahasına manuel kaynak yönetimini azaltır.

• Uygulama yönlendirme eklentisinin yönetilen kimliği, anahtar kasanızda Key Vault Secrets User ve Key Vault Okuyucusu rollerine ihtiyaç duyar. Yerleşik DNS bileşeninin ağ geçidi kaynaklarını eşitleyebilmesi için, bu kimliğin giriş özel DNS bölgesinde de Özel DNS Bölgesi Katkıda Bulunanı rolüne sahip olması gerekir.

  Note

  Eklentiyle dağıtılan yerleşik DNS bileşeni, DNS kayıtlarını otomatik olarak uzlaştırmaz. Ağ Geçidi API'si kayıtları için İş Yükü Kimliği yaklaşımını kullanın.

Daha fazla bilgi için bkz. Azure DNS ve TLS'yi uygulama yönlendirme Ağ Geçidi API uygulamasıyla yapılandırma.

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. Mevcut küme rol izinleri.

AKS, yerel Kubernetes RBAC ile tümleştirilmiş bir kimlik sağlayıcısı olarak Microsoft Entra ID kullanarak veya küme erişimini denetlemek için yerel Azure RBAC kullanarak Microsoft Entra ID aracılığıyla Kubernetes erişimini destekler. Aşağıdaki bölümlerde her iki yaklaşım da ayrıntılı olarak yer almaktadır.

Kubernetes RBAC'i Microsoft Entra ID ile ilişkilendirme

Kubernetes, aşağıdaki API nesneleri aracılığıyla RBAC'yi destekler:

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

• Eylemleri gerçekleştirme iznine sahip kullanıcıları ve grupları atayan bağlamalar. RoleBinding veya ClusterRoleBinding nesnesi kullanarak 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 kuruluş dizinini kullanmak üzere bu rolleri Microsoft Entra kullanıcılara ve gruplara bağlayın. Daha fazla bilgi için Microsoft Entra entegrasyonu ile Kubernetes RBAC kullanma konusuna bakın.

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

Kümede yetkilendirme denetimlerini zorunlu kılmak için Azure RBAC ve Azure rol atamaları kullanmanızı öneririz. Bu yetkilendirme yaklaşımı Microsoft Entra kimlik doğrulamasıyla tümleşir. Yönetim grubu, abonelik veya kaynak grubu gibi çeşitli kapsamlarda roller atayabilirsiniz. Kapsam altındaki tüm kümeler, Kubernetes kümesindeki nesnelere erişim izinlerine sahip olan kişilere göre tutarlı bir rol atamaları kümesini devralır.

ClusterRoleBindings ve RoleBindings ile Kubernetes-native RBAC kullanmanızı önermiyoruz.

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

Yerel hesaplar

AKS, yerel Kubernetes kullanıcı kimlik doğrulama destekler. Kümelere kullanıcı access sağlamak için bu yöntemi kullanmanızı önermiyoruz. Bu yöntem sertifika tabanlıdır ve birincil kimlik sağlayıcınıza dışarıdan gerçekleştirilir, bu da merkezi kullanıcı erişim kontrolü ve yönetimini zorlaştırır. Microsoft Entra ID kullanarak kümenize erişimi her zaman yönetin ve kümenizi yerel hesap erişimini açıkça yasaklaacak şekilde yapılandırın.

Başvuru uygulamasında, sistem kümeyi dağıttığında yerel küme hesaplarına erişim açıkça yasaktır.

İş yükü için Microsoft Entra ID'yi tümleştirin.

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 depolayabilir. Pod’un bu dosyalara erişmesi gerektiğinde, kaynağa karşı Azure yönetilen kimliğiyle kimlik doğrulaması yapar.

Referans uygulamada, AKS üzerinde Microsoft Entra İş Yükü Kimliği, pod’lar için yönetilen kimlikler sağlar. Bu yaklaşım, dış kimlik sağlayıcılarıyla federasyona yönelik Kubernetes yerel özellikleriyle tümleşir. Daha fazla bilgi için İş yükü kimlik federasyonu sayfasına bakın.

Ağ modeli seçme

AKS iki ağ modelinde CNI eklentileri sağlar: katman ve düz. Her iki model de küme içi trafik denetimi için ağ ilkelerini destekler.

Azure CNI Pod Alt Ağı gibi düz bir ağ eklentisiyle, her pod sanal ağ alt ağından bir IP adresi alır. Aynı ağdaki veya eşlenen ağlardaki kaynaklar, ağ adresi çevirisi (NAT) olmadan podlara doğrudan IP adresleriyle erişebilir. İş yükünüz podların sanal ağdan doğrudan yönlendirilebilir olmasını gerektirdiğinde düz ağ modeli kullanın.

Bu uygulama, sanal ağ IP adreslerini yalnızca düğümlere ayıran ve ayrı bir CIDR aralığından pod IP'leri atayan bir katman ağ eklentisi olan Azure CNI Yer Paylaşımını kullanır. Azure CNI Yer Paylaşımı düz modellerden çok daha az sanal ağ IP adresi tükettiğinden, çoğu dağıtım için bunu öneririz.

Modeller hakkında daha fazla bilgi için bkz . AKS CNI ağına genel bakış ve AKS'de ağ bağlantısı ve güvenliği için en iyi yöntemler.

Uygulama yönlendirme

Bu mimari , Kubernetes Gateway API'siyle uygulama yönlendirme eklentisini kullanır. Uygulama yönlendirme eklentisi, kümenin yönetilen ağ geçidi altyapısı içermesi gerektiğini bildiren bir AKS kümesi yapılandırmasıdır. Ağ Geçidi API'si, , , GatewayClassGatewayve diğerleri dahil olmak üzere HTTPRoutekubernetes özel kaynak tanımları (CRD) kümesidir. Kubernetes topluluğu, Ağ Geçidi API'sini önceki Giriş API'sinin ardılı olarak belirlemiştir. Ağ Geçidi API'si, trafik yönetimi için standartlaştırılmış, rol odaklı ve genişletilebilir bir çerçeve sağlar.

Ağ Geçidi API bileşenleri aşağıdaki yaşam döngüsü aşamalarında dağıtılır:

• Küme tasarımı. Uygulama ekibi, hangi ağ geçidi denetleyicisinin giriş trafiğini yönetmesi gerektiğine ve bu denetleyicinin yaşam döngüsünü nasıl yöneteceğine karar verir. Ağ geçidi denetleyicileri genellikle veri düzlemi proxy'lerini bir araya getirir, bu nedenle bu karar trafik yolunu hangi proxy'nin işlediğini de belirler. Bu mimari, yönetilen Gateway API CRD'lerine olanak tanır. Eklentiyi, ağ geçidi denetleyicisi olarak yönetilen Istio'yu kullanacak ve ağ geçidi ara sunucusu olarak Envoy ile eşleşecek şekilde yapılandırır. Istio'yu bir hizmet ağı olarak da kullanabilirsiniz, ancak bu mimari yalnızca ağ geçidi denetleyicisi olarak Istio kullanır ve hizmet ağı özelliklerini etkinleştirmez.

  Ekip farklı bir uygulama gerektiriyorsa NGINX Gateway Fabric, Envoy Gateway ve Traefik gibi diğer Ağ Geçidi API denetleyicilerini kullanabilir. Bu denetleyicilerin kendi kendine yönetilmesi için bildirimlere sahip olmak, benzeşim önleme, düğüm yerleştirme, yoklamalar, RBAC kapsamını belirleme, ölçeklendirme ilkeleri, kaynak IP kısıtlamaları ve sürüm yaşam döngüsü gerekir. Buna karşılık, takımlar ara sunucu davranışı, küme yükseltmelerinden bağımsız sürüm sabitleme ve kısıtlanmamış yapılandırma üzerinde tam idare elde eder.

• Küme oluşturma. Bu aşamada tasarım kararı alınmaz. AKS, Ağ Geçidi API'leri CRD'lerini, Istio ağ geçidi denetleyicisi podlarını aks-istio-system ad alanına ve GatewayClass'ı approuting-istio yükler. Bu aşamada, ağ geçidi proxy’si için veri düzlemi podları bulunmamaktadır.

• Küme önyüklemesi. İş yükü ekibi, ağ geçidi proxy’sinin iç veya dış yük dengeleyici üzerinden erişime açılıp açılmayacağını, yük dengeleyicinin ön uç IP’sine hangi alt ağın ev sahipliği yaptığını ve ağ geçidi proxy’sinin hangi ad alanında çalışacağını belirler. Bu mimaride, ağ geçidi proxy'si bir iç yük dengeleyici üzerinden yayımlanır. Yük dengeleyici IP'leri için ayrılmış bir alt ağ vardır ve ağ geçidi ara sunucusu a0008iş yükü ad alanına dağıtılmıştır.

  approuting-istio GatewayClass’a referans veren bir Ağ Geçidi kaynağı bu kararları ifade eder. Ağ geçidi denetleyicisi, kaynağı Gateway kaynağıyla aynı ad alanında Envoy Gateway proxy dağıtımları, bir LoadBalancer hizmeti, bir HorizontalPodAutoscaler ve bir PodDisruptionBudget hâline gelecek şekilde uzlaştırır.

  Eklentiye özel bir DNS bölgesi eklendiğinde, eklentinin DNS bileşeni DNS A kayıtlarını yönetebilir, böylece kod olarak altyapı (IaC) şablonlarınızda statik kayıtları tutmanız gerekmez. Bootstrapping, Access kümesi gizli dizilerinde açıklanan TLS sertifika eşitleme kaynaklarını da dağıtır.

  Note

  Eklentiyle dağıtılan yerleşik DNS bileşeni, Ağ Geçidi API'si kaynaklarını kullandığınızda DNS kayıtlarını otomatik olarak uzlaştırmaz. Otomatik özel DNS kaydı mutabakatı etkinleştirmek için bir ClusterExternalDNS veya ExternalDNS özel kaynağı dağıtın. Uygulama yönlendirme operatörü bileşeni daha sonra, Gateway ve HTTPRoute kaynaklarını izleyen ve A kayıtlarını bağlı DNS bölgesine yayımlayan yönetilen bir external-dns örneği dağıtır.

  DNS bölgesine yazma işlemi RBAC izinleri gerektirdiğinden, bu tümleştirme; hedef bölgede DNS Bölgesi Katkıda Bulunanı rolüne sahip kullanıcı tarafından atanan bir yönetilen kimliği, kümenin OpenID Connect (OIDC) yayımlayıcısına güvenen federasyon kimlik bilgilerini ve özel bir Kubernetes Hizmet Hesabını içeren Microsoft Entra İş Yükü Kimliği gerektirir. Ek kimlik altyapısı gereksinimlerini güvenlik ve operasyonel gereksinimlerinize göre değerlendirin.

• İş yükü dağıtımı. Uygulama ekibi hangi konak adlarının, yolların ve arka uçların trafik alması gerektiğini tanımlar. Ağ geçidine bağlanan HTTPRoute kaynakları bu yönlendirme kararlarını gösterir. Ağ geçidi denetleyicisi bildirilen yönlendirme davranışını Envoy podlarına iletir.

• Devam eden bakım: Eklenti, Istio ağ geçidi denetleyicisi sürümünü AKS kümesi sürümüyle bağlar, bu nedenle yükseltmeler bağımsız yaşam döngüsü yönetimi gerektirmek yerine küme yükseltmeleri ile birlikte gerçekleşir. Bu eklenti, Istio'yu yalnızca ağ geçidi ara sunucusu yönetimi için kullanır. Sidecar enjeksiyonunu veya ayrı bir eklenti olan tam Istio servis ağını etkinleştirmez.

Note

İş yükünüz, eklentinin henüz desteklemediği özellikler gerektiriyorsa — örneğin Sunucu Adı Göstergesi (SNI) geçişi için TLSRoute, özel Lua veya Wasm eklentileriyle gelişmiş trafik dönüştürmeleri ya da uyumluluk gereksinimleri belirli bir vekil sunucu ürününü zorunlu kılıyorsa — öz yönetimi tercih edin. Ayrıca, proxy'yi küme yükseltmelerinden bağımsız olarak sürüme almanız gerekiyorsa veya iki eklenti birlikte mevcut olmadığından kümeniz zaten Istio hizmet mesh eklentisini kullanıyorsa kendi kendine yönetimi seçin.

Ağ Geçidi ve HTTPRoute kaynaklarını uygulama

Bu mimari, giriş trafiği yönetimi için Kubernetes Gateway API'siyle uygulama yönlendirme eklentisini kullanır. Bu bölüm, önceki bölümde açıklanan küme önyükleme ve iş yükü dağıtım aşamalarını kapsar. Bu noktada ağ geçidi denetleyicisi çalışıyor ve Ağ Geçidi API'sinin kaynaklarının uzlaştırmasını bekliyor.

Ağ Geçidi API'si, uygulamaya özgü ek açıklamalar yerine TLS ilkesini, üst bilgi tabanlı yönlendirmeyi ve trafiğin yerel API alanları olarak bölünmesini ifade eden, satıcıdan bağımsız bir standarttır. Yönlendirme yapılandırmanız belirli bir ara sunucu teknolojisine bağlı olmadığından, temel alınan uygulamayı daha sonra yeniden yazmadan değiştirebilirsiniz. Uygulama yönlendirme eklentisi, ağ geçidi denetleyicisinin ve proxy’nin yaşam döngüsünü yöneterek yükseltmeleri, güvenlik yamalarını, ölçeklendirme yapılandırmasını ve RBAC kapsamlandırmasını yönetme gereksinimini ortadan kaldırır.

Ağ Geçidi API'si girişi birbirinden bağımsız olarak değişen iki kaynağa ayırır:

• Ağ Geçidi kaynağı , kullanıma sunulan bağlantı noktaları ve protokoller, TLS sertifikaları ve iç yük dengeleyici için alt ağ dahil olmak üzere ağ yüzeyini bildirir. Bu kaynak sık değişmez ve kendisine bağlı tüm yolları etkiler.

• HTTPRoute kaynağı yönlendirme mantığını veya hangi konakların, yolların ve üst bilgilerin hangi arka uç hizmetleriyle eşlendiğini bildirir. Bu kaynak her dağıtımda değişir ve kapsamı tek tek hizmetler olarak belirlenmiştir.

Bu mimari, her kaynağın farklı bir değişiklik temposu ve patlama yarıçapı olduğundan, yönlendirme değişikliğinin ağ yapılandırmasını kesintiye uğratması veya tam tersi riskini azaltır. Ayrıca çeşitli bağımlılıkları kaldırır.

• Yönlendirme yapılandırmanız belirli bir ara sunucu teknolojisine bağlı değil.
• Proxy sürümü, bağımsız izleme gerektirmek yerine AKS küme sürümünüzle birlikte taşınır.
• Her Ağ Geçidi kaynağı, tüm yollarda tek bir denetleyici paylaşmak yerine kendi proxy dağıtımını alır.

Yaşam döngüsü aşamaları bölümünde açıklandığı gibi, yapılandırılmış GatewayClass’ı referans alan bir Gateway kaynağı uyguladığınızda, gateway denetleyicisi onu gateway proxy dağıtım kaynaklarına ve destekleyici kaynaklara dönüştürür. Ağ geçidi kaynağındaki altyapı ek açıklamaları aracılığıyla alt ağ yerleşimini denetleyebilirsiniz.

Bu bildirim temelli model, ara sunucu için Helm grafiklerini, kapsayıcı görüntülerini veya dağıtım bildirimlerini yönetme gereksinimini ortadan kaldırır. Niyetinizi Gateway API kaynak yapılandırması aracılığıyla ifade edersiniz ve ağ geçidi denetleyicisi proxy’yi istediğiniz duruma yakınsatır.

Yönetilen bir ağ geçidi denetleyicisi genellikle ağ geçidi proxy’sini, hazır olma ve canlılık yoklamaları, RBAC izinleri, CPU tabanlı otomatik ölçeklendirmeyle replika ölçeklendirmesi ve gönüllü kesintiler sırasında en az bir podun kullanılabilir kalmasını sağlayan bir PodDisruptionBudget dahil olmak üzere, üretim odaklı varsayılanlarla yapılandırır.

Eklenti zamanlama topolojisi

AKS eklentileri, uygulama ekibinin denetlemediği zamanlama kararlarını temel alarak yönetilen bileşenleri düğüm havuzlarına yerleştirir. Sistem ve kullanıcı düğümü havuzlarını boyutlandırmadan önce, etkinleştirilen her eklentinin podlarını zamanladığı yeri belirleyin. Bazı eklentiler sistem düğüm havuzunun taint’lerini tolere eder ve bu nedenle yalnızca sistem havuzunda çalışır. Diğer eklentiler kullanıcı havuzlarını hedefler. Bu topoloji, her havuzda gerekli olan kapasiteyi doğrudan etkiler.

Yönetilen Envoy ağ geçidi ara sunucusu, kullanıcı düğümü havuzunda değil, tasarım gereği sistem düğümü havuzunda çalışır. Proxy'nin ek kaynak ayak izini hesaba katıp sistem havuzunu boyutlandırın. Bu varsayılan topoloji kuruluşunuzun gereksinimlerini karşılamıyorsa (örneğin maliyet yalıtımı, ağ segmentasyonu veya uyumluluk nedeniyle kullanıcı havuzlarında ara sunucuya ihtiyacınız varsa), düğüm yerleştirme kararları almak için kendi kendine yönetilen bir ağ geçidi denetleyicisine geçin.

Yönetilen bir ağ geçidi denetleyicisiyle bile uygulama ekibi, proxy replikalarını düğümler arasında dağıtmak için pod anti-eğilimini yapılandırabilir. Bu ayarları izin verilenler listesine alınan ağ geçidi özelleştirme ayarları aracılığıyla yapılandırabilirsiniz. Daha fazla bilgi için Ağ geçidi kaynağını özelleştirme konusuna bakın.

Ağ geçidi ara sunucusu sistem düğümü havuzunda ve iş yükü kullanıcı düğümü havuzunda çalıştığından, zamanlayıcı bunları bağımsız zamanlama etki alanları olarak ele alır. Her gelen istek iş yüküne ulaşmadan önce ara sunucu üzerinden aktığı için ağ geçidi ara sunucusu ve iş yükü hizmetleri sık sık iletişim kurar. Farklı düğüm havuzlarındaki podlar arasında bölge yerleşimini ilişkilendiren yerleşik bir mekanizma yoktur. Açık bir yönlendirme olmadan zamanlayıcı, iş yükü podlarını proxy replikasının bulunmadığı erişilebilirlik alanlarına yerleştirebilir; bu da trafiğin bir erişilebilirlik alanı sınırını aşmasına neden olarak gecikmeye ve alanlar arası veri aktarım maliyetlerine yol açabilir.

Bu bölgeler arası trafiği azaltmak için, iş yükünüzde, bölge düzeyinde proxy replikalarıyla aynı yerde konumlandırılmasını sağlayacak şekilde tercih edilen pod yakınlığını yapılandırın. Proxy ile iş yükü ayrı düğüm havuzlarında çalıştığında, düğüm düzeyindeki yakınlık havuzlar arasında etki etmediğinden, sağlayabileceğiniz en yakın birlikte konumlandırma budur. Interpod benşiminin zamanlayıcıya işlem yükü eklediğini ve büyük kümelerde zamanlamayı yavaşlatabileceğini unutmayın.

İdare ilkelerindeki eklenti kaynak gereksinimleri

AKS eklentileri, kaynak gereksinimleri uygulama ekibi tarafından değil AKS tarafından tanımlanan ve denetlenen yönetilen bileşenleri dağıtır. Küme, Azure İlkesi ve Open Policy Agent (OPA) Gatekeeper aracılığıyla kapsayıcı kaynak sınırı ilkelerini Deny modunda zorunlu kıldığında, ilkelerin etkin olan tüm eklentileri hesaba katması gerekir. Aksi takdirde Gatekeeper, yönetilen podların oluşturulmasını sessizce engeller; bu da herhangi bir belirgin dağıtım hatası göstermeden ingress, gizli bilgilerin eşitlenmesi ve gözlemlenebilirlik gibi platform özelliklerini devre dışı bırakır.

İlke yazmanın önkoşulu olarak eklenti kaynak profili oluşturmayı değerlendirin. Kapsayıcı CPU'sunu, belleği, birim türünü veya güvenlik bağlamı kısıtlamalarını tanımlamadan önce, etkinleştirilen her eklentinin envanterini oluşturun ve çalışma zamanı kaynak gereksinimlerini belirleyin. Gerçekçi trafik koşullarında gerçek kaynak tüketimini yakalamak için üretim öncesi ortamda yük testi veya denetimli dağıtımları kullanın. Ardından ilke sınırlarınızı hem eklenti bileşenlerine hem de iş yükü kapsayıcılarınıza uyacak şekilde ayarlayın. Bu yaklaşım, idare korumalarınızın platform tarafından yönetilen altyapıya müdahale etmeden kümeyi korumasını sağlar.

Örneğin, yönetilen Envoy ağ geçidi ara sunucusu, kopya başına en fazla 2 CPU çekirdeği ve 1 GiB bellek gerektirir. Bu değerler büyük olasılıkla küçük veya düşük kaynak iş yükünün gereksinimlerini aşıyor. İlke sınırlarınızı, uygulama kapsayıcılarınızla birlikte ağ geçidi proxy’sini de barındıracak şekilde ayarlayın. Bu ayarlama olmadan, Ağ Geçidi Denetleyicisi ağ geçidi ara sunucu podlarını reddeder ve giriş işlem hattının tamamı gerçekleşmez.

Küme içi ağ geçidi TLS sonlandırması ve HTTPS zorlaması

Bu mimari, ağ geçidini 443 numaralı bağlantı noktasında, Key Vault’tan eşitlenen bir TLS sertifikasıyla HTTPS kullanacak şekilde ve yeniden yönlendirme için 80 numaralı bağlantı noktasında bir HTTP dinleyicisiyle yapılandırır. Ağ geçidindeki altyapı ek açıklamaları, yük dengeleyiciyi ingress alt ağına yerleştirir ve onu iç yük dengeleyici olarak yapılandırır. HTTP dinleyicisine bağlı bir yeniden yönlendirme HTTPRoute’u, tüm HTTP isteklerini HTTPS’ye yükseltmek için 301 Moved Permanently döndürür. HTTPRoute uygulaması HTTPS dinleyicisine bağlanır ve trafiği HTTP üzerinden iş yükü hizmetine yönlendirir. Ağ geçidi ara sunucusu TLS sonlandırması gerçekleştirdiğinden, arka uç hizmetleriyle iletişim şifrelenmemiştir.

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

Bu mimaride ağ akışı aşağıdaki trafik türlerini 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ı trafik; buna ağ geçidi proxy’si ile iş yükü arasındaki iletişim de dahildir. İş 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.

Diyagramda mimari içindeki dört farklı trafik deseni gösterilmektedir. Bir kutu, Azure Güvenlik Duvarı içeren bir alt ağ kutusu içeren merkez ağını içerir. Ayrı bir kutu spoke ağını içerir ve içinde Web Uygulaması Güvenlik Duvarı (WAF), AKS tarafından yönetilen iç yük dengeleyicisi ve AKS için alt ağ kutuları bulunur. İki yönlü siyah ok, iki ağ arasındaki sanal ağ eşlemesini gösterir. Kesintisiz yeşil oklar, genel internetten uç ağdaki WAF’a, WAF alt ağından iç yük dengeleyici alt ağına ve oradan AKS alt ağına yönelen, kullanıcının başlattığı istek trafiğini gösterir. Düz turuncu oklar, spoke ağındaki AKS alt ağından hub ağa kümenin başlattığı istek trafiğini ve hub ağındaki Azure Güvenlik Duvarı alt ağından genel internete giden çıkış trafiğini gösterir. Noktalı turuncu oklar, herkese açık internetten merkez ağın Azure Güvenlik Duvarı alt ağına ve merkez ağdan uç ağın AKS alt ağına geri dönen yanıt trafiğini gösterir. Yeşil noktalı oklar AKS alt ağından yük dengeleyici alt ağına ve ardından uç ağının WAF alt ağına ve uç ağının WAF alt ağından genel İnternet'e gelen yanıt trafiğini gösterir.

Bu mimarinin 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 ile şifrelenmiş istekleri kabul eder. TLS v1.2 izin verilen en düşük sürümdür ve kısıtlı bir şifreleme kümesine izin verir. SNI katı eşleştirme etkinleştirildi. Uçtan uca TLS, aşağıdaki diyagramda gösterildiği gibi iki farklı TLS sertifikası kullanılarak Application Gateway aracılığıyla ayarlanır.

Diyagramda istemciden iş yüküne uçtan uca TLS trafik akışı gösterilir. 1. adım, Application Gateway'e HTTPS trafiği gönderen bir kullanıcıyı gösterir. 2. adımda, Application Gateway'den AKS kümesindeki Envoy proxy'sine bir ok geçer. 3. adım, Envoy proxy'sinden AKS kümesindeki iş yüküne işaret eden bir ok gösterir. 4. adım, Application Gateway ve Envoy proxy'sinden Key Vault giden satırları gösterir. Bu satırlar bicycle.contoso.com ve *.aks-ingress.contoso.com olmak üzere iki sertifika içerir. Her TLS sonlandırma noktası bir kilit simgesiyle işaretlenir.

Bu mimarinin Visio dosyasını indirin.

1. İstemci, etki alanı adına bir HTTPS isteği gönderir: bicycle.contoso.com, Application Gateway'in genel IP adresine DNS A kaydıyla ilişkilendirilmiş bir ad. 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. Application Gateway tümleşik bir web application firewall sahiptir ve bicycle.contoso.com için TLS el sıkışması anlaşması yaparak yalnızca güvenli şifrelere izin verir.

   Application Gateway, düz metin istek ve yanıtlarını incelemesi gereken Application Gateway web uygulama güvenlik duvarı için önemli olan bir TLS sonlandırma noktasıdır.

2. Application Gateway, web application firewall denetim kurallarını işler ve trafiği yapılandırılan arka uca ileden yönlendirme kurallarını çalıştırır.

   Application Gateway'den arka uca trafik taşınırken, iç load balancer'a yönlendirildiğinden *.aks-ingress.contoso.com için bir joker TLS sertifikası kullanılarak yeniden şifrelenir. Bu yeniden şifreleme, güvenli olmayan trafiğin küme alt ağından akmamasını sağlamaya yardımcı olur.

3. Ağ geçidi ara sunucusu, şifrelenmiş trafiği yük dengeleyici aracılığıyla alır. Proxy, *.aks-ingress.contoso.com için başka bir TLS sonlandırma noktasıdır ve trafiği HTTP üzerinden iş yükü pod’larına iletir.

4. Her iki TLS sertifikası da Key Vault depolanır.

   Küme, Application Gateway ile tümleştirilen kullanıcı tarafından atanan yönetilen kimlikle bicycle.contoso.com sertifikaya erişir. Daha fazla bilgi için bkz. Key Vault sertifikalarıyla TLS sonlandırma. *.aks-ingress.contoso.com için TLS sertifikası, Gateway kaynağının başvurduğu bir Kubernetes Secret'ı olarak küme içine eşitlenir. Daha fazla bilgi için bkz Gizli yönetim ekleme.

Her atlamada uçtan uca TLS trafiği uygulayabilirsiniz. Poddan poda trafiğin güvenliğini sağlamaya ilişkin tüm kararların performansını, gecikme süresini ve operasyonel etkilerini dikkate almayı unutmayın. Uygun denetim düzlemi RBAC ve olgun yazılım geliştirme yaşam döngüsü uygulamalarına sahip tek kiracılı kümelerin çoğunda TLS'nin ağ geçidi ara sunucusuna kadar şifrelemesi ve Web Uygulaması Güvenlik Duvarı ile korunması yeterlidir. Bu yaklaşım, iş yükü yönetimi ve düşük ağ performansı ek yükünü en aza indirir. İş yükünüz ve uyumluluk gereksinimleriniz, TLS sonlandırma gerçekleştireceğiniz yeri belirler.

Çıkış trafik akışı

Bu mimaride, kümeden gelen tüm çıkış trafiğinin Azure Güvenlik Duvarı gitmesini öneririz. Kendi benzer ağ sanal gerecinizi de kullanabilirsiniz. Azure NAT Gateway veya HTTP proxy gibi diğer çıkış seçeneklerini önermiyoruz çünkü bunlar ağ trafiği denetimi sağlamaz. Sıfır Güven denetimi ve trafiği inceleyebilme özelliği için tüm çıkış trafiğini Azure Güvenlik Duvarı aracılığıyla gönderin. Bu yapılandırmayı kullanıcı tanımlı yollar (UDR) ile uygulayın. Yolun bir sonraki atlaması, Azure Güvenlik Duvarı'nın özel IP adresidir. Azure Güvenlik Duvarı, tanımladığınız kurallara veya yerleşik tehdit bilgileri kurallarına göre çıkış trafiğinin engellenip engellenmeyeceğine veya izin verilip verilmeyeceğine karar verir.

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 egress ağ trafiği kurallarını gözden geçirin.

Note

Azure Güvenlik Duvarı üzerinden UDR'leri kullanarak giriş ve çıkış trafiği için genel noktanız olarak bir genel yük dengeleyici kullanıyorsanız, asimetrik yönlendirme senaryosu görebilirsiniz. Bu mimaride, Application Gateway arkasındaki ayrılmış bir giriş alt akında iç yük dengeleyiciler kullanılır. Bu tasarım seçimi güvenliği artırır ve ayrıca asimetrik yönlendirme endişelerini ortadan kaldırır. Veya Application Gateway önce veya sonra giriş trafiğini Güvenlik Duvarı üzerinden yönlendirebilirsiniz, ancak bu yaklaşım çoğu durumda gerekli değildir ve bunu önermiyoruz. Asimetrik yönlendirme hakkında daha fazla bilgi için bkz. Azure standart yük dengeleyici ile Güvenlik Duvarını Entegre Etme.

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üncellenmiş bir imajı veya Key Vault'tan gizli bilgileri çekmesi gerekebilir. Bu senaryolarda Özel Bağlantı kullanmanızı öneririz.

Özel Bağlantı kullanmanın 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 hizmetler veya ürünler Özel Bağlantı desteklemez. Bu gibi durumlarda, hizmete erişmek için alt ağda sanal ağ hizmet uç noktasını etkinleştirmeyi düşünün.

Container Registry için özel olarak ayrılmış veri uç noktalarını kullanın. Bunlar olmadan, görüntü katmanı indirmeleri kayıt defterinin özel uç noktası yerine bir *.blob.core.windows.net uç noktaya yönlendirilir ve çıkış güvenlik duvarı kurallarınızın tehlikeli bir Blob depolama joker karakterine izin vermesi gerekir. Bu kural, düğümden any Azure Depolama hesabına giden trafiğe izin verir. Ayrılmış veri uç noktaları, joker karakteri kayıt defterinize özgü ve Özel Bağlantı üzerinden özel uç noktanıza çözümlenen FQDN'lerle (<registry>.<region>.data.azurecr.io) değiştirerek görüntü katmanı trafiğini özel yol üzerinde tutar ve çıkış kurallarını kümenizin kayıt defteriyle sınırlamanızı sağlar.

Ö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. Güvenlik duvarı çıkış akışlarına kaynak ağ adresi çevirisi (SNAT) uygular ve pod IP'sini akış başına ekli genel IP adreslerinden biriyle değiştirir ve seçim belirleyici değildir. Ekli genel IP kümesinin tamamını hedef hizmetin IP izin verilenler listesine ekleyin veya bu kümeyi bitişik aralık olarak ifade etmek için bir genel IP adresi ön eki kullanın.

Genel uç noktalar aracılığıyla Azure hizmetlere bağlanmanın 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. Ekli genel IP sayısı SNAT bağlantı noktası havuzunu ve dolayısıyla kümenin eşzamanlı giden bağlantı tavanını da kapsıyor. Planlı bir şekilde çoklu IP adreslerini Azure Güvenlik Duvarı üzerinde kullanmaya başlayın ve bu sayede bağlantı noktası tükenmesine ulaşmadan önce hazırlıklı olun. Çok sayıda eşzamanlı giden bağlantı açan kümelerde, SNAT bağlantı noktası havuzunu önemli ölçüde genişletmek ve tüm çıkış trafiğini güvenlik duvarı denetimi altında tutmak için kümeye bir Azure NAT Gateway ekleyin.

Podlar arası 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. Kritik ağ akışlarının engellenmesini önlemek için ilkeleri dikkatli bir şekilde uygulayın. Gerektiğinde yalnızca ağ geçidi ara sunucusu ile iş yükü arasındaki trafik gibi belirli iletişim yollarına izin verin. Ağ geçidi ara sunucusu iş yüküyle aynı ad alanında çalıştığından, bunu ad alanı seçicisi yerine pod etiketiyle hedefle. Daha fazla bilgi için bkz. Ağ ilkeleri.

Kümeyi oluştururken ağ ilkesini etkinleştirin, çünkü kümeyi daha sonra eklemek düğüm havuzlarınızı yeniden oluşturabilir. uygulayan NetworkPolicyteknolojiler için birkaç seçeneğiniz vardır. Azure ağ ilkesi için Azure CNI gerekir. 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, çeşitli operasyonlar gerçekleştirmek 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 özel bir AKS kümesi ayarlamanızı öneririz.

Daha fazla bilgi için bkz. API sunucusu tarafından yetkilendirilmiş IP aralıklarını tanımlama.

AKS kümenizi özel küme olarak dağıtmanızı öneririz. Tüm denetim düzlemi ve düğüm havuzu trafiği özel ağınızda kalır ve genel İnternet'e açık değildir. Başvuru uygulaması, API sunucusu sanal ağ tümleştirmesini kullanarak özel bir küme ayarlar. Düşük ortamlar kolaylık sağlamak için bu özel küme önerisini gevşetmeyi düşünebilir, ancak üretim AKS kümeleri her zaman güvenli bir dağıtım temeli için özel kümeler olarak dağıtılmalıdır.

Özel bir AKS kümesine yönelik özel trafik, konuşma sanal ağından, eşlenmiş ağlardan veya uzak ağlardaki özel uç noktalardan kaynaklanabilir. AKS düğümleri doğal olarak uç noktada bulunsa da, yönetim görevlerini yapan yöneticiler, AKS API sunucusuna özel bir şekilde ulaşmak için ayrılmış bir ağ yoluna ihtiyaç duyar. Bu bağlantıyı aşağıdaki yollarla kurabilirsiniz:

• Tünel: Azure Bastion kullanarak doğrudan kümenin API sunucusuna bir tünel açın.
• Atlama kutusu: Sıçrama kutusu VM'sini sağlayın ve SSH veya RDP aracılığıyla bağlanmak için Azure Bastion kullanın. Operatör, özel IP adresini kullanarak kümenin API sunucusuna yönelik isteklerde bulunur.

Bu mimari, bir operatörün yerel makinesini Azure CLI komutlar aracılığıyla özel AKS API sunucusuna bağlamak için Azure Bastion yerel istemci tünelini kullanır. Tünel, atlama kutusu olmadan doğrudan kubectl ve Helm iş akışlarını destekler. Bu yaklaşım, AKS API uç noktasının özel kalmasını sağlarken bir atlama kutusuna göre daha basit ve daha az maliyetli kalmasını sağladığından önerilir. Birden çok işleç arasında koordinasyon sağlamak da daha az karmaşıktır.

Ancak, şu gereksinimlerden herhangi birine sahipseniz bir atlama kutusu kullanmayı seçebilirsiniz:

• Operatörler güvenli olmayan cihazlar kullanır. İstemci cihazlarınıza güvenilmiyorsa atlama kutusu daha güçlü güvenlik sağlamlaştırması sağlayabilir.

• Operatörler kararsız ağlar üzerinden bağlanır. Atlama kutusu, özellikle uzun süre çalışan veya toplu yönetim işlemleri için kümeye daha kararlı bir bağlantı sağlayabilir.

• Operatörler gelişmiş tanılama araçlarını kullanır. Paket yakalama gibi bazı tanılama araçları, tünel yaklaşımlarıyla iyi çalışmayabilir.

Gizli yönetimi ekleyin

Gizli bilgileri Key Vault gibi yönetilen bir anahtar deposunda depolayın. Bunun avantajları, yönetilen anahtar deposunun gizli dizi döndürmeyi işlemesi, güçlü bir şifreleme ve erişim denetim günlüğü sağlaması ve çekirdek gizli dizileri dağıtım işlem hattı dışında tutmasıdır. Bu mimaride, bir Key Vault güvenlik duvarı etkinleştirilir ve yapılandırılır ve gizli dizilere ve sertifikalara erişme gibi Azure kaynaklara bağlanmak için Özel Bağlantı kullanılır.

Key Vault diğer Azure hizmetleriyle iyi tümleştirilmiştir. Bu hizmetlerin yerleşik özelliğini sırları erişmek için kullanın. Application Gateway giriş akışı için TLS sertifikalarına nasıl eriştiği hakkında daha fazla bilgi için Giriş trafiği akışı bölümüne bakın.

Key Vault için Azure RBAC izin modeli, gizli dizilere erişmek üzere iş yükü kimliklerine Key Vault Gizli Dizi Kullanıcısı veya Key Vault Okuyucusu rollerinden birini atamanıza olanak tanır. Daha fazla bilgi için bkz. Azure RBAC kullanarak Key Vault'a Erişme.

Küme gizli bilgilerine erişim

Belirli bir mağazadan gizli bilgilere erişmek için bir podun iş yükü kimliklerini kullanması gerekir. Geri getirme işlemini kolaylaştırmak için gizli bilgileri depolamak için bir CSI çekme 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 volüm dosya sisteminden gizli veriyi 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, manuel TLS yapılandırma yaklaşımıyla Secrets Store CSI sürücüsüne sahip Key Vault'u kullanır. SecretProviderClass kaynağı, hangi Key Vault sertifikalarının Kubernetes Gizli Öğeleri olarak kümede eşitleneceğini tanımlar. CSI sürücüsü, eşitlenmiş Secret’ı oluşturmak ve sürdürmek için en az bir pod’un ilgili CSI birimini bağlamasını gerektirir. Tüm bağlanmış podları silerseniz, sürücü Secret nesnesini çöp toplama işlemiyle kaldırır; bu da ağ geçidinin TLS sertifikasını kaybetmesine neden olur. Bunu önlemek için, CSI biriminin iş yükü pod’larınızın yaşam döngülerinden bağımsız olarak bağlı kalmasını sağlayan, adanmış ve sürekli çalışan bir pod dağıtın.

Bu mimaride, göstermelik bir görevle hafif bir kapsayıcı çalıştıran busybox kapsayıcı görüntüsü kullanılır. Flux bunu önyükleme sırasında dağıttığı için, kapsayıcı görüntüsünü küme oluşturulmadan önce Azure Container Registry’ye içe aktarın. CSI eklentisinde gizli dizi rotasyonunu etkinleştirin ve Key Vault sertifika yenilemelerinin otomatik olarak yansıtılması için örneğin iki dakikalık bir rotasyon yoklama aralığı ayarlayın. Ağ Geçidi kaynağı, HTTPS sonlandırma için senkronize edilmiş TLS Secret öğesine referans verir. Daha fazla bilgi için bkz. Uygulama yönlendirmesinin Gateway API uygulamasıyla gelen trafiğin güvenliğini sağlama.

AKS'nin Azure bileşenlerine erişiminde belirtildiği gibi, bu el ile yapılandırmayı operatör tarafından yönetilen TLS yaklaşımıyla değiştirebilirsiniz. Bu yaklaşımla, Key Vault sertifika URI’sini ve bir Workload Identity ServiceAccount’ını doğrudan ağ geçidi dinleyicisinde tanımlarsınız. Uygulama yönlendirme işleci daha sonra SecretProviderClass'ı oluşturur ve Ağ Geçidi sertifika başvurusuna otomatik olarak düzeltme eki uygular; bu da küme önyüklemesi sırasında bu kaynakları yazma gereksinimini ortadan kaldırır veya ayrılmış bir TLS eşitleme pod'u oluşturur. Her iki yaklaşım da, sertifika yenilemelerini Key Vault’tan almak için CSI sürücüsünün rotasyon mekanizmasına dayanır.

İş yükü depolama

Bu mimaride iş yükü durumsuzdur. Durum depolamanız gerekiyorsa, onu kümenin dışında kalıcı hale getirmenizi öneririz. İş yükü durumu kılavuzu bu makalenin kapsamı dışındadır.

Daha fazla bilgi için bkz. AKS'teki 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, OPA Gatekeeper 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ümedeki ilke uygulamasını yönetir ve tüm ilke denetimlerini günlüğe kaydeder. İlke değişiklikleri kümenize hemen yansıtılmaz, bu nedenle bazı gecikmeler bekleyebilirsiniz.

AKS kümelerinizi yönetmek için Azure İlkesi çeşitli yollarla 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.

Politikaların yararlı olabileceği sık görülen bir durum, kapsayıcı görüntülerin yönetimi ve doğrulanmasıdır. Kapsayıcı görüntüleri güvenlik açıklarının kaynağı olabilir ve bazı kuruluşlar, güvenilmeyen kapsayıcı görüntülerinin bir kapsayıcı görüntüsü tarama aracı kullanılarak doğrulanması ve ardından bir üretim kümesinde kullanılmadan önce onaylanmasını gerektirir. Azure İlkesi kullanarak bu işlemi zorunlu kılabilir ve güvenilmeyen kapsayıcı görüntülerinin kümeye dağıtılmasını engelleyebilirsiniz. Daha fazla bilgi için bkz. Quarantine deseni.

İlkeler ayarladığınızda, bunları iş yükünün gereksinimlerine göre uygulayın. Şu faktörleri göz önünde bulundurun:

• Politikalar topluluğu olarak bilinen girişimleri ayarlamaya veya tek tek politika seçmeye karar verin. 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şim kuran 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 mi yoksa reddetmek mi istediğinize karar verin. 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 Reddetme modunu seçtiğinizde dikkatli olun.

• İş yükünüzde tasarım gereği uyumlu olmaması gereken alanlarınız olup olmadığını belirleyin. Azure İlkesi, ilke zorlamasından muaf tutulan Kubernetes ad alanlarını belirtebilir. Bu örneklerin farkında olmanız için denetim modunda ilkeler uygulamaya devam etmeniz önerilir.

• Yerleşik ilkeler kapsamında olmayan gereksinimleriniz olup olmadığını belirleyin. Ö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 olup olmadığını belirleyin. Ö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.

• belirli kapsamlara Azure ilkeleri atamanız gerekip gerekmediğini belirleyin. Üretim ilkelerinin üretim öncesi ortamınızda da doğrulandığından emin olun. Aksi takdirde, üretim ortamınıza dağıttığınızda, ön üretimde hesaba katmadığınız beklenmedik ek kısıtlamalarla karşılaşabilirsiniz.

Başvuru uygulaması, AKS kümesi oluşturulduğunda Azure İlkesi etkinleştirir. Kısıtlayıcı ilke, uyumsuzlukları görünür kılmak 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.

Kümenizin içinden Azure İlkesi işlevlerini gözlemlemek için gatekeeper-system ad alanında tüm podların pod günlüklerine ve azure-policy ad alanında azure-policy-webhook ve kube-system podlarının günlüklerine erişebilirsiniz.

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

Artan taleple birlikte, Kubernetes mevcut düğümlere daha fazla pod ekleyerek, yatay pod otomatik ölçeklendirme aracılığıyla ölçeklendirme yapabilir. Kubernetes daha fazla pod planlayamaz hale geldiğinde, düğüm sayısı AKS kümesi otomatik ölçeklendirme ile artırılmak zorundadı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 aracılığıyla ReplicaSet ayarlayarak pod çoğaltma 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.

El ile gerçekleştirilen mekanizmalardan bazıları otomatik ölçeklendiricide yerleşik olduğundan otomatik ölçeklendirme yaklaşımını kullanmanızı ö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.

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. Yalnızca CPU kullanımı yerel olarak 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ı tahsis edilmiş 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, ölçeklendirme işlemi tamamlanmadan önce denetlediğinde bir yarış durumu oluşabilir. Bu nedenle, sonuç yanlış bir oran hesaplaması olabilir. Daha fazla bilgi için bakınız ölçeklendirme olaylarının soğuma periyodu.

İş 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çümlere göre ölçeklendirmenin kullanışlı bir yolu olan Azure İzleyici ölçekleyici içerir.

Küme otomatik ölçeklendiricisi

cluster otomatik ölçeklendiricisi bir düğüm havuzundaki düğüm sayısını ölçeklendirin bir AKS eklentisi bileşenidir. Küme oluşturma sırasında onu 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 pod zamanlayamazsa, otomatik ölçeklendirici düğüm havuzunda otomatik olarak yeni bir düğüm ayarlar. Buna karşılık, küme otomatik ölçeklendiricisi düğümlerin kullanılmayan kapasitesini denetler. Düğüm beklenen kapasitede çalışmazsa 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. 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.

İş 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ımlamaya yönelik öneriler. En son çevrimiçi hizmetler için SLA makalesinde AKS 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ılabilirlik veya kapasiteye ihtiyacınız varsa, daha fazla düğüm eklemek için ölçeklendirme yapı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 kısıtlar kullanmanızı öneririz. Sistem düğüm havuzlarına uygulama podlarının zamanlanmasını önlemek için, sistem düğüm havuzunuzun CriticalAddonsOnly taint ile işaretlendiğinden emin olun.

Zamanında güncelleştirmeler gibi kümenizdeki düzenli bakım görevleri güvenilirlik açısından çok önemlidir. Ayrıca, yoklamalar aracılığıyla podların durumunu izlemenizi öneririz.

Pod kullanılabilirliği

• Pod kaynağı gereksinimlerini belirtin: Dağıtımlarınızda pod kaynağı gereksinimlerini belirtmenizi öneririz. Zamanlayıcı, ardından pod'u uygun şekilde 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ımdaki kaç replikasının inebileceğini belirler. Daha fazla bilgi için bkz. Pod kesinti bütçeleri.

  Dağıtımda, donanım hataları gibi kesintilerle baş etmek için birden çok kopya yapılandırın. Güncellemeler ve yükseltmeler gibi planlı olaylar için, kesinti bütçesi beklenen uygulama yükünü karşılayabilecek gerekli sayıda pod kopyasının mevcut olmasını sağlamada yardımcı olabilir.

• İş yükü ad alanları üzerinde kaynak kotaları ayarlayın: Ad alanı üzerindeki kaynak kotası, pod isteklerinin ve sınırlarının dağıtımda düzgün ayarlandığından emin olunmasını sağlar. Daha fazla bilgi için bkz. Kaynak kotalarını uygula.

  Note

  Kaynak kotalarını küme düzeyinde ayarlarsanız, uygun isteklere ve sınırlara sahip olmayan dış iş yüklerini dağıtırsanız sorunlarla karşılaşabilirsiniz. Kotaları ad alanı düzeyinde ayarladığınızda, bunların yalnızca iş yükü bileşenlerinize uygulanmasını sağlar.

• Pod isteklerini ve sınırlarını ayarlayın: Kubernetes'in podlara CPU ve bellek kaynaklarını verimli bir şekilde ayırmasını sağlamak için istekleri ve sınırları ayarlayın. Bir düğümde daha yüksek konteyner yoğunluğu sağlar. İ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 dengesizlik yaratan eşiği 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.

Erişilebilirlik bölgeleri

Bazı kesinti türlerine karşı koruma sağlamak için bölge bunları destekliyorsa availability zones kullanın. Hem denetim düzlemi bileşenleri hem de düğüm havuzlarındaki düğümler alanlar arası yedekli hale gelir ve bu da birden çok bölgeye yayıldığı anlamına gelir. 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ı: Availability zones destekleyen bir bölge seçin. Daha fazla bilgi için bkz. Limitations. Çalışma süresi SLA'sına sahip olmak için Standart veya Premium katmanını seçmeniz gerekir. Kullanılabilirlik bölgelerini kullandığınızda kullanılabilirlik SLA'sı daha yüksek olur.

• 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 sanal makine ölçek kümesi, bölgeler genelinde aynı donanım yapılandırmasını sağlar.

  Bölge yedekliliğ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 bölgeleri arasında dağıtılması garanti edilmez.

• Bağımlı kaynaklar: Availability zones kullanmanın dayanıklılık avantajını elde etmek için, tüm servis bağımlılıklarının da bu bölgeleri desteklemesi gerekir. Bağımlı bir hizmet bölgeleri desteklemiyorsa, bölge hatası bu hizmetin başarısız olmasına neden olabilir.

  Örneğin, iş yükünüzün alanlar arası dayanıklı olmayan bir veritabanı kullandığını varsayalım. Bir hata oluşursa AKS düğümü başka bir bölgeye geçebilir, ancak veritabanı düğümle birlikte bu bölgeye taşınmaz, bu nedenle iş yükünüz kesintiye uğrar.

Bu mimaride basitlik sağlamak için AKS, üç Kullanılabilirlik Bölgesine 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

Availability zones'u etkinleştirdiğinizde, tüm bir bölgenin başarısız olması durumunda yeterli kapsama alanı sağlanmaz. Daha yüksek kullanılabilirlik elde etmek için farklı bölgelerde birden çok AKS kümesi çalıştırın.

• Kullanılabilir olduklarında 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ölgelerde çiftler 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 belirli DevOps araçları çok bölgeli dağıtımları kolaylaştırabilir.

• bir 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ölgelere çoğaltır. Ayrıca, birincil bölgede kesinti yaşansa bile görüntülere sürekli access 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 trafiği olmayan trafiği bölgeler arasında dağıtabildiğinden Load Balancer kullanır. Trafiği bölgeler arasında dağıtmanız gerekiyorsa Azure Front Door göz önünde bulundurun. Diğer seçenekler için bkz. Yük dengeleyici seçme.

Note

Çok bölgeli kümeler için AKS temeli örnek senaryosu bu makaledeki mimariyi etkin-etkin ve yüksek oranda kullanılabilir bir yapılandırmaya birden çok bölge içerecek şekilde genişletir.

Felaket kurtarma

İdeal olarak, birincil bölgede bir hata oluşursa, hızla başka bir bölgedeki bir örneğe geçebilirsiniz. Bir kümeyi önceden oluşturabilir veya gerekli olana kadar kümeyi oluşturmayı bekleyebilirsiniz. Aşağıdaki önerileri gözden geçirin:

• Birden çok bölge kullanın. Birincil bölgenizin eşleştirilmiş bir bölgesi varsa, o eşleşmeyi 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 kurtarma stratejisini, örneğin başka bir bölgeye çoğaltmayı, DevOps işlem hattına entegre edin.

• Olağanüstü durum kurtarmayı destekleyen özellikleri kullanarak her Azure hizmetini ayarlayın. Örneğin, bu mimaride Container Registry coğrafi çoğaltma için etkinleştirilir. Bir bölge kullanılamaz hale gelirse, ACR'nin sistem durumuna duyarlı yük devretme özelliği, kümenizin yapılandırmasında değişiklik yapmayı gerektirmeden çekme isteklerini genel uç nokta üzerinden otomatik olarak sağlıklı bir çoğaltmaya yönlendirir.

• 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 yeni bir küme ayarlayabilir ve GitOps tabanlı küme önyüklemesi ve ardından uygulama dağıtımı aracılığıyla bu kümeyi çalışma durumuna döndürebilirsiniz. Ancak yapılandırma haritaları, işler ve gizli anahtarlar gibi başlangıç işleminizde yakalanamayan kritik kaynak durumları varsa, kurtarma stratejinizi gözden geçirin. 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 yedeklemesi kurtarma stratejinizin bir parçası olması gerektiğinde, küme içindeki iş gereksinimlerinize uygun bir çözüm yüklemeniz gerekir. Bu etken, küme kaynak durumunu seçtiğiniz bir hedefe gönderir ve Azure üzerinde disk tabanlı, kalıcı hacim anlık görüntülerini koordine edip yönetmekten sorumludur.

VMware Velero , doğrudan yükleyip yönetebileceğiniz yaygın bir Kubernetes yedekleme çözümü örneğidir. Ya da yönetilen bir Velero uygulaması sağlamak için AKS yedekleme uzantısı kullanabilirsiniz. AKS yedekleme uzantısı, hem Kubernetes kaynaklarını hem de kalıcı birimleri yedekleyebilme özelliğine sahiptir; zamanlamalar ve yedekleme kapsamı, Azure Backup kasası yapılandırması olarak dışa aktarılır.

Referans uygulaması yedekleme yapmaz ve bu, yönetmek, izlemek, satın almak ve güvenliğini sağlamak için ek Azure kaynakları gerektirir. Bu kaynaklar bir Azure Depolama hesabı, bir Azure Backup kasası ve yapılandırması ile güvenilir erişim özelliği içerebilir. Bunun yerine GitOps, durum bilgisi olmayan iş yükünü çalıştırma amacı ile birlikte kurtarma çözümüdür.

Tanımlı kurtarma noktası hedefinizi ve kurtarma süresi hedefinizi içeren 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.

Durum bilgisi olan iş yüklerini desteklemeniz ve AKS Backup benimsemeniz gerekiyorsa, kümenizde bu yedeklemenin yapılandırılmasını zorunlu kılmak için Azure İlkesi kullanın. Azure İzleyici, yedekleme işinin durumunu bu mimaride önceden oluşturulmuş olan gözlemlenebilirlik yığını aracılığıyla ortaya çıkar. Bu idarenin ötesinde tasarımınızda aşağıdaki mimari konuları dikkate alın:

• Yedekleme kapsamı. Kümenin tamamını mı yoksa belirli ad alanlarını mı yedeklediğinize karar verin. AKS Backup, verileri bir blob kapsayıcısında ve disk veya dosya anlık görüntüleri olarak depolar. İşletimsel kurtarma, ortam kopyalama ve küme yükseltmeleri gibi senaryolar için depolama hesabı boyutlandırmanızı, bekletme ilkelerinizi ve kurtarma ayrıntı düzeyini belirlediğinden bu kapsamı erken tanımlayın.
• Güvenilir erişim. AKS Backup, kümenin genel, özel veya IP kısıtlı olmasına bakılmaksızın Backup kasası ile AKS kümesi arasında güvenilir erişim gerektirir.
• RBAC izinleri. Backup kasasının yönetilen kimliği, yedeklemeleri yapılandırmak ve yürütmek için AKS kümesinde bir dizi izin gerektirir. Yedekleme uzantısı, yedeklemelerin depolandığı depolama hesabında izinlere sahip bir kullanıcı kimliği de oluşturur.
• Ağdan çıkış Yedekleme uzantısı, kümenin içinden Azure Backup hizmetlerle iletişim kurar. Azure Güvenlik Duvarı ve NSG kurallarınızda gerekli giden uç noktaları hesap edin.
• Küme içi ayak izi. Uzantı, düğümlerinize pod dağıtır. Düğüm kaynak bütçelerinizde ek işlem yükü ve bellek tüketimini hesaba katın ve uzantı ad alanını ağ ilkesi yönetiminize dahil edin.

Kubernetes API sunucusu SLA'sı

AKS'yi ücretsiz hizmet olarak kullanabilirsiniz, ancak bu katman finansal olarak desteklenmiş bir SLA sağlamaz. SLA elde etmek için Standard katmanını seçmeniz gerekir. Tüm üretim kümelerinin Standart katmanı kullanmasını öneririz. Ücretsiz katmanı ön üretim kümeleri için, Premium katmanını ise yalnızca mission-critical 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.

Taviz

Mimariyi bölgeler ve özellikle bölgeler arasında dağıtmak için maliyet ve kullanılabilirlik arasında bir dengeleme 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 arasındaki düğüm iletişiminde az miktarda ek ağ gecikmesi ve bölgeler arasındaki iletişimde daha önemli gecikme süresi 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üle edilen kesintilerle zorunlu yük devretme testi yaparak çözümünüzün dayanıklılığını test edin. Benzetimler bir düğümü durdurmayı, bir bölge hatasının benzetimini yapmak için belirli bir bölgedeki tüm AKS kaynaklarını azaltmayı veya dış bağımlılık hatasını çağırmayı içerebilir. Azure ve kümedeki çeşitli kesinti türlerinin benzetimini yapmak için Azure Chaos Studio de kullanabilirsiniz.

Daha fazla bilgi için bkz. Chaos Studio.

Günlükleri ve ö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 Kubernetes izleme hizmetlerini öneririz. Azure İzleyici, çalışmakta olan podlardan kapsayıcı günlüklerini yakalar ve görüntüleme amacıyla 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 Azure İzleyici de kullanabilirsiniz. Toplanan verilerin izlenmesi, analizi ve görselleştirmesi için kritik öneme sahip telemetri verilerini içerir.

Podlardan günlük toplamayı etkinleştir

ContainerLogV2 günlük şeması, Kubernetes podlarından kapsayıcı günlüklerini verimli bir şekilde yakalamak için tasarlanmıştır. Günlük kayıtları bir Azure Log Analytics çalışma alanında ContainerLogV2 tablosunda birleştirilir.

AKS kümesinde pod günlüğü koleksiyonunu yapılandırmak için iki birincil yöntem vardır. Her iki yaklaşım da ayarları özelleştirmenize olanak sağlar. Ad alanlarını filtreleyebilir, koleksiyon aralıklarını ayarlayabilir, belirli özellikleri (veya ContainerLogV2gibiContainerLogV2-HighScale) etkinleştirebilir veya yasaklayabilir ve hangi veri akışlarının toplanmasını belirtebilirsiniz.

• Birden çok kümede merkezi, yeniden kullanılabilir izleme yapılandırmalarına ihtiyacınız varsa veya küme yapılandırmasının Azure yerel kaynaklarda dışlanmasını tercih ediyorsanız, data toplama kurallarını (DCR) kullanın. DCR'ler, Azure Resource Manager denetim düzleminin yerel olarak yönettiği Azure kaynaklardır ve bunları Bicep dosyalarına ekleyebilirsiniz. Referans uygulaması DCR'leri kullanır.

• Alternatif olarak, Kubernetes API denetim düzlemi aracılığıyla yapılandırılan, uygun olmayan Kubernetes YAML nesneleri olan ConfigMap'leri kullanarak izleme tanımlayabilirsiniz. Azure İzleyici Aracısı, kümede çalışarak ConfigMap nesnelerini izler. Hangi verilerin topleneceğini belirlemek için önceden tanımlanmış ayarları kullanır.

Her iki yöntem de etkinleştirildiğinde, ConfigMap ayarları DCR'lerden önceliklidir. Kapsayıcı günlüğü koleksiyonu için ConfigMap ve DCR yapılandırmasını karıştırmaktan kaçının çünkü günlük sorunlarının giderilmesi zor olabilir.

Uyarılar ve Prometheus ölçümleri

Kesintiler ve arızalar iş yükü uygulamaları için önemli riskler oluşturur ve bu da altyapınızın sistem durumu ve performansıyla ilgili sorunları proaktif olarak belirlemeyi önemli hale getirir. Ortamınızı izleyip öğrendikleriniz üzerinde işlem yaptığınızda kesintileri azaltır ve çözümünüzün güvenilirliğini artırırsınız. Kümenizdeki olası hata koşullarını tahmin etmek için Kubernetes için önerilen Prometheus uyarı kurallarını etkinleştirin.

Podlarda barındırılan iş yüklerinin çoğu Prometheus ölçümlerini gösterir. Azure İzleyici Prometheus ile tümleştirebilir. Kapsayıcılardan, podlardan, düğümlerden ve kümeden toplanan uygulama ve iş yükü ölçümlerini görüntüleyebilirsiniz.

Microsoft olmayan 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.

Azure altyapısı ve Kubernetes denetim düzlemi günlükleri

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. Bu seçenekler küme sorunlarını gidermenize yardımcı olabilir ve nispeten düşük günlük yoğunluğuna sahiptir. Çoğu kümede aşağıdaki seçenekleri etkinleştirmenizi öneririz:

• ClusterAutoscaler: Günlüğe kaydetme yoluyla ölçeklendirme işlemlerine gözlemlenebilirlik kazandırın. Daha fazla bilgi için bkz.Küme otomatik ölçekleyici günlükleri ve durumu.

• KubeControllerManager: Kubernetes ile Azure kontrol düzlemi arasındaki etkileşime gözlemlenebilirlik kazandırın.

• kube-audit-admin: Kümenizi değiştiren etkinliklerde gözlemlenebilirlik elde edin. Her iki kube-audit ve kube-audit-admin'i etkinleştirmeye gerek yoktur çünkü kube-audit değiştirme yapılmayan (okuma) işlemlerini de içeren bir üst kümedir.

• 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, KubeScheduler veya kube-audit gibi diğer günlük kategorilerini etkinleştirmeniz de 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 sürekli olarak açık tutarsanız, verileri Azure İzleyici'a aktarıp depolamak için gereksiz maliyetlere neden olabilirsiniz.

Azure İzleyici, başlangıç olarak kullanabileceğiniz bir dizi günlük sorgusu içerir, ancak bunları kendi sorgularınızı oluşturmanıza yardımcı olması için temel olarak da kullanabilirsiniz. Kitaplığınız büyüdükçe, bir veya daha fazla query paketi kullanarak günlük sorgularını kaydedebilir ve yeniden kullanabilirsiniz. Özel sorgu kitaplığınız AKS kümelerinizin sistem durumu ve performansı konusunda daha fazla gözlemlenebilirlik sağlar. SLO'larınıza ulaşmanıza yardımcı olur.

AKS için en iyi yöntemleri izleme hakkında daha fazla bilgi için bkz. monitor AKS with Azure İzleyici.

Ağ ölçümleri

Temel, küme düzeyinde ağ ölçümleri yerel platform ve Prometheus ölçümleri aracılığıyla kullanılabilir. Prometheus ölçümlerini kullanarak ağ ölçümlerini düğüm düzeyinde kullanıma açmak için AKS ağ ölçümlerini 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ğini içermelidir.

Başvuru uygulaması, ağ ile ilgili bazı ölçümleri de toplayan Azure İzleyici kullanır. Başvuru uygulaması, Azure İzleyici bazı ağ ölçümlerini doğrudan toplamayı yasaklar ve bunun yerine managed Prometheus ile bir Azure İzleyici çalışma alanı kullanarak ağ gözlemlenebilirlik ölçümlerini toplar.

İ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ş Kapsayıcı Ağ Hizmetleri özelliğini kullanarak bu ayrıntılı ölçümlere erişebilirsiniz. Çoğu iş yükü, bu ağ gözlemlenebilirliği derinliğini gerektirmez. Podlarınızın paket düzeyine kadar duyarlılığa sahip yüksek düzeyde optimize edilmiş bir ağ talep etmediği sürece, gelişmiş ağ izlemeyi etkinleştirmemelisiniz.

Loglama için maliyet optimizasyonu

Başvuru uygulaması, ContainerLogV2 tablosunu Başlangıç noktası olarak Temel planı kullanacak şekilde yapılandırır. Kapsayıcılar için Microsoft Defender ve başvuru uygulaması için oluşturulan uyarılar bu tabloyu sorgulamaz, bu nedenle Temel plan alım maliyetlerini azalttığı için uygun maliyetli olabilir.

Günlük hacminiz ve sorgu gereklilikleriniz geliştikçe, ihtiyaçlarınıza en uygun maliyetli olan tablo planını seçin. Çözüm, sorguların tablo verilerini sık sık taradığı okuma yoğunluklu hale gelirse, varsayılan Analytics planı daha uygun olabilir. Analiz planı sorgu ücretlerini ortadan kaldırır ve bu da sorgu etkinliğinin alım maliyetlerine ağır bastığı senaryolar için iyileştirir. Kullanım düzenlerini izlediğinizde ve tablo planlarını gerektiği gibi ayarladığınızda, izleme çözümünüz için maliyet ve işlevsellik arasında bir denge elde edebilirsiniz.

Daha fazla bilgi için bkz. Log Analytics çalışma alanında veri kullanımına göre tablo planı seçme.

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.

Note

AKS' nin altyapı düğümleri için yerleşik kendi kendine düzeltme sağlayan otomatik düğüm onarım özelliği vardır.

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 API değişiklikleri ve kaldırılan özelliklerle birlikte gelebilen Kubernetes sürümü (Kubernetes 1.32.3'ten 1.32.7'ye veya Kubernetes 1.32.7'den 1.33.1'e gibi). 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 yerleşik güncelleme işlemi, Windows Update veya apt gibi. İş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 düzeltme eki ve yükseltme kılavuzu'na, AKS 2. gün işlemleri kılavuzu'nda bakınız. Bu mimariyle ilgili temel öneriler için aşağıdaki bilgileri kullanın.

Sabit altyapı

AKS kümelerini sabit altyapı olarak çalıştıran iş yükleri, kümelerini otomatik olarak veya el ile güncelleştirmez. node görüntü yükseltme değerini none ve cluster otomatik yükseltme değerini none olarak ayarlayı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 aşağıdaki adımları gerçekleştirmeniz gerekir:

1. Güncelleştirmeyi bir üretim öncesi ortamda test edin ve yeni bir kümede uyumluluğunu değerlendirin.

2. Güncelleştirilmiş AKS sürümünü ve node pool VHD'lerini içeren bir prodüksiyon replika instance dağıtın.

3. Yeni üretim kümesi hazır olduğunda, eski kümeyi boşaltın ve sonunda devreden çıkarın.

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ümeler için bir yerinde yükseltme stratejisi bulunmalı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.

• Aşamalı güncellemeler 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ını 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 kota ve IP adresi alanının kullanılabilir olması gerektiği anlamına gelir. 33% surge 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. Ayrıca giriş denetleyicileri, hizmet kafesleri ve iş yükü podlarınız gibi iş yükü bileşenlerinizi test edin. Testleri bir üretim öncesi ortamda çalıştırı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üğümler için güncelleştirmeler ayda yaklaşık bir kez gerçekleşir. Linux düğümleri için 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.

• NodeImage'yi yükseltme kanalı olarak kullandığınızda, haftada en az bir kez ayarlamanız gereken planlı bakım pencerenize uyum sağlar. Hangi düğüm görüntüsü işletim sistemini kullanırsanız kullanın, güncellemelerin zamanında uygulanmasını sağlamak için bunu 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 sıkı bir yamalama temposu istiyorsa ve kümeniz olası kesintileri tolere edebilirse, bunun yerine SecurityPatch yükseltme kanalını kullanın. Microsoft bu güncellemeleri de test eder. Güncelleştirmeler, yalnızca Microsoft'un zamanlanmış bir sonraki düğüm görüntüsü yükseltmesinden önce yayımlanması gerektiğini düşündüğü kadar önemli güvenlik yükseltmeleri varsa yayımlanır. Kanalı SecurityPatch kullandığınızda, NodeImage kanalının aldığı güncelleştirmeleri de alırsınız. SecurityPatch kanal seçeneği, bakım pencerelerinizi kullanmaya devam eder; bu nedenle, bu beklenmeyen güvenlik güncellemelerini desteklemek için bakım pencerenizde daha sık zaman aralıkları (günlük veya iki günde bir) olduğundan emin olun.

Çoğu yerinde yükseltme yapan küme, None ve Unmanaged düğüm görüntüsü yükseltme kanal seçeneklerinden 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üm (N-2) içinde 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 blue-green dağıtımı yaklaşımını kullanmanızı öneririz.

Kubernetes kümesini ilk kez dağıtırken cluster 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ı yerine 'güncel olma' yaklaşımını benimsemek daha iyidir.

Warning

Bu güncelleştirmeleri önce alt ortamlarınızda test etmediğiniz sürece, küçük sürüm güncellemeleri söz konusu olsa bile, üretim AKS kümesine otomatik olarak düzeltme eki veya güncelleme uygulamanızı önermeyiz. Daha fazla bilgi için bkz. Kubernetes'i en son sürümüne düzenli olarak güncelleştirme ve AKS kümesini yükseltme.

Azure Event Grid için AKS sistemini kullanarak kümeniz için yeni bir AKS sürümü kullanılabilir olduğunda bildirim alabilirsiniz. Referans uygulaması, olay akışı bildirim çözümünüzdeki Microsoft.ContainerService.NewKubernetesVersionAvailable olayına abone olabilmeniz için bu Event Grid sistemini 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 sistemlerinde patch'nin ötesine geçmek nadirdir. AKS sürümünüzü otomatik olarak güncellediğinizde, uyumsuzluk olmaması için kod olarak altyapınızda (IaC) AKS sürüm ayarını kontrol edin. Planlı bakım pencerenizi otomatik güncelleme 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. Daha fazla bilgi için aşağıdaki kaynaklara bakın:

• Kapsayıcılar için Microsoft Defender kapsayıcı görüntüleriniz için Defender for Cloud önerileri tanımlar ve düzeltir.
• Kapsayıcılar için Defender, düzenli olarak kapsayıcı görüntülerinizi güvenlik açıklarına karşı tarar.
• Kapsayıcılar için Defender ayrıca şüpheli etkinlikler için gerçek zamanlı güvenlik uyarıları da oluşturur.
• AKS'deki uygulamalar ve kümeler için güvenlik 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 ayrıntılı bilgiler.

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

Küme ve iş yükü işlemleri (DevOps) ile ilgili dikkat edilmesi gerekenler için bkz. Operational Excellence tasarım ilkeleri sütunu.

Küme başlatma

Kümenizi ayarladıktan sonra, bu çalışan bir kümedir, ancak iş yüklerini dağıtmadan önce yapmanız gereken daha fazla adım olabilir. Kümenizi hazırlama işlemine bootstrapping adı verilir. Önyükleme genellikle önkoşul görüntülerini küme düğümlerine dağıtmak, ad alanları oluşturmak ve kuruluşunuzun kullanım örneğinin gereksinimlerini karşılayan diğer görevleri gerçekleştirmektir.

Yeni ayarlanmış bir kümeden düzgün yapılandırılmış bir kümeye geçişi hızlandırmak için benzersiz önyükleme işleminizi tanımlamanız ve ilgili varlıkları önceden hazırlamanız gerekir. Örneğin, Linkerd veya Consul Connect gibi bir hizmet ağı kullanıyorsanız, uygulama iş yüklerinin zamanlanmasından önce genellikle ağı dağıtırsınız. Kümeyi ayarlamadan önce, hizmet ağı görüntülerinin önceden oluşturulmuş bir kapsayıcı kayıt defterinde mevcut olduğunu doğrulamanız gerekir. Bu doğrulama, dağıtım gecikmelerini veya hatalarını önlemeye yardımcı olur.

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

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

Note

Bu yöntemlerden herhangi biri herhangi bir küme topolojisiyle çalışır, ancak tekdüzenlik ve büyük ölçekte daha kolay idare nedeniyle filolar için GitOps Flux v2 küme uzantısını öneririz. Yalnızca birkaç küme çalıştırdığınızda GitOps aşırı karmaşık olabilir. Bunun yerine, önyüklemenin gerçekleştirildiğinden emin olmak için işlemi bir veya daha fazla dağıtım hatlarına entegre etmeyi tercih edebilirsiniz. Kuruluşunuz ve ekip hedeflerinize en uygun yöntemi kullanın.

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. İleride güçlü bir yönetim temeli oluşturacak şekilde ortamı kurar ve aynı zamanda kaynak şablonları olarak 'bootstrapping'i dahil etmeyi destekleyerek IaC stratejinizle uyumlu hale getirir.

Önyükleme bildirimleri yalnızca dağıtım zamanında bilinen kapsayıcı kayıt defteri URL'si, Key Vault adı veya kimlik istemci kimliği gibi değerler gerektirdiğinde kustomization yapılandırmasında Flux değişken değiştirmesini kullanın. Bir Kustomization, Git deposundaki hangi yolun eşzamanlanacağını ve derleme sonrasında hangi değişken ikamelerinin uygulanacağını tanımlar. Kustomization’ları, IaC şablonunuzdaki Flux uzantısı dağıtımının bir parçası olarak yapılandırır; küme oluşturulurken değerlerin dağıtılan kaynaklardan çözümlenmesini sağlamak için ikame değişkenlerini burada tanımlarsınız. Bu yaklaşım, bir ConfigMap'in ilk eşitlemeden önce mevcut olmasının gerektiği durumlarda ortaya çıkan zamanlama sorunlarını ortadan kaldırır ve kullanıcıların yalnızca ortama özel değerleri özelleştirmek için depoyu çatallamak zorunda kalmasını da önler. Flux uzantısı aracısı, bu IaC yapılandırmasını Flux Kustomize denetleyicisinin uzlaştıracağı Kubernetes özel kaynaklarına çevirir ve her yolu işlerken değişken değişikliklerini uygular.

Son olarak, GitOps Flux v2 küme uzantısını kullandığınızda, önyükleme işleminin herhangi bir parçası için kubectl gerekli değildir. Acil durumlarda düzeltmeler için kubectl tabanlı erişim 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 bir iş yüküyle başlayın ve bunun üzerine inşa edin. İlk görev, ağı yapılandırmaktır. Merkez ve uçlar için sanal ağları ve bu ağların içindeki alt ağları ayarlayın. Örneğin, bir uç sistem ve kullanıcı düğümü havuzları, giriş kaynakları ve özel AKS API sunucusu 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 kullanın

Mümkün olduğunda emredici bir yaklaşım yerine idempotent 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. Başvuru uygulaması Bicep kullanır, ancak bunun yerine Terraform veya Azure Resource Manager şablonları (ARM şablonları) kullanmayı seçebilirsiniz.

İdare ilkelerine göre kaynakları ayarladığınızdan 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. Ayrıca Azure İlkesi kullanarak kuruluşunuzun bu kararlara yönelik ilkelerini zorunlu kılabilirsiniz.

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. 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çin Pipelines sürekli olarak uygulama oluşturabilmeli ve dağıtabilmelidir. 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 Services ve Jenkins bulunur.

Küme CI/CD

Diyagramda ci/CD iş akışı soldan sağa gösterilir. Sol tarafta Kod olarak altyapı simgesi, kaynak denetiminde depolanan bildirim temelli yapılandırmayı temsil eder. Kod olarak altyapıdan 'Dağıt' etiketli yatay bir ok, 'GitOps' etiketli merkezi bir kutuya yönelir. Bu kutu Azure Pipelines, GitHub Actions ve Jenkins İşlem Hatlarını içerir. GitOps kutusundan, Eşitle etiketli bir ok AKS simgesine işaret eder.

Bu mimarinin 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 aşağıdaki 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.

Aşağıdaki örnek diyagramda GitOps ve Flux ile küme yapılandırmasını otomatikleştirme gösterilmektedir.

Diyagramda, soldan sağa dört numaralandırılmış adımla GitOps iş akışı gösterilmektedir. En solda, dizüstü bilgisayar içeren bir geliştirici simgesi, kullanıcının IaC değişikliklerini Git deposuna gönderdiği 1. Adım olarak görünür. 2. adım, "git clone --mirror" etiketiyle belirtilmiş bir ok aracılığıyla bağlanan Git deposunu, AKS kümesi sınırının içindeki bir Flux simgesine göstermek için gösterir. 3. adım, Flux simgesinden küme içindeki Kubernetes API sunucusu simgesine işaret eden kubectl apply etiketli bir ok gösterir. 4. adım, geliştirici ile Kubernetes API sunucusu arasında diyagonal çizgi içeren ve üzeri çizili kubectl etiketine sahip kırmızı bir daire görüntüler.

Bu mimarinin 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, 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 access yoktur.

Git sunucunuzda, değişikliklerin üretime uygulanmadan önce birden çok geliştirici tarafından bir pull request aracılığıyla onaylanabilmesi için dal politikaları oluşturabilirsiniz.

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. Bu işlem değişikliğin simülasyonunu oluşturur 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

AKS için Well-Architected Framework'te özetlenen maliyet optimizasyonu tasarım denetim listesini ve öneriler listesini gözden geçirerek başlayın. Genel iş yükü önerileri için, Maliyet Optimizasyonu için Tasarım inceleme kontrol listesine bakınız.

Bu temel mimaride kullanılan bileşenler için maliyet tahminini Azure fiyatlandırma hesaplayıcısı bulabilirsiniz. Tahmininizi, kullanım örneğiniz için gereken bileşenleri içerecek şekilde değiştirin. Bu tahmin, kümeyle doğrudan ilişkili uç düzeyindeki kaynakları kapsar. Azure Güvenlik Duvarı, hub sanal ağları ve Azure Özel DNS bölgeleri gibi paylaşılan hub altyapısı, genellikle merkezi bir platform ekibine ait ve yönetilen kaynaklar olduğundan dahil değildir.

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

Provision

• 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, storage, 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. Ddv5 serisi sistem düğümü havuzu için tipik bir VM türüdür ve başvuru uygulaması Standard_D2d_v5 SKU'yu kullanır.

• Geliştirme/test ve üretim ortamları için aynı yapılandırmayı kullanmayın. Ü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, yüksek kullanılabilirlik garantisinin gerekmediği geliştirme/test veya deneysel iş yükleri için tasarlanmış kümelerle tasarruf sağlanabilir. Örneğin, SLO'nuz yeterli olabilir. Ayrıca, iş yükünüz destekliyorsa, spot VM çalıştıran ayrılmış spot düğüm havuzlarını kullanmayı göz önünde bulundurun.

  AKS iş yükü mimarisinin bir parçası olarak Azure SQL Veritabanı veya Azure App Service içeren üretim dışı iş yükleri için Azure Geliştirme/Test aboneliklerini kullanmaya ve hizmet indirimleri almaya 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 düğümlerin tüm kapasitesini 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.

• Uzun bir süre mevcut olması gereken iş yükleriniz için düğüm maliyetlerini azaltmak amacıyla bir veya üç yıllık Azure Ayrılmış Sanal Makine Örneklerine taahhütte bulunun. Daha fazla bilgi için bkz. Save costs with Azure Reserved Virtual Machine Instances.

• 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. Küme ekipler arasında paylaşılıyorsa, paylaşılan bulut hizmetlerinin ölçülen maliyetlerini belirlemek için her tüketici için ücretlendirme raporları oluşturun. Daha fazla bilgi için bkz. Düğüm havuzu için leke, etiket veya işaret belirleme.

• İş 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. Bandwidth pricing.

• 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.

Monitor

Kümenin tamamını ve işlem maliyetini, storage, bant genişliğini, günlükleri ve güvenlik duvarını izleyebilirsiniz. Azure maliyetleri izlemek ve analiz etmek için aşağıdaki seçenekleri sağlar:

• Azure Danışmanı
• Maliyet Yönetimi

Maliyetlerinizi gerçek zamanlı olarak veya düzenli bir zamanlamaya göre izleyerek, maliyetlerin zaten hesaplandığı ay sonundan önce işlem yapabilirsiniz. Bütçenin içinde 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. Kullanım ölçümlerini Azure İzleyici ölçümlerde görebilirsiniz.

Optimize

Azure Danışmanı önerilerini izleyin. İyileştirmenin diğer yollarını keşfedin:

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

  Important

  Maliyetleri denetlemek için bir düğüm havuzu için en düşük ve en yüksek düğüm sayısı gibi küme otomatik ölçeklendiricisi ayarlarında hızlı veya sık değişiklikler yapmak istenmeyen veya karşı üretim sonuçlarına neden olabilir. Örneğin, 10 dakika olarak ayarlanırsa ve en düşük ve en yüksek düğüm ayarları iş yükü özelliklerine göre 5 dakikada bir değiştirilirse scale-down-unneeded-time , düğüm sayısı hiçbir zaman azalmaz. Bunun nedeni, küme otomatik ölçeklendiricisi ayarları yenilendiğinde her düğüm için gereksiz sürenin hesaplanması sıfırlanı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 haklarınızı belirlemeyi göz önünde bulundurun.

• İş yükünüz destekliyorsa, kullanıcı düğümü havuzlarınızı çalıştırılma beklentisi olmadığında sıfır düğüme ölçekleyin. 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.

Daha fazla bilgi için bkz. AKS fiyatlandırması.

Sonraki Adımlar

• GitHub'daki AKS yol haritası

İlgili kaynaklar

• Geldirilmiş AKS mikro hizmetler mimarisi
• AKS üzerinde Mikro Hizmetler mimarisi
• AKS kümesini korumaya yardımcı olmak için Azure Güvenlik Duvarı kullanın
• AKS için GitOps
• AKS kullanarak veri akışı