Azure Kubernetes Service'te (AKS) genel standart yük dengeleyici kullanma

Azure Load Balancer, hem gelen hem de giden senaryoları destekleyen Open Systems Interconnection (OSI) modelinin 4. katmanında çalışır. Yük dengeleyicinin ön ucuna ulaşan gelen akışları arka uç havuzu örneklerine dağıtır.

AKS ile tümleştirilmiş genel yük dengeleyici iki amaca hizmet eder:

1. Özel IP adresini Giden Havuzunun genel IP adresi bölümüne çevirerek AKS sanal ağının içindeki küme düğümlerine giden bağlantılar sağlamak için.
2. türüne LoadBalancersahip Kubernetes hizmetleri aracılığıyla uygulamalara erişim sağlamak, uygulamalarınızı kolayca ölçeklendirmenize ve yüksek oranda kullanılabilir hizmetler oluşturmanıza olanak tanır.

Ön uç olarak yalnızca özel IP'lere izin verildiğinde iç (veya özel) yük dengeleyici kullanılır. İç yük dengeleyiciler, sanal ağ içindeki trafiğin yükünü dengelemek için kullanılır. Karma bir senaryoda yük dengeleyici ön ucuna şirket içi ağdan da erişilebilir.

Bu makale AKS üzerinde genel yük dengeleyici ile tümleştirmeyi kapsar. İç yük dengeleyici tümleştirmesi için bkz . AKS'de iç yük dengeleyici kullanma.

Başlamadan önce

• Azure Load Balancer iki SKU'da kullanılabilir: Temel ve Standart. Standart SKU, aks kümesi oluşturduğunuzda varsayılan olarak kullanılır. Standart SKU daha büyük bir arka uç havuzu, birden çok düğüm havuzu, Kullanılabilirlik Alanları gibi ek işlevlere erişmenizi sağlar ve varsayılan olarak güvenlidir. AKS için önerilen yük dengeleyici SKU'su. Temel ve Standart SKU'lar hakkında daha fazla bilgi için bkz. Azure Load Balancer SKU karşılaştırması.
• Türüne LoadBalancersahip Kubernetes hizmetleri için desteklenen ek açıklamaların tam listesi için bkz . LoadBalancer ek açıklamaları.
• Bu makalede, Standart SKU Azure Load Balancer ile bir AKS kümeniz olduğu varsayılır. AKS kümesine ihtiyacınız varsa Azure CLI, Azure PowerShell veya Azure portalını kullanarak bir küme oluşturabilirsiniz.
• AKS, aracı düğümlerinin yaşam döngüsünü ve işlemlerini yönetir. Aracı düğümleriyle ilişkili IaaS kaynaklarının değiştirilmesi desteklenmez. Desteklenmeyen bir işlem örneği, yük dengeleyici kaynak grubunda el ile değişiklikler yapmaktır.

Önemli

Giden bağlantı sağlamak için kendi ağ geçidinizi, güvenlik duvarınızı veya ara sunucunuzu kullanmayı tercih ederseniz, userDefinedRouting (UDR) olarak giden türünü kullanarak yük dengeleyici giden havuzunun ve ilgili ön uç IP'sinin oluşturulmasını atlayabilirsiniz. Giden türü, bir küme için çıkış yöntemini tanımlar ve varsayılan olarak yazın LoadBalancer.

Genel standart yük dengeleyiciyi kullanma

Giden türüne LoadBalancer (varsayılan) sahip bir AKS kümesi oluşturduktan sonra, kümeniz hizmetleri kullanıma açmak için yük dengeleyiciyi kullanmaya hazırdır.

türünde LoadBalancerbir genel hizmet oluşturan adlı public-svc.yamlbir hizmet bildirimi oluşturun.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

Yük dengeleyici IP adresini belirtin

Yük dengeleyici ile belirli bir IP adresi kullanmak istiyorsanız iki yol vardır:

Önemli

LoadBalancerIP özelliğini yük dengeleyici YAML bildirimine eklemek, yukarı akış Kubernetes'in ardından kullanımdan kaldırılıyor. Geçerli kullanım aynı kalır ve mevcut hizmetlerin değişiklik yapılmadan çalışması beklenir, ancak bunun yerine hizmet ek açıklamalarını ayarlamanızı kesinlikle öneririz.

• Hizmet ek açıklamalarını ayarlama: IPv4 adresi ve service.beta.kubernetes.io/azure-load-balancer-ipv6 IPv6 adresi için kullanınservice.beta.kubernetes.io/azure-load-balancer-ipv4.
• LoadBalancerIP özelliğini yük dengeleyici YAML bildirimine ekleyin: Service.Spec.LoadBalancerIP özelliğini yük dengeleyici YAML bildirimine ekleyin. Bu alan, yukarı akış Kubernetes'in ardından kullanımdan kaldırılıyor ve çift yığını destekleyemez. Geçerli kullanım aynı kalır ve mevcut hizmetlerin değişiklik yapılmadan çalışması beklenir.

Hizmet bildirimini dağıtma

kullanarak kubectl apply genel hizmet bildirimini dağıtın ve YAML bildiriminizin adını belirtin.

kubectl apply -f public-svc.yaml

Azure Load Balancer, yeni hizmeti önleyen yeni bir genel IP ile yapılandırılır. Azure Load Balancer birden çok ön uç IP'sine sahip olabileceğinden, dağıttığınız her yeni hizmet benzersiz bir şekilde erişilecek yeni bir ayrılmış ön uç IP'sine sahip olur.

Hizmetinizin oluşturulduğunu ve yük dengeleyicinin aşağıdaki komutu kullanarak yapılandırıldığını onaylayın.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

Hizmet ayrıntılarını görüntülediğinizde, yük dengeleyicide bu hizmet için oluşturulan genel IP adresi EXTERNAL-IP sütununda gösterilir. IP adresinin beklemede> olandan <gerçek bir genel IP adresine değişmesi birkaç dakika sürebilir.

