Använda en offentlig standardlastbalanserare i Azure Kubernetes Service (AKS)

Azure Load Balancer fungerar på nivå 4 i OSI-modellen (Open Systems Interconnection) som stöder både inkommande och utgående scenarier. Den distribuerar inkommande flöden som kommer till lastbalanserarens klientdel till serverdelspoolinstanserna.

En offentlig lastbalanserare som är integrerad med AKS har två syften:

1. För att tillhandahålla utgående anslutningar till klusternoderna i det virtuella AKS-nätverket genom att översätta den privata IP-adressen till en offentlig IP-adressdel i dess utgående pool.
2. För att ge åtkomst till program via Kubernetes-tjänster av typen LoadBalancerkan du enkelt skala dina program och skapa tjänster med hög tillgänglighet.

En intern (eller privat) lastbalanserare används när endast privata IP-adresser tillåts som klientdel. Interna lastbalanserare används för att belastningsutjämningstrafik i ett virtuellt nätverk. En lastbalanserares klientdel kan också nås från ett lokalt nätverk i ett hybridscenario.

Den här artikeln beskriver integrering med en offentlig lastbalanserare på AKS. För integrering av intern lastbalanserare, se Använda en intern lastbalanserare i AKS.

Innan du börjar

• Azure Load Balancer finns i två SKU:er: Basic och Standard. Standard-SKU:n används som standard när du skapar ett AKS-kluster. Standard-SKU:n ger dig åtkomst till ytterligare funktioner, till exempel en större serverdelspool, flera nodpooler, Tillgänglighetszoner och är säker som standard. Det är den rekommenderade lastbalanserarens SKU för AKS. Mer information om SKU:er för Basic och Standard finns i Jämförelse av Azure Load Balancer SKU.
• En fullständig lista över anteckningar som stöds för Kubernetes-tjänster med typen LoadBalancerfinns i LoadBalancer-anteckningar.
• Den här artikeln förutsätter att du har ett AKS-kluster med Standard SKU Azure Load Balancer. Om du behöver ett AKS-kluster kan du skapa ett med hjälp av Azure CLI, Azure PowerShell eller Azure-portalen.
• AKS hanterar livscykeln och driften av agentnoder. Det går inte att ändra de IaaS-resurser som är associerade med agentnoderna. Ett exempel på en åtgärd som inte stöds är att göra manuella ändringar i resursgruppen för lastbalanseraren.

Viktigt!

Om du föredrar att använda din egen gateway, brandvägg eller proxy för att tillhandahålla utgående anslutning kan du hoppa över skapandet av lastbalanserarens utgående pool och respektive klientdels-IP med hjälp av utgående typ som UserDefinedRouting (UDR). Den utgående typen definierar utgående metod för ett kluster och anger som standard LoadBalancer.

Använda den offentliga standardlastbalanseraren

När du har skapat ett AKS-kluster med utgående typ LoadBalancer (standard) är klustret redo att använda lastbalanseraren för att exponera tjänster.

Skapa ett tjänstmanifest med namnet public-svc.yaml, som skapar en offentlig tjänst av typen LoadBalancer.

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

Ange lastbalanserarens IP-adress

Om du vill använda en specifik IP-adress med lastbalanseraren finns det två sätt:

Viktigt!

Att lägga till egenskapen LoadBalancerIP i YAML-manifestet för lastbalanseraren är inaktuellt för att följa uppströms Kubernetes. Även om den aktuella användningen förblir densamma och befintliga tjänster förväntas fungera utan ändringar rekommenderar vi starkt att du anger tjänstanteckningar i stället.

• Ange tjänstanteckningar: Använd service.beta.kubernetes.io/azure-load-balancer-ipv4 för en IPv4-adress och service.beta.kubernetes.io/azure-load-balancer-ipv6 för en IPv6-adress.
• Lägg till egenskapen LoadBalancerIP i YAML-manifestet för lastbalanseraren: Lägg till egenskapen Service.Spec.LoadBalancerIP i YAML-manifestet för lastbalanseraren. Det här fältet är inaktuellt för att följa uppströms Kubernetes och det kan inte ha stöd för dubbla staplar. Den aktuella användningen är densamma och befintliga tjänster förväntas fungera utan ändringar.

Distribuera tjänstmanifestet

Distribuera manifestet för den offentliga tjänsten med hjälp kubectl apply av och ange namnet på ditt YAML-manifest.

kubectl apply -f public-svc.yaml

Azure Load Balancer har konfigurerats med en ny offentlig IP-adress som frontar den nya tjänsten. Eftersom Azure Load Balancer kan ha flera klientdels-IP-adresser får varje ny tjänst som du distribuerar en ny dedikerad klientdels-IP som ska användas unikt.

Bekräfta att tjänsten har skapats och att lastbalanseraren har konfigurerats med hjälp av följande kommando.

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

