AKS için ağ topolojisi ve bağlantı konuları

Tasarımla ilgili dikkat edilecek noktalar

Azure Kubernetes Service (AKS), kapsayıcı ağı için üç farklı ağ modeli sağlar: Kubenet, CNI Katman ve CNI. Bu modellerin her biri benzersiz özelliklere ve avantajlara sahiptir ve AKS'de kapsayıcı ağı için esneklik ve ölçeklenebilirlik seçenekleri sunar.

Kubenet

Kubenet, IP adresi alanından tasarruf sağlayan ve basit yapılandırma sunan temel bir ağ çözümüdür. Kullanıcı tanımlı yolları el ile yönetmenin ve bakımının kabul edilebilir olduğu, 400'den az düğüme sahip küçük AKS kümeleri için idealdir. İç veya dış yük dengeleyicilerin küme dışından podlara ulaşmak için yeterli olduğu senaryolar için uygundur.

Azure CNI

Azure CNI, gelişmiş ağ için tasarlanmış bir ağ modelidir. Podlar için tam sanal ağ bağlantısı sağlayarak poddan poda ve poddan VM'ye bağlantı sağlar. Sanal düğümler gibi gelişmiş AKS özelliklerinin gerekli olduğu senaryolar için idealdir. Yeterli IP adresi alanının kullanılabildiği ve dış kaynakların podlara doğrudan ulaşması gereken senaryolar için uygundur. AKS ağ ilkeleri Azure CNI ile de desteklenir.

Azure CNI Katmanı

Azure CNI Yer Paylaşımı, IP adresi eksikliklerini gidermek ve ağ yapılandırmasını basitleştirmek için tasarlanmıştır. Düğüm başına 1000 düğüme ve 250 poda kadar ölçeklendirmenin yeterli olduğu ve pod bağlantısı için ek atlamanın kabul edilebilir olduğu senaryolar için uygundur. AKS çıkış gereksinimleri Azure CNI Yer Paylaşımı ile de karşılanabilir.

Ağ modeli başına önerilen kullanım örneklerinin özeti için bkz . AKS'de ağ modellerini karşılaştırma.

Ayrıca AKS kümenizi tasarlarken, ölçeklendirmeyi desteklemek için sanal ağ alt ağının IP adresini ve boyutunu dikkatli bir şekilde planlamak önemlidir. Sanal düğümler hızlı küme ölçeklendirmesi için kullanılabilir, ancak bilinen bazı sınırlamalar vardır.

AKS kümeleri Temel ve Standart Azure Load Balancer SKU'larını destekler ve hizmetler genel veya iç yük dengeleyicilerle kullanıma sunılabilir. AKS, kümede çalışan podlara ad çözümlemesi sağlamak için CoreDNS kullanır ve giden (çıkış) ağ trafiği bir Azure Güvenlik Duvarı veya ağ sanal gereci kümesi aracılığıyla gönderilebilir.

Varsayılan olarak, AKS kümesindeki tüm podlar herhangi bir sınırlama olmadan trafik gönderebilir ve alabilir. Ancak Kubernetes ağ ilkeleri, AKS kümesindeki podlar arasındaki güvenlik ve filtre ağ trafiğini iyileştirmek için kullanılabilir. AKS için iki ağ ilkesi modeli mevcuttur: Azure ağ ilkeleri ve Calico.

Son olarak AKS, kümenin dağıtıldığı alt ağda bir ağ güvenlik grubu (NSG) ayarlar. Bu NSG'yi el ile düzenlememek önerilir, ancak AKS'de dağıtılan hizmetler bunu etkileyebilir.

Genel olarak, uygun ağ modelini seçmek ve ağ kaynaklarını dikkatlice planlamak AKS kümenizin performansını, güvenliğini ve maliyetini iyileştirmeye yardımcı olabilir.

Özel kümeler

