Použití veřejného standardního nástroje pro vyrovnávání zatížení ve službě Azure Kubernetes Service (AKS)

  • Článek

Azure Load Balancer funguje ve vrstvě 4 modelu OSI (Open Systems Interconnection), který podporuje příchozí i odchozí scénáře. Distribuuje příchozí toky, které přicházejí na front-end nástroje pro vyrovnávání zatížení do instancí back-endového fondu.

Veřejný nástroj pro vyrovnávání zatížení integrovaný s AKS slouží ke dvěma účelům:

  1. Pokud chcete poskytovat odchozí připojení k uzlům clusteru uvnitř virtuální sítě AKS tak, že přeložíte privátní IP adresu na veřejnou IP adresu, která je součástí jeho odchozího fondu.
  2. Pokud chcete poskytovat přístup k aplikacím prostřednictvím služeb Kubernetes typu LoadBalancer, které umožňují snadno škálovat aplikace a vytvářet vysoce dostupné služby.

Interní (nebo privátní) nástroj pro vyrovnávání zatížení se používá, pokud jsou jako front-end povoleny pouze privátní IP adresy. Interní nástroje pro vyrovnávání zatížení se používají k vyrovnávání zatížení provozu uvnitř virtuální sítě. Front-end nástroje pro vyrovnávání zatížení je také přístupný z místní sítě v hybridním scénáři.

Tento článek popisuje integraci s veřejným nástrojem pro vyrovnávání zatížení v AKS. Informace o integraci interního nástroje pro vyrovnávání zatížení najdete v tématu Použití interního nástroje pro vyrovnávání zatížení v AKS.

Než začnete

  • Azure Load Balancer je k dispozici ve dvou SKU: Basic a Standard. Skladová položka Standard se ve výchozím nastavení používá při vytváření clusteru AKS. Skladová položka Standard poskytuje přístup k přidaným funkcím, jako je větší back-endový fond, více fondů uzlů, Zóny dostupnosti a je ve výchozím nastavení zabezpečený. Jedná se o doporučenou skladovou položku nástroje pro vyrovnávání zatížení pro AKS. Další informace o cenových úrovních Basic a Standard najdete v porovnání skladových položek Azure Load Balanceru.
  • Úplný seznam podporovaných poznámek pro služby Kubernetes s typem LoadBalancernajdete v poznámkách LoadBalancer.
  • Tento článek předpokládá, že máte cluster AKS s azure Load Balancerem úrovně Standard . Pokud potřebujete cluster AKS, můžete ho vytvořit pomocí Azure CLI, Azure PowerShellu nebo webu Azure Portal.
  • AKS spravuje životní cyklus a operace uzlů agentů. Úprava prostředků IaaS přidružených k uzlům agenta se nepodporuje. Příkladem nepodporované operace je ruční změny ve skupině prostředků nástroje pro vyrovnávání zatížení.

Důležité

Pokud chcete k poskytování odchozího připojení raději použít vlastní bránu, bránu firewall nebo proxy server, můžete přeskočit vytvoření odchozího fondu nástroje pro vyrovnávání zatížení a příslušné front-endové IP adresy pomocí typu odchozích přenosů jako uživatelem Definovanérouting (UDR). Typ odchozích přenosů definuje metodu výchozího přenosu dat pro cluster a ve výchozím nastavení typ LoadBalancer.

Použití veřejného load balanceru úrovně Standard

Po vytvoření clusteru AKS s odchozím typem LoadBalancer (výchozí) je cluster připravený k použití nástroje pro vyrovnávání zatížení ke zveřejnění služeb.

Vytvořte manifest služby s názvem public-svc.yaml, který vytvoří veřejnou službu typu LoadBalancer.

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

Zadání IP adresy nástroje pro vyrovnávání zatížení

Pokud chcete použít konkrétní IP adresu s nástrojem pro vyrovnávání zatížení, existují dva způsoby:

Důležité

Přidání vlastnosti LoadBalancerIP do manifestu YAML nástroje pro vyrovnávání zatížení zastaralá po upstreamu Kubernetes. I když současné využití zůstává stejné a očekává se, že stávající služby budou fungovat bez úprav, důrazně doporučujeme místo toho nastavit poznámky ke službám .

  • Nastavení poznámek služby: Slouží service.beta.kubernetes.io/azure-load-balancer-ipv4 pro adresu IPv4 a service.beta.kubernetes.io/azure-load-balancer-ipv6 pro adresu IPv6.
  • Do manifestu YAML nástroje pro vyrovnávání zatížení přidejte vlastnost LoadBalancerIP: Přidejte vlastnost Service.Spec.LoadBalancerIP do manifestu YAML nástroje pro vyrovnávání zatížení. Toto pole zastaralá po upstreamu Kubernetes a nemůže podporovat duální stack. Aktuální využití zůstává stejné a očekává se, že stávající služby budou fungovat beze změny.

Nasazení manifestu služby

Nasaďte manifest veřejné služby pomocí kubectl apply a zadejte název manifestu YAML.

kubectl apply -f public-svc.yaml

Azure Load Balancer se konfiguruje s novou veřejnou IP adresou, která předčítá novou službu. Vzhledem k tomu, že Azure Load Balancer může mít několik IP adres front-endu, získá každá nová služba, kterou nasadíte, novou vyhrazenou IP adresu front-endu, ke které se má jedinečný přístup.