När du visar tjänstinformationen visas den offentliga IP-adressen som skapats för den här tjänsten i lastbalanseraren i kolumnen EXTERNAL-IP . Det kan ta några minuter innan IP-adressen ändras från <väntande> till en faktisk offentlig IP-adress.

Mer detaljerad information om din tjänst finns i följande kommando.

kubectl describe service public-svc

Följande exempelutdata är en komprimerad version av utdata när du har kört kubectl describe service. LoadBalancer Ingress visar den externa IP-adressen som exponeras av din tjänst. IP visar de interna adresserna.

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

Konfigurera den offentliga standardlastbalanseraren

Du kan anpassa olika inställningar för din offentliga standardlastbalanserare när klustret skapas eller genom att uppdatera klustret. Med de här anpassningsalternativen kan du skapa en lastbalanserare som uppfyller dina arbetsbelastningsbehov. Med standardlastbalanseraren kan du:

• Ange eller skala antalet hanterade utgående IP-adresser.
• Ta med egna anpassade utgående IP-adresser eller utgående IP-prefix.
• Anpassa antalet allokerade utgående portar till varje nod i klustret.
• Konfigurera tidsgränsinställningen för inaktiva anslutningar.

Viktigt!

Endast ett utgående IP-alternativ (hanterade IP-adresser, bring your own IP eller IP-prefix) kan användas vid en viss tidpunkt.

Ändra typ av inkommande pool

AKS-noder kan refereras till i lastbalanserarens serverdelspooler antingen genom deras IP-konfiguration (Azure Virtual Machine Scale Sets-baserat medlemskap) eller endast via deras IP-adress. Genom att använda det IP-adressbaserade medlemskapet i serverdelspoolen får du högre effektivitet vid uppdatering av tjänster och etablering av lastbalanserare, särskilt vid höga nodantal. Etablering av nya kluster med IP-baserade serverdelspooler och konvertering av befintliga kluster stöds nu. I kombination med NAT Gateway eller användardefinierade routningsutgående typer är etablering av nya noder och tjänster mer högpresterande.

Det finns två olika typer av poolmedlemskap:

• nodeIPConfiguration – äldre VM Scale Sets IP-konfigurationsbaserad poolmedlemskapstyp
• nodeIP – IP-baserad medlemskapstyp

Krav

• AKS-klustret måste vara version 1.23 eller senare.
• AKS-klustret måste använda standardlastbalanserare och vm-skalningsuppsättningar.

Begränsningar

• Kluster som använder IP-baserade serverdelspooler är begränsade till 2 500 noder.

Skapa ett nytt AKS-kluster med IP-baserat inkommande poolmedlemskap

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

Uppdatera ett befintligt AKS-kluster för att använda IP-baserat inkommande poolmedlemskap

Varning

Den här åtgärden orsakar ett tillfälligt avbrott i inkommande tjänsttrafik i klustret. Påverkanstiden ökar med större kluster som har många noder.

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

Skala antalet hanterade utgående offentliga IP-adresser

Azure Load Balancer tillhandahåller utgående och inkommande anslutningar från ett virtuellt nätverk. Regler för utgående trafik gör det enkelt att konfigurera nätverksadressöversättning för den offentliga standardlastbalanseraren.

Regler för utgående trafik följer samma syntax som belastningsutjämning och inkommande NAT-regler:

klientdels-IP-adresser + parametrar + serverdelspool

En utgående regel konfigurerar utgående NAT för alla virtuella datorer som identifieras av serverdelspoolen som ska översättas till klientdelen. Parametrar ger mer kontroll över den utgående NAT-algoritmen.

Du kan använda en regel för utgående trafik med en enda offentlig IP-adress, men regler för utgående trafik är bra för att skala utgående NAT eftersom de underlättar konfigurationsbördan. Du kan använda flera IP-adresser för att planera för storskaliga scenarier och utgående regler för att minska SNAT-överbelastningsbenägna mönster. Varje IP-adress som tillhandahålls av en klientdel innehåller 64 000 tillfälliga portar som lastbalanseraren kan använda som SNAT-portar.

När du använder en Standard SKU-lastbalanserare med hanterade utgående offentliga IP-adresser (som skapas som standard) kan du skala antalet hanterade utgående offentliga IP-adresser med hjälp av parametern --load-balancer-managed-outbound-ip-count .

Använd följande kommando för att uppdatera ett befintligt kluster. Du kan också ange att den här parametern ska ha flera hanterade offentliga IP-adresser för utgående trafik.

Viktigt!

Vi rekommenderar inte att du använder Azure-portalen för att göra några regeländringar för utgående trafik. När du gör dessa ändringar bör du gå igenom AKS-klustret och inte direkt på Load Balancer-resursen.

Regeländringar för utgående trafik som görs direkt på Load Balancer-resursen tas bort när klustret avstäms, till exempel när det stoppas, startas, uppgraderas eller skalas.

