Bu makale, AKS kümesini üretim ortamına dağıtmak için önerilen yapılandırmaların kapsamlı bir gözden geçirilmesini sağlayan AKS Baseline mimarisinin bir uzantısı olarak düşünülmesi amaçlanır. Bu makalenin odak noktası, AKS'de Windows kapsayıcıları dağıtmayla ilgili rehberlik sağlamaktır. Bu nedenle, bu makale AKS üzerinde Windows dağıtımına özgü yapılandırmalara odaklanır ve burada zaten açıklanan yapılandırmalar için AKS Temeli belgelerine geri dönmeniz gerekir.
Ağ tasarımı
Bu mimaride kullanılan ağ tasarımı AKS Baseline mimarisinde kullanılan tasarımı temel alır ve bu nedenle aşağıdaki değişiklikler dışında tüm temel bileşenleri bu tasarımla paylaşır.
- Windows tabanlı iş yüklerini desteklemek için Active Directory etki alanı denetleyicileri eklendi.
- Bu mimarideki giriş çözümü, AKS Baseline mimarisinde kullanılan Azure Uygulaması Gateway yerine Azure Front Door (AFD) ve Microsoft Entra uygulama ara sunucusunu kullanır.
Not
Windows iş yüklerinin AKS'ye geçirilmesi genellikle büyük yeniden düzenleme çalışmalarını içermez ve bu nedenle iş yükleri, şirket içinde uygulanması nispeten kolay olan ancak Azure'da bir zorluk oluşturan özellikleri kullanıyor olabilir. Bir örnek, gMSA ve Kerberos kimlik doğrulaması kullanan bir uygulama olabilir. Bu yaygın bir kullanım örneğidir ve bu nedenle bu mimari, bu iş yüklerinin gereksinimlerini karşılayan bileşenlere yol açar. Özellikle, giriş yolunun bir parçası olarak AFD tarafından önlenen uygulama ara sunucusunu kullanma. İş yükünüzün bu desteğe ihtiyacı yoksa, giriş için AKS temelindeki yönergeleri izleyebilirsiniz.
Giriş tasarımı
Bileşenler:
- WAF ile Azure Front Door: AFD, AKS kümesinde barındırılan uygulamalar için genel kullanıma yönelik giriş noktasıdır. AFD Premium, iç uygulama trafiğini özel ağa kilitleyerek en yüksek güvenlik düzeyini sağlayan Özel Bağlantı kullanımına izin verdiğinden bu tasarımda kullanılır. Web Uygulaması Güvenlik Duvarı (WAF), yaygın web uygulaması açıklarına ve güvenlik açıklarına karşı koruma sağlar.
- Microsoft Entra uygulama ara sunucusu: Bu bileşen, AKS tarafından yönetilen iç yük dengeleyicinin önünde ikinci giriş noktası görevi görür. Kullanıcıların ön kimlik doğrulaması için Microsoft Entra Id etkindir ve yetkisiz IP aralıklarını (uygulama ara sunucusu, koşullu erişim ilkesiyle karşılaştırdığı kaynak istemci IP'sini görür) ve kullanıcıların siteye erişmesini önlemek için bir koşullu erişim ilkesi kullanır. WAF'yi destekleyen bir Azure hizmeti kullanırken Kerberos kimlik doğrulama isteklerini yönlendirmenin tek yolu budur. Uygulama Ara Sunucusu korumalı uygulamalara çoklu oturum açma erişimi sağlamanın ayrıntılı açıklaması için bkz. Uygulama Ara Sunucusu ile uygulamalarınızda çoklu oturum açma (SSO) için Kerberos Kısıtlanmış Temsili
- İç yük dengeleyici: AKS tarafından yönetilir. Bu yük dengeleyici, giriş denetleyicisini özel bir statik IP adresi aracılığıyla kullanıma sunar. Gelen HTTP isteklerini alan tek bir kişi noktası görevi görür.
- Bu mimaride küme içi giriş denetleyicisi (Nginx gibi) kullanılmaz.
Bu tasarımı uygulamak için AFD,uygulama bu hizmette yayımlandığında oluşturulan Uygulama Ara Sunucusu URL'sini kullanacak şekilde yapılandırılmalıdır. Bu yapılandırma, gelen trafiği ara sunucuya yönlendirir ve ön kimlik doğrulamasının gerçekleşmesine izin verir.
Not
İstemci kaynağı IP'sinin korunması desteklenmez, bu nedenle uygulama mimarlarının kaynak IP adresine bağımlı uygulamalar için bu mantığı küme dışından çıkarmak için alternatif ölçüler planlamaları gerekir.
Ağ topolojisi
Aşağıdaki diyagramda bu mimaride kullanılan merkez-uç ağ tasarımı gösterilmektedir.
Bu mimarinin bir Visio dosyasını indirin.
Düğüm havuzu topolojisi
Bu mimari üç düğüm havuzu kullanır: Linux çalıştıran bir sistem düğümü havuzu, Linux çalıştıran bir kullanıcı düğümü havuzu ve Windows çalıştıran bir kullanıcı düğümü havuzu. Windows ve Linux kullanıcı düğümü havuzları iş yükleri için kullanılırken, sistem düğümü havuzu CoreDNS gibi tüm sistem düzeyinde yapılandırmalar için kullanılır.
Giriş trafik akışı
- İstemci, etki alanı adına bir HTTPS isteği gönderir:
bicycle.contoso.com. Bu ad, Azure Front Door'un genel IP adresi için DNS A kaydıyla ilişkilendirilir. Bu trafik, istemci tarayıcısı ve ağ geçidi arasındaki trafiğin denetlenediğinden veya değiştirilemiyorsan emin olmak için şifrelenir. - Azure Front Door tümleşik bir web uygulaması güvenlik duvarına (WAF) sahiptir ve için
bicycle.contoso.comTLS el sıkışması anlaşması yaparak yalnızca güvenli şifrelemelere olanak sağlar. Azure Front Door Gateway, WAF inceleme kurallarını işlemek ve trafiği yapılandırılan arka uça ileden yönlendirme kurallarını yürütmek için gerekli olduğundan bir TLS sonlandırma noktasıdır. TLS sertifikası Azure Key Vault'ta depolanır. - AFD, kullanıcı isteğini Azure Uygulaması Lication Proxy'sine yönlendirir. AFD yalnızca HTTPS trafiğine izin verecek şekilde yapılandırılmıştır. Ön kimlik doğrulaması etkinse kullanıcının Microsoft Entra Id ile kimlik doğrulaması yapması gerekir.
- Uygulama Ara Sunucusu kullanıcıyı AKS yük dengeleyici aracılığıyla arka uç uygulama kapsayıcısına yönlendirir.
Not
Akıştaki her atlamada uçtan uca TLS trafiğini zorunlu kılabilir, ancak poddan poda trafiğin güvenliğini sağlamaya karar verirken performansı, gecikme süresini ve operasyonel etkiyi ölçmeyi göz önünde bulundurun. Uygun denetim düzlemi RBAC ve olgun Yazılım Geliştirme Yaşam Döngüsü uygulamalarıyla tek kiracılı kümelerin çoğunda, giriş denetleyicisine kadar şifrelemeyi zorlamak ve arka ucu bir Web Uygulaması Güvenlik Duvarı (WAF) ile korumak yeterlidir. Bu yapılandırma, iş yükü yönetimi ve ağ performansı üzerindeki etkileri en aza indirir. İş yükünüz ve uyumluluk gereksinimleriniz, TLS sonlandırma işlemini nerede gerçekleştireceğinize karar verecek.
Çıkış trafik akışı
AKS Temeli makalesinde bulunan tüm yönergeler burada Windows iş yükleri için ek bir öneriyle birlikte geçerlidir: Otomatik Windows Server güncelleştirmelerinden yararlanmak için, Azure Güvenlik Duvarı kural kümesinde gerekli FQDN'leri engellememelisiniz.
Not
Linux tabanlı ve Windows tabanlı iş yükleri için ayrı düğüm havuzları kullanmak, belirli bir iş yükünü dağıttığınızda iş yükü türüne göre uygun düğüm havuzuna dağıtıldığından emin olmak için bir düğüm seçici kullanılması gerekir.
IP adresi planlaması
Linux düğüm havuzlarına sahip AKS kümelerinden farklı olarak, Windows düğüm havuzlarına sahip AKS kümeleri Için Azure CNI gerekir. Azure CNI'nin kullanılması, bir pod'a Azure Sanal Ağ bir IP adresi atanmasına olanak tanır. Pod daha sonra azure Sanal Ağ aracılığıyla diğer tüm cihazlar gibi iletişim kurabilir. ExpressRoute veya VPN kullanarak diğer podlara, eşlenmiş ağlara veya şirket içi ağlara ya da Özel Bağlantı kullanarak diğer Azure hizmetlerine bağlanabilir.
AKS Temeli mimarisi makalesinde sağlanan IP adreslerini planlamayla ilgili tüm yönergeler burada geçerlidir ve bir öneri daha vardır: etki alanı denetleyicileriniz için ayrılmış bir alt ağ sağlamayı göz önünde bulundurun. Windows düğüm havuzuyla ilgili olarak, bunu diğer düğüm havuzlarından ayrı alt ağlar aracılığıyla mantıksal olarak ayırmanız önerilir.
Düğüm havuzu yükseltmesi
Windows düğümlerini yükseltme işlemi, Azure Kubernetes Service (AKS) düğümü görüntü yükseltme belgelerinde sağlanan yönergelerden farklı değildir, ancak yükseltme temponuzu planlamak için aşağıdaki zamanlama farklılıklarını göz önünde bulundurmanız gerekir.
Microsoft, düğümler için aylık olarak güncel düzeltme ekleri de dahil olmak üzere yeni Windows Server görüntüleri sağlar ve otomatik düzeltme eki uygulamaz veya güncelleştirme yapmaz. Bu nedenle düğümlerinizi bu zamanlamaya göre el ile veya program aracılığıyla güncelleştirmeniz gerekir. Zamanlamaya göre çalışan bir cron işi oluşturmak için GitHub Actions'ı kullanmak, aylık yükseltmeleri program aracılığıyla zamanlamanıza olanak tanır. Yukarıdaki bağlantılı belgelerde sağlanan kılavuz Linux düğümü işlemlerini yansıtır, ancak YAML dosyasını iki haftada bir değil aylık çalışacak şekilde ayarlayabilirsiniz. Ayrıca en son Windows Server görüntüsüne yükseltirken emin olmak için YAML dosyasındaki "runs-on" parametresini "windows-latest" olarak değiştirmeniz gerekir.
Ek yönergeler için çalışan düğümü düzeltme eki uygulama ve güncelleştirme ile ilgili AKS işleci kılavuzuna bakın.
Not
Düğüm ve düğüm havuzu yükseltmeleri gerçekleştirilmeden önce kümelerin yükseltilmesi gerekir. Yükseltmeyi gerçekleştirmek için Küme yükseltmeleri kılavuzunu izleyin.
İşlemle ilgili dikkat edilmesi gerekenler
Windows sunucu tabanlı görüntülerle ilişkili daha büyük görüntü boyutları, düğüm havuzunuzda uygun şekilde boyutlandırılmış işletim sistemi disklerinin dağıtımını gerektirir. Kısa ömürlü işletim sistemi disklerinin kullanılması Windows dahil olmak üzere tüm düğümler için hala önerilir, bu nedenle dağıtımınızı planlarken uymanız gereken boyut gereksinimlerini anladığınızdan emin olun.
Kimlik yönetimi
Windows kapsayıcıları etki alanına katılamaz, bu nedenle Active Directory kimlik doğrulaması ve yetkilendirmesi gerekiyorsa Grup Yönetilen Hizmet Hesaplarını (gMSA) kullanabilirsiniz. gMSA kullanmak için, Windows düğümlerini çalıştıran AKS kümenizde gMSA profilini etkinleştirmeniz gerekir. Mimarinin tam gözden geçirilmesi ve profili etkinleştirme kılavuzu için gMSA AKS belgelerine bakın.
Düğüm ve pod ölçeklendirme
Windows kapsayıcıları için küme otomatik ölçeklendiricisi kılavuzu değiştirilmez. Yönergeler için Küme otomatik ölçeklendiricisi belgelerine bakın.
Temel küme belgelerinde pod ölçeklendirme için kullanılabilen el ile ve otomatik ölçeklendirme yaklaşımları açıklanmaktadır. Her iki yaklaşım da Windows kapsayıcılarını çalıştıran kümeler için kullanılabilir ve bu makalede sağlanan yönergeler genellikle burada da geçerlidir.
Pod ölçeklendirme işlemleri açısından Linux ve Windows kapsayıcıları arasındaki farklar çoğu durumda görüntünün boyutudur. Windows kapsayıcılarının daha büyük görüntü boyutları büyük olasılıkla ölçeklendirme işlemlerinin tamamlanması için gereken süreyi artırır ve bu nedenle ölçeklendirme yaklaşımıyla ilgili bazı noktalar dikkate alınmalıdır. Bu senaryo, .NET çalışma zamanının boyutu nedeniyle eski .NET uygulamalarında yaygındır. Ölçeklendirme sürelerinde görüntüyü aşağı çekme gecikmelerini azaltmak için, görüntüyü ACR'den çekerek her Windows düğümünde önbelleğe almak için bir DaemonSet kullanabilir ve bu nedenle podları görüntü önceden yüklenmiş olarak döndürebilirsiniz. Bu noktadan sonra podların çevrimiçi olmadan önce iş yükünüz için tanımlanan uygulama yapılandırma işlemlerini çalıştırması yeterli olacaktır.
Ölçeklendirme işlemlerinin zaman etkisini anlamak için karşılaştırma alıştırmaları gerçekleştirilmelidir ve bu veriler iş gereksinimlerine göre tartılmalıdır. İş yükünüzün otomatik ölçeklendirme yoluyla mümkün olandan daha hızlı ölçeklendirilmesi gerekiyorsa, aşağıdaki alternatif "sık erişimli yedek" çözümü göz önünde bulundurmanız önerilir:
İlk olarak en yoğun yükleme zamanlarında ve yoğun olmayan yükleme zamanlarında kaç pod çalıştırmanız gerektiğini belirlemek için temel test yapmanız gerekir. Bu temel oluşturulduysa, istediğiniz zaman kullanılabilir olması gereken toplam düğüm sayısını hesaba eklemek için düğüm sayınızı planlayabilirsiniz. Bu çözüm, kümeniz için el ile ölçeklendirmeyi kullanmayı ve ilk düğüm sayısını gerekli düğümlerin en yüksek olmayan sayısına ayarlamayı içerir. Yoğun bir zaman aralığına yaklaştığınızda, düğümlerin yoğun yük süresi sayısına önceden ölçeklendirmeniz gerekir. Zaman geçtikçe, değişen uygulama kullanımını veya diğer iş gereksinimlerini hesaba katmak için temelinizi düzenli olarak yeniden oluşturmanız gerekir.
İzleme
Windows çalıştıran kapsayıcılar, Linux kapsayıcıları gibi Azure İzleyici ve Container Insights ile izlenebilir. Bu nedenle AKS Temeli makalesinde bulunan yönergeler çoğunlukla burada da geçerlidir. Ancak, bir Windows Server kümesi için Container Insights izlemesinin sınırlamaları şunlardır:
- Windows'un Bellek RSS ölçümü yoktur. Sonuç olarak, Windows düğümleri ve kapsayıcılar için kullanılamaz. Çalışma Kümesi ölçümü kullanılabilir
- Windows düğümleri için disk depolama kapasitesi bilgileri kullanılamaz.
Ayrıca, Windows Server sistemlerinizden olayları ve performans sayaçlarını toplamak için veri toplama kurallarını kullanarak Container Insights'ı tamamlayabilirsiniz.
Not
Windows Server 2022 işletim sistemi için kapsayıcı içgörüleri genel önizleme aşamasındadır.
İlke yönetimi
AKS temel makalesinde bulunan tüm ilke kılavuzu Windows iş yükleri için geçerlidir. Azure Kubernetes Service başvuru makalesinin Azure İlkesi yerleşik tanımlarında bulunan Windows'a özgü ek ilkeler şunlardır:
- Kubernetes kümesi Windows kapsayıcıları AŞıRı CPU ve bellek kullanmamalıdır
- Kubernetes kümesi Windows kapsayıcıları ContainerAdministrator olarak çalışmamalıdır
- Kubernetes kümesi Windows kapsayıcıları yalnızca onaylı kullanıcı ve etki alanı kullanıcı grubuyla çalıştırılmalıdır
Küme önyüklemesi
AKS Temeli makalesinde sağlanan küme önyükleme kılavuzunda olduğu gibi, küme operatörleri de Windows tabanlı iş yükleri için önyükleme yaklaşımını dikkate almalıdır. AKS Temeli makalesinde sağlanan yönergelerin aynısı burada da geçerlidir.
Maliyet yönetimi
AKS Temeli makalesinde bulunan tüm maliyet iyileştirme yönergeleri Windows iş yükleri için geçerlidir. Dikkate alınması gereken diğer maliyet konuları şunlardır:
- Windows Server lisanslama maliyetleri AKS kümenizin düğüm maliyetini artırır. Bu faktöre yönelik maliyet iyileştirme önerileri kapasite ayırmayı veya diğer iş kullanımları için zaten varsa mevcut lisansları kullanmayı içerir.
- Birden çok görüntü için gereken depolama miktarı, ACR'den alınan eşzamanlı düğüm sayısı ve coğrafi çoğaltma gereksinimleri nedeniyle Windows kapsayıcı görüntülerinin boyutu ek Azure Container Registry (ACR) maliyetlerine neden olabilir.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazarlar:
- Isabelle Bersano | Bulut Çözümü Mimarı
- Akshay Nimbalkar | Ana Bulut Çözümü Mimarı
- Clayton Siemens | Asıl İçerik Geliştirici
Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.
Sonraki adımlar
- Windows kapsayıcıları hakkında daha fazla bilgi edinin
İlgili kaynaklar
- AKS kümesinde Windows düğüm havuzlarını dağıtmayı öğrenin