Hizmetiniz hakkında daha ayrıntılı bilgi için aşağıdaki komutu kullanın.

kubectl describe service public-svc

Aşağıdaki örnek çıktı, çalıştırdıktan kubectl describe servicesonra çıkışın sıkıştırılmış bir sürümüdür. LoadBalancer Girişi , hizmetiniz tarafından kullanıma sunulan dış IP adresini gösterir. IP , iç adresleri gösterir.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

Genel standart yük dengeleyiciyi yapılandırma

Küme oluşturma zamanında veya kümeyi güncelleştirerek standart genel yük dengeleyiciniz için farklı ayarları özelleştirebilirsiniz. Bu özelleştirme seçenekleri, iş yükü gereksinimlerinizi karşılayan bir yük dengeleyici oluşturmanıza olanak sağlar. Standart yük dengeleyici ile şunları yapabilirsiniz:

• Yönetilen giden IP sayısını ayarlayın veya ölçeklendirin.
• Kendi özel giden IP'lerinizi veya giden IP ön ekinizi getirin.
• Kümedeki her düğüme ayrılan giden bağlantı noktalarının sayısını özelleştirin.
• Boşta bağlantılar için zaman aşımı ayarını yapılandırın.

Önemli

Belirli bir zamanda yalnızca bir giden IP seçeneği (yönetilen IP'ler, kendi IP'nizi getirin veya IP ön eki) kullanılabilir.

Gelen havuz türünü değiştirme

AKS düğümlerine yük dengeleyici arka uç havuzlarında IP yapılandırmaları (Azure Sanal Makine Ölçek Kümeleri tabanlı üyelik) veya yalnızca IP adresleriyle başvurulabilir. IP adresi tabanlı arka uç havuzu üyeliğinin kullanımı, özellikle yüksek düğüm sayılarında hizmetleri güncelleştirirken ve yük dengeleyiciler sağlarken daha yüksek verimlilik sağlar. IP tabanlı arka uç havuzları ile yeni kümelerin sağlanması ve mevcut kümelerin dönüştürülmesi artık desteklenmektedir. NAT Ağ Geçidi veya kullanıcı tanımlı yönlendirme çıkış türleriyle birleştirildiğinde, yeni düğümlerin ve hizmetlerin sağlanması daha yüksek performans gösterir.

İki farklı havuz üyeliği türü kullanılabilir:

• nodeIPConfiguration- eski Sanal Makine Ölçek Kümeleri IP yapılandırması tabanlı havuz üyelik türü
• nodeIP - IP tabanlı üyelik türü

Gereksinimler

• AKS kümesi 1.23 veya daha yeni bir sürüm olmalıdır.
• AKS kümesi standart yük dengeleyicileri ve sanal makine ölçek kümelerini kullanıyor olmalıdır.

IP tabanlı gelen havuz üyeliğiyle yeni bir AKS kümesi oluşturma

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Mevcut AKS kümesini IP tabanlı gelen havuz üyeliğini kullanacak şekilde güncelleştirme

Uyarı

Bu işlem, kümedeki gelen hizmet trafiğinde geçici bir kesintiye neden olur. Etki süresi, çok sayıda düğüme sahip daha büyük kümelerle artar.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Yönetilen giden genel IP sayısını ölçeklendirme

Azure Load Balancer, sanal ağdan giden ve gelen bağlantı sağlar. Giden kuralları, genel standart yük dengeleyici için ağ adresi çevirisini yapılandırmayı kolaylaştırır.

Giden kuralları, yük dengeleme ve gelen NAT kurallarıyla aynı söz dizimini izler:

ön uç IP'leri + parametreler + arka uç havuzu

Giden kuralı, arka uç havuzu tarafından tanımlanan tüm sanal makineler için giden NAT'yi ön uça çevrilecek şekilde yapılandırıyor. Parametreler giden NAT algoritması üzerinde daha fazla denetim sağlar.

Giden kuralını tek bir genel IP adresiyle kullanabilirsiniz ancak giden kuralları, yapılandırma yükünü kolaylaştırdığından giden NAT'yi ölçeklendirmek için harikadır. SNAT tükenme eğilim desenlerini azaltmak üzere büyük ölçekli senaryoları ve giden kuralları planlamak için birden çok IP adresi kullanabilirsiniz. Ön uç tarafından sağlanan her IP adresi, yük dengeleyicinin SNAT bağlantı noktaları olarak kullanması için 64k kısa ömürlü bağlantı noktaları sağlar.

Yönetilen giden genel IP'ler (varsayılan olarak oluşturulur) ile Standart SKU yük dengeleyici kullanırken, parametresini --load-balancer-managed-outbound-ip-count kullanarak yönetilen giden genel IP'lerin sayısını ölçeklendikleyebilirsiniz.

Mevcut bir kümeyi güncelleştirmek için aşağıdaki komutu kullanın. Bu parametreyi birden çok yönetilen giden genel IP'ye sahip olacak şekilde de ayarlayabilirsiniz.

Önemli

Giden kuralı değişiklikleri yapmak için Azure portalını kullanmanızı önermeyiz. Bu değişiklikleri yaparken doğrudan Load Balancer kaynağında değil AKS kümesinden geçmeniz gerekir.

Küme durdurulduğunda, başlatıldığında, yükseltildiğinde veya ölçeklendirildiğinde, küme uzlaştırıldığında doğrudan Load Balancer kaynağında yapılan giden kuralı değişiklikleri kaldırılır.

Örneklerde gösterildiği gibi Azure CLI'yi kullanın. CLI komutları kullanılarak az aks yapılan giden kuralı değişiklikleri, küme kapalı kalma süresi boyunca kalıcıdır.

Daha fazla bilgi için bkz . Azure Load Balancer giden kuralları.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