Använd Azure CLI, som du ser i exemplen. Regeländringar för utgående trafik som görs med az aks CLI-kommandon är permanenta över klusteravbrott.

Mer information finns i Utgående regler för Azure Load Balancer.

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

I exemplet ovan anges antalet hanterade utgående offentliga IP-adresser till 2 för myAKSCluster-klustret i myResourceGroup.

När klustret skapas kan du också ange det första antalet hanterade offentliga ip-adresser för utgående trafik genom att lägga till parametern --load-balancer-managed-outbound-ip-count och ange det till önskat värde. Standardantalet för hanterade utgående offentliga IP-adresser är 1.

Ange dina egna utgående offentliga IP-adresser eller prefix

När du använder en Standard SKU-lastbalanserare skapar AKS-klustret automatiskt en offentlig IP-adress i resursgruppen aks-hanterad infrastruktur och tilldelar den till den utgående lastbalanserarens pool som standard.

En offentlig IP-adress som skapats av AKS är en AKS-hanterad resurs, vilket innebär att AKS hanterar livscykeln för den offentliga IP-adressen och inte kräver användaråtgärder direkt på den offentliga IP-resursen. Du kan också tilldela en egen anpassad offentlig IP-adress eller ett offentligt IP-prefix när klustret skapas. Dina anpassade IP-adresser kan också uppdateras på ett befintligt klusters lastbalanserares egenskaper.

Kraven för att använda din egen offentliga IP-adress eller prefix är:

• Användarna måste skapa och äga anpassade offentliga IP-adresser. Hanterade offentliga IP-adresser som skapats av AKS kan inte återanvändas som en "bring your own custom IP" eftersom det kan orsaka hanteringskonflikter.
• Du måste se till att AKS-klusteridentiteten (tjänstens huvudnamn eller hanterade identitet) har behörighet att komma åt den utgående IP-adressen enligt listan med nödvändiga offentliga IP-behörigheter.
• Kontrollera att du uppfyller de krav och begränsningar som krävs för att konfigurera utgående IP-adresser eller utgående IP-prefix.

Uppdatera klustret med din egen utgående offentliga IP-adress

az network public-ip show Använd kommandot för att visa ID:t för dina offentliga IP-adresser.

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

Kommandot ovan visar ID för den offentliga IP-adressen myPublicIP i resursgruppen myResourceGroup .

az aks update Använd kommandot med parametern load-balancer-outbound-ips för att uppdatera klustret med dina offentliga IP-adresser.

I följande exempel används parametern load-balancer-outbound-ips med ID:t från föregående kommando.

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

Uppdatera klustret med ditt eget offentliga IP-prefix för utgående trafik

Du kan också använda offentliga IP-prefix för utgående trafik med din Standard SKU-lastbalanserare. I följande exempel används kommandot az network public-ip prefix show för att visa ID:n för dina offentliga IP-prefix.

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

Kommandot ovan visar ID:t för det offentliga IP-prefixet myPublicIPPrefix i resursgruppen myResourceGroup .

I följande exempel används parametern load-balancer-outbound-ip-prefix med ID:na från föregående kommando.

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

Skapa klustret med din egen offentliga IP-adress eller prefix

När du skapar klustret kan du ta med dina egna IP-adresser eller IP-prefix för utgående trafik för att stödja scenarier som att lägga till utgående slutpunkter i en allowlist. Om du vill definiera dina egna offentliga IP-adresser och IP-prefix när klustret skapas lägger du till samma parametrar som visas i föregående kommando.

az aks create Använd kommandot med parametern load-balancer-outbound-ips för att skapa ett nytt kluster med dina egna offentliga IP-adresser.

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

az aks create Använd kommandot med parametern load-balancer-outbound-ip-prefixes för att skapa ett nytt kluster med dina egna offentliga IP-prefix.

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

Konfigurera de allokerade utgående portarna

Viktigt!

Om du har program i klustret som kan upprätta ett stort antal anslutningar till en liten uppsättning mål, till exempel många instanser av ett klientdelsprogram som ansluter till en databas, kan du ha ett scenario som är känsligt för SNAT-portöverbelastning. SNAT-portöverbelastning inträffar när ett program får slut på utgående portar som ska användas för att upprätta en anslutning till ett annat program eller en annan värd. Om du har ett scenario som är känsligt för SNAT-portöverbelastning rekommenderar vi starkt att du ökar de allokerade utgående portarna och utgående ip-adresser på lastbalanseraren.

Mer information om SNAT finns i Använda SNAT för utgående anslutningar.

Som standard anger AKS AllokeradeOutboundPorts på lastbalanseraren till 0, vilket möjliggör automatisk utgående porttilldelning baserat på serverdelspoolens storlek när du skapar ett kluster. Om ett kluster till exempel har 50 eller färre noder allokeras 1 024 portar till varje nod. När antalet noder i klustret ökar är färre portar tillgängliga per nod.