AKS kümesi IP görünürlüğü genel veya özel olabilir. Özel kümeler Kubernetes API'sini bir özel IP adresi üzerinden kullanıma sunar, ancak genel ip adresi üzerinden kullanıma sunmaz. Bu özel IP adresi, AKS sanal ağında özel bir uç nokta üzerinden temsil edilir. Kubernetes API'sine IP adresi üzerinden değil, tam etki alanı adı (FQDN) üzerinden erişilmelidir. Kubernetes API FQDN'sinden IP adresine çözüm genellikle bir Azure Özel DNS bölgesi tarafından gerçekleştirilir. Bu DNS bölgesi Azure tarafından AKS düğümü kaynak grubunda oluşturulabilir veya mevcut bir DNS bölgesi belirtebilirsiniz.

Kurumsal ölçekte kanıtlanmış uygulamalardan sonra, Azure iş yükleri için DNS çözümlemesi, bağlantı aboneliğinde dağıtılan merkezi DNS sunucuları tarafından bir merkez sanal ağında veya azure Sanal WAN bağlı paylaşılan hizmetler sanal ağında sunulur. Bu sunucular, Azure DNS (IP adresi 168.63.129.16) kullanarak Azure'a özgü ve ortak adları ve kurumsal DNS sunucularını kullanan özel adları koşullu olarak çözümler. Ancak, bu merkezi DNS sunucuları AKS kümesi için oluşturulan DNS özel bölgesine bağlanana kadar AKS API FQDN'sini çözümleyemez. Bölge adına rastgele bir GUID eklendiğinden her AKS'nin benzersiz bir DNS özel bölgesi vardır. Bu nedenle, her yeni AKS kümesi için ilgili özel DNS bölgesi merkezi DNS sunucularının bulunduğu sanal ağa bağlanmalıdır.

Tüm sanal ağlar, ad çözümlemesi için bu merkezi DNS sunucularını kullanacak şekilde yapılandırılmalıdır. Ancak AKS sanal ağı merkezi DNS sunucularını kullanacak şekilde yapılandırılmışsa ve bu DNS sunucuları henüz özel DNS bölgesine bağlı değilse AKS düğümleri Kubernetes API'sinin FQDN'sini çözümleyemez ve AKS kümesinin oluşturulması başarısız olur. AKS sanal ağı yalnızca küme oluşturulduktan sonra merkezi DNS sunucularını kullanacak şekilde yapılandırılmalıdır.

Küme oluşturulduktan sonra, DNS özel bölgesi ile merkezi DNS sunucularının dağıtıldığı sanal ağ arasında bağlantı oluşturulur. AKS sanal ağı da bağlantı aboneliğindeki merkezi DNS sunucularını kullanacak şekilde yapılandırılmıştır ve AKS Kubernetes API'sine yönetici erişimi şu akışı izler:

Not

Bu makaledeki görüntüler, geleneksel merkez-uç bağlantı modelini kullanan tasarımı yansıtır. Kurumsal ölçekli giriş bölgeleri, merkezi DNS sunucularının bir Sanal WAN hub'ına bağlı paylaşılan hizmetler sanal ağında yer aldığı Sanal WAN bağlantı modelini tercih edebilir.

1. Yönetici, Kubernetes API'sinin FQDN'sini çözümler. Şirket içi DNS sunucuları isteği yetkili sunuculara iletir: Azure'daki DNS çözümleyicileri. Bu sunucular, isteği Azure DNS sunucusuna ()168.63.129.16 iletir ve ip adresini Azure Özel DNS bölgesinden alır.
2. IP adresi çözümlendikten sonra Kubernetes API'sine giden trafik, bağlantı modeline bağlı olarak şirket içinden Azure'daki VPN veya ExpressRoute ağ geçidine yönlendirilir.
3. Özel uç nokta, merkez sanal ağında bir /32 yol tanıtacaktır. VPN ve ExpressRoute ağ geçitleri trafiği doğrudan AKS sanal ağında dağıtılan Kubernetes API özel uç noktasına gönderir.

Uygulama kullanıcılarından kümeye trafik

Gelen (giriş) denetleyicileri AKS kümelerinde çalışan uygulamaları kullanıma açmak için kullanılabilir.