Yukarıdaki örnek, myResourceGroup'taki myAKSCluster kümesi için yönetilen giden genel IP sayısını 2 olarak ayarlar.

Küme oluşturma zamanında, parametresini ekleyip --load-balancer-managed-outbound-ip-count istediğiniz değere ayarlayarak yönetilen giden genel IP'lerin ilk sayısını da ayarlayabilirsiniz. Varsayılan yönetilen giden genel IP sayısı 1'dir.

Kendi giden genel IP'lerinizi veya ön eklerinizi sağlayın

Standart SKU yük dengeleyici kullandığınızda AKS kümesi, AKS tarafından yönetilen altyapı kaynak grubunda otomatik olarak bir genel IP oluşturur ve bunu varsayılan olarak yük dengeleyici giden havuzuna atar.

AKS tarafından oluşturulan genel IP, AKS tarafından yönetilen bir kaynaktır, yani AKS bu genel IP'nin yaşam döngüsünü yönetir ve doğrudan genel IP kaynağında kullanıcı eylemi gerektirmez. Alternatif olarak, küme oluşturma zamanında kendi özel genel IP'nizi veya genel IP ön ekinizi atayabilirsiniz. Özel IP'leriniz mevcut bir kümenin yük dengeleyici özelliklerinde de güncelleştirilebilir.

Kendi genel IP'nizi veya ön ekinizi kullanma gereksinimleri şunlardır:

• Kullanıcıların özel genel IP adresleri oluşturması ve sahip olması gerekir. AKS tarafından oluşturulan yönetilen genel IP adresleri, yönetim çakışmalarına neden olabileceği için "kendi özel IP'nizi getirin" olarak yeniden kullanılamaz.
• Aks küme kimliğinin (Hizmet Sorumlusu veya Yönetilen Kimlik) gerekli genel IP izinleri listesine göre giden IP'ye erişim izinlerine sahip olduğundan emin olmanız gerekir.
• Giden IP'leri veya giden IP ön eklerini yapılandırmak için gereken önkoşulları ve kısıtlamaları karşıladığınızdan emin olun.

Kümeyi kendi giden genel IP'nizle güncelleştirme

az network public-ip show Genel IP'lerinizin kimliklerini listelemek için komutunu kullanın.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

Yukarıdaki komut, myResourceGroup kaynak grubundaki myPublicIP genel IP'sinin kimliğini gösterir.

az aks update Kümenizi genel IP'lerinizle güncelleştirmek için parametresiyle komutunu load-balancer-outbound-ips kullanın.

Aşağıdaki örnek, parametresini load-balancer-outbound-ips önceki komutun kimlikleriyle birlikte kullanır.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Kümeyi kendi giden genel IP ön ekinizle güncelleştirme

Çıkış için Genel IP ön eklerini Standart SKU yük dengeleyicinizle de kullanabilirsiniz. Aşağıdaki örnek, genel IP ön eklerinizin kimliklerini listelemek için az network public-ip prefix show komutunu kullanır.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

Yukarıdaki komut, myResourceGroup kaynak grubundaki myPublicIPPrefix genel IP ön ekinin kimliğini gösterir.

Aşağıdaki örnek, önceki komutun kimlikleriyle load-balancer-outbound-ip-prefixes parametresini kullanır.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Kümeyi kendi genel IP'niz veya ön eklerinizle oluşturma

Kümenizi oluştururken, çıkış uç noktalarını izin verilenler listesine ekleme gibi senaryoları desteklemek üzere çıkış için kendi IP adreslerinizi veya IP ön eklerinizi getirebilirsiniz. Küme oluşturma zamanında kendi genel IP'lerinizi ve IP ön eklerinizi tanımlamak için, önceki komutta gösterilen parametrelerin aynısını eklersiniz.

az aks create Kendi genel IP'lerinizle yeni bir küme oluşturmak için parametresiyle komutunu load-balancer-outbound-ips kullanın.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

az aks create Kendi genel IP ön eklerinizle yeni bir küme oluşturmak için parametresiyle komutunu load-balancer-outbound-ip-prefixes kullanın.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Ayrılan giden bağlantı noktalarını yapılandırma

Önemli

Kümenizde, bir veritabanına bağlanan bir ön uç uygulamasının birçok örneği gibi küçük hedef kümesine çok sayıda bağlantı kurabilen uygulamalarınız varsa, SNAT bağlantı noktası tükenmesi ile karşılaşmaya açık bir senaryonuz olabilir. SNAT bağlantı noktası tükenmesi, bir uygulamanın başka bir uygulama veya konakla bağlantı kurmak için kullanılacak giden bağlantı noktaları yetersiz olduğunda gerçekleşir. SNAT bağlantı noktası tükenmesi ile karşılaşmaya duyarlı bir senaryonuz varsa, yük dengeleyicide ayrılan giden bağlantı noktalarını ve giden ön uç IP'lerini artırmanızı kesinlikle öneririz.

SNAT hakkında daha fazla bilgi için bkz . Giden bağlantılar için SNAT kullanma.

Varsayılan olarak AKS, yük dengeleyicisinde AllocatedOutboundPorts'u olarak ayarlar ve bu da küme oluştururken arka uç havuzu boyutuna göre otomatik giden bağlantı noktası atamasını etkinleştirir.0 Örneğin, bir kümede 50 veya daha az düğüm varsa, her düğüme 1024 bağlantı noktası ayrılır. Kümedeki düğüm sayısı arttıkça düğüm başına daha az bağlantı noktası kullanılabilir.

Önemli

Düğüm boyutu 50'den küçük veya buna eşit olduğunda ön uç IP'lerinin eklenip eklenmediğine bakılmaksızın 1024 bağlantı noktası sabit sınırı vardır (1-50).

AKS kümesi yük dengeleyicisi için AllocatedOutboundPorts değerini göstermek için kullanın az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

Aşağıdaki örnek çıktı, arka uç havuzu boyutuna göre otomatik giden bağlantı noktası atamasının küme için etkinleştirildiğini gösterir.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus  