Viktigt!

Det finns en hård gräns på 1 024 portar oavsett om klientdels-IP-adresser läggs till när nodstorleken är mindre än eller lika med 50 (1–50).

Om du vill visa värdet AllocatedOutboundPorts för AKS-klusterlastbalanseraren använder du 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

Följande exempelutdata visar att automatisk utgående porttilldelning baserat på storleken på serverdelspoolen är aktiverad för klustret.

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

Om du vill konfigurera ett specifikt värde för AllocatedOutboundPorts och utgående IP-adress när du skapar eller uppdaterar ett kluster använder du load-balancer-outbound-ports antingen load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipseller load-balancer-outbound-ip-prefixes. Innan du anger ett specifikt värde eller ökar ett befintligt värde för antingen utgående portar eller utgående IP-adresser måste du beräkna lämpligt antal utgående portar och IP-adresser. Använd följande ekvation för den här beräkningen avrundad till närmaste heltal: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

När du beräknar antalet utgående portar och IP-adresser och anger värdena bör du ha följande information i åtanke:

• Antalet utgående portar per nod är fast baserat på det värde du anger.
• Värdet för utgående portar måste vara en multipel av 8.
• Att lägga till fler IP-adresser lägger inte till fler portar till någon nod, men det ger kapacitet för fler noder i klustret.
• Du måste ta hänsyn till noder som kan läggas till som en del av uppgraderingarna, inklusive antalet noder som anges via maxSurge-värden.

I följande exempel visas hur de värden du anger påverkar antalet utgående portar och IP-adresser:

• Om standardvärdena används och klustret har 48 noder har varje nod 1 024 tillgängliga portar.
• Om standardvärdena används och klustret skalar från 48 till 52 noder uppdateras varje nod från 1 024 portar som är tillgängliga för 512 tillgängliga portar.
• Om antalet utgående portar är inställt på 1 000 och det utgående IP-antalet är inställt på 2, kan klustret ha stöd för högst 128 noder: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
• Om antalet utgående portar är inställt på 1 000 och det utgående IP-antalet är inställt på 7, kan klustret ha stöd för högst 448 noder: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
• Om antalet utgående portar är inställt på 4 000 och det utgående IP-antalet är inställt på 2, kan klustret ha stöd för högst 32 noder: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
• Om antalet utgående portar är inställt på 4 000 och det utgående IP-antalet är inställt på 7, kan klustret ha stöd för högst 112 noder: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Viktigt!

När du har beräknat antalet utgående portar och IP-adresser kontrollerar du att du har ytterligare utgående portkapacitet för att hantera nodökning under uppgraderingar. Det är viktigt att allokera tillräckligt med överskottsportar för ytterligare noder som behövs för uppgradering och andra åtgärder. AKS är som standard en buffertnod för uppgraderingsåtgärder. Om du använder maxSurge-värden multiplicerar du de utgående portarna per nod med ditt maxSurge-värde för att fastställa antalet portar som krävs. Om du till exempel beräknar att du behöver 4 000 portar per nod med 7 IP-adresser i ett kluster med högst 100 noder och en maximal ökning på 2:

• 2 överspänningsnoder * 4 000 portar per nod = 8 000 portar som behövs för nodökning under uppgraderingar.
• 100 noder * 4 000 portar per nod = 400 000 portar som krävs för klustret.
• 7 IP-adresser * 64 000 portar per IP = 448 000 tillgängliga portar för klustret.

Exemplet ovan visar att klustret har en överkapacitet på 48 000 portar, vilket är tillräckligt för att hantera de 8 000 portar som behövs för nodökning under uppgraderingar.

När värdena har beräknats och verifierats kan du använda dessa värden med hjälp av load-balancer-outbound-ports och antingen load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipseller load-balancer-outbound-ip-prefixes när du skapar eller uppdaterar ett kluster.

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

Konfigurera tidsgränsen för inaktiv lastbalanserare

När SNAT-portresurserna är uttömda misslyckas utgående flöden tills befintliga flöden släpper SNAT-portar. Lastbalanseraren återtar SNAT-portar när flödet stängs och den AKS-konfigurerade lastbalanseraren använder en tidsgräns på 30 minuter för inaktivitet för att frigöra SNAT-portar från inaktiva flöden.

Du kan också använda transport (till exempel TCP keepalives eller application-layer keepalives) för att uppdatera ett inaktivt flöde och återställa tidsgränsen för inaktivitet om det behövs. Du kan konfigurera den här tidsgränsen enligt exemplet nedan.

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