Ověřte, že je vaše služba vytvořená a nástroj pro vyrovnávání zatížení je nakonfigurovaný pomocí následujícího příkazu.

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

Při zobrazení podrobností služby se veřejná IP adresa vytvořená pro tuto službu v nástroji pro vyrovnávání zatížení zobrazí ve sloupci EXTERNAL-IP . Může trvat několik minut, než se IP adresa změní z <čekání> na skutečnou veřejnou IP adresu.

Podrobnější informace o vaší službě získáte pomocí následujícího příkazu.

kubectl describe service public-svc

Následující příklad výstupu je zhuštěná verze výstupu po spuštění kubectl describe service. Příchozí přenos dat LoadBalanceru zobrazuje externí IP adresu vystavenou vaší službou. IP adresa zobrazuje interní adresy.

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
...

Konfigurace veřejného load balanceru úrovně Standard

Při vytváření clusteru nebo aktualizací clusteru můžete přizpůsobit různá nastavení pro váš standardní veřejný nástroj pro vyrovnávání zatížení. Tyto možnosti přizpůsobení umožňují vytvořit nástroj pro vyrovnávání zatížení, který vyhovuje vašim potřebám úloh. S nástrojem pro vyrovnávání zatížení úrovně Standard můžete:

  • Nastavte nebo škálujte počet spravovaných odchozích IP adres.
  • Přineste si vlastní odchozí IP adresy nebo předponu odchozíCH IP adres.
  • Přizpůsobte počet přidělených odchozích portů každému uzlu v clusteru.
  • Nakonfigurujte nastavení časového limitu pro nečinná připojení.

Důležité

V daném okamžiku se dá použít jenom jedna možnost odchozí IP adresy (spravované IP adresy, přineste si vlastní IP adresu nebo předponu IP adresy).

Změna typu příchozího fondu

Na uzly AKS je možné odkazovat v back-endových fondech nástroje pro vyrovnávání zatížení pomocí konfigurace IP adresy (členství na škálovacích sadách virtuálních počítačů Azure) nebo pouze podle jejich IP adresy. Využití členství back-endového fondu založeného na IP adresách poskytuje vyšší efektivitu při aktualizaci služeb a zřizování nástrojů pro vyrovnávání zatížení, zejména při vysokých počtech uzlů. Zřizování nových clusterů s back-endovými fondy založenými na IP adresách a převod stávajících clusterů se teď podporuje. V kombinaci se službou NAT Gateway nebo uživatelem definovanými typy výchozího přenosu dat jsou zřizování nových uzlů a služeb výkonnější.

K dispozici jsou dva různé typy členství ve fondu:

  • nodeIPConfiguration – starší verze typu členství ve fondu založeném na konfiguraci škálovacích sad virtuálních počítačů
  • nodeIP – Typ členství na základě IP adresy

Požadavky

  • Cluster AKS musí být verze 1.23 nebo novější.
  • Cluster AKS musí používat standardní nástroje pro vyrovnávání zatížení a škálovací sady virtuálních počítačů.

Vytvoření nového clusteru AKS s členstvím v příchozím fondu založeném na IP adrese

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

Aktualizace existujícího clusteru AKS tak, aby používal členství v příchozím fondu založeném na IP adrese

Upozorňující

Tato operace způsobí dočasné přerušení příchozího provozu služby v clusteru. Doba dopadu se zvyšuje u větších clusterů, které mají mnoho uzlů.

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

Škálování počtu spravovaných odchozích veřejných IP adres

Azure Load Balancer poskytuje odchozí a příchozí připojení z virtuální sítě. Odchozí pravidla usnadňují konfiguraci překladu síťových adres pro veřejný load balancer úrovně Standard.

Odchozí pravidla se řídí stejnou syntaxí jako vyrovnávání zatížení a příchozí pravidla překladu adres (NAT):

IP adresy front-endu + parametry + back-endový fond

Odchozí pravidlo konfiguruje odchozí překlad adres (NAT) pro všechny virtuální počítače identifikované back-endovým fondem tak, aby se překládaly na front-end. Parametry poskytují větší kontrolu nad odchozím algoritmem NAT.

I když můžete použít odchozí pravidlo s jednou veřejnou IP adresou, pravidla odchozích přenosů jsou skvělá pro škálování odchozího překladu adres ( NAT), protože usnadňují zátěž konfigurace. K plánování rozsáhlých scénářů a pravidel odchozích přenosů můžete použít více IP adres, abyste mohli zmírnit náchylné vzorce vyčerpání SNAT. Každá IP adresa poskytovaná front-endem poskytuje 64k dočasných portů, které nástroj pro vyrovnávání zatížení použije jako porty SNAT.

Pokud používáte nástroj pro vyrovnávání zatížení skladové položky Standard se spravovanými veřejnými IP adresami odchozích přenosů (které se ve výchozím nastavení vytvářejí), můžete pomocí parametru --load-balancer-managed-outbound-ip-count škálovat počet spravovaných veřejných IP adres odchozích přenosů.

K aktualizaci existujícího clusteru použijte následující příkaz. Tento parametr můžete také nastavit tak, aby měl několik spravovaných odchozích veřejných IP adres.

Důležité