• Giriş denetleyicileri, küçük bir karmaşıklık artışı karşılığında uygulama düzeyinde yönlendirme sağlar.
• Giriş denetleyicileri Web Uygulaması Güvenlik Duvarı (WAF) işlevselliğini içerebilir.
• Giriş denetleyicileri küme dışında ve küme içinde çalışabilir:
  • Küme dışı giriş denetleyicisi, Azure Uygulaması Lication Gateway Giriş Denetleyicisi (AGIC) eklentisi gibi işlemleri (HTTP trafik yönlendirmesi veya TLS sonlandırma gibi) AKS dışındaki başka bir hizmete yükler.
  • Küme içi çözüm, işlem (HTTP trafik yönlendirme veya TLS sonlandırma gibi) için AKS kümesi kaynaklarını kullanır. Küme içi giriş denetleyicileri daha düşük maliyet sunabilir, ancak dikkatli bir kaynak planlama ve bakım gerektirir.
• Temel HTTP uygulama yönlendirme eklentisinin kullanımı kolaydır, ancak HTTP uygulama yönlendirmesinde belgelendiği gibi bazı kısıtlamaları vardır.

Giriş denetleyicileri, uygulamaları ve API'leri genel veya özel bir IP adresiyle kullanıma açabilir.

• Asimetrik yönlendirmeyi önlemek için yapılandırma çıkış filtreleme tasarımıyla hizalanmalıdır. UDR'ler asimetrik yönlendirmeye (potansiyel olarak) neden olabilir, ancak zorunlu değildir. Application Gateway trafikte SNAT yapabilir; yani dönüş trafiği application gateway düğümüne geri döner ve UDR yalnızca İnternet trafiği için ayarlanmışsa UDR yoluna gitmez.
• TLS sonlandırması gerekiyorsa TLS sertifikalarının yönetimi göz önünde bulundurulmalıdır.

Uygulama trafiği şirket içinden veya genel İnternet'ten gelebilir. Aşağıdaki resimde, bir Azure Uygulaması Lication Gateway'in hem şirket içinden hem de genel İnternet'ten kümelere ters ara sunucu bağlantıları için yapılandırıldığı bir örnek açıklanmaktadır.

Şirket içinden gelen trafik, önceki diyagramdaki numaralandırılmış mavi açıklama balonlarının akışını izler.

1. İstemci, bağlantı aboneliğinde dağıtılan DNS sunucularını veya şirket içi DNS sunucularını kullanarak uygulamaya atanan FQDN'yi çözümler.
2. Uygulama FQDN'sini bir IP adresine (uygulama ağ geçidinin özel IP adresi) çözümledikten sonra trafik bir VPN veya ExpressRoute ağ geçidi üzerinden yönlendirilir.
3. Ağ geçidi alt ağına yönlendirme, isteği web uygulaması güvenlik duvarına gönderecek şekilde yapılandırılır.
4. Web uygulaması güvenlik duvarı AKS kümesinde çalışan iş yüküne geçerli istekler gönderir.

Yapılandırması AKS'de dağıtılan iş yükleriyle yakından ilişkili olduğundan ve dolayısıyla aynı uygulama ekibi tarafından yönetildiğinden, bu örnekteki Azure Uygulaması Lication Gateway AKS kümesiyle aynı abonelikte dağıtılabilir. İnternet'ten erişim, önceki diyagramdaki numaralandırılmış yeşil açıklama balonlarının akışını izler.

1. Genel İnternet'ten gelen istemciler, Azure Traffic Manager kullanarak uygulamanın DNS adını çözümler. Alternatif olarak, Azure Front Door gibi diğer küresel yük dengeleme teknolojileri kullanılabilir.
2. Uygulama genel FQDN'si Traffic Manager tarafından, istemcilerin genel İnternet üzerinden erişeceği uygulama ağ geçidinin genel IP adresine çözümlenir.
3. Uygulama ağ geçidi AKS'de dağıtılan iş yüküne erişir.

Not

Bu akışlar yalnızca web uygulamaları için geçerlidir. Web dışı uygulamalar bu makalenin kapsamı dışındadır ve hub sanal ağındaki Azure Güvenlik Duvarı veya Sanal WAN bağlantı modeli kullanılıyorsa güvenli sanal hub aracılığıyla kullanıma sunulur.