Om du förväntar dig att ha många kortlivade anslutningar och inga långvariga anslutningar som kan ha långa tider av inaktivitet, som att använda kubectl proxy eller kubectl port-forward, kan du överväga att använda ett lågt timeout-värde, till exempel 4 minuter. När du använder TCP keepalives räcker det att aktivera dem på ena sidan av anslutningen. Det räcker till exempel att aktivera dem på serversidan bara för att återställa flödets inaktiva timer. Det är inte nödvändigt för båda sidor att starta TCP keepalives. Liknande begrepp finns för programskiktet, inklusive databasklientserverkonfigurationer. Kontrollera på serversidan vilka alternativ som finns för programspecifika keepalives.

Viktigt!

AKS aktiverar TCP-återställning vid inaktivitet som standard. Vi rekommenderar att du behåller den här konfigurationen och använder den för mer förutsägbart programbeteende i dina scenarier.

TCP RST skickas endast under TCP-anslutningen i ETABLERAT tillstånd. Du kan läsa mer om det här.

När du anger IdleTimeoutInMinutes till ett annat värde än standardvärdet på 30 minuter bör du överväga hur länge dina arbetsbelastningar behöver en utgående anslutning. Tänk också på att standardvärdet för timeout för en Standard SKU-lastbalanserare som används utanför AKS är 4 minuter. Ett IdleTimeoutInMinutes-värde som mer exakt återspeglar din specifika AKS-arbetsbelastning kan bidra till att minska SNAT-överbelastningen som orsakas av att anslutningar inte längre används.

Varning

Om du ändrar värdena för AllocatedOutboundPorts och IdleTimeoutInMinutes kan det avsevärt ändra beteendet för utgående regel för lastbalanseraren och bör inte göras lätt. Kontrollera avsnittet SNAT-felsökning och granska utgående regler och utgående anslutningar för Lastbalanserare i Azure innan du uppdaterar dessa värden för att få en fullständig förståelse för effekten av dina ändringar.

Begränsa inkommande trafik till specifika IP-intervall

I följande manifest används loadBalancerSourceRanges för att ange ett nytt IP-intervall för inkommande extern trafik.

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

I det här exemplet uppdateras regeln så att inkommande extern trafik endast tillåts MY_EXTERNAL_IP_RANGE från intervallet. Om du ersätter MY_EXTERNAL_IP_RANGE med ip-adressen för det interna undernätet begränsas trafiken till endast interna IP-adresser för klustret. Om trafiken är begränsad till interna IP-adresser för klustret kan klienter utanför Kubernetes-klustret inte komma åt lastbalanseraren.

Kommentar

• Inkommande, externa trafikflöden från lastbalanseraren till det virtuella nätverket för ditt AKS-kluster. Det virtuella nätverket har en nätverkssäkerhetsgrupp (NSG) som tillåter all inkommande trafik från lastbalanseraren. Den här NSG:n använder en tjänsttagg av typen LoadBalancer för att tillåta trafik från lastbalanseraren.
• Podd CIDR bör läggas till i loadBalancerSourceRanges om det finns poddar som behöver komma åt tjänstens LoadBalancer IP för kluster med version v1.25 eller senare.

Underhålla klientens IP-adress för inkommande anslutningar

Som standard bevarar inte en tjänst av typen LoadBalanceri Kubernetes och i AKS klientens IP-adress på anslutningen till podden. Käll-IP-adressen för paketet som levereras till podden blir nodens privata IP-adress. För att underhålla klientens IP-adress måste du ange service.spec.externalTrafficPolicy till local i tjänstdefinitionen. Följande manifest visar ett exempel.

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

Anpassningar via Kubernetes-anteckningar

Följande anteckningar stöds för Kubernetes-tjänster med typen LoadBalancer, och de gäller endast för INBOUND-flöden .

Annotation	Värde	beskrivning
service.beta.kubernetes.io/azure-load-balancer-internal	true eller false	Ange om lastbalanseraren ska vara intern. Om den inte anges är den offentlig som standard.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet	Namn på undernätet	Ange vilket undernät den interna lastbalanseraren ska bindas till. Om den inte anges är den standardinställningen för det undernät som konfigurerats i molnkonfigurationsfilen.
service.beta.kubernetes.io/azure-dns-label-name	Namn på DNS-etiketten på offentliga IP-adresser	Ange DNS-etikettnamnet för den offentliga tjänsten. Om den är inställd på en tom sträng används inte DNS-posten i den offentliga IP-adressen.
service.beta.kubernetes.io/azure-shared-securityrule	true eller false	Ange hur tjänsten exponeras via en potentiellt delad Azure-säkerhetsregel för att öka tjänstexponeringen med hjälp av Azure Augmented Security Rules i nätverkssäkerhetsgrupper.
service.beta.kubernetes.io/azure-load-balancer-resource-group	Namnet på resursgruppen	Ange resursgruppen för offentliga IP-adresser för lastbalanseraren som inte finns i samma resursgrupp som klusterinfrastrukturen (nodresursgruppen).
service.beta.kubernetes.io/azure-allowed-service-tags	Lista över tillåtna tjänsttaggar	Ange en lista över tillåtna tjänsttaggar avgränsade med kommatecken.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout	Tidsgränser för TCP-inaktivitet i minuter	Ange tiden i minuter för TCP-anslutningens inaktiva timeouter som ska inträffa på lastbalanseraren. Standardvärdet och minimivärdet är 4. Det maximala värdet är 30. Värdet måste vara ett heltal.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset	true eller false	Ange om lastbalanseraren ska inaktivera TCP-återställning vid tidsgräns för inaktivitet.
service.beta.kubernetes.io/azure-load-balancer-ipv4	IPv4-adress	Ange den IPv4-adress som ska tilldelas till lastbalanseraren.
service.beta.kubernetes.io/azure-load-balancer-ipv6	IPv6-adress	Ange den IPv6-adress som ska tilldelas till lastbalanseraren.