K provedení jakýchkoli změn odchozích pravidel nedoporučujeme používat Azure Portal. Při provádění těchto změn byste měli projít cluster AKS, nikoli přímo na prostředek Load Balanceru.

Změny odchozích pravidel provedené přímo u prostředku Load Balanceru se odeberou při každém odsouhlasení clusteru, například při zastavení, spuštění, upgradu nebo škálování clusteru.

Použijte Azure CLI, jak je znázorněno v příkladech. Změny odchozích pravidel provedených pomocí az aks příkazů rozhraní příkazového řádku jsou trvalé napříč výpadky clusteru.

Další informace najdete v tématu Odchozí pravidla služby Azure Load Balancer.

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

Výše uvedený příklad nastaví počet spravovaných odchozích veřejných IP adres na 2 pro cluster myAKSCluster v myResourceGroup.

Při vytváření clusteru můžete také nastavit počáteční počet spravovaných veřejných IP adres odchozích přenosů tak, že připojíte --load-balancer-managed-outbound-ip-count parametr a nastavíte ho na požadovanou hodnotu. Výchozí počet spravovaných odchozích veřejných IP adres je 1.

Zadejte vlastní odchozí veřejné IP adresy nebo předpony.

Pokud používáte nástroj pro vyrovnávání zatížení skladové položky Standard , cluster AKS automaticky vytvoří veřejnou IP adresu ve skupině prostředků infrastruktury spravované službou AKS a ve výchozím nastavení ji přiřadí odchozímu fondu nástroje pro vyrovnávání zatížení.

Veřejná IP adresa vytvořená službou AKS je prostředek spravovaný službou AKS, což znamená, že AKS spravuje životní cyklus této veřejné IP adresy a nevyžaduje akci uživatele přímo u prostředku veřejné IP adresy. Případně můžete při vytváření clusteru přiřadit vlastní veřejnou IP adresu nebo předponu veřejné IP adresy. Vlastní IP adresy je také možné aktualizovat ve vlastnostech nástroje pro vyrovnávání zatížení existujícího clusteru.

Mezi požadavky pro použití vlastní veřejné IP adresy nebo předpony patří:

  • Uživatelé musí vytvářet a vlastnit vlastní veřejné IP adresy. Spravované veřejné IP adresy vytvořené službou AKS se nedají znovu použít jako "přineste si vlastní IP adresu", protože to může způsobit konflikty správy.
  • Musíte zajistit, aby identita clusteru AKS (instanční objekt nebo spravovaná identita) má oprávnění pro přístup k odchozí IP adrese podle seznamu požadovaných veřejných IP oprávnění.
  • Ujistěte se, že splňujete požadavky a omezení potřebná ke konfiguraci odchozích IP adres nebo předpon odchozích IP adres.

Aktualizace clusteru vlastní odchozí veřejnou IP adresou

az network public-ip show Pomocí příkazu zobrazte seznam ID veřejných IP adres.

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

Výše uvedený příkaz zobrazí ID veřejné IP adresy myPublicIP ve skupině prostředků myResourceGroup .

az aks update Pomocí příkazu s parametrem load-balancer-outbound-ips aktualizujte cluster vašimi veřejnými IP adresami.

Následující příklad používá load-balancer-outbound-ips parametr s ID z předchozího příkazu.

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

Aktualizace clusteru pomocí vlastní předpony veřejné IP adresy odchozích přenosů

Pro výchozí přenos dat s nástrojem pro vyrovnávání zatížení skladové položky Standard můžete také použít předpony veřejných IP adres. Následující příklad používá příkaz az network public-ip prefix show k výpisu ID předpon veřejných IP adres.

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

Výše uvedený příkaz zobrazí ID předpony veřejné IP adresy myPublicIPPrefix ve skupině prostředků myResourceGroup .

Následující příklad používá parametr load-balancer-outbound-ip-prefixes s ID z předchozího příkazu.

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

Vytvoření clusteru s vlastní veřejnou IP adresou nebo předponami

Při vytváření clusteru můžete použít vlastní IP adresy nebo předpony IP adres pro výchozí přenos dat, abyste mohli podporovat scénáře, jako je přidání koncových bodů výchozího přenosu dat do seznamu povolených přenosů dat. Pokud chcete definovat vlastní veřejné IP adresy a předpony IP adres při vytváření clusteru, připojte stejné parametry uvedené v předchozím příkazu.

az aks create Pomocí příkazu s parametrem load-balancer-outbound-ips vytvořte nový cluster s vlastními veřejnými IP adresami.

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

az aks create Pomocí příkazu s parametrem load-balancer-outbound-ip-prefixes vytvořte nový cluster s vlastními předponami veřejné IP adresy.

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

Konfigurace přidělených odchozích portů

Důležité

Pokud máte aplikace v clusteru, které můžou navázat velký počet připojení k malé sadě cílů, jako je mnoho instancí front-endové aplikace připojující se k databázi, může být scénář náchylný k vyčerpání portů SNAT. K vyčerpání portů SNAT dochází v případě, že aplikace vyčerpá odchozí porty, které se mají použít k navázání připojení k jiné aplikaci nebo hostiteli. Pokud máte scénář náchylný k vyčerpání portů SNAT, důrazně doporučujeme zvýšit přidělené odchozí porty a odchozí IP adresy front-endu v nástroji pro vyrovnávání zatížení.

