Bu başvuru mimarisi, bir Azure Kubernetes hizmeti (AKS) kümesinin birden çok bölgede etkin/etkin ve yüksek oranda kullanılabilir bir yapılandırmada nasıl çalıştırılacağını ayrıntılarıyla açıklamaktadır.
Bu mimari, aks temel mimarisiüzerinde oluşturulur ve Microsoft 'un aks altyapısı için önerilen başlangıç noktasıdır. aks taban çizgisi ayrıntıları, Azure Active Directory (Azure AD) pod kimliği, giriş ve çıkış kısıtlamaları, kaynak sınırları ve diğer güvenli aks altyapı yapılandırmalarına benzer özellikler altyapısal. Bu altyapısal ayrıntıları bu belgede ele alınmıyor. Çok bölgeli içeriğe geçmeden önce AKS taban çizgisini tanımanız önerilir.
bu mimarinin başvuru uygulamasına GitHubkullanılabilir.
Bileşenler
Birçok bileşen ve Azure hizmeti çok bölgeli AKS başvuru mimarisinde kullanılır. Yalnızca bu çok küme mimarisine benzersizlik olan bileşenler aşağıda listelenmiştir. Kalan için aks taban çizgisi mimarisinebaşvurun.
- Birden çok küme/birden çok bölge Her biri 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 bir bölgeye yönlendirilir.
- hub-bölge başına bağlı ağ Bölgesel bir hub-bağlı ağ çifti, her bölgesel AKS örneği için 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, bu bölgede bulunan AKS örneğine ve destekleyici hizmetlere özgü hassas değerleri ve anahtarları depolamak için her bölgede sağlanır.
- Azure ön kapısı Azure ön kapısı, her bir AKS kümesinin önünde bulunan bölgesel bir Azure Application Gateway örneğine yük dengelemek ve trafik yönlendirmek için kullanılır. Azure ön kapısı, bu başvuru mimarisi için gereken katman yedi küresel yönlendirmeye izin verir.
- 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 üzere 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 kapsayıcı kayıt defterinde saklanır. Bu mimaride, kümedeki tüm Kubernetes örnekleri için tek bir Azure Container Registry kullanılır. Azure Container Registry coğrafi çoğaltma, resimlerin seçili Azure bölgelerine çoğaltılmasını ve bir bölge kesinti yaşar olsa bile görüntülere devam eden erişim sağlamayı sağlar.
Tasarım desenleri
Bu başvuru mimarisi iki bulut tasarım deseni kullanır. Coğrafi düğüm (coğrafi), herhangi bir bölgenin herhangi bir istek ve bir uygulamanın ya da 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 deseninin konuları
Her bir AKS kümesinin dağıtılacağı bölgeleri seçerken, bölgeleri iş yükü tüketicisine veya müşterilerinize yakın şekilde düşünün. Ayrıca, eşleştirilmiş Azure bölgelerini kullanmayı göz önünde bulundurun. Eşleştirilmiş bölgeler, Azure bakımının nasıl gerçekleştirildiğini etkileyen aynı coğrafya içindeki iki bölgeden oluşur. Kümeniz iki bölgenin ötesinde ölçeklendirilirken, her bir AKS kümesi çifti için bölgesel Çift yerleştirme planlaması yapmaya devam edin. Alınan bölgeler hakkında daha fazla bilgi için bkz. Azure eşlenmiş bölgeler.
Her bölgede, AKS düğüm havuzlarındaki düğümler, çok sayıda kullanılabilirlik alanına yayılmaktadır ve bu nedenle sorunları önlemek için bu bölgeler arasında yer vardı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 bölgeleri hakkında daha fazla bilgi için bkz. aks kullanılabilirlik alanları.
Dağıtım damgası konuları
Çok bölgeli bir AKS kümesi yönetirken, birden çok bölge arasında birden fazla AKS örneği dağıtılır. Bu örneklerden her biri damga olarak kabul edilir. Bir bölgesel hata durumunda veya kümeniz için daha fazla kapasite ve/veya bölgesel varlık ekleme ihtiyacı varsa, 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ğıdaki noktaları göz önünde bulundurmanız önemlidir:
- Kod olarak altyapı gibi Genelleştirilmiş yapılandırmaya izin veren damga tanımı teknolojisini seçin
- Değişkenler veya parametre dosyaları gibi bir dağıtım giriş mekanizmasını kullanarak örneğe özgü değerler sağlama
- Esnek, yinelenebilir ve ıdempotent dağıtımına izin veren dağıtım araçlarını seçin
- Etkin/etkin damga yapılandırmasında trafiğin her bir damgada nasıl dengelendiği göz önünde bulundurun
- Düğüm damgaları eklendiğinde ve koleksiyondan kaldırıldığında kapasiteyi ve maliyet sorunlarını göz önünde bulundurun
- Damga koleksiyonunu tek bir birim olarak nasıl görünürlük ve/veya takip etmeyi düşünün
Bu öğelerin her biri, bu başvuru mimarisinin aşağıdaki bölümlerindeki belirli kılavuzlarla ayrıntılıdır.
Küme dağıtımı ve önyükleme
Yüksek oranda kullanılabilir ve coğrafi olarak dağıtılmış yapılandırmalarda birden fazla Kubernetes kümesi dağıtımında, her bir Kubernetes kümesinin toplamını, bağlantılı birim olarak göz önünde bulundurmak önemlidir. Her bir Kubernetes örneğinin mümkün olduğunca özdeş olmasını sağlamak için otomatik dağıtım ve yapılandırma için kod odaklı stratejiler geliştirmek isteyebilirsiniz. Ek Kubernetes örnekleri ekleyerek veya kaldırarak ölçeği genişletme ve içine alma stratejilerini düşünmek isteyeceksiniz. Bölgesel hata ile düşünmek isteyeceksiniz ve bir hatanın tüm ürünüdür 'ın dağıtım ve yapılandırma planınızda dengelendirilecek olmasını sağlayabilirsiniz.
Küme tanımı
Azure Kubernetes hizmet kümesi dağıtmak için çok sayıda seçeneğiniz vardır. Azure portal, Azure clı Azure PowerShell modülü, bireysel veya uyumsuz aks kümelerini dağıtmaya yönelik tüm seçeneklerdir. Ancak, bu araçlar, sıkı şekilde bağlanmış birçok AKS kümesi ile çalışırken zorluk sunabilir. Örneğin, Azure portal kullanılması, kaçırılmış adımlar veya kullanılamayan yapılandırma seçenekleri nedeniyle isabetsizlik yapılandırması fırsatını açar. Ayrıca, portalı kullanan birçok kümenin dağıtımı ve yapılandırılması, bir veya daha fazla mühendisin odaklanılmasını gerektiren zamanında bir işlemdir. Komut satırı araçlarını kullanarak yinelenebilir ve otomatikleştirilmiş bir işlem oluşturabileceğiniz gibi, ıdempotlik, dağıtım hatası denetimi ve hata kurtarma işlemleri sizin oluşturduğunuz betiklerdir.
Birçok AKS örneğiyle çalışırken, altyapıyı kod çözümleri olarak (örneğin, Azure Resource Manager şablonları, bicep şablonları veya Terkform yapılandırması) dikkate etmenizi öneririz. Kod çözümleri olarak altyapı otomatik, ölçeklenebilir ve ıdempotent dağıtım çözümü sağlar. Bu başvuru mimarisi, çözümler paylaşılan hizmetleri için bir ARM şablonu ve daha sonra AKS kümeleri + bölgesel hizmetler için bir ARM şablonu içerir. Altyapı kod olarak kullanıldığında, bir dağıtım damgası ağ, yetkilendirme ve tanılama gibi Genelleştirilmiş yapılandırmalara göre tanımlanabilir. Bir dağıtım parametre dosyası, bölgesel olarak belirtilen değerlerle birlikte etkinleştirilebilir. Bu yapılandırmayla, her bölgede neredeyse özdeş bir damgası dağıtmak için tek bir şablon kullanılabilir.
Kod varlıkları olarak altyapı geliştirme ve sürdürme maliyeti maliyetli olabilir. Bazı durumlarda (örneğin, bir statik/sabit sayıda AKS örneği dağıtıldığında) kod olarak altyapı yükü, avantajları engelleyebilir. Bu gibi durumlarda, komut satırı araçlarıyla veya hatta el ile yaklaşımda olduğu gibi daha fazla kesinlik kullanan bir yaklaşım kullanılması tamam.
Küme dağıtımı
Küme damgası tanımı tanımlandıktan sonra, tek tek veya birden çok damga örneği dağıtmak için çok sayıda seçeneğiniz vardır. önerimiz GitHub eylemler veya Azure Pipelines gibi modern sürekli tümleştirme teknolojisini kullanmaktır. Sürekli tümleştirme tabanlı dağıtım çözümlerinin avantajı şunlardır:
- Kod kullanılarak damgaların eklenmesine ve kaldırılmasına izin veren kod tabanlı dağıtımlar
- Tümleşik test özellikleri
- Tümleşik ortam ve hazırlama özellikleri
- Tümleşik gizli diziler yönetimi çözümleri
- Kod/dağıtım kaynak denetimiyle tümleştirme
- Dağıtım geçmişi ve günlüğe kaydetme
Genel kümeden yeni damgalar eklendiğinde veya kaldırıldığında, dağıtım işlem hattının yansıtacak şekilde güncelleştirilmesi gerekir. başvuru uygulamasında her bölge, bir GitHub eylem iş akışında (örnek)tek bir adım olarak dağıtılır. Bu yapılandırma, her küme örneğinin dağıtım ardışık düzeninde açık bir şekilde tanımlanması halinde basittir. Ancak, bu yapılandırma, dağıtımdan küme ekleme ve kaldırma konusunda bazı yönetim yükünü taşır.
Diğer bir seçenek, istenen konumların bir listesini ya da veri noktalarını belirten diğer noktaları temel alan kümeler oluşturmak için mantığın kullanılması olabilir. Örneğin, dağıtım işlem hattı istenen bölgelerin bir listesini içerebilir; işlem hattının içindeki bir adım daha sonra bu listede döngü, listede bulunan her bölgeye bir küme dağıtacağız. Bu yapılandırmanın dezavantajı, dağıtım genelleştirmesinin karmaşıklıksıdır ve her küme damgasının dağıtım ardışık düzeninde açık bir şekilde ayrıntılandırılmıştır. Pozitif avantaj, işlem hattından küme damgaları ekleme veya kaldırma, istenen bölgelerin listesine basit bir güncelleştirme haline gelir.
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ı gerektiğine dikkat edin. Dağıtım teknolojunuza ve yapılandırmanıza bağlı olarak, AKS örneklerinin uygun şekilde Kullanımdan kaldırılmış olduğundan emin olmak için ek bir adım gerekebilir.
Küme önyükleme
Her bir 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ı göz önünde bulundurmanız gerekir.
Dağıtıma benzer şekilde, bu yapılandırma birkaç Kubernetes örneğine el ile yönetilmesi zor hale gelebilir. Bunun yerine, uygun ölçekte yapılandırma ve ilke için aşağıdaki seçenekleri göz önünde bulundurun.
Giüstler
Kubcertağları bileşenlerini el ile yapılandırmak yerine, bu yapılandırmaların bir kaynak depoya iade edileceği şekilde bir Kubernetes kümesine yapılandırma uygulamak için otomatik araçları kullanmayı düşünün. Bu süreç genellikle giar olarak adlandırılır ve Kubernetes için popüler giar çözümleri Flox ve argo CD 'si içerir.
Gilar, aks temel başvuru mimarisindedaha ayrıntılı bir şekilde ayrıntılıdır. Buradaki önemli notta, her bir Kubernetes örneğinin bir beslik efor olmadan aynı şekilde yapılandırıldığından emin olmak için bir büyük harf tabanlı yaklaşım kullanılması.
Azure İlkesi
Birden çok Kubernetes örneği eklendikçe, ilke odaklı idare, uyumluluk ve yapılandırmanın avantajı artar. Bu durumda, Azure Ilkeleri, ilke kullanılarak küme denetimi için merkezi ve ölçeklenebilir bir yöntem sağlar. AKS ilkelerinin avantajı, aks temel başvuru mimarisindeayrıntılı olarak açıklanmıştır.
AKS kümeleri oluşturulduğunda bu başvuru uygulamasında Azure Ilkesi etkinleştirilir ve uyumlu olmayan bir görünürlük elde etmek için denetim modunda kısıtlayıcı girişimi atar. Uygulama, yerleşik girişimlerin parçası olmayan ek ilkeler de ayarlar. Bu ilkeler reddetme modunda ayarlanır. Örneğin, kümede yalnızca onaylanan kapsayıcı görüntülerinin çalıştırılmasını sağlamak için bir ilke vardır. Kendi özel girişimlerinizi oluşturmayı düşünün. İş yükünüz için geçerli olan ilkeleri tek bir atamaya birleştirin.
İlke kapsamı, her ilke ve ilke girişiminin hedefini ifade eder. Bu mimariye ilişkin başvuru uygulama, her bir AKS kümesinin dağıtıldığı kaynak grubuna ilke atamak için bir ARM şablonu kullanır. Genel kümenin parmak izi büyüdükçe, bu çok sayıda yinelenen ilkeye neden olur. Ayrıca, ilkelerin bir abonelik kapsamındaki tüm AKS kümelerine ve/veya bir yönetim grubu altında bulunan tüm aboneliklere uygulanmasına imkan tanıyan bir Azure aboneliğine veya Azure yönetim grubuna ilke kapsamı da atayabilirsiniz.
Birden çok AKS kümesi için ilke tasarlarken aşağıdaki öğeleri göz önünde bulundurun:
- Tüm AKS örneklerine Global olarak uygulanması gereken ilkeler bir yönetim grubuna veya aboneliğine uygulanabilir
- Her bölgesel kümeyi kendi kaynak grubuna yerleştirmek, kaynak grubuna uygulanan bölgeye özgü ilkelerin yapılmasına izin verir
İlke yönetimi stratejisi oluşturmaya yardımcı olacak bir malzeme için bulut benimseme çerçeveleri yönetim grubu ve abonelik organizasyonu ' na bakın.
İş yükü dağıtımı
AKS örnek yapılandırmasına ek olarak, her bir bölge örneğine veya damgasına dağıtılan iş yükünü göz önünde bulundurun. Dağıtım çözümleri veya işlem hatları, her bir bölgesel damgaya uyum sağlamak için yapılandırma gerektirir. Genel kümeye ek damgalar eklendikçe, dağıtım işleminin yeni bölgesel örneklere uyum sağlayacak kadar genişletilmesi veya esnek olması gerekir.
İş yükü dağıtımı için planlama yaparken aşağıdaki öğeleri göz önünde bulundurun.
- Birden çok küme damgalarının tamamında tek bir dağıtım yapılandırmasının kullanılabilir olmasını sağlamak için, bir Held grafiği gibi dağıtımı genelleştirin.
- Tüm küme damgaları genelinde iş yükünü dağıtmak için yapılandırılmış tek bir sürekli dağıtım işlem hattı kullanın.
- Dağıtım parametreleri olarak damgaya özgü örnek ayrıntılarını sağlayın.
- Uygulama tanılama günlüğü ve dağıtılmış izlemenin uygulama genelinde Observability için nasıl yapılandırıldığını göz önünde bulundurun.
Kullanılabilirlik/yük devretme
Çok bölgeli bir Kubernetes mimarisi seçmek için önemli bir mosyon, hizmet kullanılabilirliğine yöneliktir. Diğer bir deyişle, bir hizmet veya hizmet bileşeni bir bölgede kullanılamaz hale gelirse trafik, hizmetin kullanılabilir olduğu bir bölgeye yönlendirilmelidir. Çok bölgeli bir mimari birçok farklı hata noktası içerir. Bu bölümde, bu olası hata noktalarının her biri açıklanmaktadır.
Uygulama pods (bölgesel)
Bir Kubernetes dağıtım nesnesi, Pod 'ın (ReplicaSet) birden çok çoğaltmasını oluşturmak için kullanılır. Bunlardan biri kullanılamıyorsa, trafik kalan aralarında yönlendirilir. Kubernetes ReplicaSet, belirtilen sayıda kopyayı tutmayı ve çalıştırmayı dener. Bir örnek kapalıysa, yeni bir örnek yeniden oluşturulmalıdır. Son olarak, bu, Pod 'da çalışan uygulamanın veya işlemin durumunu denetlemek için kullanılır. Hizmet uygun şekilde yanıt vermiyorsa, bu araştırma, Replicakümesini kaldırır ve bu da yeni bir örnek oluşturmak için çoğaltma kümesini zorlar.
Daha fazla bilgi için bkz. Kubernetes ReplicaSet.
Uygulama pods (genel)
Tüm bölge kullanılamaz hale geldiğinde, kümedeki FID 'ler isteklere yönelik olarak artık kullanılabilir olmaz. Bu durumda, Azure ön kapı örneği tüm trafiği kalan sağlıklı bölgelere yönlendirir. Bu bölgelerdeki Kubernetes kümeleri ve düğüm istekleri istemcilere sunmaya devam edecektir.
Kalan kümeye gelen trafiği/istekleri daha fazla dengelemek için bu duruma dikkat edin. Göz önünde bulundurulması gereken birkaç nokta vardır:
- Ağ ve işlem kaynaklarının, bölge yük devretmesi nedeniyle trafiğin ani artışına artışlarını devralarak kadar doğru boyutlandırıldığından emin olun. Örneğin, Azure CNı kullanırken, bir spıked trafik yüküne sahip tüm Pod IP 'Leri destekleyebilen bir alt ağa sahip olduğunuzdan emin olun.
- Artan bölgesel talebe yönelik telafi sağlamak için pod çoğaltma sayısını artırmak üzere yatay Pod otomatik Scaler 'ı kullanın.
- AKS kümesi otomatik Scaler ' ını kullanarak Kubernetes örnek düğümü sayısını artan bölge taleplerini dengelemek için artırın.
Daha fazla bilgi için bkz. yatay Pod otomatik Scaler ve aks kümesi otomatik Scaler.
Kubernetes düğüm havuzları (bölgesel)
Örneğin, bir Azure Server 'ın tek bir rafı tarafından kullanılamaz hale gelirse, örneğin işlem kaynakları için yerelleştirilmiş bir hata meydana gelebilir. AKS düğümlerinizin tek nokta bölgesel bir hata haline gelmesini sağlamak için Azure kullanılabilirlik bölgelerini kullanın. Kullanılabilirlik bölgelerini kullanmak belirli bir kullanılabilirlik bölgesindeki AKS düğümlerinin, başka bir kullanılabilirlik alanında tanımlananlardan fiziksel olarak ayrılması sağlar.
Daha fazla bilgi için bkz. aks ve Azure kullanılabilirlik alanları.
Kubernetes düğüm havuzları (genel)
Tüm bölgesel bir hatada, Azure ön kapısının trafiği kalan ve sağlıklı bölgelere yönlendirmesi gerekir. Bu durumda, kalan kümeye gelen trafiği/istekleri daha fazla dengelemek için bu duruma dikkat edin.
Daha fazla bilgi için bkz. Azure ön kapısı.
Ağ topolojisi
AKS temel başvuru mimarisine benzer şekilde, Bu mimaride hub-ışınsal ağ topolojisi kullanılmaktadır. Aks taban çizgisi başvuru mimarisindebelirtilen noktalara ek olarak, aşağıdakileri göz önünde bulundurun:
- Hub-bağlı sanal ağlarının eşlenme olduğu her bölge AKS örneği için bir hub-bağlı bileşen uygulayın.
- Tüm giden trafiği her bölgesel hub ağında bulunan bir Azure Güvenlik Duvarı örneğiyle yönlendirin. Tüm bölgelerde güvenlik duvarı ilkelerini yönetmek için Azure Güvenlik Duvarı Yöneticisi ilkelerini kullanın.
- Aks taban çizgisi başvuru mimarisinde bulunan IP boyutlandırmayı ve bölgesel hata durumunda hem düğüm hem de Pod ölçek işlemleri IÇIN ek IP adreslerine izin ver ' i izleyin.
Trafik yönetimi
AKS temel başvuru mimarisi sayesinde, iş yükü trafiği doğrudan bir Azure Application Gateway örneğine yönlendirilir ve ardından arka uç yük dengeleyici/AKS giriş kaynaklarına iletilir. Birden çok küme ile çalışırken, istemci istekleri Azure Application Gateway örneğine yönlendiren bir Azure ön kapı örneği aracılığıyla yönlendirilir.
Kullanıcı, https://contoso-web.azurefd.net Azure ön kapı örneğine çözümlenen bir etki alanı adına (ör.) bir istek gönderir. Bu istek, Azure ön kapısının tüm alt etki alanları için verilen bir joker (*. azurefd.net) sertifikası ile şifrelenir. Azure ön kapı örneği, WAF ilkelerine karşı isteği doğrular, en hızlı arka ucu seçer (sağlık ve gecikme süresine göre) ve arka uç IP adresini (Azure Application Gateway örneği) çözümlemek için ortak DNS kullanır.
Ön kapı, isteği bölge damgası için giriş noktası görevi gören seçili uygun Application Gateway örneğine iletir. Trafik İnternet üzerinden akar ve Azure ön kapısına göre şifrelenir. Application Gateway örneğinin yalnızca ön kapı örneğinden gelen trafiği kabul ettiğinden emin olmak için bir yöntem düşünün. Bir yaklaşım, Application Gateway 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. Kaynak özelliği, bir Azure kaynağının IP adreslerini gösteren yerleşik bir hizmet etiketi ayarlamanıza olanak sağlar. Bu soyutlama, kuralı yapılandırmayı ve bakımını ve IP adreslerini izlemeyi kolaylaştırır. Ayrıca,
X-Azure-FDIDApplication Gateway örneğinin yalnızca ön kapı örneğinden gelen trafiği kabul ettiğinden emin olmak için arka uç üst bilgisini kullanarak ön kapıyı kullanın. Ön kapı üstbilgileri hakkında daha fazla bilgi için bkz. Azure ön KAPıDA http üstbilgileri Için protokol desteği.
Paylaşılan kaynak konuları
Bu başvuru mimarisinin odaklanmasına karşın birden çok Azure bölgesinde yayılan birden fazla Kubernetes örneği bulunduğundan, tüm örneklerde bazı paylaşılan kaynakların olması mantıklı olur. Tüm paylaşılan kaynakları dağıtmak için tek bir ARM şablonu kullanan AKS çok bölgeli başvuru, her bir bölgesel damgayı dağıtmak için de başka bir. Bu bölümde, her bir paylaşılan kaynak ve birden çok AKS örneği arasında kullanımı için önemli noktalar ayrıntılı olarak ele alınmalıdır.
Container Registry
Azure Container Registry, kapsayıcı görüntüsü 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
Bir AKS kümesinin dağıtıldığı her bölgedeki bir kapsayıcı kayıt defterinin konumlandırılması, ağ kapatma işlemlerine izin verir ve bu da hızlı, güvenilir görüntü katmanı aktarımlarını etkinleştirir. Aynı zamanda birden çok görüntü hizmeti uç noktası olması, olay bölgesel Hizmetleri 'nde de kullanılabilirlik sağlar. Azure Container Registry 'nin coğrafi çoğaltma işlevlerini kullanma, birden çok bölgeye çoğaltılan bir Container Registry örneğini yönetmenizi sağlar.
AKS çok bölgeli başvuru uygulamasının her bir küme bölgesinde tek bir Container Registry örneği ve bu örneğin çoğaltmaları oluşturulmuş. Azure Container Registry çoğaltma hakkında daha fazla bilgi için bkz. Azure Container Registry coğrafi çoğaltma.
Azure portal içinden birden fazla ACR çoğaltmasını gösteren resim.
Küme Erişimi
Her bir AKS örneği, Azure Container Registry görüntü katmanlarını çekme için erişim gerektirir. Azure Container Registry erişim oluşturmak için birden çok yol vardır; Bu başvuru mimarisi, her küme için bir Azure yönetilen kimliği kullanır ve bu da Container Registry örneğinde AcrPull rolü verilir. Container Registry erişim için Yönetilen kimlikler kullanma hakkında daha fazla bilgi ve öneriler için bkz. aks temel başvuru mimarisi.
Bu yapılandırma, küme damgası ARM şablonunda tanımlanmıştır, böylece her yeni damga dağıtıldığında yeni AKS örneğine erişim verilir. Container Registry paylaşılan bir kaynak olduğundan, dağıtım damga şablonunuzun, bu durumda Container Registry kaynak KIMLIĞI olan gerekli ayrıntıları tükettiğinden ve bu bilgileri kullanabildiğinden emin olun.
Log Analytics ve Azure Izleyici
Olayları gerçek zamanlı olarak görüntüleyebilmeniz için, kapsayıcılar için Azure Izleyici özelliği, izleme ve günlüğe kaydetme için önerilen araçtır. Azure Izleyici, tanılama günlüklerini depolamak için bir Log Analytics çalışma alanı kullanır. Daha fazla bilgi için bkz. aks temel başvuru mimarisi .
Bu başvuru mimarisi gibi bir çapraz bölge uygulamasının izlenmesini değerlendirirken, her damga arasındaki kuponu göz önünde bulundurmanız ö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 uygulamaları, her bir Kubernetes kümesi tarafından paylaşılan tek bir Log Analytics çalışma alanını kullanır. Diğer paylaşılan kaynaklarla olduğu gibi, tek bir Log Analytics çalışma alanı hakkında bilgi edinmek ve her kümeyi buna bağlamak için bölgesel damgalarınızı tanımlayın.
Her bölgesel küme, tanılama günlüklerini tek bir Log Analytics çalışma alanına bırakmıştır. bu veriler, kaynak ölçümleriyle birlikte, genel kümeyi tamamen temsil eden raporlar ve panolar daha kolay bir şekilde oluşturmak için kullanılabilir.
Azure Front Door
Azure ön kapısı, her bir AKS kümesine yük dengelemek ve trafik yönlendirmek için kullanılır. Azure ön kapısı, bu başvuru mimarisi için gereken katman yedi küresel yönlendirmeye izin verir.
Küme yapılandırması
Bölgesel AKS örnekleri eklendikçe, Kubernetes kümesi ile birlikte dağıtılan Application Gateway, doğru yönlendirme için bir ön kapı arka ucu olarak kaydedilmeleri gerekir. Bu işlem, kod varlıkları olarak altyapınızda bir güncelleştirme yapılmasını gerektirir. Alternatif olarak, bu işlem dağıtım yapılandırmasından bağlanabilir ve Azure CLı gibi araçlarla yönetilebilir. Dahil edilen başvuru uygulamaları dağıtım işlem hattı, bu işlem için farklı bir Azure CLı adımını kullanır.
Sertifikalar
Ön kapı geliştirme ve 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 uygulama, bir Izin yetkilisi x3 sertifikası oluşturmak için Certbot kullanır. Bir üretim kümesi için planlama yaparken, kuruluşunuzun TLS sertifikaları için tercih ettiğiniz yöntemi kullanın.
Ön kapı tarafından desteklenen diğer CA 'Lar hakkında daha fazla bilgi için bkz. Azure ön kapıda özel https 'yi etkinleştirmek Için Izin verilen sertifika yetkilileri.
Küme erişimi ve kimliği
aks taban çizgisi başvuru mimarisindeanlatıldığı gibi, Azure Active Directory kümelerin erişim kimlik sağlayıcısı olarak kullanılması önerilir. Azure Active Directory 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çeneklere şunlar dahildir:
- Ü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 ihtiyaçları sağlar; Ancak, herhangi bir grup üyesine önemli bir ayrıcalık verir.
- Tek bir küme örneğindeki nesnelere erişim vermek için kullanılan her bir 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 bunu bir Azure dizin grubu yapısıyla ilişkilendirin. Bu seçenekle, yönetim ek yükü önemli ölçüde artar; Ancak, her kümede değil, ad alanları ve Kubernetes API 'LERI için ayrıntılı erişim sağlar.
dahil edilen başvuru uygulamasıyla, yönetici erişimi için iki AAD 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 Azure Active Directory ile yönetme hakkında daha fazla bilgi için bkz. aks Azure AD tümleştirmesi.
Veri, durum ve önbellek
Küresel olarak dağıtılan AKS örneklerinin bir kümesini kullanırken, küme genelinde çalışabilecek uygulama, işlem veya diğer iş yüklerinin mimarisini göz önünde bulundurun. Durum tabanlı iş yükü küme genelinde yayıldığında, bir durum deposuna erişmesi gerekecektir mi? Bir işlem başarısızlık nedeniyle kümede başka bir yerde yeniden oluşturulduğunda, iş yükü veya işlem bağımlı durum deposuna veya önbelleğe alma çözümüne erişmeye devam eder mi? Durum, birçok şekilde sağlanabilir; Ancak, tek bir Kubernetes kümesinde karmaşık olabilir. Birden çok kümelenmiş Kubernetes örneğine eklenirken karmaşıklık artar. Bölgesel erişim ve karmaşıklık sorunları nedeniyle uygulamalarınızı genel olarak dağıtılmış bir durum depolama hizmeti kullanmak üzere mimari olarak düşünün.
Birden çok küme başvuru uygulamasına durum sorunları için bir tanıtım veya yapılandırma dahil değildir. kümelenmiş aks örnekleri genelinde uygulamalar çalıştırıyorsanız, Azure Cosmos DB gibi küresel olarak dağıtılan bir veri hizmetini kullanmak için iş yükünü mimariye göre tasarlayarak düşünün. 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ünü kullanıyorsa, önbelleğe alma hizmetleri 'nin çalışır durumda kalması için etkinleştirildiğinden emin olun. Bunu yapmak için, iş yükünün önbellekte ilişkili yük devretmeyle dayanıklı olduğundan ve tüm bölgesel AKS örneklerinde önbelleğe alma çözümlerinin bulunduğundan emin olun.
Maliyet yönetimi
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 Well-Architected Framework 'ün maliyet iyileştirme bölümünde açıklanmaktadır.