Anpassa lastbalanserarens hälsoavsökning

Annotation	Värde	beskrivning
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Intervall för hälsoavsökning
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Det minsta antalet hälsoavsökningar som inte är felfria
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Sökväg för hälsoavsökningen
service.beta.kubernetes.io/port_{port}_no_lb_rule	sant/falskt	{port} är tjänstportnummer. När värdet är true genereras ingen lb-regel eller hälsoavsökningsregel för den här porten. Hälsokontrolltjänsten ska inte exponeras för det offentliga internet (t.ex. istio/envoy health check service)
service.beta.kubernetes.io/port_{port}_no_probe_rule	sant/falskt	{port} är tjänstportnummer. När värdet är true genereras ingen hälsoavsökningsregel för den här porten.
service.beta.kubernetes.io/port_{port}_health-probe_protocol	Hälsoavsökningsprotokoll	{port} är tjänstportnummer. Explicit protokoll för hälsoavsökningen för tjänstporten {port}, åsidosättande port.appProtocol om det anges.
service.beta.kubernetes.io/port_{port}_health-probe_port	portnummer eller portnamn i tjänstmanifestet	{port} är tjänstportnummer. Explicit port för hälsoavsökningen för tjänstporten {port}, vilket överskrider standardvärdet.
service.beta.kubernetes.io/port_{port}_health-probe_interval	Intervall för hälsoavsökning	{port} är tjänstportnummer.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	Det minsta antalet hälsoavsökningar som inte är felfria	{port} är tjänstportnummer.
service.beta.kubernetes.io/port_{port}_health-probe_request-path	Sökväg för hälsoavsökningen	{port} är tjänstportnummer.

Som beskrivs här är Tcp, Http och Https tre protokoll som stöds av lastbalanserarens tjänst.

För närvarande varierar standardprotokollet för hälsoavsökningen mellan tjänster med olika transportprotokoll, appprotokoll, anteckningar och externa trafikprinciper.

1. för lokala tjänster används HTTP och /healthz. Hälsoavsökningen frågar NodeHealthPort i stället för den faktiska serverdelstjänsten
2. för TCP-klustertjänster används TCP.
3. för kluster-UDP-tjänster, inga hälsoavsökningar.

Kommentar

För lokala tjänster med PLS-integrering och PLS-proxyprotokoll aktiverat fungerar inte http+/healthz-standardhälsoavsökningen. Hälsoavsökningen kan därför anpassas på samma sätt som klustertjänster för att stödja det här scenariot.

Sedan v1.20 introduceras tjänstkommentarer service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path för att fastställa hälsoavsökningens beteende.

• För kluster =1.23 spec.ports.appProtocol används endast som avsökningsprotokoll <när service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path det också har angetts.
• För kluster 1.24 spec.ports.appProtocol används som avsökningsprotokoll >och / används som standardsökväg för avsökningsbegäran (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path kan användas för att ändra till en annan sökväg för begäran).

Observera att sökvägen för begäran ignoreras när du använder TCP eller spec.ports.appProtocol är tom. Mer specifikt:

loadbalancer sku	externalTrafficPolicy	spec.ports.Protocol	spec.ports.AppProtocol	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	LB-avsökningsprotokoll	Sökväg för LB-avsökningsbegäran
standard	lokal	någon	någon	någon	http	/healthz
standard	cluster	Udp	någon	någon	null	null
standard	cluster	tcp		(ignoreras)	tcp	NULL
standard	cluster	tcp	tcp	(ignoreras)	tcp	NULL
standard	cluster	tcp	http/https		TCP(<=1.23) eller http/https(>=1.24)	null(<=1.23) eller /(>=1.24)
standard	cluster	tcp	http/https	/custom-path	http/https	/custom-path
standard	cluster	tcp	protokoll som inte stöds	/custom-path	tcp	NULL
Grundläggande	lokal	någon	någon	någon	http	/healthz
Grundläggande	cluster	tcp		(ignoreras)	tcp	NULL
Grundläggande	cluster	tcp	tcp	(ignoreras)	tcp	NULL
Grundläggande	cluster	tcp	http		TCP(<=1.23) eller http/https(>=1.24)	null(<=1.23) eller /(>=1.24)
Grundläggande	cluster	tcp	http	/custom-path	http	/custom-path
Grundläggande	cluster	tcp	protokoll som inte stöds	/custom-path	tcp	NULL