Další informace o SNAT najdete v tématu Použití SNAT pro odchozí připojení.

Ve výchozím nastavení nastaví AKS na svém nástroji 0pro vyrovnávání zatížení přidělené porty PřidělenéOutboundPorts, což umožňuje automatické přiřazování portů odchozích přenosů na základě velikosti back-endového fondu při vytváření clusteru. Pokud má například cluster 50 nebo méně uzlů, přidělí se každému uzlu 1024 portů. S rostoucím počtem uzlů v clusteru je na jeden uzel k dispozici méně portů.

Důležité

Existuje pevný limit 1024 portů bez ohledu na to, jestli se přidají IP adresy front-endu, pokud je velikost uzlu menší nebo rovna 50 (1–50).

Pokud chcete zobrazit hodnotu AllocatedOutboundPorts pro nástroj pro vyrovnávání zatížení clusteru AKS, použijte 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

Následující příklad výstupu ukazuje, že pro cluster je povolené automatické přiřazení portů odchozích přenosů na základě velikosti back-endového fondu.

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

Konfigurace konkrétní hodnoty pro AllocatedOutboundPorts a odchozí IP adresu při vytváření nebo aktualizaci clusteru, použijte a buď load-balancer-outbound-portsload-balancer-managed-outbound-ip-count, load-balancer-outbound-ipsnebo load-balancer-outbound-ip-prefixes. Před nastavením konkrétní hodnoty nebo zvýšením stávající hodnoty pro odchozí porty nebo odchozí IP adresy musíte vypočítat odpovídající počet odchozích portů a IP adres. Pro tento výpočet použijte následující rovnici zaokrouhlenou na nejbližší celé číslo: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Při výpočtu počtu odchozích portů a IP adres a nastavení hodnot mějte na paměti následující informace:

  • Počet odchozích portů na uzel je pevný na základě hodnoty, kterou jste nastavili.
  • Hodnota odchozích portů musí být násobkem 8.
  • Přidání dalších IP adres nepřidá do žádného uzlu další porty, ale poskytuje kapacitu pro další uzly v clusteru.
  • Musíte počítat s uzly, které se můžou přidat jako součást upgradů, včetně počtu uzlů zadaných prostřednictvím maximálních hodnot.

Následující příklady ukazují, jak nastavené hodnoty ovlivňují počet odchozích portů a IP adres:

  • Pokud se použijí výchozí hodnoty a cluster má 48 uzlů, každý uzel má k dispozici 1024 portů.
  • Pokud se použijí výchozí hodnoty a cluster se škáluje z 48 na 52 uzlů, každý uzel se aktualizuje z 1024 portů dostupných na 512 dostupných portů.
  • Pokud je počet odchozích portů nastavený na 1 000 a počet odchozích IP adres je nastavený na 2, může cluster podporovat maximálně 128 uzlů: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • Pokud je počet odchozích portů nastavený na 1 000 a počet odchozích IP adres je nastavený na 7, cluster může podporovat maximálně 448 uzlů: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • Pokud je počet odchozích portů nastavený na 4 000 a počet odchozích IP adres je nastavený na 2, cluster může podporovat maximálně 32 uzlů: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • Pokud je počet odchozích portů nastavený na 4 000 a počet odchozích IP adres je nastavený na 7, cluster může podporovat maximálně 112 uzlů: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Důležité

Po výpočtu počtu odchozích portů a IP adres ověřte, že máte další kapacitu odchozích portů pro zpracování nárůstu uzlu během upgradů. Je důležité přidělit dostatečné nadbytečné porty pro další uzly potřebné pro upgrade a další operace. Výchozí hodnota AKS je jeden uzel vyrovnávací paměti pro operace upgradu. Pokud používáte hodnoty maxSurge, vynásobte odchozí porty na uzel hodnotou maxSurge a určete požadovaný počet portů. Pokud například vypočítáte, že potřebujete 4000 portů na uzel s 7 IP adresou v clusteru s maximálně 100 uzly a maximální nárůst 2:

  • 2 přepětí uzlů * 4 000 portů na uzel = 8000 portů potřebných pro přepětí uzlů během upgradů.
  • 100 uzlů * 4000 portů na uzel = 400 000 portů požadovaných pro váš cluster.
  • 7 IP adres * 64000 portů na IP adresu = 448 000 portů dostupných pro váš cluster.

Výše uvedený příklad ukazuje, že cluster má nadbytečnou kapacitu 48 000 portů, což je dostatečné pro zpracování 8000 portů potřebných pro nárůst uzlu během upgradů.

Po výpočtu a ověření hodnot můžete tyto hodnoty použít buď pomocí load-balancer-outbound-portsload-balancer-managed-outbound-ip-countload-balancer-outbound-ips, nebo load-balancer-outbound-ip-prefixes při vytváření nebo aktualizaci clusteru.

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

Konfigurace časového limitu nečinnosti nástroje pro vyrovnávání zatížení

Když dojde k vyčerpání prostředků portů SNAT, odchozí toky selžou, dokud stávající toky nevyvolají porty SNAT. Nástroj pro vyrovnávání zatížení uvolní porty SNAT při zavření toku a nástroj pro vyrovnávání zatížení nakonfigurovaný službou AKS využívá 30minutový časový limit nečinnosti pro uvolnění portů SNAT z nečinných toků.