Alternatif olarak, web tabanlı uygulamalar için trafik akışları hem bağlantı aboneliğindeki Azure Güvenlik Duvarı hem de AKS sanal ağındaki WAF arasında geçiş yapmak için yapılabilir. Bu yaklaşım, İnternet'teki bilinen kötü amaçlı IP adreslerinden gelen trafiği bırakmak için Azure Güvenlik Duvarı zeka tabanlı filtreleme kullanma gibi daha fazla koruma sunma avantajına sahiptir. Ancak bazı dezavantajları da vardır. Örneğin, özgün istemci IP adresinin kaybı ve uygulamaları kullanıma sunarken güvenlik duvarı ile uygulama ekipleri arasında gereken ek koordinasyon. Bunun nedeni, Azure Güvenlik Duvarı hedef ağ adresi çevirisi (DNAT) kurallarının gerekli olmasıdır.

AKS podlarından arka uç hizmetlerine trafik

AKS kümesinin içinde çalışan podların Azure Depolama, Azure SQL veritabanları veya Azure Cosmos DB NoSQL veritabanları gibi arka uç hizmetlerine erişmesi gerekebilir. Sanal ağ hizmet uç noktaları ve Özel Bağlantı, bu Azure yönetilen hizmetleriyle bağlantının güvenliğini sağlamak için kullanılabilir.

Arka uç trafiği için Azure özel uç noktaları kullanıyorsanız Azure hizmetleri için DNS çözümlemesi Azure Özel DNS bölgeleri kullanılarak gerçekleştirilebilir. Tüm ortamın DNS çözümleyicileri merkez sanal ağında (veya Sanal WAN bağlantı modelini kullanıyorsa paylaşılan hizmetler sanal ağında) olduğundan, bu özel bölgeler bağlantı aboneliğinde oluşturulmalıdır. Özel hizmetin FQDN'sini çözümlemek için gereken A kaydını oluşturmak için, özel DNS bölgesini (bağlantı aboneliğinde) özel uç noktayla (uygulama aboneliğinde) ilişkilendirebilirsiniz. Bu işlem, bu aboneliklerde belirli ayrıcalıklar gerektirir.

A kayıtlarını el ile oluşturmak mümkündür, ancak özel DNS bölgesini özel uç noktayla ilişkilendirmek, yanlış yapılandırmalara daha az eğilimli bir kuruluma neden olur.

AKS podlarından özel uç noktalar aracılığıyla kullanıma sunulan Azure PaaS hizmetlerine arka uç bağlantısı şu sırayı izler:

1. AKS podları, AKS sanal ağında özel DNS sunucuları olarak tanımlanan bağlantı aboneliğindeki merkezi DNS sunucularını kullanarak Hizmet olarak Azure platformunun (PaaS) FQDN'sini çözümler.
2. Çözümlenen IP, doğrudan AKS podlarından erişilen özel uç noktaların özel IP adresidir.

AKS kümesi Azure Güvenlik Duvarı ile çıkış filtreleme için yapılandırılmış olsa bile AKS podları ile varsayılan başına özel uç noktalar arasındaki trafik, merkez sanal ağındaki (veya Sanal WAN kullanılıyorsa güvenli sanal hub) Azure Güvenlik Duvarı gitmez. Bunun nedeni, özel uç noktanın AKS'nin dağıtıldığı uygulama sanal ağının alt ağlarında bir /32 yol oluşturmasıdır.

Tasarım önerileri

• Güvenlik ilkeniz Kubernetes API'sinin bir özel IP adresiyle (genel IP adresi yerine) olmasını zorunlu tutuyorsa, özel bir AKS kümesi dağıtın.
  • Özel küme oluştururken, oluşturma işleminin bir sistem özel DNS bölgesi kullanmasına izin vermek yerine özel özel DNS bölgeleri kullanın.
• AKS kümesine atanabilecek sınırlı bir IP adresi aralığınız olmadığı sürece Azure Container Networking Interface'i (CNI) ağ modeli olarak kullanın.
  • CNI ile IP adresi planlaması hakkındaki belgeleri izleyin.
  • Son sınırlamaları doğrulamak üzere Windows Server düğüm havuzlarını ve sanal düğümleri kullanmak için Windows AKS desteği hakkında SSS bölümüne bakın.