Sedan v1.21 introduceras två tjänstkommentarer service.beta.kubernetes.io/azure-load-balancer-health-probe-interval som load-balancer-health-probe-num-of-probe anpassar konfigurationen av hälsoavsökningen. Om service.beta.kubernetes.io/azure-load-balancer-health-probe-interval inte har angetts tillämpas standardvärdet 5. Om load-balancer-health-probe-num-of-probe inte har angetts tillämpas standardvärdet 2. Och den totala avsökningen bör vara mindre än 120 sekunder.

Hälsoavsökning för anpassad lastbalanserare för port

Olika portar i en tjänst kan kräva olika konfigurationer av hälsoavsökningar. Detta kan bero på tjänstdesign (till exempel en enda hälsoslutpunkt som styr flera portar) eller Kubernetes-funktioner som MixedProtocolLBService.

Följande anteckningar kan användas för att anpassa avsökningskonfigurationen per tjänstport.

portspecifik kommentar	global avsökningsanteckning	Användning
service.beta.kubernetes.io/port_{port}_no_lb_rule	N/A (ingen motsvarighet globalt)	om värdet är sant genereras inga lb-regler och avsökningsregler
service.beta.kubernetes.io/port_{port}_no_probe_rule	N/A (ingen motsvarighet globalt)	om värdet är sant genereras inga avsökningsregler
service.beta.kubernetes.io/port_{port}_health-probe_protocol	N/A (ingen motsvarighet globalt)	Ange hälsoavsökningsprotokollet för den här tjänstporten (t.ex. Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port	N/A (ingen motsvarighet globalt)	Anger hälsoavsökningsporten för den här tjänstporten (t.ex. 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	För Http eller Https anger du sökvägen för hälsoavsökningsbegäran. Standardvärdet är /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Antal på varandra följande avsökningsfel innan porten anses vara felaktig
service.beta.kubernetes.io/port_{port}_health-probe_interval	service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Tiden mellan avsökningsförsök

För följande manifest skiljer sig avsökningsregeln för port httpsserver från den för httpserver eftersom anteckningar för port httpsserver har angetts.

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

I det här manifestet använder https-portarna en annan nodport, en HTTP-beredskapskontroll på port 10256 på /healthz(healthz-slutpunkten för 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

I det här manifestet använder https-portarna en annan slutpunkt för hälsoavsökning, en HTTP-beredskapskontroll på port 30000 på /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

Felsöka SNAT

Om du vet att du startar många utgående TCP- eller UDP-anslutningar till samma mål-IP-adress och port, och du observerar misslyckade utgående anslutningar eller support meddelar dig att du uttömmer SNAT-portar (förallokerade tillfälliga portar som används av PAT), har du flera allmänna åtgärdsalternativ. Granska de här alternativen och bestäm vad som är bäst för ditt scenario. Det är möjligt att en eller flera kan hjälpa dig att hantera ditt scenario. Detaljerad information finns i felsökningsguiden för utgående anslutningar.

Rotorsaken till SNAT-överbelastning är ofta ett antimönster för hur utgående anslutning upprättas, hanteras eller konfigureras timers ändras från deras standardvärden. Granska det här avsnittet noggrant.

Steg

1. Kontrollera om anslutningarna förblir inaktiva under en längre tid och förlita dig på standardtimeouten för inaktivitet för att frigöra porten. I så fall kan standardtimeouten på 30 minuter behöva minskas för ditt scenario.
2. Undersöka hur ditt program skapar utgående anslutning (till exempel kodgranskning eller paketinsamling).
3. Kontrollera om den här aktiviteten är ett förväntat beteende eller om programmet beter sig felaktigt. Använd mått och loggar i Azure Monitor för att underbygga dina resultat. Använd till exempel kategorin "Misslyckades" för SNAT-anslutningsmått.
4. Utvärdera om lämpliga mönster följs.
5. Utvärdera om SNAT-portöverbelastning bör minskas med fler utgående IP-adresser + fler allokerade utgående portar.

Designmönster

Dra nytta av återanvändning av anslutningar och anslutningspooler när det är möjligt. Dessa mönster hjälper dig att undvika resursöverbelastningsproblem och resulterar i förutsägbart beteende. Primitiver för dessa mönster finns i många utvecklingsbibliotek och ramverk.

• Atomiska begäranden (en begäran per anslutning) är vanligtvis inte ett bra designval. Sådana antimönster begränsar skalning, minskar prestanda och minskar tillförlitligheten. Återanvänd i stället HTTP/S-anslutningar för att minska antalet anslutningar och associerade SNAT-portar. Programskalan ökar och prestandan förbättras på grund av minskade kostnader för handskakningar, omkostnader och kryptografiska åtgärder vid användning av TLS.
• Om du använder slut på kluster/anpassad DNS eller anpassade överordnade servrar på coreDNS bör du tänka på att DNS kan introducera många enskilda flöden på volymen när klienten inte cachelagrar RESULTATET för DNS-matcharna. Se till att anpassa coreDNS först i stället för att använda anpassade DNS-servrar och definiera ett bra cachelagringsvärde.
• UDP-flöden (till exempel DNS-sökningar) allokerar SNAT-portar under tidsgränsen för inaktivitet. Ju längre tidsgränsen för inaktivitet är, desto högre tryck på SNAT-portarna. Använd kort timeout för inaktivitet (till exempel 4 minuter).
• Använd anslutningspooler för att forma anslutningsvolymen.
• Överge aldrig tyst ett TCP-flöde och förlita dig på TCP-timers för att rensa flödet. Om du inte tillåter att TCP uttryckligen stänger anslutningen förblir tillståndet allokerat vid mellanliggande system och slutpunkter, och det gör SNAT-portar otillgängliga för andra anslutningar. Det här mönstret kan utlösa programfel och SNAT-överbelastning.
• Ändra inte TCP-nära relaterade timervärden på OS-nivå utan expertkunskap om påverkan. TCP-stacken återställs, men programmets prestanda kan påverkas negativt när slutpunkterna för en anslutning har felmatchade förväntningar. Att vilja ändra timers är vanligtvis ett tecken på ett underliggande designproblem. Granska följande rekommendationer.

Flytta från en Basic SKU-lastbalanserare till Standard SKU

Om du har ett befintligt kluster med Basic SKU-lastbalanseraren finns det viktiga beteendeskillnader att notera när du migrerar till Standard SKU-lastbalanseraren.

Till exempel är det vanligt att göra blå/gröna distributioner för att migrera kluster med tanke på typen av kluster och kan bara definieras vid tidpunkten load-balancer-sku för klusterskapande. Basic SKU-lastbalanserare använder dock Basic SKU IP-adresser som inte är kompatibla med Standard SKU-lastbalanserare. Standard SKU-lastbalanserare kräver Standard SKU IP-adresser. När du migrerar kluster för att uppgradera SKU:er för lastbalanserare krävs en ny IP-adress med en kompatibel IP-adress-SKU.

Mer information om hur du migrerar kluster finns i vår dokumentation om migreringsöverväganden.

Begränsningar

Följande begränsningar gäller när du skapar och hanterar AKS-kluster som stöder en lastbalanserare med standard-SKU :n:

• Minst en offentlig IP-adress eller IP-prefix krävs för att tillåta utgående trafik från AKS-klustret. Den offentliga IP-adressen eller IP-prefixet krävs för att upprätthålla anslutningen mellan kontrollplanet och agentnoderna, samt för att behålla kompatibiliteten med tidigare AKS-versioner. Du har följande alternativ för att ange offentliga IP-adresser eller IP-prefix med en Standard SKU-lastbalanserare:
  • Ange dina egna offentliga IP-adresser.
  • Ange dina egna offentliga IP-prefix.
  • Ange ett tal upp till 100 så att AKS-klustret kan skapa så många offentliga IP-adresser för Standard SKU i samma resursgrupp som AKS-klustret. Den här resursgruppen namnges vanligtvis med MC_ i början. AKS tilldelar den offentliga IP-adressen till Standard SKU-lastbalanseraren. Som standard skapas en offentlig IP-adress automatiskt i samma resursgrupp som AKS-klustret om ingen offentlig IP-adress, offentligt IP-prefix eller antal IP-adresser har angetts. Du måste också tillåta offentliga adresser och låta bli att skapa Azure-principer som förbjuder skapandet av IP-adresser.
• En offentlig IP-adress som skapats av AKS kan inte återanvändas som en anpassad egen offentlig IP-adress. Användarna måste skapa och hantera alla anpassade IP-adresser.
• Det går bara att definiera lastbalanserarens SKU när du skapar ett AKS-kluster. Du kan inte ändra lastbalanserarens SKU när ett AKS-kluster har skapats.
• Du kan bara använda en typ av SKU för lastbalanserare (Basic eller Standard) i ett enda kluster.
• Standard SKU-lastbalanserare stöder endast Standard SKU IP-adresser.

Nästa steg

Mer information om Kubernetes-tjänster finns i dokumentationen om Kubernetes-tjänster.

Mer information om hur du använder intern lastbalanserare för inkommande trafik finns i dokumentationen om aks interna lastbalanserare.