Přenos (například TCP keepalives ) application-layer keepalivesmůžete použít také k aktualizaci nečinných toků a resetování časového limitu nečinnosti v případě potřeby. Tento časový limit můžete nakonfigurovat podle následujícího příkladu.

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

Pokud očekáváte, že budete mít řadu krátkodobých připojení a žádná dlouhodobá připojení, která můžou mít dlouhou dobu nečinnosti, jako je použití kubectl proxy nebo kubectl port-forward, zvažte použití nízké hodnoty časového limitu, například 4 minuty. Pokud používáte protokol TCP keepalives, stačí je povolit na jedné straně připojení. Stačí jim například povolit na straně serveru pouze resetování časovače nečinnosti toku. Není nutné, aby obě strany spustily protokol TCP keepalives. Pro aplikační vrstvu existují podobné koncepty, včetně konfigurací databázového klientského serveru. Na straně serveru zkontrolujte, jaké možnosti existují pro uchování specifické pro aplikaci.

Důležité

AKS ve výchozím nastavení povoluje resetování protokolu TCP v nečinnosti. Doporučujeme zachovat tuto konfiguraci a využít ji k předvídatelnějšímu chování aplikací ve vašich scénářích.

Protokol TCP RST se odesílá pouze během připojení TCP ve stavu ESTABLISHED. Další informace najdete tady.

Při nastavování hodnoty IdleTimeoutInMinutes na jinou hodnotu než výchozí hodnota 30 minut zvažte, jak dlouho vaše úlohy potřebují odchozí připojení. Zvažte také, že výchozí hodnota časového limitu pro nástroj pro vyrovnávání zatížení skladové položky Standard , která se používá mimo AKS, je 4 minuty. Hodnota IdleTimeoutInMinutes , která přesněji odráží vaši konkrétní úlohu AKS, může pomoct snížit vyčerpání SNAT způsobené propojením, která se už nepoužívají.

Upozorňující

Změna hodnot pro AllocatedOutboundPorts a IdleTimeoutInMinutes může výrazně změnit chování pravidla odchozích přenosů pro váš nástroj pro vyrovnávání zatížení a nemělo by se provádět mírně. Než aktualizujete tyto hodnoty, projděte si část Řešení potíží s SNAT a projděte si pravidlaodchozích přenosů a odchozí připojení Load Balanceru v Azure, abyste plně porozuměli dopadu změn.

Omezení příchozího provozu na konkrétní rozsahy IP adres

Následující manifest používá loadBalancerSourceRanges k určení nového rozsahu IP adres pro příchozí externí provoz.

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

Tento příklad aktualizuje pravidlo tak, aby umožňovalo příchozí externí provoz pouze z rozsahu MY_EXTERNAL_IP_RANGE . Pokud nahradíte MY_EXTERNAL_IP_RANGE IP adresou interní podsítě, provoz se omezí jenom na interní IP adresy clusteru. Pokud je provoz omezený na interní IP adresy clusteru, klienti mimo cluster Kubernetes nemají přístup k nástroji pro vyrovnávání zatížení.

Poznámka:

  • Příchozí externí provoz proudí z nástroje pro vyrovnávání zatížení do virtuální sítě pro váš cluster AKS. Virtuální síť má skupinu zabezpečení sítě (NSG), která umožňuje veškerý příchozí provoz z nástroje pro vyrovnávání zatížení. Tato skupina zabezpečení sítě používá značku služby typu LoadBalancer k povolení provozu z nástroje pro vyrovnávání zatížení.
  • Pod CIDR by se měl přidat do loadBalancerSourceRanges, pokud existují pody, které potřebují přístup k IP adrese LoadBalanceru služby pro clustery verze 1.25 nebo vyšší.

Údržba IP adresy klienta u příchozích připojení

Ve výchozím nastavení služba typu LoadBalancerv Kubernetes a v AKS neuchová IP adresu klienta v připojení k podu. Zdrojová IP adresa paketu, který se doručí do podu, se stane privátní IP adresou uzlu. Pokud chcete zachovat IP adresu klienta, musíte service.spec.externalTrafficPolicy nastavit local v definici služby. Následující manifest ukazuje příklad.

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

Přizpůsobení prostřednictvím poznámek Kubernetes

Následující poznámky jsou podporovány pro služby Kubernetes s typem LoadBalancera vztahují se pouze na příchozí toky.