Küme load-balancer-outbound-ports oluştururken veya güncelleştirirken AllocatedOutboundPorts ve giden IP adresi için belirli bir değeri yapılandırmak için ve kullanın ve load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipsveya load-balancer-outbound-ip-prefixeskullanın. Belirli bir değeri ayarlamadan veya giden bağlantı noktaları veya giden IP adresleri için var olan bir değeri artırmadan önce, uygun sayıda giden bağlantı noktası ve IP adresi hesaplamanız gerekir. En yakın tamsayıya yuvarlanmış bu hesaplama için aşağıdaki denklemi kullanın: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Giden bağlantı noktalarının ve IP'lerin sayısını hesaplarken ve değerleri ayarlarken aşağıdaki bilgileri göz önünde bulundurun:

• Düğüm başına giden bağlantı noktası sayısı, ayarladığınız değere göre sabittir.
• Giden bağlantı noktalarının değeri 8'in katı olmalıdır.
• Daha fazla IP eklemek herhangi bir düğüme daha fazla bağlantı noktası eklemez, ancak kümedeki daha fazla düğüm için kapasite sağlar.
• maxSurge değerleri aracılığıyla belirtilen düğüm sayısı da dahil olmak üzere yükseltmelerin bir parçası olarak eklenebilen düğümleri hesaba katmalısınız.

Aşağıdaki örneklerde, ayarladığınız değerlerin giden bağlantı noktası ve IP adresi sayısını nasıl etkilediği gösterilmektedir:

• Varsayılan değerler kullanılıyorsa ve kümede 48 düğüm varsa, her düğümde 1024 bağlantı noktası vardır.
• Varsayılan değerler kullanılırsa ve küme 48 düğümden 52 düğüme ölçeklendirilirse, her düğüm kullanılabilir 1024 bağlantı noktası ile 512 bağlantı noktası arasında güncelleştirilir.
• Giden bağlantı noktası sayısı 1.000 ve giden IP sayısı 2 olarak ayarlandıysa, küme en fazla 128 düğümü destekleyebilir: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
• Giden bağlantı noktası sayısı 1.000 ve giden IP sayısı 7 olarak ayarlandıysa, küme en fazla 448 düğümü destekleyebilir: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
• Giden bağlantı noktası sayısı 4.000 ve giden IP sayısı 2 olarak ayarlandıysa, küme en fazla 32 düğümü destekleyebilir: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
• Giden bağlantı noktası sayısı 4.000 ve giden IP sayısı 7 olarak ayarlandıysa, küme en fazla 112 düğümü destekleyebilir: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Önemli

Giden bağlantı noktalarını ve IP sayısını hesapladıktan sonra, yükseltmeler sırasında düğüm dalgalanmasını işlemek için ek giden bağlantı noktası kapasitesine sahip olduğunuzu doğrulayın. Yükseltme ve diğer işlemler için gereken ek düğümler için yeterli fazla bağlantı noktası ayırmak kritik önem taşır. AKS, yükseltme işlemleri için varsayılan olarak bir arabellek düğümüne sahiptir. maxSurge değerlerini kullanıyorsanız, gereken bağlantı noktası sayısını belirlemek için düğüm başına giden bağlantı noktalarını maxSurge değerinizle çarpın. Örneğin, en fazla 100 düğüme ve en fazla 2 artışa sahip bir kümede 7 IP adresine sahip düğüm başına 4000 bağlantı noktası gerektiğini hesaplarsanız:

• Yükseltmeler sırasında düğüm dalgalanması için 2 dalgalanma düğümü * düğüm başına 4000 bağlantı noktası = 8000 bağlantı noktası gerekir.
• Kümeniz için 100 düğüm * düğüm başına 4000 bağlantı noktası = 400.000 bağlantı noktası gerekir.
• Kümeniz için ip başına 7 IP * 64000 bağlantı noktası = 448.000 bağlantı noktası kullanılabilir.

Yukarıdaki örnekte kümenin 48.000 bağlantı noktası fazla kapasitesi olduğu ve yükseltmeler sırasında düğüm dalgalanması için gereken 8000 bağlantı noktasını işlemek için yeterli olduğu gösterilmektedir.

Değerler hesaplanıp doğrulandıktan sonra, ve kullanarak load-balancer-outbound-portsload-balancer-managed-outbound-ip-countload-balancer-outbound-ipsveya küme oluştururken veya load-balancer-outbound-ip-prefixes güncelleştirirken bu değerleri uygulayabilirsiniz.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

Yük dengeleyici boşta kalma zaman aşımını yapılandırma

SNAT bağlantı noktası kaynakları tükendiğinde, mevcut akışlar SNAT bağlantı noktalarını serbest bırakana kadar giden akışlar başarısız olur. Yük dengeleyici, akış kapandığında SNAT bağlantı noktalarını geri alır ve AKS tarafından yapılandırılan yük dengeleyici, boşta akışlardan SNAT bağlantı noktalarını geri kazanmak için 30 dakikalık boşta kalma zaman aşımı kullanır.

Ayrıca, bir boş akışı yenilemek ve gerekirse bu boşta kalma zaman aşımını sıfırlamak için aktarım (örneğin, TCP keepalives veya application-layer keepalives) kullanabilirsiniz. Aşağıdaki örneği izleyerek bu zaman aşımını yapılandırabilirsiniz.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

Çok sayıda kısa süreli bağlantınız olmasını ve veya kubectl port-forwardgibi kubectl proxy uzun süre boşta kalma süresine sahip olabilecek uzun süreli bağlantı olmamasını bekliyorsanız, 4 dakika gibi düşük bir zaman aşımı değeri kullanmayı göz önünde bulundurun. TCP korumalarını kullanırken, bağlantının bir tarafında etkinleştirmek yeterlidir. Örneğin, bunları yalnızca akışın boşta kalan zamanlayıcısını sıfırlamak için sunucu tarafında etkinleştirmek yeterlidir. Her iki tarafın da TCP korumalarını başlatması gerekmez. Veritabanı istemci-sunucu yapılandırmaları da dahil olmak üzere uygulama katmanı için benzer kavramlar mevcuttur. Uygulamaya özgü korumalar için hangi seçeneklerin mevcut olduğunu sunucu tarafında denetleyin.