• Merkezi bir abonelikte Azure Güvenlik Duvarı veya WAF kullanmadığınız sürece AKS kümesi için kullanılan sanal ağı korumak için Azure DDoS Koruması'nı kullanın.
• Azure Sanal WAN veya merkez-uç mimarisi, Azure DNS bölgeleri ve kendi DNS altyapınız ile genel ağ kurulumuna bağlı DNS yapılandırmasını kullanın.
• Ağ bağlantılarının güvenliğini sağlamak için Özel Bağlantı kullanın ve Azure Depolama, Azure Container Registry, Azure SQL Veritabanı ve Azure Key Vault gibi Özel Bağlantı destekleyen diğer yönetilen Azure hizmetlerine özel IP tabanlı bağlantı kullanın.
• Gelişmiş HTTP yönlendirmesi ve güvenliği sağlamak ve uygulamalar için tek bir uç nokta sunmak için giriş denetleyicisi kullanın.
• Giriş kullanacak şekilde yapılandırılmış tüm web uygulamaları TLS şifrelemesi kullanmalıdır ve şifrelenmemiş HTTP üzerinden erişime izin vermemelidir. Abonelik, kurumsal ölçekli giriş bölgelerinin başvuru uygulamalarını içeren ilkeler bölümünde önerilen ilkeleri içeriyorsa bu ilke zaten uygulanır.
• İsteğe bağlı olarak, AKS kümenizin işlem ve depolama kaynaklarını korumak için küme dışı giriş denetleyicisi kullanın.
  • Birinci taraf tarafından yönetilen bir Azure hizmeti olan Azure Uygulaması Lication Gateway Giriş Denetleyicisi (AGIC) eklentisini kullanın.
  • AGIC ile her AKS kümesi için ayrılmış bir Azure Uygulaması lication Gateway dağıtın ve aynı Application Gateway'i birden çok AKS kümesinde paylaşmayın.
  • Kaynak veya işlem kısıtlamaları yoksa veya AGIC gerekli özellikleri sağlamıyorsa NGINX, Traefik veya Kubernetes tarafından desteklenen başka bir çözüm gibi küme içi giriş denetleyicisi çözümünü kullanın.
• İnternet'e yönelik ve güvenlik açısından kritik, iç kullanıma yönelik web uygulamaları için giriş denetleyicisiyle bir web uygulaması güvenlik duvarı kullanın.
  • Azure Uygulaması lication Gateway ve Azure Front Door ile tümleştirme Web tabanlı uygulamaları korumak için Azure Web Uygulaması Güvenlik Duvarı.
• Güvenlik ilkeniz AKS kümesinde oluşturulan tüm giden İnternet trafiğinin incelenmesini gerektiriyorsa, yönetilen hub sanal ağında dağıtılan Azure Güvenlik Duvarı veya üçüncü taraf ağ sanal gereci (NVA) kullanarak güvenli çıkış ağ trafiği. Daha fazla bilgi için bkz . Çıkış trafiğini sınırlama. AKS giden türü UDR, bir yol tablosunu AKS düğümü alt ağıyla ilişkilendirmeyi gerektirir, bu nedenle bugün Azure Sanal WAN veya Azure Route Server tarafından desteklenen dinamik yol ekleme ile kullanılamaz.
• Özel olmayan kümeler için yetkili IP aralıklarını kullanın.
• Azure Load Balancer'ın Temel katmanı yerine Standart katmanı kullanın.
• Azure'da kubernetes kümesi tasarlarken dikkat edilmesi gereken önemli noktalardan biri, özel gereksinimleriniz için uygun ağ modelini seçmektir. Azure Kubernetes Service (AKS) üç farklı ağ modeli sunar: Kubenet, Azure CNI ve Azure CNI Yer Paylaşımı. Bilinçli bir karar vermek için her modelin özelliklerini ve özelliklerini anlamak önemlidir.

AKS'deki üç ağ modeli arasında özellik karşılaştırması için; Kubenet, Azure CNI ve Azure CNI Yer Paylaşımı, bkz . AKS'de ağ modellerini karşılaştırma.