Poznámka Hodnota Popis
service.beta.kubernetes.io/azure-load-balancer-internal true nebo false Určete, jestli má být nástroj pro vyrovnávání zatížení interní. Pokud není nastavená, nastaví se jako veřejná.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Název podsítě Určete, ke které podsíti má být interní nástroj pro vyrovnávání zatížení vázán. Pokud není nastavená, nastaví se výchozí hodnota podsítě nakonfigurované v konfiguračním souboru cloudu.
service.beta.kubernetes.io/azure-dns-label-name Název popisku DNS na veřejných IP adresách Zadejte název popisku DNS pro veřejnou službu. Pokud je nastavená na prázdný řetězec, položka DNS ve veřejné IP adrese se nepoužívá.
service.beta.kubernetes.io/azure-shared-securityrule true nebo false Určete zveřejnění služby prostřednictvím potenciálně sdíleného pravidla zabezpečení Azure za účelem zvýšení vystavení služby pomocí rozšířených pravidel zabezpečení Azure ve skupinách zabezpečení sítě.
service.beta.kubernetes.io/azure-load-balancer-resource-group Název skupiny prostředků Zadejte skupinu prostředků veřejných IP adres nástroje pro vyrovnávání zatížení, které nejsou ve stejné skupině prostředků jako infrastruktura clusteru (skupina prostředků uzlu).
service.beta.kubernetes.io/azure-allowed-service-tags Seznam povolených značek služeb Zadejte seznam povolených značek služeb oddělených čárkami.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Vypršení časového limitu nečinnosti protokolu TCP v minutách Zadejte dobu v minutách pro vypršení časového limitu nečinnosti připojení TCP v nástroji pro vyrovnávání zatížení. Výchozí a minimální hodnota je 4. Maximální hodnota je 30. Hodnota musí být celé číslo.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true nebo false Určete, jestli má nástroj pro vyrovnávání zatížení zakázat resetování protokolu TCP při vypršení časového limitu nečinnosti.
service.beta.kubernetes.io/azure-load-balancer-ipv4 Adresa protokolu IPv4 Zadejte adresu IPv4, kterou chcete přiřadit nástroji pro vyrovnávání zatížení.
service.beta.kubernetes.io/azure-load-balancer-ipv6 IPv6 adresa Zadejte adresu IPv6, kterou chcete přiřadit nástroji pro vyrovnávání zatížení.

Přizpůsobení sondy stavu nástroje pro vyrovnávání zatížení

Poznámka Hodnota Popis
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Interval sondy stavu
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Minimální počet odpovědí, které nejsou v pořádku sondy stavu
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Cesta požadavku sondy stavu
service.beta.kubernetes.io/port_{port}_no_lb_rule true/false {port} je číslo portu služby. Pokud je nastavená hodnota true, nevygeneruje se žádné pravidlo nástroje pro vyrovnávání zatížení ani pravidlo sondy stavu pro tento port. Služba kontroly stavu by neměla být vystavená veřejnému internetu (např. istio/služba kontroly stavu envoy)
service.beta.kubernetes.io/port_{port}_no_probe_rule true/false {port} je číslo portu služby. Pokud je nastavená hodnota true, nevygeneruje se žádné pravidlo sondy stavu pro tento port.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protokol sondy stavu {port} je číslo portu služby. Explicitní protokol sondy stavu pro port služby {port} přepisuje port.appProtocol, pokud je nastavený.
service.beta.kubernetes.io/port_{port}_health-probe_port číslo portu nebo název portu v manifestu služby {port} je číslo portu služby. Explicitní port sondy stavu pro port služby {port} přepisuje výchozí hodnotu.
service.beta.kubernetes.io/port_{port}_health-probe_interval Interval sondy stavu {port} je číslo portu služby.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe Minimální počet odpovědí, které nejsou v pořádku sondy stavu {port} je číslo portu služby.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Cesta požadavku sondy stavu {port} je číslo portu služby.

Jak je uvedeno tady, protokoly Tcp, Http a Https jsou podporované službou nástroje pro vyrovnávání zatížení tři protokoly.

Výchozí protokol sondy stavu se v současné době liší mezi službami s různými přenosovými protokoly, aplikačními protokoly, poznámkami a externími zásadami provozu.

  1. pro místní služby by se použily protokoly HTTP a /healthz. Sonda stavu bude dotazovat NodeHealthPort místo skutečné back-endové služby.
  2. pro clusterové služby TCP by se použil protokol TCP.
  3. pro služby UDP clusteru žádné sondy stavu.

Poznámka:

U místních služeb s povolenou integrací PLS a proxy protokolem PLS nefunguje výchozí sonda stavu HTTP+/healthz. Sondu stavu je tedy možné přizpůsobit stejným způsobem jako služby clusteru, aby tento scénář podporovaly.

Od verze 1.20 se zavádí poznámka service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path služby, která určuje chování sondy stavu.

  • U clusterů <=1,23 spec.ports.appProtocol by se jako protokol sondy použil pouze v případě, že service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path je nastavený.
  • Pro clustery 1.24 spec.ports.appProtocol by se použil jako protokol sondy a / použil by se jako výchozí cesta požadavku sondy >(service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path lze ji použít ke změně na jinou cestu požadavku).

Všimněte si, že cesta k požadavku by byla ignorována při použití protokolu TCP nebo spec.ports.appProtocol je prázdná. Konkrétně:

Skladová položka nástroje pro vyrovnávání zatížení externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Protokol sondy nástroje LB Cesta požadavku sondy nástroje pro vyrovnávání zatížení
standard local jakékoliv jakékoliv jakékoliv http /healthz
standard cluster Udp jakékoliv jakékoliv null null
standard cluster tcp (ignorováno) tcp null
standard cluster tcp tcp (ignorováno) tcp null
standard cluster tcp http/https TCP(<=1.23) nebo http/https(>=1.24) null(<=1,23) nebo /(>=1,24)
standard cluster tcp http/https /custom-path http/https /custom-path
standard cluster tcp nepodporovaný protokol /custom-path tcp null
Základní local jakékoliv jakékoliv jakékoliv http /healthz
Základní cluster tcp (ignorováno) tcp null
Základní cluster tcp tcp (ignorováno) tcp null
Základní cluster tcp http TCP(<=1.23) nebo http/https(>=1.24) null(<=1,23) nebo /(>=1,24)
Základní cluster tcp http /custom-path http /custom-path
Základní cluster tcp nepodporovaný protokol /custom-path tcp null