Önemli

AKS, tcp sıfırlamayı varsayılan olarak boşta olarak etkinleştirir. Senaryolarınızda daha öngörülebilir uygulama davranışı için bu yapılandırmayı korumanızı ve bu yapılandırmadan yararlanmanızı öneririz.

TCP RST yalnızca TCP bağlantısı sırasında ESTABLISHED durumunda gönderilir. Bu konuda burada daha fazla bilgi edinebilirsiniz.

IdleTimeoutInMinutes ayarını varsayılan değer olan 30 dakikadan farklı bir değere ayarlarken, iş yüklerinizin ne kadar süreyle giden bağlantıya ihtiyacı olduğunu göz önünde bulundurun. Aks dışında kullanılan Standart SKU yük dengeleyici için varsayılan zaman aşımı değerinin 4 dakika olduğunu da göz önünde bulundurun. Belirli AKS iş yükünüzü daha doğru yansıtan idleTimeoutInMinutes değeri, bağlantıların artık kullanılmaması nedeniyle oluşan SNAT tükenmesini azaltmaya yardımcı olabilir.

Uyarı

AllocatedOutboundPorts ve IdleTimeoutInMinutes değerlerinin değiştirilmesi, yük dengeleyiciniz için giden kuralın davranışını önemli ölçüde değiştirebilir ve basit bir şekilde yapılmamalıdır. Değişikliklerinizin etkisini tam olarak anlamak için bu değerleri güncelleştirmeden önce SNAT Sorun Giderme bölümünü gözden geçirin ve Azure'daki Load Balancer giden kuralları ve giden bağlantıları gözden geçirin.

Gelen trafiği belirli IP aralıklarıyla kısıtlama

Aşağıdaki bildirim, gelen dış trafik için yeni bir IP aralığı belirtmek üzere loadBalancerSourceRanges kullanır.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

Bu örnek, kuralı yalnızca aralıktan MY_EXTERNAL_IP_RANGE gelen dış trafiğe izin verecek şekilde güncelleştirir. değerini iç alt ağ IP adresiyle değiştirirseniz MY_EXTERNAL_IP_RANGE , trafik yalnızca küme iç IP'leriyle sınırlıdır. Trafik küme iç IP'leri ile sınırlıysa Kubernetes kümenizin dışındaki istemciler yük dengeleyiciye erişemez.

Not

• Aks kümeniz için yük dengeleyiciden sanal ağa gelen dış trafik akışları. Sanal ağ, yük dengeleyiciden gelen tüm trafiğe izin veren bir ağ güvenlik grubuna (NSG) sahiptir. Bu NSG, yük dengeleyiciden gelen trafiğe izin vermek için LoadBalancer türünde bir hizmet etiketi kullanır.
• v1.25 veya üzeri sürüme sahip kümeler için hizmetin LoadBalancer IP'sine erişmesi gereken podlar varsa, pod CIDR loadBalancerSourceRanges'e eklenmelidir.

Gelen bağlantılarda istemcinin IP'sini koruma

Varsayılan olarak, Kubernetes ve AKS'de türündeki LoadBalancerbir hizmet, pod bağlantısında istemcinin IP adresini kalıcı yapmaz. Pod'a teslim edilen paket üzerindeki kaynak IP, düğümün özel IP'sine dönüşür. İstemcinin IP adresini korumak için hizmet tanımında olarak ayarlamanız service.spec.externalTrafficPolicylocal gerekir. Aşağıdaki bildirimde bir örnek gösterilmektedir.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Kubernetes Ek Açıklamaları aracılığıyla özelleştirmeler

Aşağıdaki ek açıklamalar türüne LoadBalancersahip Kubernetes hizmetleri için desteklenir ve yalnızca GELEN akışları için geçerlidir.

Annotation	Value	Açıklama
service.beta.kubernetes.io/azure-load-balancer-internal	true veya false	Yük dengeleyicinin dahili olup olmayacağını belirtin. Ayarlanmadıysa, varsayılan olarak genel olur.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet	Alt ağın adı	İç yük dengeleyicinin hangi alt ağa bağlı olacağını belirtin. Ayarlanmadıysa, varsayılan olarak bulut yapılandırma dosyasında yapılandırılan alt ağ olur.
service.beta.kubernetes.io/azure-dns-label-name	Genel IP'lerde DNS etiketinin adı	Genel hizmet için DNS etiket adını belirtin. Boş bir dizeye ayarlanırsa, Genel IP'deki DNS girişi kullanılmaz.
service.beta.kubernetes.io/azure-shared-securityrule	true veya false	Ağ Güvenliği gruplarında Azure Artırılmış Güvenlik Kuralları'nı kullanarak hizmetin açığa çıkarılma olasılığını artırmak için paylaşılan bir Azure güvenlik kuralı aracılığıyla hizmeti ifşa etme seçeneğini belirtin.
service.beta.kubernetes.io/azure-load-balancer-resource-group	Kaynak grubunun adı	Küme altyapısıyla (düğüm kaynak grubu) aynı kaynak grubunda olmayan yük dengeleyici genel IP'lerinin kaynak grubunu belirtin.
service.beta.kubernetes.io/azure-allowed-service-tags	İzin verilen hizmet etiketlerinin listesi	İzin verilen hizmet etiketlerinin listesini virgülle ayırarak belirtin.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout	Dakika cinsinden TCP boşta kalma zaman aşımları	Yük dengeleyicide TCP bağlantısı boşta kalma zaman aşımlarının gerçekleşeceğini dakika cinsinden belirtin. Varsayılan ve en düşük değer 4'dür. En yüksek değer 30'dur. Değer bir tamsayı olmalıdır.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset	true veya false	Yük dengeleyicinin boşta kalma zaman aşımında TCP sıfırlamayı devre dışı bırakması gerekip gerekmediğini belirtin.
service.beta.kubernetes.io/azure-load-balancer-ipv4	IPv4 adresi	Yük dengeleyiciye atanacak IPv4 adresini belirtin.
service.beta.kubernetes.io/azure-load-balancer-ipv6	IPv6 adresi	Yük dengeleyiciye atanacak IPv6 adresini belirtin.

