Bu başvuru mimarisi, azure kubernetes service (AKS) kümesinin birden çok örneğini etkin/etkin ve yüksek oranda kullanılabilir bir yapılandırmada birden çok bölgede çalıştırmayı açıklar.
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.
Bu mimarinin başvuru uygulaması GitHub'da kullanılabilir.
Components
Çok bölgeli AKS başvuru mimarisinde birçok bileşen ve Azure hizmeti kullanılır. Yalnızca bu çok kümeli mimariye özgü bileşenler aşağıda listelenmiştir. Kalanlar için AKS Temeli mimarisine başvurun.
- Birden çok küme / birden çok bölge Her birinin ayrı bir Azure bölgesinde 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ölge başına merkez-uç ağı 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 deposu Azure Key Vault, AKS örneğine özgü hassas değerleri ve anahtarları ve bu bölgede bulunan destekleyici hizmetleri depolamak için her bölgede sağlanır.
- Azure Front Door 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 başvuru mimarisi için gerekli olan katman yedi genel yönlendirmeye olanak tanır.
- Log Analytics Bölgesel Log Analytics örnekleri 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.
- 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 başvuru mimarisi iki bulut tasarım deseni kullanır. Coğrafi Düğüm (coğrafi bölgeler),herhangi bir bölgenin herhangi bir isteğe hizmet sunabildiği coğrafi düğüm ve bir uygulamanın veya uygulama bileşeninin birden çok bağımsız kopyasının tek bir kaynaktan (dağıtım şablonu) dağıtıldığı Dağıtım DamgaLarı .
Coğrafi Düğüm deseni ile ilgili 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 kümesini yönetirken, birden çok aks örneği birden çok bölgeye dağıtılır. Bu örneklerin her biri damga olarak kabul edilir. Bölgesel bir hata veya kümeniz için daha fazla kapasite ve / veya bölgesel varlık ekleme gereksinimi durumunda, 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:
- Kod olarak altyapı gibi genelleştirilmiş yapılandırmaya olanak tanıyan damga damga tanımları için uygun teknolojiyi seçin
- Değişkenler veya parametre dosyaları gibi bir dağıtım giriş mekanizması kullanarak örneğe özgü değerler sağlama
- Esnek, tekrarlanabilir 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 üzerinde nasıl dengelenmiş olduğunu göz önünde bulundurun
- Damga pulları koleksiyona eklendikçe ve koleksiyondan kaldırıldıkçe kapasite ve maliyet endişelerini göz önünde bulundurun
- Görünürlük elde etmeyi ve/veya pul koleksiyonunu tek bir birim olarak izlemeyi göz önünde bulundurun.
Bu öğelerin her biri, bu başvuru mimarisinin aşağıdaki bölümlerindeki belirli yönergelerle ayrıntılı olarak açıklanmıştır.
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 örneklerini ekleyerek veya kaldırarak ölçeği genişletme ve daraltma stratejilerini göz önünde bulundurmanız gerekir. Tasarım, dağıtım ve yapılandırma planınızın bölgesel hataları veya diğer yaygın senaryoları hesaba eklemesini istersiniz.
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 bağlı olmayan 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 yapılandırmayı kaçırma fırsatını açar. Ayrıca, portalı kullanan birçok kümenin dağıtımı ve yapılandırması, bir veya daha fazla mühendisin odaklanmasını gerektiren zamanında bir işlemdir. 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.
Birçok AKS örneğiyle çalışırken, ve Azure Resource Manager şablonları, Bicep şablonları veya Terraform yapılandırmaları gibi kod çözümleri olarak altyapıyı göz önünde bulundurmanızı öneririz. Kod olarak altyapı çözümleri otomatik, ölçeklenebilir ve bir kez etkili bir dağıtım çözümü sağlar. Bu başvuru mimarisi, çözüm paylaşılan hizmetleri için bir ARM Şablonu ve ardından AKS kümeleri + bölgesel hizmetler için başka bir şablon içerir. 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ölgesel değerler ile 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. Statik/sabit sayıda AKS örneğinin dağıtılması gibi bazı durumlarda, kod olarak altyapının ek yükü avantajlardan daha ağır basabilir. Bu durumlarda, komut satırı araçları gibi daha kesin bir yaklaşım kullanmak, hatta el ile bir yaklaşım kullanmak sorun değildir.
Küme dağıtımı
Küme damgası tanımı tanımlandıktan sonra, tek tek veya birden çok damga pulu ö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
- Kod/dağıtım kaynağı denetimi ile tümleştirme
- Dağıtım geçmişi ve günlüğe kaydetme
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. Başvuru uygulamasında her bölge, GitHub Action iş akışı içinde (örnek) tek bir adım olarak dağıtılır. Bu yapılandırma, her küme örneğinin dağıtım işlem hattı içinde açıkça tanımlanmasıyla 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 mantık kullanmaktı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, bir küme damgasının dağıtım işlem hattından kaldırılması, bunun da kullanımdan kaldırılmasını sağlamaz. Dağıtım çözümünüz ve yapılandırmanıza bağlı olarak, AKS örneklerinin uygun şekilde kullanımdan kaldırıldığından emin olmak için ek bir adıma ihtiyacınız olabilir.
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 kullanıma alındığından, bir Kubernetes kümesine yapılandırma uygulamak için otomatik yöntemler kullanmayı göz önünde bulundurun. 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. Bu uygulama, kümeler dağıtıldıktan hemen sonra ve otomatik olarak kümelere önyüklemeyi etkinleştirmek için AKS için Flux uzantısını kullanır.
GitOps, AKS temel başvuru mimarisinde daha ayrıntılı olarak anlatılmıştır. Buradaki önemli nokta, yapılandırma için GitOps tabanlı bir yaklaşım kullanmanın, her Kubernetes örneğinin benzer şekilde özel bir çaba olmadan yapılandırılmasına yardımcı olmasıdır. Filonuzun büyüklüğü büyüdükçe bu 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. özellikle Azure İlkesi ilkelerden yararlanmak, 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 ve uyumsuzluğa görünürlük elde etmek için Denetim modunda kısıtlayıcı girişimi atadığında Azure İlkesi bu başvuru uygulamasında etkinleştirilir. Uygulama, yerleşik girişimlerin parçası olmayan daha fazla ilke de ayarlar. 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. Bu mimariyle ilişkili başvuru uygulaması, her AKS kümesinin dağıtıldığı kaynak grubuna ilke atamak için bir ARM şablonu kullanır. 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 ve/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 ilkeler bir yönetim grubuna veya aboneliğe uygulanabilir
- Her bölgesel kümenin kendi kaynak grubuna yerleştirilmesi, kaynak grubuna bölgeye özgü ilkelerin uygulanmasına olanak tanır
İ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 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 Podları (bölgesel)
Kubernetes dağıtım nesnesi, bir podun (ReplicaSet) birden çok çoğaltmasını oluşturmak için kullanılır. Biri kullanılamıyorsa, trafik kalan trafik arasında yönlendirilir. Kubernetes ReplicaSet, belirtilen sayıda çoğaltmayı çalışır durumda tutmaya çalışır. Bir örnek kapanırsa yeni bir örnek yeniden oluşturulmalıdır. Son olarak, 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.
Uygulama Podları (genel)
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 örneği tüm trafiği kalan iyi durumdaki bölgelere yönlendirir. Bu bölgelerdeki Kubernetes kümeleri ve podları isteklere hizmet etmeye devam edecektir.
Kalan kümeye yönelik artan trafiği / istekleri telafi etmek için bu duruma dikkat edin. Dikkate alınması gereken birkaç şey:
- 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, ani trafik yükü olan tüm Pod IP'lerini destekleyebilecek 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.
Kubernetes düğüm havuzları (bölgesel)
Örneğin, güç tek bir Azure sunucu rafı için kullanılamaz hale gelirse, işlem kaynaklarında bazen yerelleştirilmiş hata oluşabilir. AKS düğümlerinizi tek nokta bölgesel hata haline getirmekten korumak için Azure Kullanılabilirlik alanlarını kullanın. Kullanılabilirlik alanlarının kullanılması, belirli bir kullanılabilirlik alanındaki AKS düğümlerinin başka bir kullanılabilirlik alanında tanımlananlardan fiziksel olarak ayrılmasını sağlar.
Daha fazla bilgi için bkz . AKS ve Azure kullanılabilirlik alanları.
Kubernetes düğüm havuzları (genel)
Tam bir bölgesel hata durumunda Azure Front Door trafiği kalan ve iyi durumdaki bölgelere yönlendirir. Yine, kalan kümeye yönelik artan trafiği / istekleri telafi etmek için bu duruma dikkat edin.
Daha fazla bilgi için bkz . Azure Front Door.
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:
- Merkez-uç sanal ağlarının eşlendiği her bölgesel AKS örneği için bir merkez-uç uygulayın.
- 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 bölgesel bir hatayla karşılaşırsanız hem düğüm hem de pod ölçeklendirme işlemleri için daha fazla IP adresi 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 / 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 örneğine çözümlenen bir etki alanı adına (gibi
https://contoso-web.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 örneği isteği WAF ilkelerine göre doğrular, en hızlı arka ucu seçer (sistem durumuna ve gecikme süresine göre) ve arka uç IP adresini (Azure Uygulaması lication Gateway örneği) çözümlemek için genel DNS kullanır.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 ve Azure Front Door tarafından şifrelenir. 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 yalnızca Front Door örneğinden gelen trafiği kabul etmesini sağlamak için Front Door to arka uç
X-Azure-FDIDüst bilgisini 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 başvuru mimarisinin odak noktası, birden çok Azure bölgesine yayılmış birden çok Kubernetes örneğine sahip olmak olsa da, tüm örneklerde bazı paylaşılan kaynakların olması mantıklıdır. Aks çok bölgeli başvuru uygulaması, tüm paylaşılan kaynakları dağıtmak için tek bir ARM şablonu ve ardından her bölgesel damgayı dağıtmak için başka bir şablon kullanı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 (çekme) sağlamak için bu başvuru mimarisinde kullanılır. Ç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ölgede bir kapsayıcı kayıt defterini konumlandırmak, ağ kapatma işlemlerine olanak tanıyarak hızlı ve güvenilir görüntü katmanı aktarımları sağlar. Bölgesel hizmetler kullanılamadığında kullanılabilirlik sağlamak için birden çok görüntü hizmeti uç noktası olması. Azure Container Registries coğrafi çoğaltma işlevini kullanmak, birden çok bölgeye çoğaltılan bir Container Registry örneğini yönetmenize olanak tanır.
AKS çok bölgeli başvuru uygulaması, bu örneğin her küme bölgesine tek bir Container Registry örneği ve çoğaltmaları oluşturmuştur. 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 ACR çoğaltmasını gösteren görüntü.
Küme Erişimi
Her AKS örneği, Azure Container Registry'den görüntü katmanlarını çekmek için erişim gerektirir. Azure Container Registry'ye erişim sağlamanın birden çok yolu vardır; Bu başvuru mimarisi, her küme için bir Azure Yönetilen Kimliği kullanır ve bu kimlik daha sonra Container Registry örneğinde AcrPull rolü verilir. Kapsayıcı Kayıt Defteri erişimi için Yönetilen Kimlikleri kullanma hakkında daha fazla bilgi ve öneri için AKS temel başvuru mimarisine bakın.
Bu yapılandırma, her yeni damga dağıtıldığında yeni AKS örneğine erişim verilmesi için küme damgası ARM şablonunda tanımlanır. Container Registry paylaşılan bir kaynak olduğundan, dağıtım damgası şablonunuzun Kapsayıcı Kayıt Defteri'nin kaynak kimliğini kullanıp gerekli ayrıntıları kullanabildiğ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 Kapsayıcı Analizler tarafından da toplanabilir ve verileri Prometheus için Azure İzleyici yönetilen hizmetine veya Azure İzleyici Günlüklerine gönderebilirsiniz.
Aks denetim düzlemi bileşenlerinden kaynak günlüklerini toplayıp analiz etmek ve Log Analytics çalışma alanına iletmek için AKS kümesi tanılama ayarlarınızı da yapılandırabilirsiniz.
AKS Daha fazla bilgi için bkz . AKS temel başvuru mimarisi.
Bu başvuru mimarisi gibi bölgeler arası bir uygulama için izleme göz önünde bulundurulduğunda, her damga pulu arasındaki bağlamayı göz önünde bulundurmak önemlidir. Bu durumda, her damgayı tek bir birimin (bölgesel küme) bir bileşeni olarak düşünün. Çok bölgeli AKS başvuru uygulaması, her Kubernetes kümesi tarafından paylaşılan tek bir Log Analytics çalışma alanını kullanır. Diğer paylaşılan kaynaklarda olduğu gibi, tek Log Analytics çalışma alanı hakkındaki bilgileri kullanmak ve her kümeyi buna bağlamak için bölgesel damganızı tanımlayın.
Her bölgesel küme tek bir Log Analytics çalışma alanına tanılama günlükleri yaydığına göre, bu veriler ve kaynak ölçümleri, genel kümenin tamamını temsil eden raporları ve panoları daha kolay oluşturmak için kullanılabilir.
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, her ikisi de bu başvuru mimarisi için gerekli olan katman yedi genel yönlendirmeye olanak tanır.
Küme yapılandırması
Bölgesel AKS örnekleri eklendikçe, Kubernetes kümesiyle birlikte dağıtılan Application Gateway'in düzgün yönlendirme için Front Door arka ucu olarak kaydedilmesi gerekir. 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çlarla yönetilebilir. Dahil edilen başvuru uygulamaları dağıtım işlem hattı, bu işlem için ayrı bir Azure CLI adımı kullanır.
Sertifikalar
Front Door, Geliştirme/Test ortamlarında bile otomatik olarak imzalanan sertifikaları desteklemez. HTTPS trafiğini etkinleştirmek için bir sertifika yetkilisi (CA) tarafından imzalanan TLS/SSL sertifikanızı oluşturmanız gerekir. Başvuru uygulaması, Let's Encrypt Authority X3 sertifikası oluşturmak için Certbot kullanır. Bir üretim kümesi planlarken, TLS sertifikaları temini için kuruluşunuzun tercih edilen yöntemini kullanın.
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.
Küme erişimi ve kimliği
AKS temel başvuru mimarisinde açıklandığı gibi, kümelerin erişim kimliği sağlayıcısı olarak Microsoft Entra Id kullanılması önerilir. 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 Azure Dizin Grubu 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.
Dahil edilen başvuru uygulamasıyla, yönetici erişimi için iki Microsoft Entra grubu oluşturulur. Bu gruplar, dağıtım parametresi dosyası kullanılarak küme damgası dağıtım zamanında belirtilir. Her grubun üyeleri ilgili küme damgasına tam erişime sahiptir.
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
Aks örneklerinin genel olarak dağıtılmış bir kümesini 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ükü kümeye yayıldığı için durum deposuna erişmesi gerekecek mi? Hata nedeniyle kümenin başka bir yerinde bir işlem yeniden oluşturulursa, iş yükü veya işlem bağımlı durum deposuna veya önbelleğe alma çözümüne erişmeye devam edecek mi? Durum birçok yolla elde edilebilir; ancak, tek bir Kubernetes kümesinde karmaşık olabilir. Birden çok kümelenmiş Kubernetes örneğine 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.
Çok kümeli başvuru uygulaması, durumla ilgili endişeler için bir tanıtım veya yapılandırma içermez. Uygulamaları kümelenmiş AKS örnekleri arasında ç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 küresel olarak dağıtılan ve veritabanınızın yerel çoğaltmalarından veri okumanıza ve yazmanıza olanak tanıyan bir veritabanı sistemidir. Daha fazla bilgi için bkz . Azure Cosmos DB.
İş yükünüz bir önbelleğe alma çözümü kullanıyorsa, önbelleğe alma hizmetlerinin işlevsel kalması için mimarisinin oluşturulmuş olduğundan emin olun. Bunu yapmak için iş 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