Od verze 1.21 jsou zavedeny dvě poznámky service.beta.kubernetes.io/azure-load-balancer-health-probe-intervalload-balancer-health-probe-num-of-probe služby, které přizpůsobují konfiguraci sondy stavu. Pokud service.beta.kubernetes.io/azure-load-balancer-health-probe-interval není nastavená, použije se výchozí hodnota 5. Pokud load-balancer-health-probe-num-of-probe není nastavená, použije se výchozí hodnota 2. Celková sonda by měla být menší než 120 sekund.

Vlastní sonda stavu Load Balanceru pro port

Různé porty ve službě můžou vyžadovat různé konfigurace sond stavu. Důvodem může být návrh služby (například jeden koncový bod stavu, který řídí více portů) nebo funkce Kubernetes, jako je MixedProtocolLBService.

Následující poznámky lze použít k přizpůsobení konfigurace sondy na port služby.

anotace specifická pro port globální poznámka sondy Využití
service.beta.kubernetes.io/port_{port}_no_lb_rule Není k dispozici (žádný ekvivalent globálně) pokud je nastavená hodnota true, nebudou generována žádná pravidla nástroje pro vyrovnávání zatížení a pravidla sondy.
service.beta.kubernetes.io/port_{port}_no_probe_rule Není k dispozici (žádný ekvivalent globálně) pokud je nastavená hodnota true, nevygenerují se žádná pravidla sondy.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Není k dispozici (žádný ekvivalent globálně) Nastavte protokol sondy stavu pro tento port služby (např. Http, Https, Tcp).
service.beta.kubernetes.io/port_{port}_health-probe_port Není k dispozici (žádný ekvivalent globálně) Nastaví port sondy stavu pro tento port služby (např. 15021).
service.beta.kubernetes.io/port_{port}cesta _health-probe_request service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Pro http nebo https nastaví cestu požadavku sondy stavu. Výchozí hodnota /
service.beta.kubernetes.io/port_{port}_health-probe_num-sonda service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Počet po sobě jdoucích selhání sondy před tím, než se port považuje za chybný
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Doba mezi pokusy sondy

V následujícím manifestu se pravidlo sondy pro port httpsserver liší od pravidla testu pro server http, protože jsou zadány poznámky pro port httpsserver.

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

V tomto manifestu používají porty HTTPS jiný port uzlu, kontrolu připravenosti HTTP na portu 10256 na /healthz(koncový bod stavu kube-proxy).

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

V tomto manifestu používají porty HTTPS jiný koncový bod sondy stavu, kontrolu připravenosti HTTP na portu 30000 v /healthz/ready.

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

Řešení potíží s SNAT

Pokud víte, že spouštíte řadu odchozích připojení TCP nebo UDP ke stejné cílové IP adrese a portu a zjistíte, že odchozí připojení nebo podpora vás upozorní, že vyčerpáte porty SNAT (předem nepřidělené dočasné porty používané patem), máte několik obecných možností omezení rizik. Projděte si tyto možnosti a rozhodněte se, co je pro váš scénář nejvhodnější. Je možné, že jeden nebo více vám může pomoct se správou vašeho scénáře. Podrobné informace najdete v průvodci odstraňováním potíží s odchozími připojeními.

Hlavní příčinou vyčerpání SNAT je často anti-vzor pro to, jak se navazuje, spravuje nebo konfigurovatelné časovače mění z jejich výchozích hodnot. Pečlivě si prostudujte tuto část.

Kroky

  1. Zkontrolujte, jestli připojení zůstávají dlouho nečinná, a při uvolnění daného portu se spoléhá na výchozí časový limit nečinnosti. Pokud ano, výchozí časový limit 30 minut může být pro váš scénář potřeba snížit.
  2. Prozkoumejte, jak vaše aplikace vytváří odchozí připojení (například kontrola kódu nebo zachytávání paketů).
  3. Určete, jestli je tato aktivita očekávaná nebo jestli se aplikace nechová správně. Využijte metriky a protokoly ve službě Azure Monitor k podsadení vašich zjištění. Například pro metriku připojení SNAT použijte kategorii Selhání.
  4. Vyhodnoťte, jestli jsou dodrženy vhodné vzory .
  5. Vyhodnoťte, jestli by se mělo zmírnit vyčerpání portů SNAT s více odchozími IP adresami a více přidělenými odchozími porty.

Vzory návrhu