Yük dengeleyici sistem durumu araştırmasını özelleştirme

Annotation	Value	Açıklama
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Sistem durumu yoklama aralığı
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Sistem durumu yoklaması için en az iyi durumda olmayan yanıt sayısı
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Sistem durumu yoklamasının istek yolu
service.beta.kubernetes.io/port_{port}_no_lb_rule	true/false	{port} hizmet bağlantı noktası numarasıdır. true olarak ayarlandığında, bu bağlantı noktası için lb kuralı veya durum yoklaması kuralı oluşturulmaz. Sistem durumu denetimi hizmeti genel İnternet'e açık olmamalıdır (ör. istio/envoy sistem durumu denetim hizmeti)
service.beta.kubernetes.io/port_{port}_no_probe_rule	true/false	{port} hizmet bağlantı noktası numarasıdır. true olarak ayarlandığında, bu bağlantı noktası için sistem durumu yoklaması kuralı oluşturulmaz.
service.beta.kubernetes.io/port_{port}_health-probe_protocol	Sistem durumu yoklama protokolü	{port} hizmet bağlantı noktası numarasıdır. {port} hizmet bağlantı noktası için durum yoklaması için açık protokol, ayarlanırsa port.appProtocol geçersiz kılınıyor.
service.beta.kubernetes.io/port_{port}_health-probe_port	hizmet bildiriminde bağlantı noktası numarası veya bağlantı noktası adı	{port} hizmet bağlantı noktası numarasıdır. {port} hizmet bağlantı noktası için durum yoklaması için varsayılan değeri geçersiz kılarak açık bağlantı noktası.
service.beta.kubernetes.io/port_{port}_health-probe_interval	Sistem durumu yoklama aralığı	{port} hizmet bağlantı noktası numarasıdır.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	Sistem durumu yoklaması için en az iyi durumda olmayan yanıt sayısı	{port} hizmet bağlantı noktası numarasıdır.
service.beta.kubernetes.io/port_{port}_health-probe_request-path	Sistem durumu yoklamasının istek yolu	{port} hizmet bağlantı noktası numarasıdır.

Burada belirtildiği gibi Tcp, Http ve Https, yük dengeleyici hizmeti tarafından desteklenen üç protokollerdir.

Şu anda sistem durumu yoklamasının varsayılan protokolü farklı aktarım protokollerine, uygulama protokollerine, ek açıklamalara ve dış trafik ilkelerine sahip hizmetler arasında değişiklik gösterir.

1. yerel hizmetler için HTTP ve /healthz kullanılabilir. Sistem durumu yoklaması gerçek arka uç hizmeti yerine NodeHealthPort'u sorgular
2. küme TCP hizmetleri için TCP kullanılır.
3. küme UDP hizmetleri için sistem durumu yoklaması yok.

Not

PLS tümleştirmesi ve PLS proxy protokolü etkinleştirilmiş yerel hizmetler için varsayılan HTTP+/healthz sistem durumu yoklaması çalışmaz. Bu nedenle sistem durumu yoklaması, bu senaryoyu desteklemek için küme hizmetleriyle aynı şekilde özelleştirilebilir.

v1.20'den bu yana sistem durumu yoklaması davranışını belirlemek için hizmet ek açıklaması service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path kullanıma sunulmuştur.

• =1.23 kümeleri <için, spec.ports.appProtocol yalnızca aynı zamanda ayarlandığında yoklama protokolü service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path olarak kullanılır.
• 1.24 kümeleri >için yoklama spec.ports.appProtocol protokolü olarak kullanılır ve / varsayılan yoklama isteği yolu olarak kullanılır (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path farklı bir istek yoluna geçmek için kullanılabilir).

TCP kullanılırken istek yolunun yoksayılacağına veya spec.ports.appProtocol boş olduğuna dikkat edin. Daha açık belirtmek gerekirse:

loadbalancer sku'su	externalTrafficPolicy	spec.ports.Protocol	spec.ports.AppProtocol	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	LB Yoklama Protokolü	LB Yoklaması İstek Yolu
standart	yerel	herhangi bir	herhangi bir	herhangi bir	http	/healthz
standart	cluster	Udp	herhangi bir	herhangi bir	null	null
standart	cluster	tcp		(yoksayıldı)	tcp	boş
standart	cluster	tcp	tcp	(yoksayıldı)	tcp	boş
standart	cluster	tcp	http/https		TCP(<=1.23) veya http/https(>=1.24)	null(<=1.23) veya /(>=1.24)
standart	cluster	tcp	http/https	/custom-path	http/https	/custom-path
standart	cluster	tcp	desteklenmeyen protokol	/custom-path	tcp	boş
Temel	yerel	herhangi bir	herhangi bir	herhangi bir	http	/healthz
Temel	cluster	tcp		(yoksayıldı)	tcp	boş
Temel	cluster	tcp	tcp	(yoksayıldı)	tcp	boş
Temel	cluster	tcp	http		TCP(<=1.23) veya http/https(>=1.24)	null(<=1.23) veya /(>=1.24)
Temel	cluster	tcp	http	/custom-path	http	/custom-path
Temel	cluster	tcp	desteklenmeyen protokol	/custom-path	tcp	boş

