Bu mimaride, etkin/etkin ve yüksek oranda kullanılabilir bir yapılandırmada Azure Kubernetes Service (AKS) kümesinin birden çok örneğinin birden çok bölgede nasıl çalıştırılacakları açıklanmaktadır.
Bu mimari, Microsoft'un AKS altyapısı için önerilen başlangıç noktası olan AKS temel mimarisini temel alır. AKS temeli, Microsoft Entra İş Yükü Kimliği, giriş ve çıkış kısıtlamaları, kaynak sınırları ve diğer güvenli AKS altyapısı yapılandırmaları gibi altyapı özelliklerinin ayrıntılarını içerir. Bu altyapı ayrıntıları bu belgede ele alınmıyor. Çok bölgeli içeriğe geçmeden önce AKS temeli hakkında bilgi sahibi olmanız önerilir.
Mimari
Bu mimarinin bir Visio dosyasını indirin.
Bileşenler
Bu çok bölgeli AKS mimarisinde birçok bileşen ve Azure hizmeti kullanılır. Burada yalnızca bu çok kümeli mimariye özgü bileşenler listelenir. Kalanlar için AKS Temeli mimarisine bakın.
- Bölgesel AKS kümeleri: Her birinin ayrı bir Azure bölgesinde yer alan birden çok AKS kümesi dağıtılır. Normal işlemler sırasında ağ trafiği tüm bölgeler arasında yönlendirilir. Bir bölge kullanılamaz duruma gelirse, trafik isteği veren kullanıcıya en yakın bölgeye yönlendirilir.
- Bölgesel merkez-uç ağları: Her bölgesel AKS örneği için bölgesel merkez-uç ağ çifti dağıtılır. Azure Güvenlik Duvarı Yöneticisi ilkeleri tüm bölgelerde güvenlik duvarı ilkelerini yönetmek için kullanılır.
- Bölgesel anahtar kasası: Azure Key Vault her bölgede sağlanır. Anahtar kasaları AKS kümesine özgü hassas değerleri ve anahtarları ve bu bölgedeki destekleyici hizmetleri depolamak için kullanılır.
- Birden çok günlük çalışma alanı: Bölgesel Log Analytics çalışma alanları bölgesel ağ ölçümlerini ve tanılama günlüklerini depolamak için kullanılır. Ayrıca, tüm AKS örnekleri için ölçümleri ve tanılama günlüklerini depolamak için paylaşılan bir Log Analytics örneği kullanılır.
- Genel Azure Front Door profili: Azure Front Door, trafiği yük dengelemek ve her AKS kümesinin önünde yer alan bölgesel bir Azure Uygulaması Lication Gateway örneğine yönlendirmek için kullanılır. Azure Front Door, her ikisi de bu mimari için gerekli olan katman 7 genel yönlendirmeye olanak tanır.
- Genel kapsayıcı kayıt defteri: İş yükünün kapsayıcı görüntüleri yönetilen bir kapsayıcı kayıt defterinde depolanır. Bu mimaride, kümedeki tüm Kubernetes örnekleri için tek bir Azure Container Registry kullanılır. Azure Container Registry için coğrafi çoğaltma, görüntülerin seçilen Azure bölgelerine çoğaltılmasına ve bir bölgede kesinti yaşansa bile görüntülere sürekli erişim sağlanmasına olanak tanır.
Tasarım desenleri
Bu mimaride iki bulut tasarım deseni kullanılır:
- Coğrafi düğümler (coğrafi düğümler), herhangi bir bölgenin herhangi bir isteği karşıladığı yer.
- Bir uygulamanın veya uygulama bileşeninin birden çok bağımsız kopyasının dağıtım şablonu gibi tek bir kaynaktan dağıtıldığı Dağıtım Damgaları.
Coğrafi düzende dikkat edilmesi gerekenler
Her AKS kümesini dağıtmak için bölgeleri seçerken iş yükü tüketicisine veya müşterilerinize yakın bölgeleri göz önünde bulundurun. Ayrıca bölgeler arası çoğaltmayı da kullanmayı göz önünde bulundurun. Bölgeler arası çoğaltma, olağanüstü durum kurtarma koruması için aynı uygulamaları ve verileri diğer Azure bölgelerinde zaman uyumsuz olarak çoğaltır. Kümeniz iki bölgenin ötesine ölçeklendikçe, her aks kümesi çifti için bölgeler arası çoğaltmayı planlamaya devam edin.
Her bölge içinde AKS düğüm havuzlarındaki düğümler, bölgesel hatalardan kaynaklanan sorunları önlemeye yardımcı olmak için birden çok kullanılabilirlik alanına yayılır. Kullanılabilirlik alanları, bölgesel küme yerleşimini etkileyen sınırlı bir bölge kümesinde desteklenir. Desteklenen bölgelerin listesi de dahil olmak üzere AKS ve kullanılabilirlik alanları hakkında daha fazla bilgi için bkz . AKS kullanılabilirlik alanları.
Dağıtım damgasıyla ilgili dikkat edilmesi gerekenler
Çok bölgeli aks çözümünü yönetirken, birden çok bölgeye birden çok AKS kümesi dağıtırsınız. Bu kümelerin her biri damga olarak kabul edilir. Bölgesel bir hata varsa veya kümeleriniz için daha fazla kapasite veya bölgesel iletişim durumu eklemeniz gerekiyorsa yeni bir damga örneği oluşturmanız gerekebilir. Dağıtım damgaları oluşturmak ve yönetmek için bir işlem seçerken aşağıdakilere dikkat etmek önemlidir:
- Genelleştirilmiş yapılandırmaya izin veren damga pulu tanımları için uygun teknolojiyi seçin. Örneğin, altyapıyı kod olarak tanımlamak için Bicep'i kullanabilirsiniz.
- Değişkenler veya parametre dosyaları gibi bir dağıtım giriş mekanizması kullanarak örneğe özgü değerler sağlayın.
- Esnek, yinelenebilir ve bir kez etkili dağıtıma olanak tanıyan dağıtım araçlarını seçin.
- Etkin/etkin damga pulu yapılandırmasında trafiğin her damga pulu arasında nasıl dengelenmiş olduğunu göz önünde bulundurun. Bu mimaride genel yük dengeleme için Azure Front Door kullanılır.
- Damga pulları eklendikçe ve koleksiyondan kaldırıldıkçe kapasite ve maliyet kaygılarını göz önünde bulundurun.
- Damga pulları koleksiyonunun tek bir birim olarak nasıl görünürlük kazanıp izleneceğini göz önünde bulundurun.
Bu öğelerin her biri, aşağıdaki bölümlerde belirli yönergelerle ayrıntılı olarak verilmiştir.
Filo yönetimi
Bu çözüm, tüm kümeleri birleşik bir filonun parçası olarak ele almak için gelişmiş bir düzenleyici dahil edilmeden çok kümeli ve çok bölgeli topolojiyi temsil eder. Küme sayısı arttığında, katılan kümelerin daha iyi ölçekli yönetimi için üyeleri Azure Kubernetes Fleet Manager'a kaydetmeyi göz önünde bulundurun. Burada sunulan altyapı mimarisi, Fleet Manager kaydıyla temel olarak değişmez, ancak 2. gün operasyonları ve benzer etkinlikler aynı anda birden çok kümeyi hedefleyebilecek bir denetim düzleminden yararlanır.
Dikkat edilmesi gereken noktalar
Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.
Küme dağıtımı ve önyükleme
Yüksek oranda kullanılabilir ve coğrafi olarak dağıtılmış yapılandırmalarda birden çok Kubernetes kümesi dağıtırken, her Kubernetes kümesinin toplamını birleştirilmiş birim olarak değerlendirmek önemlidir. Her Kubernetes örneğinin mümkün olduğunca özdeş olduğundan emin olmak için otomatik dağıtım ve yapılandırma için kod temelli stratejiler geliştirmek isteyebilirsiniz. Diğer Kubernetes kümelerini ekleyerek veya kaldırarak ölçeği genişletme ve daraltma stratejilerini göz önünde bulundurun. Tasarımınız ve dağıtım ve yapılandırma planınız kullanılabilirlik alanı kesintilerini, bölgesel hataları ve diğer yaygın senaryoları dikkate almalıdır.
Küme tanımı
Azure Kubernetes Service kümesini dağıtmak için birçok seçeneğiniz vardır. Azure portalı, Azure CLI ve Azure PowerShell modülünün tümü tek tek veya desteklenmeyen AKS kümelerini dağıtmak için uygun seçeneklerdir. Ancak bu yöntemler, çok sayıda sıkı şekilde bağlanmış AKS kümesiyle çalışırken güçlükler ortaya koyabilir. Örneğin, Azure portalını kullanmak, eksik adımlar veya kullanılamayan yapılandırma seçenekleri nedeniyle yanlış yapılandırma fırsatı açar. Portalı kullanan birçok kümenin dağıtımı ve yapılandırması, bir veya daha fazla mühendisin odaklanmasını gerektiren zaman alan bir işlemdir. Azure CLI veya Azure PowerShell kullanıyorsanız, komut satırı araçlarını kullanarak yinelenebilir ve otomatik bir işlem oluşturabilirsiniz. Ancak, bir kez etkililik, dağıtım hatası denetimi ve hata kurtarma sorumluluğu size ve oluşturduğunuz betiklere aittir.
Birden çok AKS örneğiyle çalışırken altyapıyı Bicep, Azure Resource Manager şablonları veya Terraform gibi kod çözümleri olarak değerlendirmenizi öneririz. Kod olarak altyapı çözümleri otomatik, ölçeklenebilir ve bir kez etkili bir dağıtım çözümü sağlar. Örneğin, çözümün paylaşılan hizmetleri için bir Bicep dosyası, AKS kümeleri ve diğer bölgesel hizmetler için de başka bir Bicep dosyası kullanabilirsiniz. Altyapıyı kod olarak kullanırsanız ağ, yetkilendirme ve tanılama gibi genelleştirilmiş yapılandırmalarla bir dağıtım damgası tanımlanabilir. Dağıtım parametresi dosyası bölgeye özgü değerlerle sağlanabilir. Bu yapılandırmayla, herhangi bir bölgeye neredeyse aynı damgayı dağıtmak için tek bir şablon kullanılabilir.
Kod varlıkları olarak altyapı geliştirme ve bakımının maliyeti yüksek olabilir. Bazı durumlarda, altyapıyı kod olarak tanımlamanın getirdiği ek yük, çok küçük (örneğin, 2 veya 3) ve değişmeyen sayıda AKS örneğiniz olması gibi avantajlardan daha ağır basabilir. Bu gibi durumlarda, komut satırı araçları ve hatta Azure portalı ile el ile yaklaşımlar gibi daha kesin bir yaklaşım kullanmak kabul edilebilir.
Küme dağıtımı
Küme damgası tanımlandıktan sonra, tek tek veya birden çok damga örneği dağıtmak için birçok seçeneğiniz vardır. Önerimiz GitHub Actions veya Azure Pipelines gibi modern sürekli tümleştirme teknolojisini kullanmaktır. Sürekli tümleştirme tabanlı dağıtım çözümlerinin avantajları şunlardır:
- Kod kullanılarak damgaların eklenmesine ve kaldırılmasına olanak sağlayan kod tabanlı dağıtımlar
- Tümleşik test özellikleri
- Tümleşik ortam ve hazırlama özellikleri
- Tümleşik gizli dizi yönetimi çözümleri
- Hem uygulama kodu hem de dağıtım betikleri ve şablonları için kaynak denetimiyle tümleştirme
- Dağıtım geçmişi ve günlüğe kaydetme
- Kimlerin ve hangi koşullar altında değişiklik yapabileceğini denetlemek için erişim denetimi ve denetim özellikleri
Genel kümeye yeni damgalar eklendikçe veya kaldırıldığında tutarlı kalmak için dağıtım işlem hattının güncelleştirilmesi gerekir. Yaklaşımlardan biri, gitHub Actions iş akışı içinde her bölgenin kaynaklarını tek bir adım olarak dağıtmaktır. Her küme örneği dağıtım işlem hattı içinde açıkça tanımlandığından bu yapılandırma basittir. Bu yapılandırma, küme ekleme ve dağıtımdan kaldırma konusunda bazı yönetim ek yüklerini içerir.
Bir diğer seçenek de istenen konumların listesini veya diğer veri noktalarını gösteren kümeleri oluşturmak için iş mantığı oluşturmaktır. Örneğin, dağıtım işlem hattı istenen bölgelerin listesini içerebilir; İşlem hattı içindeki bir adım, listede bulunan her bölgeye bir küme dağıtarak bu listede döngü yapabilir. Bu yapılandırmanın dezavantajı, dağıtım genelleştirmesindeki karmaşıklıktır ve her küme damgasının dağıtım işlem hattında açıkça ayrıntılı olarak açıklanmamış olmasıdır. Bunun olumlu avantajı, küme damgalarını işlem hattından eklemenin veya kaldırmanın istenen bölgeler listesinde basit bir güncelleştirme haline gelmesidir.
Ayrıca, dağıtım işlem hattından bir küme damgasının kaldırılması her zaman damga damgasının kaynaklarının yetkisini almaz. Dağıtım çözümünüz ve yapılandırmanıza bağlı olarak AKS örneklerinin ve diğer Azure kaynaklarının yetkisini almak için ek bir adım gerekebilir. Azure kaynaklarının artık ihtiyacınız olmadığında temizleme de dahil olmak üzere tam yaşam döngüsü yönetimini etkinleştirmek için dağıtım yığınlarını kullanmayı göz önünde bulundurun.
Küme önyüklemesi
Her Kubernetes örneği veya damgası dağıtıldıktan sonra giriş denetleyicileri, kimlik çözümleri ve iş yükü bileşenleri gibi küme bileşenlerinin dağıtılması ve yapılandırılması gerekir. Ayrıca küme genelinde güvenlik, erişim ve idare ilkeleri uygulamayı da göz önünde bulundurmanız gerekir.
Dağıtıma benzer şekilde, bu yapılandırmaların birkaç Kubernetes örneğinde el ile yönetilmesi zor olabilir. Bunun yerine, büyük ölçekte yapılandırma ve ilke için aşağıdaki seçenekleri göz önünde bulundurun.
GitOps
Kubernetes bileşenlerini el ile yapılandırmak yerine, bu yapılandırmalar bir kaynak depoda denetlendiğinden, yapılandırmaları bir Kubernetes kümesine uygulamak için otomatik yöntemlerin kullanılması önerilir. Bu işlem genellikle GitOps olarak adlandırılır ve Kubernetes için popüler GitOps çözümleri arasında Flux ve Argo CD bulunur. Örneğin AKS için Flux uzantısı, kümeler dağıtıldıktan hemen sonra ve otomatik olarak kümelere önyüklemeyi etkinleştirir.
GitOps, AKS temel başvuru mimarisinde daha ayrıntılı olarak anlatılmıştır. Yapılandırma için GitOps tabanlı bir yaklaşım kullanarak, her Kubernetes örneğinin benzer şekilde özel bir çaba olmadan yapılandırıldığından emin olursunuz. Filonuzun boyutu büyüdükçe kolaylaştırılmış bir yapılandırma süreci daha da önemli hale gelir.
Azure İlkesi
Birden çok Kubernetes örneği eklendikçe ilke temelli idare, uyumluluk ve yapılandırmanın avantajı artar. İlkeleri, özellikle de Azure İlkesi kullanmak, küme denetimi için merkezi ve ölçeklenebilir bir yöntem sağlar. AKS ilkelerinin avantajı, AKS temel başvuru mimarisinde ayrıntılı olarak anlatılmıştır.
AKS kümeleri oluşturulduğunda Azure İlkesi etkinleştirilmelidir. Uyumsuzluğun görünürlüğünü elde etmek için girişimler Denetim modunda atanmalıdır. Ayrıca, yerleşik girişimlerin parçası olmayan daha fazla ilke ayarlayabilirsiniz. Bu ilkeler Reddetme modunda ayarlanır. Örneğin, kümede yalnızca onaylanan kapsayıcı görüntülerinin çalıştırıldığından 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.
İlke kapsamı , her ilkenin ve ilke girişiminin hedefini ifade eder. Her AKS kümesinin dağıtıldığı kaynak grubuna ilke atamak için Bicep'i kullanabilirsiniz. Genel kümenin ayak izi büyüdükçe birçok yinelenen ilkeye neden olur. İlkelerin kapsamını bir Azure aboneliği veya Azure yönetim grubu olarak da ayarlayabilirsiniz. Bu yöntem, bir abonelik kapsamındaki tüm AKS kümelerine veya bir yönetim grubu altında bulunan tüm aboneliklere tek bir ilke kümesi uygulamanıza olanak tanır.
Birden çok AKS kümesi için ilke tasarlarken aşağıdaki öğeleri göz önünde bulundurun:
- Tüm AKS örneklerine genel olarak uygulanması gereken ilkeleri bir yönetim grubuna veya aboneliğe uygulayın.
- Her bölgesel kümeyi, bölgeye özgü ilkelerin kaynak grubuna uygulanmasına olanak tanıyan kendi kaynak grubuna yerleştirin.
İlke yönetimi stratejisi oluşturmanıza yardımcı olacak malzemeler için bkz. Bulut Benimseme Çerçevesi kaynak kuruluşu.
İş yükü dağıtımı
AKS örneği yapılandırmasına ek olarak, her bölgesel örneğe veya damgaya dağıtılan iş yükünü göz önünde bulundurun. Dağıtım çözümleri veya işlem hatları, her bölgesel damgayı barındırmak için yapılandırma gerektirir. Genel kümeye daha fazla damga eklendikçe dağıtım işleminin genişletilmesi veya yeni bölgesel örnekleri barındıracak kadar esnek olması gerekir.
İş yükü dağıtımını planlarken aşağıdaki öğeleri göz önünde bulundurun.
- Birden çok küme damgasında tek bir dağıtım yapılandırmasının kullanılabildiğinden emin olmak için dağıtımı helm grafiği gibi genelleştirin.
- İş yükünü tüm küme damgalarına dağıtmak için yapılandırılmış tek bir sürekli dağıtım işlem hattı kullanın.
- Damgaya özgü örnek ayrıntılarını dağıtım parametreleri olarak sağlayın.
- Uygulama tanılama günlüğünün ve dağıtılmış izlemenin uygulama genelinde gözlemlenebilirlik için nasıl yapılandırıldığını düşünün.
Kullanılabilirlik ve yük devretme
Çok bölgeli Kubernetes mimarisini seçmenin önemli bir nedeni hizmet kullanılabilirliğidir. Başka bir ifadeyle, bir hizmet veya hizmet bileşeni bir bölgede kullanılamaz duruma gelirse trafik, söz konusu hizmetin başka bir örneğinin hala kullanılabilir olduğu bir bölgeye yönlendirilmelidir. Çok bölgeli mimari birçok farklı hata noktası içerir. Bu bölümde, bu olası hata noktalarının her biri tartışılır.
Uygulama pod hataları
Kubernetes Deployment nesnesi, podun birden çok çoğaltmasını yöneten bir ReplicaSet oluşturmak için kullanılır. Bir pod kullanılamıyorsa, trafik kalan pod arasında yönlendirilir. Kubernetes ReplicaSet, belirtilen sayıda çoğaltmayı çalışır durumda tutmaya çalışır. Bir örnek devre dışı kalırsa, otomatik olarak yeni bir örnek oluşturulmalıdır. Canlılık yoklamaları, podda çalışan uygulamanın veya işlemin durumunu denetlemek için kullanılabilir. Hizmet yanıt vermiyorsa canlılık yoklaması podu kaldırır ve bu da ReplicaSet'i yeni bir örnek oluşturmaya zorlar.
Daha fazla bilgi için bkz . Kubernetes ReplicaSet.
Veri merkezi donanım hataları
Yerelleştirilmiş hata bazen oluşabilir. Örneğin, güç tek bir Azure sunucuları rafı için kullanılamaz hale gelebilir. AKS düğümlerinizi tek bir hata noktası haline getirmekten korumak için Azure kullanılabilirlik alanlarını kullanın. Kullanılabilirlik alanlarını kullanarak, bir kullanılabilirlik alanındaki AKS düğümlerinin başka bir kullanılabilirlik alanında tanımlanan düğümlerden fiziksel olarak ayrıldığından emin olursunuz.
Daha fazla bilgi için bkz . AKS ve Azure kullanılabilirlik alanları.
Azure bölgesi hataları
Tüm bölge kullanılamaz duruma geldiğinde, kümedeki podlar artık istek sunmak için kullanılamaz. Bu durumda Azure Front Door tüm trafiği kalan iyi durumdaki bölgelere yönlendirir. İyi durumdaki bölgelerdeki Kubernetes kümeleri ve podları isteklere hizmet etmeye devam eder.
Artan istekleri ve kalan kümeye gelen trafiği telafi etmek için bu duruma dikkat edin. Aşağıdaki noktalara bir göz atın:
- Ağ ve işlem kaynaklarının, bölge yük devretmesi nedeniyle trafikteki ani artışı emecek şekilde doğru boyutlandırıldığından emin olun. Örneğin, Azure CNI kullanırken trafik artış gösterirken tüm Pod IP adreslerini destekleyecek kadar büyük bir alt ağınız olduğundan emin olun.
- Artan bölgesel talebi telafi etmek üzere pod çoğaltma sayısını artırmak için Yatay Pod Otomatik Ölçeklendiricisi'ni kullanın.
- Artan bölgesel talebi telafi etmek üzere Kubernetes örnek düğümü sayılarını artırmak için AKS Kümesi Otomatik Ölçeklendiricisi'ni kullanın.
Daha fazla bilgi için bkz . Yatay Pod Otomatik Ölçeklendiricisi ve AKS kümesi otomatik ölçeklendiricisi.
Ağ topolojisi
AKS temel başvuru mimarisine benzer şekilde, bu mimaride merkez-uç ağ topolojisi kullanılır. AKS temel başvuru mimarisinde belirtilen noktalara ek olarak aşağıdaki en iyi yöntemleri göz önünde bulundurun:
- Her bölgesel AKS örneği için bir merkez-uç sanal ağ kümesi uygulayın. Her bölge içinde her uç ile merkez sanal ağına eşleyin.
- Tüm giden trafiği her bölgesel merkez ağında bulunan bir Azure Güvenlik Duvarı örneği üzerinden yönlendirin. Tüm bölgelerde güvenlik duvarı ilkelerini yönetmek için Azure Güvenlik Duvarı Yöneticisi ilkelerini kullanma.
- AKS temel başvuru mimarisinde bulunan IP boyutlandırmasını izleyin ve başka bir bölgede bölgesel bir hatayla karşılaşmanız ve kalan bölgelere giden trafiğin önemli ölçüde artması durumunda hem düğüm hem de pod ölçek işlemleri için daha fazla IP adresi olmasını sağlayın.
Trafik yönetimi
AKS temel başvuru mimarisiyle iş yükü trafiği doğrudan bir Azure Uygulaması lication Gateway örneğine yönlendirilir, ardından arka uç yük dengeleyici ve AKS giriş kaynaklarına iletilir. Birden çok kümeyle çalıştığınızda istemci istekleri, Azure Uygulaması lication Gateway örneğine yönlendirilen bir Azure Front Door örneği üzerinden yönlendirilir.
Bu diyagramın Visio dosyasını indirin.
Kullanıcı, Azure Front Door profiline çözümlenen bir etki alanı adına (örneğin
https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net) bir istek gönderir. Bu istek, Azure Front Door'un tüm alt etki alanları için verilen bir joker sertifika (*.azurefd.net) ile şifrelenir. Azure Front Door isteği web uygulaması güvenlik duvarı ilkelerine karşı doğrular, en hızlı kaynağı seçer (sistem durumuna ve gecikme süresine göre) ve kaynak IP adresini (Azure Uygulaması lication Gateway örneği) çözümlemek için genel DNS kullanır.Azure Front Door, isteği seçilen uygun Application Gateway örneğine iletir ve bölgesel damga için giriş noktası görevi görür. Trafik İnternet üzerinden akar. Azure Front Door, çıkış noktası trafiğinin şifrelenmesini sağlar.
Application Gateway örneğinin yalnızca Front Door örneğinden gelen trafiği kabul etmesini sağlamak için bir yöntem düşünün. Bir yaklaşım, Application Gateway'i içeren alt ağda bir ağ güvenlik grubu kullanmaktır. Kurallar Gelen (veya giden) trafiği Kaynak, Bağlantı Noktası, Hedef gibi özelliklere göre filtreleyebilir. Source özelliği, bir Azure kaynağının IP adreslerini gösteren yerleşik bir hizmet etiketi ayarlamanıza olanak tanır. Bu soyutlama, kuralı yapılandırmayı ve korumayı ve IP adreslerini izlemeyi kolaylaştırır. Ayrıca, Application Gateway örneğinin
X-Azure-FDIDyalnızca Front Door örneğinden gelen trafiği kabul etmesini sağlamak için Azure Front Door'un talebe göndermeden önce eklediği üst bilgiyi kullanmayı göz önünde bulundurun. Front Door üst bilgileri hakkında daha fazla bilgi için bkz . Azure Front Door'da HTTP üst bilgileri için protokol desteği.
Paylaşılan kaynakla ilgili dikkat edilmesi gerekenler
Bu senaryonun odak noktası birden çok Azure bölgesine yayılmış birden çok Kubernetes örneğinin bulunması olsa da, bazı kaynakları tüm bölgelerde paylaşmak mantıklıdır. Bir yaklaşım, tüm paylaşılan kaynakları dağıtmak için tek bir Bicep dosyası, her bölgesel damgayı dağıtmak için başka bir dosya kullanmaktır. Bu bölümde, bu paylaşılan kaynakların her biri ayrıntılı olarak anlatılır ve her birinin birden çok AKS örneğinde kullanılmasıyla ilgili dikkat edilmesi gerekenler ele alınmalıdır.
Container Registry
Azure Container Registry, kapsayıcı görüntü hizmetleri sağlamak için bu mimaride kullanılır. Küme, kapsayıcı görüntülerini kayıt defterinden çeker. Çok bölgeli küme dağıtımında Azure Container Registry ile çalışırken aşağıdaki öğeleri göz önünde bulundurun.
Coğrafi Kullanılabilirlik
AKS kümesinin dağıtıldığı her bölgeye bir kapsayıcı kayıt defteri yerleştirin. Bu yaklaşım, düşük gecikme süreli ağ işlemlerine olanak tanıyarak hızlı ve güvenilir görüntü katmanı aktarımları sağlar. Ayrıca, bölgesel hizmetler kullanılamadığında kullanılabilirlik sağlamak için birden çok görüntü hizmeti uç noktanız olduğu anlamına gelir. Azure Container Registry'nin coğrafi çoğaltma işlevini kullanmak, birden çok bölgeye otomatik olarak çoğaltılan bir kapsayıcı kayıt defterini yönetmenize olanak tanır.
Küme içeren her Azure bölgesine çoğaltmalar içeren tek bir kayıt defteri oluşturmayı göz önünde bulundurun. Azure Container Registry çoğaltması hakkında daha fazla bilgi için bkz . Azure Container Registry'de coğrafi çoğaltma.
Azure portalından birden çok Azure Container Registry çoğaltmasını gösteren görüntü.
Küme erişimi
Her AKS kümesi, kapsayıcı görüntüsü katmanlarını çekebilmesi için kapsayıcı kayıt defterine erişim gerektirir. Azure Container Registry'ye erişim sağlamanın birden çok yolu vardır. Bu mimaride, her küme için bir yönetilen kimlik oluşturulur ve bu kimlik kapsayıcı kayıt defterinde rolü verilir AcrPull . Azure Container Registry erişimi için yönetilen kimlikleri kullanma hakkında daha fazla bilgi ve öneri için bkz . AKS temel başvuru mimarisi.
Bu yapılandırma, küme damgası Bicep dosyasında tanımlanır, böylece her yeni damga dağıtıldığında yeni AKS örneğine erişim verilir. Kapsayıcı kayıt defteri paylaşılan bir kaynak olduğundan, dağıtımlarınızın kapsayıcı kayıt defterinin kaynak kimliğini parametre olarak içerdiğinden emin olun.
Azure İzleyici
Azure İzleyici Kapsayıcı içgörüleri özelliği, kümenizin ve kapsayıcı iş yüklerinizin performansını ve durumunu izlemek ve anlamak için önerilen araçtır. Kapsayıcı içgörüleri hem günlük verilerini depolamak için log Analytics çalışma alanını hem de sayısal zaman serisi verilerini depolamak için Azure İzleyici Ölçümlerini kullanır. Prometheus ölçümleri Container Insights tarafından da toplanabilir ve veriler Prometheus için Azure İzleyici yönetilen hizmetine veya Azure İzleyici Günlükleri'ne gönderilebilir. Daha fazla bilgi için bkz . AKS temel başvuru mimarisi.
Ayrıca AKS denetim düzlemi bileşenlerinden kaynak günlüklerini toplayıp analiz etmek ve bunları Log Analytics çalışma alanına iletmek için AKS kümesi tanılama ayarlarınızı yapılandırabilirsiniz.
Çok bölgeli mimari için bir izleme çözümü tasarlarken, her damga pulu arasındaki bağlantıyı göz önünde bulundurmanız önemlidir. Her Kubernetes kümesi tarafından paylaşılan tek bir Log Analytics çalışma alanı dağıtabilirsiniz. Diğer paylaşılan kaynaklarda olduğu gibi, genel olarak paylaşılan tek Log Analytics çalışma alanı hakkındaki bilgileri kullanmak için bölgesel damganızı tanımlayın ve her bölgesel kümeyi bu paylaşılan çalışma alanına bağlayın. Her bölgesel küme tanılama günlüklerini tek bir Log Analytics çalışma alanına yaydığında, çok bölgeli çözümünüzün tamamının nasıl çalıştığını anlamanıza yardımcı olacak raporları ve panoları daha kolay oluşturmak için verileri kaynak ölçümleriyle birlikte kullanabilirsiniz.
Azure Front Door
Azure Front Door, trafiği yük dengelemek ve her AKS kümesine yönlendirmek için kullanılır. Azure Front Door, katman 7 genel yönlendirmeyi de etkinleştirir. Bu özellikler bu senaryo için gereklidir.
Küme yapılandırması
Her bölgesel AKS örneği eklendikçe, Kubernetes kümesiyle birlikte dağıtılan Application Gateway'in Azure Front Door'a kaynak olarak kaydedilmesi gerekir ve bu da yönlendirme için kullanılabilir hale gelir. Bu işlem, kod varlıkları olarak altyapınızda bir güncelleştirme gerektirir. Alternatif olarak, bu işlem dağıtım yapılandırmasından ayrıştırılabilir ve Azure CLI gibi araçlar kullanılarak yönetilebilir.
Sertifikalar
Azure Front Door, geliştirme veya test ortamlarında bile otomatik olarak imzalanan sertifikaların kullanıldığı kaynakları desteklemez. HTTPS trafiğini etkinleştirmek için bir sertifika yetkilisi (CA) tarafından imzalanan TLS/SSL sertifikanızı oluşturmanız gerekir. Front Door'un desteklediği diğer CA'lar hakkında bilgi için bkz . Azure Front Door'da özel HTTPS'yi etkinleştirmek için izin verilen sertifika yetkilileri.
Test veya üretim dışı kümeler için Certbot kullanarak uygulama ağ geçitlerinin her biri için bir Let's Encrypt Authority X3 sertifikası oluşturabilirsiniz.
Bir üretim kümesi planlarken, TLS sertifikaları temini için kuruluşunuzun tercih edilen yöntemini kullanın.
Küme erişimi ve kimliği
AKS temel başvuru mimarisinde açıklandığı gibi, kümeleriniz için kimlik sağlayıcısı olarak Microsoft Entra Id kullanmanızı öneririz. Microsoft Entra grupları daha sonra küme kaynaklarına erişimi denetlemek için kullanılabilir.
Birden çok kümeyi yönetirken bir erişim şemasına karar vermeniz gerekir. Seçenekler arasında bulunanlar:
- Üyelerin kümedeki her Kubernetes örneğindeki tüm nesnelere erişebileceği genel bir küme genelinde erişim grubu oluşturun. Bu seçenek en az yönetim gereksinimi sağlar; ancak, herhangi bir grup üyesine önemli ayrıcalıklar verir.
- Tek bir küme örneğindeki nesnelere erişim vermek için kullanılan her Kubernetes örneği için ayrı bir erişim grubu oluşturun. Bu seçenekle yönetim yükü artar; ancak daha ayrıntılı küme erişimi de sağlar.
- Kubernetes nesne türleri ve ad alanları için ayrıntılı erişim denetimleri tanımlayın ve sonuçları bir Microsoft Entra grup yapısıyla ilişkilendirin. Bu seçenekle, yönetim yükü önemli ölçüde artar; ancak, yalnızca her kümeye değil, her kümede bulunan ad alanlarına ve Kubernetes API'lerine ayrıntılı erişim sağlar.
Yönetim erişimi için her bölge için bir Microsoft Entra grubu oluşturmayı göz önünde bulundurun. Her gruba bu bölgedeki ilgili küme damgasına tam erişim verin. Ardından her grubun üyeleri ilgili kümelere yönetici erişimine sahip olur.
AKS kümesi erişimini Microsoft Entra ID ile yönetme hakkında daha fazla bilgi için bkz . AKS Microsoft Entra tümleştirmesi.
Veri, durum ve önbellek
Genel olarak dağıtılmış bir AKS kümesi kullanırken, kümede çalıştırabilecek uygulamanın, işlemin veya diğer iş yüklerinin mimarisini göz önünde bulundurun. Durum tabanlı iş yükleri kümeler arasında yayılıyorsa, durum deposuna erişmeleri gerekiyor mu? Hata nedeniyle kümenin başka bir yerinde bir işlem yeniden oluşturulursa, iş yükü veya işlem bağımlı bir durum deposuna veya önbelleğe alma çözümüne erişmeye devam eder mi? Durum birçok şekilde depolanabilir, ancak tek bir Kubernetes kümesinde bile yönetmek karmaşıktır. Birden çok Kubernetes kümesi eklerken karmaşıklık artar. Bölgesel erişim ve karmaşıklık endişeleri nedeniyle, uygulamalarınızı genel olarak dağıtılmış bir durum deposu hizmeti kullanacak şekilde tasarlamayı göz önünde bulundurun.
Bu mimarinin tasarımı, durumla ilgili sorunlara yönelik yapılandırmayı içermez. Birden çok AKS kümesinde tek bir mantıksal uygulama çalıştırıyorsanız iş yükünüzün mimarisini Azure Cosmos DB gibi genel olarak dağıtılmış bir veri hizmeti kullanacak şekilde tasarlamayı göz önünde bulundurun. Azure Cosmos DB, veritabanınızın yerel çoğaltmalarından veri okumanızı ve yazmanızı sağlayan genel olarak dağıtılmış bir veritabanı sistemidir ve Cosmos DB hizmeti coğrafi çoğaltmayı sizin yerinize yönetir. Daha fazla bilgi için bkz . Azure Cosmos DB.
İş yükünüz bir önbelleğe alma çözümü kullanıyorsa, yük devretme olayları sırasında bile işlevsel kalmaları için önbelleğe alma hizmetlerinizin mimarisini oluşturduğunuzdan emin olun. İş yükünün önbellekle ilgili yük devretmeye dayanıklı olduğundan ve önbelleğe alma çözümlerinin tüm bölgesel AKS örneklerinde bulunduğundan emin olun.
Maliyet iyileştirme
Mimaride kullanılan hizmetlerin maliyetlerini tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Diğer en iyi yöntemler, Microsoft Azure İyi Tasarlanmış Çerçeve'nin Maliyet İyileştirme bölümünde ve Maliyetleri iyileştirme makalesindeki belirli maliyet iyileştirme yapılandırma seçeneklerinde açıklanmıştır.
Kubernetes'e özgü yapılar tarafından ayrıntılı küme altyapısı maliyet ayırması için AKS maliyet analizini etkinleştirmeyi göz önünde bulundurun.
Sonraki adımlar
- AKS kullanılabilirlik alanları
- Azure Kubernetes Fleet Manager
- Azure Container Registry’de coğrafi çoğaltma
- Azure eşleştirilmiş bölgeleri