Kdykoli je to možné, využijte možnost opakovaného použití připojení a sdružování připojení. Tyto vzory pomáhají vyhnout se problémům s vyčerpáním prostředků a vést k předvídatelnému chování. Primitiva pro tyto vzory najdete v mnoha vývojových knihovnách a architekturách.

  • Atomické požadavky (jeden požadavek na připojení) obecně nejsou dobrou volbou návrhu. Takové anti-vzory omezují škálování, snižují výkon a snižují spolehlivost. Místo toho znovu použijte připojení HTTP/S, abyste snížili počet připojení a přidružených portů SNAT. Škálování aplikace se zvyšuje a zvyšuje výkon kvůli nižším nákladům na handshake, režii a náklady na kryptografické operace při použití protokolu TLS.
  • Pokud používáte mimo cluster nebo vlastní DNS nebo vlastní nadřazené servery v coreDNS, mějte na paměti, že DNS může na svazku zavést mnoho jednotlivých toků, když klient neukládá výsledek překladačů DNS do mezipaměti. Nezapomeňte nejprve přizpůsobit coreDNS místo použití vlastních serverů DNS a definovat dobrou hodnotu ukládání do mezipaměti.
  • Toky UDP (například vyhledávání DNS) přidělují porty SNAT během časového limitu nečinnosti. Čím delší je časový limit nečinnosti, tím vyšší je tlak na porty SNAT. Použijte krátký časový limit nečinnosti (například 4 minuty).
  • Pomocí fondů připojení můžete tvarovat svazek připojení.
  • Nikdy neuklánět tok TCP a spoléhat se na časovače TCP k vyčištění toku. Pokud nechcete, aby tcp připojení explicitně zavřel, zůstane stav přidělený v přechodných systémech a koncových bodech a znepřístupňuje porty SNAT pro ostatní připojení. Tento model může aktivovat selhání aplikace a vyčerpání SNAT.
  • Neměňte hodnoty časovače související s protokolem TCP na úrovni operačního systému bez odborných znalostí o dopadu. Zatímco se zásobník TCP obnoví, výkon aplikace může být negativně ovlivněn, když koncové body připojení neodpovídají očekávání. Chcete-li změnit časovače, je obvykle znaménkem základního problému s návrhem. Projděte si následující doporučení.

Přechod z nástroje pro vyrovnávání zatížení skladové položky Basic na skladovou položku Standard

Pokud máte existující cluster s nástrojem pro vyrovnávání zatížení skladové položky Basic , při migraci na nástroj pro vyrovnávání zatížení skladové položky Standard existují důležité rozdíly v chování.

Například nasazení s modrou nebo zelenou barvou pro migraci clusterů je běžným postupem vzhledem k load-balancer-sku typu clusteru a dá se definovat pouze v době vytvoření clusteru. Nástroje pro vyrovnávání zatížení skladové položky Basic ale používají IP adresy skladové položky Basic, které nejsou kompatibilní s nástroji pro vyrovnávání zatížení skladové položky Standard. Nástroje pro vyrovnávání zatížení skladových položek úrovně Standard vyžadují IP adresy skladové položky Standard . Při migraci clusterů pro upgrade skladových položek nástroje pro vyrovnávání zatížení se vyžaduje nová IP adresa s kompatibilní skladovou adresou IP.

Další aspekty migrace clusterů najdete v naší dokumentaci k aspektům migrace.

Omezení

Při vytváření a správě clusterů AKS, které podporují nástroj pro vyrovnávání zatížení pomocí skladové položky Standard , platí následující omezení:

  • K povolení výchozího přenosu z clusteru AKS se vyžaduje alespoň jedna veřejná IP adresa nebo předpona IP adresy. Veřejná IP adresa nebo předpona IP adresy se vyžaduje k zachování připojení mezi řídicí rovinou a uzly agenta a k zajištění kompatibility s předchozími verzemi AKS. Máte následující možnosti pro zadání veřejných IP adres nebo předpon IP adres pomocí nástroje pro vyrovnávání zatížení skladové položky Standard :
    • Zadání vlastních veřejných IP adres.
    • Zadání předpon vlastních veřejných IP adres.
    • Zadejte číslo až 100, aby cluster AKS mohl vytvořit tolik veřejných IP adres skladových položek úrovně Standard ve stejné skupině prostředků jako cluster AKS. Tato skupina prostředků je obvykle pojmenována MC_ na začátku. AKS přiřadí veřejnou IP adresu nástroji pro vyrovnávání zatížení skladové položky Standard . Ve výchozím nastavení se jedna veřejná IP adresa automaticky vytvoří ve stejné skupině prostředků jako cluster AKS, pokud není zadaná žádná veřejná IP adresa, předpona veřejné IP adresy nebo počet IP adres. Je také potřeba povolit veřejné adresy a vyhnout se vytváření jakýchkoli zásad Azure, které by zakazovaly vytváření IP adres.
  • Veřejnou IP adresu vytvořenou službou AKS nejde znovu použít jako vlastní veřejnou IP adresu. Uživatelé musí vytvářet a spravovat všechny vlastní IP adresy.
  • Definici SKU nástroje pro vyrovnávání zatížení je možné provést pouze při vytváření clusteru AKS. Po vytvoření clusteru AKS už SKU nástroje pro vyrovnávání zatížení není možné změnit.
  • V jednom clusteru můžete použít pouze jeden typ skladové položky nástroje pro vyrovnávání zatížení (Basic nebo Standard).
  • Nástroje pro vyrovnávání zatížení skladové položky Úrovně Standard podporují pouze IP adresy skladové položky Standard .

Další kroky

Další informace o službách Kubernetes najdete v dokumentaci ke službám Kubernetes.

Další informace o použití interního nástroje pro vyrovnávání zatížení pro příchozí provoz najdete v dokumentaci interního nástroje pro vyrovnávání zatížení AKS.