v1.21'den bu yana, sistem durumu yoklaması yapılandırmasını özelleştiren ve kullanıma sunulan iki hizmet ek açıklaması service.beta.kubernetes.io/azure-load-balancer-health-probe-intervalload-balancer-health-probe-num-of-probe . Ayarlanmadıysa service.beta.kubernetes.io/azure-load-balancer-health-probe-interval , Varsayılan değer olan 5 uygulanır. Ayarlanmadıysa load-balancer-health-probe-num-of-probe , Varsayılan değer olan 2 uygulanır. Toplam yoklama 120 saniyeden kısa olmalıdır.

Bağlantı noktası için özel Load Balancer sistem durumu yoklaması

Bir hizmetteki farklı bağlantı noktaları farklı durum yoklaması yapılandırmaları gerektirebilir. Bunun nedeni hizmet tasarımı (birden çok bağlantı noktasını denetleen tek bir sistem durumu uç noktası gibi) veya MixedProtocolLBService gibi Kubernetes özellikleri olabilir.

Hizmet bağlantı noktası başına yoklama yapılandırmasını özelleştirmek için aşağıdaki ek açıklamalar kullanılabilir.

bağlantı noktasına özgü ek açıklama	genel yoklama ek açıklaması	Kullanım
service.beta.kubernetes.io/port_{port}_no_lb_rule	Yok (genel olarak eşdeğeri yok)	true olarak ayarlanırsa lb kuralları ve yoklama kuralları oluşturulmaz
service.beta.kubernetes.io/port_{port}_no_probe_rule	Yok (genel olarak eşdeğeri yok)	true olarak ayarlanırsa yoklama kuralı oluşturulmaz
service.beta.kubernetes.io/port_{port}_health-probe_protocol	Yok (genel olarak eşdeğeri yok)	Bu hizmet bağlantı noktası için sistem durumu yoklaması protokolunu ayarlayın (örneğin, Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port	Yok (genel olarak eşdeğeri yok)	Bu hizmet bağlantı noktası için sistem durumu yoklaması bağlantı noktasını ayarlar (örn. 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Http veya Https için sistem durumu yoklaması istek yolunu ayarlar. Varsayılan olarak /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Bağlantı noktası iyi durumda değil olarak kabul edilmeden önce ardışık yoklama hatası sayısı
service.beta.kubernetes.io/port_{port}_health-probe_interval	service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Yoklama girişimleri arasındaki süre

Aşağıdaki bildirim için, httpsserver bağlantı noktası için ek açıklamalar belirtildiğinden httpsserver bağlantı noktası yoklama kuralı httpserver için olandan farklıdır.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

Bu bildirimde, https bağlantı noktaları farklı bir düğüm bağlantı noktası kullanır ve /healthz üzerinde 10256 numaralı bağlantı noktasında HTTP hazır olma denetimi (kube-proxy'nin healthz uç noktası).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Bu bildirimde, https bağlantı noktaları farklı bir durum yoklaması uç noktası kullanır ve /healthz/ready üzerinde 30000 numaralı bağlantı noktasında HTTP hazır olma denetimi gerçekleştirir.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

SNAT sorunlarını giderme

Aynı hedef IP adresine ve bağlantı noktasına çok sayıda giden TCP veya UDP bağlantısı başlatdığınızı biliyorsanız ve giden bağlantıların başarısız olduğunu gözlemlerseniz veya destek, SNAT bağlantı noktalarını (PAT tarafından kullanılan önceden ayrılmış kısa ömürlü bağlantı noktaları) tükettiklerini size bildirirse, çeşitli genel risk azaltma seçenekleriniz vardır. Bu seçenekleri gözden geçirin ve senaryonuz için en iyi seçeneklere karar verin. Bir veya daha fazla senaryonuzun yönetilmesine yardımcı olabilir. Ayrıntılı bilgi için giden bağlantılar sorun giderme kılavuzunu gözden geçirin.

SNAT tükenmesinin kök nedeni genellikle giden bağlantının nasıl kurulduğunu, yönetildiğini veya yapılandırılabilir zamanlayıcıların varsayılan değerlerinden nasıl değiştirildiğini gösteren bir desendir. Bu bölümü dikkatli bir şekilde inceleyin.

Adımlar

1. Bağlantılarınızın uzun süre boşta kalıp kalmadığını denetleyin ve bu bağlantı noktasını serbest bırakmak için varsayılan boşta kalma zaman aşımına bağlı kalın. Öyleyse, senaryonuz için varsayılan 30 dakikalık zaman aşımının azaltılması gerekebilir.
2. Uygulamanızın giden bağlantıyı nasıl oluşturduğunu araştırın (örneğin, kod gözden geçirme veya paket yakalama).
3. Bu etkinliğin beklenen davranış olup olmadığını veya uygulamanın yanlış davranıp davranmadığını belirleyin. Bulgularınızı doğrulamak için Azure İzleyici'deki ölçümleri ve günlükleri kullanın. Örneğin, SNAT bağlantıları ölçümü için "Başarısız" kategorisini kullanın.
4. Uygun desenlerin izlenip izlenmediğini değerlendirin.
5. SNAT bağlantı noktası tükenmesi daha fazla giden IP adresi ve daha fazla ayrılmış giden bağlantı noktası ile azaltılıp azaltılmaması gerektiğini değerlendirin.

Tasarım desenleri

Mümkün olduğunda bağlantı yeniden kullanımı ve bağlantı havuzu avantajlarından yararlanın. Bu desenler, kaynak tükenmesi sorunlarını önlemenize ve öngörülebilir davranışla sonuçlanmasında yardımcı olur. Bu desenler için temel öğeler birçok geliştirme kitaplığında ve çerçevesinde bulunabilir.

• Atomik istekler (bağlantı başına bir istek) genellikle iyi bir tasarım seçimi değildir. Bu tür desen karşıtlıkları ölçeği sınırlar, performansı azaltır ve güvenilirliği azaltır. Bunun yerine, bağlantı sayısını ve ilişkili SNAT bağlantı noktalarını azaltmak için HTTP/S bağlantılarını yeniden kullanın. TLS kullanırken el sıkışmalarının, ek yükün ve şifreleme işlemi maliyetinin azalması nedeniyle uygulama ölçeği artar ve performans artar.
• Küme dışı/özel DNS veya coreDNS'de özel yukarı akış sunucuları kullanıyorsanız, istemci DNS çözümleyicilerinin sonucunu önbelleğe almadığında DNS'nin birimdeki birçok ayrı akışa neden olabileceğini unutmayın. Özel DNS sunucuları kullanmak yerine önce coreDNS'yi özelleştirip iyi bir önbelleğe alma değeri tanımladığınızdan emin olun.
• UDP akışları (örneğin, DNS aramaları) boşta kalma zaman aşımı sırasında SNAT bağlantı noktalarını ayırır. Boşta kalma zaman aşımı ne kadar uzun olursa SNAT bağlantı noktaları üzerindeki baskı o kadar yüksek olur. Kısa boşta kalma zaman aşımı (örneğin, 4 dakika) kullanın.
• Bağlantı biriminizi şekillendirmek için bağlantı havuzlarını kullanın.
• Bir TCP akışını asla sessizce bırakmayın ve akışı temizlemek için TCP zamanlayıcılarına güvenmeyin. TCP'nin bağlantıyı açıkça kapatmasına izin vermezseniz, durum ara sistemlerde ve uç noktalarda ayrılmış olarak kalır ve SNAT bağlantı noktaları diğer bağlantılar için kullanılamaz duruma gelir. Bu düzen uygulama hatalarını ve SNAT tükenmesini tetikleyebilir.
• İşletim sistemi düzeyinde TCP'nin ilgili süreölçer değerlerini etki konusunda uzman bilgisi olmadan değiştirmeyin. TCP yığını kurtarılırken, bağlantının uç noktalarının beklentileri eşleşmediğinde uygulama performansınız olumsuz etkilenebilir. Zamanlayıcıları değiştirmek isteme, genellikle temel alınan bir tasarım sorununun işaretidir. Aşağıdaki önerileri gözden geçirin.

Temel SKU yük dengeleyiciden Standart SKU'ya geçme

Temel SKU yük dengeleyicisine sahip bir kümeniz varsa, Standart SKU yük dengeleyiciye geçiş yaparken dikkat edilmesi gereken önemli davranış farklılıkları vardır.

Örneğin, kümeleri geçirmek için mavi/yeşil dağıtımlar yapmak, küme türü göz önüne alındığında load-balancer-sku yaygın bir uygulamadır ve yalnızca küme oluşturma zamanında tanımlanabilir. Ancak Temel SKU yük dengeleyiciler, Standart SKU yük dengeleyicilerle uyumlu olmayan Temel SKU IP adreslerini kullanır. Standart SKU yük dengeleyiciler Için Standart SKU IP adresleri gerekir. Yük dengeleyici SKU'larını yükseltmek için kümeleri geçirirken, uyumlu bir IP adresi SKU'su ile yeni bir IP adresi gerekir.

Kümeleri geçirme hakkında daha fazla bilgi için geçişle ilgili dikkat edilmesi gerekenler hakkındaki belgelerimizi ziyaret edin.

Sınırlamalar

Standart SKU ile yük dengeleyiciyi destekleyen AKS kümeleri oluşturup yönetirken aşağıdaki sınırlamalar geçerlidir:

• AKS kümesinden çıkış trafiğine izin vermek için en az bir genel IP veya IP ön eki gereklidir. Genel IP veya IP ön eki, kontrol düzlemi ve aracı düğümleri arasındaki bağlantıyı korumak ve AKS'nin önceki sürümleriyle uyumluluğu korumak için gereklidir. Standart SKU yük dengeleyici ile genel IP'leri veya IP ön eklerini belirtmek için aşağıdaki seçeneklere sahipsiniz:
  • Kendi genel IP'lerinizi sağlayın.
  • Kendi genel IP ön eklerinizi sağlayın.
  • AKS kümesinin AKS kümesiyle aynı kaynak grubunda o kadar çok Standart SKU genel IP'yi oluşturmasına izin vermek için 100'e kadar bir sayı belirtin. Bu kaynak grubu genellikle başlangıçta MC_ ile adlandırılır. AKS, genel IP'yi Standart SKU yük dengeleyiciye atar. Varsayılan olarak, genel IP, genel IP ön eki veya IP sayısı belirtilmezse aks kümesiyle aynı kaynak grubunda otomatik olarak bir genel IP oluşturulur. Ayrıca genel adreslere izin vermeli ve IP oluşturmayı yasaklayan Azure ilkeleri oluşturmaktan kaçınmalısınız.
• AKS tarafından oluşturulan genel IP, “kendi genel IP adresini getir” özel ip adresi olarak yeniden kullanılamaz. Kullanıcıların tüm özel IP adreslerini oluşturması ve yönetmesi gerekir.
• Yük dengeleyici SKU'su tanımlama işlemi yalnızca AKS kümesi oluşturduğunuzda yapılabilir. AKS kümesi oluşturulduktan sonra yük dengeleyici SKU'sunu değiştiremezsiniz.
• Tek bir kümede yalnızca bir tür yük dengeleyici SKU'su (Temel veya Standart) kullanabilirsiniz.
• Standart SKU yük dengeleyiciler yalnızca Standart SKU IP adreslerini destekler.

Sonraki adımlar

Kubernetes hizmetleri hakkında daha fazla bilgi edinmek için Kubernetes hizmetleri belgelerine bakın.

Gelen trafik için iç yük dengeleyici kullanma hakkında daha fazla bilgi edinmek için AKS iç yük dengeleyici belgelerine bakın.