Een openbare standard load balancer gebruiken in Azure Kubernetes Service (AKS)

De Azure Load Balancer werkt op laag 4 van het OSI-model (Open Systems Interconnect) dat zowel inkomende als uitgaande scenario's ondersteunt. Het distribueert binnenkomende stromen die binnenkomen bij de front-end van de load balancer naar de exemplaren van de back-endpool.

Een openbare load balancer die is geïntegreerd met AKS, heeft twee doeleinden:

1. Om uitgaande verbindingen met de clusterknooppunten in het virtuele AKS-netwerk te bieden door het privé-IP-adres te vertalen naar een openbaar IP-adresgedeelte van de uitgaande pool.
2. Als u toegang wilt bieden tot toepassingen via Kubernetes-services van het type LoadBalancer, kunt u uw toepassingen eenvoudig schalen en maximaal beschikbare services maken.

Een interne (of privé) load balancer wordt gebruikt wanneer alleen privé-IP-adressen als front-end zijn toegestaan. Interne load balancers worden gebruikt voor het verdelen van verkeer binnen een virtueel netwerk. Een front-end voor een load balancer kan ook worden geopend vanuit een on-premises netwerk in een hybride scenario.

In dit artikel wordt de integratie behandeld met een openbare load balancer op AKS. Zie Een interne load balancer gebruiken in AKS voor integratie van interne load balancers.

Voordat u begint

• Azure Load Balancer is beschikbaar in twee SKU's: Basic en Standard. De standard-SKU wordt standaard gebruikt wanneer u een AKS-cluster maakt. De Standard-SKU biedt u toegang tot toegevoegde functionaliteit, zoals een grotere back-endpool, meerdere knooppuntgroepen, Beschikbaarheidszones en is standaard beveiligd. Dit is de aanbevolen load balancer-SKU voor AKS. Zie de Vergelijking van de SKU Van Azure Load Balancer voor meer informatie over de Basic- en Standard-SKU's.
• Zie Aantekeningen van LoadBalancer voor een volledige lijst met ondersteunde aantekeningen voor Kubernetes-services met het typeLoadBalancer.
• In dit artikel wordt ervan uitgegaan dat u een AKS-cluster hebt met de Standard SKU Azure Load Balancer. Als u een AKS-cluster nodig hebt, kunt u er een maken met behulp van Azure CLI, Azure PowerShell of Azure Portal.
• AKS beheert de levenscyclus en bewerkingen van agentknooppunten. Het wijzigen van de IaaS-resources die zijn gekoppeld aan de agentknooppunten, wordt niet ondersteund. Een voorbeeld van een niet-ondersteunde bewerking is het aanbrengen van handmatige wijzigingen in de resourcegroep van de load balancer.

Belangrijk

Als u liever uw eigen gateway, firewall of proxy gebruikt om uitgaande verbindingen te bieden, kunt u het maken van de uitgaande pool van de load balancer en het respectieve front-end-IP-adres overslaan door het uitgaande type als UserDefinedRouting (UDR) te gebruiken. Het uitgaande type definieert de uitgaande methode voor een cluster en wordt standaard getypt LoadBalancer.

De openbare standard load balancer gebruiken

Nadat u een AKS-cluster met uitgaand type LoadBalancer (standaard) hebt gemaakt, kunt u de load balancer gebruiken om services beschikbaar te maken.

Maak een servicemanifest met de naam public-svc.yaml, waarmee een openbare service van het type LoadBalancerwordt gemaakt.

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

Het IP-adres van de load balancer opgeven

Als u een specifiek IP-adres met de load balancer wilt gebruiken, zijn er twee manieren:

Belangrijk

Het toevoegen van de eigenschap LoadBalancerIP aan het YAML-manifest van de load balancer wordt afgeschaft na upstream Kubernetes. Hoewel het huidige gebruik hetzelfde blijft en bestaande services naar verwachting zonder aanpassingen werken, raden we u ten zeerste aan serviceaantekeningen in te stellen.

• Serviceaantekeningen instellen: Gebruiken service.beta.kubernetes.io/azure-load-balancer-ipv4 voor een IPv4-adres en service.beta.kubernetes.io/azure-load-balancer-ipv6 voor een IPv6-adres.
• Voeg de eigenschap LoadBalancerIP toe aan het YAML-manifest van de load balancer: voeg de eigenschap Service.Spec.LoadBalancerIP toe aan het YAML-manifest van de load balancer. Dit veld wordt afgeschaft na upstream Kubernetes en biedt geen ondersteuning voor dual-stack. Het huidige gebruik blijft hetzelfde en bestaande services werken naar verwachting zonder aanpassingen.

Het servicemanifest implementeren

Implementeer het openbare-servicemanifest met behulp van kubectl apply en geef de naam van uw YAML-manifest op.

kubectl apply -f public-svc.yaml

De Azure Load Balancer is geconfigureerd met een nieuw openbaar IP-adres dat de nieuwe service fronteert. Omdat de Azure Load Balancer meerdere front-end-IP-adressen kan hebben, krijgt elke nieuwe service die u implementeert een nieuw toegewezen front-end-IP-adres dat uniek toegankelijk is.

Controleer of uw service is gemaakt en dat de load balancer is geconfigureerd met behulp van de volgende opdracht.

kubectl get service public-svc

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

Wanneer u de servicedetails bekijkt, wordt het openbare IP-adres dat voor deze service is gemaakt op de load balancer weergegeven in de kolom EXTERNAL-IP . Het kan enkele minuten duren voordat het IP-adres is gewijzigd van <in behandeling> naar een daadwerkelijk openbaar IP-adres.

Gebruik de volgende opdracht voor meer gedetailleerde informatie over uw service.

kubectl describe service public-svc

De volgende voorbeelduitvoer is een verkorte versie van de uitvoer nadat u de uitvoer hebt uitgevoerd kubectl describe service. LoadBalancer Inkomend verkeer toont het externe IP-adres dat door uw service wordt weergegeven. IP toont de interne adressen.

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

De openbare standaard load balancer configureren

U kunt verschillende instellingen voor uw standaard openbare load balancer aanpassen tijdens het maken van het cluster of door het cluster bij te werken. Met deze aanpassingsopties kunt u een load balancer maken die voldoet aan uw workloadbehoeften. Met de standard load balancer kunt u het volgende doen:

• Het aantal beheerde uitgaande IP-adressen instellen of schalen.
• Uw eigen aangepaste uitgaande IP-adressen of uitgaand IP-voorvoegsel gebruiken.
• Pas het aantal toegewezen uitgaande poorten aan elk knooppunt in het cluster aan.
• Configureer de time-outinstelling voor niet-actieve verbindingen.

Belangrijk

Er kan slechts één uitgaande IP-optie (beheerde IP-adressen, bring your own IP of IP-voorvoegsel) op een bepaald moment worden gebruikt.

Het type binnenkomende pool wijzigen

AKS-knooppunten kunnen worden verwezen in de back-endpools van de load balancer door hun IP-configuratie (lidmaatschap van Azure Virtual Machine Scale Sets) of alleen op hun IP-adres. Het gebruik van het lidmaatschap van de back-endpool op basis van IP-adressen biedt een hogere efficiëntie bij het bijwerken van services en het inrichten van load balancers, met name bij hoge aantallen knooppunten. Het inrichten van nieuwe clusters met back-endpools op basis van IP en het converteren van bestaande clusters wordt nu ondersteund. Wanneer het inrichten van nieuwe knooppunten en services in combinatie met NAT Gateway of door de gebruiker gedefinieerde routeringstypen beter presteert.

Er zijn twee verschillende typen groepslidmaatschappen beschikbaar:

• nodeIPConfiguration - verouderde ip-configuratie op basis van ip-configuratie van virtuele-machineschaalsets, type groepslidmaatschap
• nodeIP - Type IP-lidmaatschap

Vereisten

• Het AKS-cluster moet versie 1.23 of hoger zijn.
• Het AKS-cluster moet gebruikmaken van standard load balancers en virtuele-machineschaalsets.

Een nieuw AKS-cluster maken met lidmaatschap van binnenkomende ip-adressen

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

Een bestaand AKS-cluster bijwerken om lidmaatschap van binnenkomende ip-adressen te gebruiken

Waarschuwing

Deze bewerking veroorzaakt een tijdelijke onderbreking van binnenkomend serviceverkeer in het cluster. De impacttijd neemt toe met grotere clusters met veel knooppunten.

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

Het aantal beheerde openbare IP-adressen schalen

Azure Load Balancer biedt uitgaande en binnenkomende connectiviteit vanuit een virtueel netwerk. Uitgaande regels maken het eenvoudig om netwerkadresomzetting te configureren voor de openbare standaard load balancer.

Uitgaande regels volgen dezelfde syntaxis als taakverdeling en binnenkomende NAT-regels:

front-end-IP's + parameters + back-endpool

Met een uitgaande regel configureert u uitgaande NAT voor alle virtuele machines die worden geïdentificeerd door de back-endpool die moeten worden vertaald naar de front-end. Parameters bieden meer controle over het uitgaande NAT-algoritme.

Hoewel u een uitgaande regel met één openbaar IP-adres kunt gebruiken, zijn uitgaande regels ideaal voor het schalen van uitgaande NAT, omdat deze de configuratielast vereenvoudigen. U kunt meerdere IP-adressen gebruiken om grootschalige scenario's en uitgaande regels te plannen om SNAT-uitputtingsgevoelige patronen te beperken. Elk IP-adres dat door een front-end wordt geleverd, biedt 64.000 tijdelijke poorten voor de load balancer die als SNAT-poorten kan worden gebruikt.

Wanneer u een Standard SKU-load balancer gebruikt met beheerde openbare IP-adressen voor uitgaand verkeer (die standaard worden gemaakt), kunt u het aantal beheerde openbare IP-adressen schalen met behulp van de --load-balancer-managed-outbound-ip-count parameter.

Gebruik de volgende opdracht om een bestaand cluster bij te werken. U kunt deze parameter ook instellen op meerdere beheerde openbare IP-adressen voor uitgaand verkeer.

Belangrijk

Het wordt afgeraden om Azure Portal te gebruiken om uitgaande regels te wijzigen. Wanneer u deze wijzigingen aanbrengt, moet u het AKS-cluster doorlopen en niet rechtstreeks op de Load Balancer-resource.

Wijzigingen in uitgaande regels die rechtstreeks op de Load Balancer-resource zijn aangebracht, worden verwijderd wanneer het cluster is afgestemd, zoals wanneer het is gestopt, gestart, bijgewerkt of geschaald.

Gebruik de Azure CLI, zoals wordt weergegeven in de voorbeelden. Wijzigingen in uitgaande regels die zijn aangebracht met behulp van az aks CLI-opdrachten, zijn permanent voor downtime van clusters.

Zie de uitgaande regels van Azure Load Balancer voor meer informatie.

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

In het bovenstaande voorbeeld wordt het aantal beheerde openbare IP-adressen ingesteld op 2 voor het myAKSCluster-cluster in myResourceGroup.

Tijdens het maken van een cluster kunt u ook het eerste aantal beheerde openbare IP-adressen instellen door de --load-balancer-managed-outbound-ip-count parameter toe te voegen en deze in te stellen op de gewenste waarde. Het standaardaantal beheerde openbare IP-adressen voor uitgaand verkeer is 1.

Geef uw eigen uitgaande openbare IP-adressen of voorvoegsels op

Wanneer u een standard-SKU-load balancer gebruikt, maakt het AKS-cluster automatisch een openbaar IP-adres in de resourcegroep voor door AKS beheerde infrastructuur en wijst dit standaard toe aan de uitgaande load balancer-pool.

Een openbaar IP-adres dat door AKS is gemaakt, is een door AKS beheerde resource, wat betekent dat AKS de levenscyclus van dat openbare IP-adres beheert en geen gebruikersactie rechtstreeks op de openbare IP-resource vereist. U kunt ook uw eigen aangepaste openbare IP-adres of openbaar IP-voorvoegsel toewijzen tijdens het maken van het cluster. Uw aangepaste IP-adressen kunnen ook worden bijgewerkt op de load balancer-eigenschappen van een bestaand cluster.

Vereisten voor het gebruik van uw eigen openbare IP of voorvoegsel zijn:

• Gebruikers moeten aangepaste openbare IP-adressen maken en bezitten. Beheerde openbare IP-adressen die door AKS zijn gemaakt, kunnen niet opnieuw worden gebruikt als een 'Bring Your Own Custom IP', omdat dit beheerconflicten kan veroorzaken.
• U moet ervoor zorgen dat de AKS-clusteridentiteit (service-principal of beheerde identiteit) machtigingen heeft voor toegang tot het uitgaande IP-adres, volgens de vereiste lijst met openbare IP-machtigingen.
• Zorg ervoor dat u voldoet aan de vereisten en beperkingen die nodig zijn om uitgaande IP-adressen of uitgaande IP-voorvoegsels te configureren.

Het cluster bijwerken met uw eigen uitgaande openbare IP-adres

Gebruik de az network public-ip show opdracht om de id's van uw openbare IP-adressen weer te geven.

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

De bovenstaande opdracht toont de id voor het openbare IP-adres van myPublicIP in de resourcegroep myResourceGroup .

Gebruik de az aks update opdracht met de load-balancer-outbound-ips parameter om uw cluster bij te werken met uw openbare IP-adressen.

In het volgende voorbeeld wordt de load-balancer-outbound-ips parameter gebruikt met de id's van de vorige opdracht.

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

Het cluster bijwerken met uw eigen uitgaande openbare IP-voorvoegsel

U kunt ook openbare IP-voorvoegsels gebruiken voor uitgaand verkeer met uw Standard SKU-load balancer. In het volgende voorbeeld wordt de opdracht az network public-ip prefix show gebruikt om de id's van uw openbare IP-voorvoegsels weer te geven.

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

De bovenstaande opdracht toont de id voor het openbare IP-voorvoegsel myPublicIPPrefix in de resourcegroep myResourceGroup .

In het volgende voorbeeld wordt de parameter load-balancer-outbound-ip-voorvoegsels gebruikt met de id's van de vorige opdracht.

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

Het cluster maken met uw eigen openbare IP-adres of voorvoegsels

Wanneer u uw cluster maakt, kunt u uw eigen IP-adressen of IP-voorvoegsels voor uitgaand verkeer gebruiken om scenario's te ondersteunen, zoals het toevoegen van uitgaande eindpunten aan een acceptatielijst. Als u uw eigen openbare IP-adressen en IP-voorvoegsels tijdens het maken van het cluster wilt definiëren, voegt u dezelfde parameters toe die in de vorige opdracht worden weergegeven.

Gebruik de az aks create opdracht met de load-balancer-outbound-ips parameter om een nieuw cluster te maken met uw eigen openbare IP-adressen.

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

Gebruik de az aks create opdracht met de load-balancer-outbound-ip-prefixes parameter om een nieuw cluster te maken met uw eigen openbare IP-voorvoegsels.

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

De toegewezen uitgaande poorten configureren

Belangrijk

Als u toepassingen op uw cluster hebt die een groot aantal verbindingen tot stand kunnen brengen met een kleine set bestemmingen op openbare IP-adressen, zoals veel exemplaren van een front-endtoepassing die verbinding maakt met een database, is er mogelijk een scenario dat vatbaar is voor uitputting van SNAT-poorten. SNAT-poortuitputting treedt op wanneer een toepassing geen uitgaande poorten meer kan gebruiken om een verbinding met een andere toepassing of host tot stand te brengen. Als u een scenario hebt dat vatbaar is voor SNAT-poortuitputting, raden we u ten zeerste aan om de toegewezen uitgaande poorten en uitgaande front-end-IP's op de load balancer te verhogen.

Zie SNAT gebruiken voor uitgaande verbindingen voor meer informatie over SNAT.

Standaard stelt AKS AllocatedOutboundPorts in op de load balancer 0, waarmee automatische uitgaande poorttoewijzing wordt ingeschakeld op basis van de grootte van de back-endpool bij het maken van een cluster. Als een cluster bijvoorbeeld 50 of minder knooppunten heeft, worden er 1024 poorten toegewezen aan elk knooppunt. Met deze waarde kan maximaal aantal knooppunten worden geschaald naar clusters zonder dat er opnieuw moet worden geconfigureerd voor netwerken, maar kan SNAT-poortuitputting vaker voorkomen wanneer er meer knooppunten worden toegevoegd. Naarmate het aantal knooppunten in het cluster toeneemt, zijn er minder poorten beschikbaar per knooppunt. Het verhogen van het aantal knooppunten over de grenzen in de grafiek (bijvoorbeeld van 50 tot 51 knooppunten of 100 tot 101) kan verstorend zijn voor de connectiviteit, omdat de SNAT-poorten die aan bestaande knooppunten zijn toegewezen, worden verminderd om meer knooppunten mogelijk te maken. Het gebruik van een expliciete waarde voor AllocatedOutboundPorts, zoals hieronder wordt weergegeven, wordt aanbevolen.

Als u de waarde AllocatedOutboundPorts voor de load balancer van het AKS-cluster wilt weergeven, gebruikt u 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

In de volgende voorbeelduitvoer ziet u dat automatische uitgaande poorttoewijzing op basis van de grootte van de back-endpool is ingeschakeld voor het cluster.

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

Als u een specifieke waarde voor AllocatedOutboundPorts en uitgaand IP-adres wilt configureren bij het maken of bijwerken van een cluster, gebruikt en load-balancer-managed-outbound-ip-countgebruikt load-balancer-outbound-ports u , load-balancer-outbound-ipsof load-balancer-outbound-ip-prefixes. Voordat u een specifieke waarde instelt of een bestaande waarde verhoogt voor uitgaande poorten of uitgaande IP-adressen, moet u het juiste aantal uitgaande poorten en IP-adressen berekenen. Gebruik de volgende vergelijking voor deze berekening die is afgerond op het dichtstbijzijnde gehele getal: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Belangrijk

Als u meer uitgaande IP-adressen toevoegt aan een cluster, beschikt u niet over meer beschikbare SNAT-poorten voor knooppunten, tenzij een niet-nulwaarde voor AllocatedOutboundPorts is ingesteld. Als AllocatedOutboundPorts op de standaardwaarde 0blijft staan, worden de SNAT-poorten voor de knooppunten nog steeds ingesteld volgens de tabel in de load balancer-documentatie en worden de extra poorten van de extra IP-adressen niet gebruikt.

Houd bij het berekenen van het aantal uitgaande poorten en IP-adressen en het instellen van de waarden rekening met de volgende informatie:

• Het aantal uitgaande poorten per knooppunt is opgelost op basis van de waarde die u hebt ingesteld.
• De waarde voor uitgaande poorten moet een veelvoud van 8 zijn.
• Als u meer IP-adressen toevoegt, worden er geen poorten meer toegevoegd aan een knooppunt, maar biedt het capaciteit voor meer knooppunten in het cluster.
• U moet rekening houden met knooppunten die kunnen worden toegevoegd als onderdeel van upgrades, inclusief het aantal knooppunten dat is opgegeven via maxCount en maxSurge-waarden .

In de volgende voorbeelden ziet u hoe de waarden die u instelt van invloed zijn op het aantal uitgaande poorten en IP-adressen:

• Als de standaardwaarden worden gebruikt en het cluster 48 knooppunten heeft, heeft elk knooppunt 1024 poorten beschikbaar.
• Als de standaardwaarden worden gebruikt en het cluster wordt geschaald van 48 tot 52 knooppunten, wordt elk knooppunt bijgewerkt van 1024 poorten die beschikbaar zijn tot 512 poorten beschikbaar.
• Als het aantal uitgaande poorten is ingesteld op 1000 en het aantal uitgaande IP-adressen is ingesteld op 2, kan het cluster maximaal 128 knooppunten ondersteunen: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes
• Als het aantal uitgaande poorten is ingesteld op 1000 en het aantal uitgaande IP-adressen is ingesteld op 7, kan het cluster maximaal 448 knooppunten ondersteunen: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes
• Als het aantal uitgaande poorten is ingesteld op 4000 en het aantal uitgaande IP-adressen is ingesteld op 2, kan het cluster maximaal 32 knooppunten ondersteunen: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes
• Als het aantal uitgaande poorten is ingesteld op 4000 en het aantal uitgaande IP-adressen is ingesteld op 7, kan het cluster maximaal 112 knooppunten ondersteunen: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes

Belangrijk

Nadat u het aantal uitgaande poorten en IP-adressen hebt berekend, controleert u of u extra uitgaande poortcapaciteit hebt om knooppuntpieken tijdens upgrades af te handelen. Het is essentieel om voldoende overtollige poorten toe te wijzen voor extra knooppunten die nodig zijn voor upgrade en andere bewerkingen. AKS is standaard ingesteld op één bufferknooppunt voor upgradebewerkingen. Als u maxSurge-waarden gebruikt, vermenigvuldigt u de uitgaande poorten per knooppunt met uw maxSurge-waarde om het aantal vereiste poorten te bepalen. Als u bijvoorbeeld berekent dat u 4000 poorten per knooppunt nodig hebt met 7 IP-adressen op een cluster met maximaal 100 knooppunten en een maximale piek van 2:

• 2 piekknooppunten * 4000 poorten per knooppunt = 8000 poorten die nodig zijn voor knooppuntpieken tijdens upgrades.
• 100 knooppunten * 4000 poorten per knooppunt = 400.000 poorten vereist voor uw cluster.
• 7 IP-adressen * 64000 poorten per IP = 448.000 poorten beschikbaar voor uw cluster.

In het bovenstaande voorbeeld ziet u dat het cluster een overtollige capaciteit van 48.000 poorten heeft, wat voldoende is om de 8000 poorten te verwerken die nodig zijn voor knooppuntpieken tijdens upgrades.

Zodra de waarden zijn berekend en geverifieerd, kunt u deze waarden toepassen met behulp van load-balancer-outbound-ports , of load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipsof load-balancer-outbound-ip-prefixes bij het maken of bijwerken van een cluster.

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

Time-out voor inactiviteit van de load balancer configureren

Wanneer SNAT-poortbronnen zijn uitgeput, mislukken uitgaande stromen totdat bestaande stromen SNAT-poorten vrijgeven. Load balancer maakt SNAT-poorten vrij wanneer de stroom wordt gesloten en de door AKS geconfigureerde load balancer maakt gebruik van een time-out voor inactiviteit van 30 minuten voor het vrijmaken van SNAT-poorten uit niet-actieve stromen.

U kunt ook transport gebruiken (bijvoorbeeld TCP keepalives of application-layer keepalives) om een niet-actieve stroom te vernieuwen en deze time-out voor inactiviteit zo nodig opnieuw in te stellen. U kunt deze time-out configureren volgens het onderstaande voorbeeld.

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

Als u verwacht talloze kortdurende verbindingen te hebben en geen langdurige verbindingen die lange tijd inactief kunnen zijn, zoals het gebruik kubectl proxy of kubectl port-forward, kunt u overwegen een lage time-outwaarde te gebruiken, zoals 4 minuten. Wanneer u TCP-keepalives gebruikt, is het voldoende om ze aan één kant van de verbinding in te schakelen. Het is bijvoorbeeld voldoende om ze aan de serverzijde alleen in te schakelen om de timer voor inactiviteit van de stroom opnieuw in te stellen. Het is niet nodig dat beide zijden TCP-keepalives starten. Er bestaan vergelijkbare concepten voor toepassingslaag, waaronder configuraties van de databaseclientserver. Controleer aan de serverzijde welke opties er bestaan voor toepassingsspecifieke keepalives.

Belangrijk

Met AKS wordt TCP-reset standaard ingeschakeld voor inactiviteit. We raden u aan deze configuratie te behouden en deze te gebruiken voor meer voorspelbaar toepassingsgedrag in uw scenario's.

TCP RST wordt alleen verzonden tijdens TCP-verbinding met DE STATUS ESTABLISHED. Hier vindt u meer informatie.

Wanneer u IdleTimeoutInMinutes instelt op een andere waarde dan de standaardwaarde van 30 minuten, moet u overwegen hoe lang uw workloads een uitgaande verbinding nodig hebben. Houd er ook rekening mee dat de standaardtime-outwaarde voor een Standard SKU-load balancer die buiten AKS wordt gebruikt, vier minuten is. Een idleTimeoutInMinutes-waarde die nauwkeuriger overeenkomt met uw specifieke AKS-workload, kan helpen bij het verminderen van SNAT-uitputting die wordt veroorzaakt door het koppelen van verbindingen die niet meer worden gebruikt.

Waarschuwing

Als u de waarden voor AllocatedOutboundPorts en IdleTimeoutInMinutes wijzigt , kan het gedrag van de uitgaande regel voor uw load balancer aanzienlijk worden gewijzigd en moet dit niet licht worden gedaan. Raadpleeg de sectie SNAT Troubleshooting en controleer de uitgaande regels en uitgaande verbindingen van Load Balancer in Azure voordat u deze waarden bijwerkt om volledig inzicht te hebben in de impact van uw wijzigingen.

Inkomend verkeer beperken tot specifieke IP-bereiken

In het volgende manifest wordt loadBalancerSourceRanges gebruikt om een nieuw IP-bereik op te geven voor inkomend extern verkeer.

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

In dit voorbeeld wordt de regel bijgewerkt om inkomend extern verkeer alleen vanuit het MY_EXTERNAL_IP_RANGE bereik toe te staan. Als u het IP-adres van het interne subnet vervangt MY_EXTERNAL_IP_RANGE , wordt verkeer beperkt tot alleen interne IP-adressen van clusters. Als verkeer is beperkt tot interne IP-adressen van clusters, hebben clients buiten uw Kubernetes-cluster geen toegang tot de load balancer.

Notitie

• Binnenkomend, extern verkeer stroomt van de load balancer naar het virtuele netwerk voor uw AKS-cluster. Het virtuele netwerk heeft een netwerkbeveiligingsgroep (NSG) die al het binnenkomende verkeer van de load balancer toestaat. Deze NSG maakt gebruik van een servicetag van het type LoadBalancer om verkeer van de load balancer toe te staan.
• Pod CIDR moet worden toegevoegd aan loadBalancerSourceRanges als er pods nodig zijn voor toegang tot het IP-adres van de loadbalancer van de service voor clusters met versie v1.25 of hoger.

Het IP-adres van de client onderhouden voor binnenkomende verbindingen

Standaard behoudt een service van het type LoadBalancer Kubernetes en in AKS het IP-adres van de client niet op de verbinding met de pod. Het bron-IP-adres van het pakket dat aan de pod wordt geleverd, wordt het privé-IP-adres van het knooppunt. Als u het IP-adres van de client wilt onderhouden, moet u instellen service.spec.externalTrafficPolicy op local in de servicedefinitie. In het volgende manifest ziet u een voorbeeld.

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

Aanpassingen via Kubernetes-aantekeningen

De volgende aantekeningen worden ondersteund voor Kubernetes-services met het type LoadBalanceren zijn alleen van toepassing op INKOMENDE stromen.

Aantekening	Weergegeven als	Beschrijving
service.beta.kubernetes.io/azure-load-balancer-internal	true of false	Geef op of de load balancer intern moet zijn. Als deze niet is ingesteld, wordt deze standaard openbaar.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet	Naam van het subnet	Geef op aan welk subnet de interne load balancer moet worden gebonden. Als dit niet is ingesteld, wordt het standaard ingesteld op het subnet dat is geconfigureerd in het cloudconfiguratiebestand.
service.beta.kubernetes.io/azure-dns-label-name	Naam van het DNS-label op openbare IP-adressen	Geef de naam van het DNS-label voor de openbare service op. Als deze is ingesteld op een lege tekenreeks, wordt de DNS-vermelding in het openbare IP-adres niet gebruikt.
service.beta.kubernetes.io/azure-shared-securityrule	true of false	Geef aan dat de service beschikbaar wordt gemaakt via een mogelijk gedeelde Azure-beveiligingsregel om de blootstelling van de service te verhogen, waarbij gebruik wordt gemaakt van Azure Augmented Security Rules in Netwerkbeveiligingsgroepen.
service.beta.kubernetes.io/azure-load-balancer-resource-group	Naam van de resourcegroep	Geef de resourcegroep van openbare IP-adressen van de load balancer op die zich niet in dezelfde resourcegroep bevinden als de clusterinfrastructuur (knooppuntresourcegroep).
service.beta.kubernetes.io/azure-allowed-service-tags	Lijst met toegestane servicetags	Geef een lijst met toegestane servicetags op, gescheiden door komma's.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout	Time-outs voor tcp-inactiviteit in minuten	Geef de tijd in minuten op voor time-outs voor inactiviteit van TCP-verbinding die moeten plaatsvinden op de load balancer. De standaard- en minimumwaarde is 4. De maximumwaarde is 30. De waarde moet een geheel getal zijn.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset	true of false	Geef op of de load balancer TCP-reset moet uitschakelen bij time-out voor inactiviteit.
service.beta.kubernetes.io/azure-load-balancer-ipv4	IPv4-adres	Geef het IPv4-adres op dat moet worden toegewezen aan de load balancer.
service.beta.kubernetes.io/azure-load-balancer-ipv6	IPv6-adres	Geef het IPv6-adres op dat moet worden toegewezen aan de load balancer.

De load balancer-statustest aanpassen

Aantekening	Weergegeven als	Beschrijving
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	Statustestinterval
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Het minimale aantal beschadigde reacties van de statustest
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Aanvraagpad van de statustest
service.beta.kubernetes.io/port_{port}_no_lb_rule	waar/onwaar	{port} is servicepoortnummer. Als deze is ingesteld op true, wordt er geen regel of statustestregel voor deze poort gegenereerd. Health check service mag niet worden blootgesteld aan het openbare internet (bijvoorbeeld istio/envoy health check service)
service.beta.kubernetes.io/port_{port}_no_probe_rule	waar/onwaar	{port} is servicepoortnummer. Als deze is ingesteld op true, wordt er geen statustestregel voor deze poort gegenereerd.
service.beta.kubernetes.io/port_{port}_health-probe_protocol	Statustestprotocol	{port} is servicepoortnummer. Expliciet protocol voor de statustest voor de servicepoort {port}, waarbij port.appProtocol wordt overschreven als deze is ingesteld.
service.beta.kubernetes.io/port_{port}_health-probe_port	poortnummer of poortnaam in servicemanifest	{port} is servicepoortnummer. Expliciete poort voor de statustest voor de servicepoort {port}, waarbij de standaardwaarde wordt overschreven.
service.beta.kubernetes.io/port_{port}_health-probe_interval	Statustestinterval	{port} is servicepoortnummer.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	Het minimale aantal beschadigde reacties van de statustest	{port} is servicepoortnummer.
service.beta.kubernetes.io/port_{port}_health-probe_request-path	Aanvraagpad van de statustest	{port} is servicepoortnummer.

Zoals hier beschreven, zijn Tcp, Http en Https drie protocollen die worden ondersteund door de load balancer-service.

Op dit moment varieert het standaardprotocol van de statustest tussen services met verschillende transportprotocollen, app-protocollen, aantekeningen en beleid voor extern verkeer.

1. voor lokale services wordt HTTP en /healthz gebruikt. De statustest voert een query uit op NodeHealthPort in plaats van op de werkelijke back-endservice
2. voor CLUSTER TCP-services wordt TCP gebruikt.
3. voor UDP-services van het cluster, geen statustests.

Notitie

Voor lokale services waarvoor PLS-integratie en HET PLS-proxyprotocol is ingeschakeld, werkt de standaardstatustest HTTP+/healthz niet. De statustest kan dus op dezelfde manier worden aangepast als clusterservices ter ondersteuning van dit scenario.

Sinds v1.20 wordt serviceaantekening service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path geïntroduceerd om het gedrag van de statustest te bepalen.

• Voor clusters <=1,23 spec.ports.appProtocol wordt alleen gebruikt als testprotocol wanneer service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path deze ook is ingesteld.
• Voor clusters >1.24 spec.ports.appProtocol zou worden gebruikt als testprotocol en / worden gebruikt als standaardpad voor testaanvragen (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path kan worden gebruikt om over te schakelen naar een ander aanvraagpad).

Houd er rekening mee dat het aanvraagpad wordt genegeerd wanneer u TCP gebruikt of het pad spec.ports.appProtocol leeg is. Specifieke opdrachten:

loadbalancer-sku	externalTrafficPolicy	spec.ports.Protocol	spec.ports.AppProtocol	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Testprotocol voor LB	Aanvraagpad voor LB-test
standard	lokaal	willekeurige	willekeurige	willekeurige	http	/healthz
standard	cluster	Udp	willekeurige	willekeurige	Nul	Nul
standard	cluster	tcp		(genegeerd)	tcp	Nul
standard	cluster	tcp	tcp	(genegeerd)	tcp	Nul
standard	cluster	tcp	http/https		TCP(<=1.23) of http/https(>=1.24)	null(<=1,23) of /(>=1,24)
standard	cluster	tcp	http/https	/custom-path	http/https	/custom-path
standard	cluster	tcp	niet-ondersteund protocol	/custom-path	tcp	Nul
basisch	lokaal	willekeurige	willekeurige	willekeurige	http	/healthz
basisch	cluster	tcp		(genegeerd)	tcp	Nul
basisch	cluster	tcp	tcp	(genegeerd)	tcp	Nul
basisch	cluster	tcp	http		TCP(<=1.23) of http/https(>=1.24)	null(<=1,23) of /(>=1,24)
basisch	cluster	tcp	http	/custom-path	http	/custom-path
basisch	cluster	tcp	niet-ondersteund protocol	/custom-path	tcp	Nul

Sinds v1.21 worden er twee serviceaantekeningen service.beta.kubernetes.io/azure-load-balancer-health-probe-interval geïntroduceerd, load-balancer-health-probe-num-of-probe waarmee de configuratie van de statustest wordt aangepast. Als service.beta.kubernetes.io/azure-load-balancer-health-probe-interval dit niet is ingesteld, wordt de standaardwaarde van 5 toegepast. Als load-balancer-health-probe-num-of-probe dit niet is ingesteld, wordt de standaardwaarde 2 toegepast. En de totale test moet minder dan 120 seconden zijn.

Aangepaste load balancer-statustest voor poort

Verschillende poorten in een service kunnen verschillende statustestconfiguraties vereisen. Dit kan komen door serviceontwerp (zoals één statuseindpunt dat meerdere poorten beheert) of Kubernetes-functies zoals de MixedProtocolLBService.

De volgende aantekeningen kunnen worden gebruikt om de testconfiguratie per servicepoort aan te passen.

poortspecifieke aantekening	globale annotatie voor tests	Gebruik
service.beta.kubernetes.io/port_{port}_no_lb_rule	N.b. (geen equivalent wereldwijd)	als true is ingesteld, worden er geen lb-regels en testregels gegenereerd
service.beta.kubernetes.io/port_{port}_no_probe_rule	N.b. (geen equivalent wereldwijd)	als true is ingesteld, worden er geen testregels gegenereerd
service.beta.kubernetes.io/port_{port}_health-probe_protocol	N.b. (geen equivalent wereldwijd)	Het statustestprotocol voor deze servicepoort instellen (bijvoorbeeld Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port	N.b. (geen equivalent wereldwijd)	Hiermee stelt u de statustestpoort in voor deze servicepoort (bijvoorbeeld 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-pad	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Voor Http of Https stelt u het aanvraagpad voor de statustest in. Standaard ingesteld op/
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	Aantal opeenvolgende testfouten voordat de poort als beschadigd wordt beschouwd
service.beta.kubernetes.io/port_{port}_health-probe_interval	service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	De hoeveelheid tijd tussen testpogingen

Voor het volgende manifest is de testregel voor poort httpsserver anders dan voor httpserver, omdat aantekeningen voor poort httpsserver zijn opgegeven.

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

In dit manifest gebruiken de https-poorten een andere knooppuntpoort, een HTTP-gereedheidscontrole op poort 10256 op /healthz(healthz-eindpunt van 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

In dit manifest gebruiken de https-poorten een ander statustesteindpunt, een HTTP-gereedheidscontrole op poort 30000 op /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

Problemen met SNAT oplossen

Als u weet dat u veel uitgaande TCP- of UDP-verbindingen met hetzelfde doel-IP-adres en dezelfde poort start en u ziet dat er mislukte uitgaande verbindingen of ondersteuning u op de hoogte stelt dat u SNAT-poorten verbruikt (vooraf toegewezen tijdelijke poorten die door PAT worden gebruikt), hebt u verschillende algemene beperkingsopties. Bekijk deze opties en bepaal wat het beste is voor uw scenario. Het is mogelijk dat een of meer personen u kunnen helpen bij het beheren van uw scenario. Raadpleeg de gids voor het oplossen van problemen met uitgaande verbindingen voor gedetailleerde informatie.

De hoofdoorzaak van SNAT-uitputting is vaak een antipatroon voor hoe uitgaande connectiviteit tot stand wordt gebracht, beheerd of configureerbare timers zijn gewijzigd van hun standaardwaarden. Lees deze sectie aandachtig.

Stappen

1. Controleer of uw verbindingen lang inactief blijven en afhankelijk zijn van de standaard time-out voor inactiviteit voor het vrijgeven van die poort. Als dit het geval is, moet de standaardtime-out van 30 minuten mogelijk worden verminderd voor uw scenario.
2. Onderzoek hoe uw toepassing uitgaande connectiviteit maakt (bijvoorbeeld codebeoordeling of pakketopname).
3. Bepaal of deze activiteit verwacht gedrag vertoont of dat de app niet goed werkt. Gebruik metrische gegevens en logboeken in Azure Monitor om uw bevindingen te onderbouwen. Gebruik bijvoorbeeld de categorie Mislukt voor metrische gegevens voor SNAT-verbindingen.
4. Evalueer of de juiste patronen worden gevolgd.
5. Evalueer of SNAT-poortuitputting moet worden beperkt met meer uitgaande IP-adressen + meer toegewezen uitgaande poorten.

Ontwerppatronen

Profiteer waar mogelijk van hergebruik van verbindingen en groepsgewijze verbindingen. Deze patronen helpen u bij het voorkomen van problemen met uitputting van resources en leiden tot voorspelbaar gedrag. Primitieven voor deze patronen vindt u in veel ontwikkelbibliotheken en frameworks.

• Atomische aanvragen (één aanvraag per verbinding) zijn over het algemeen geen goede ontwerpkeuze. Dergelijke antipatronen beperken schaal, prestaties verminderen en betrouwbaarheid verlagen. Hergebruik in plaats daarvan HTTP/S-verbindingen om het aantal verbindingen en de bijbehorende SNAT-poorten te verminderen. De schaal van de toepassing verbetert en de prestaties worden verbeterd vanwege verminderde handshakes, overhead en cryptografische bewerkingskosten bij het gebruik van TLS.
• Als u geen cluster-/aangepaste DNS of aangepaste upstreamservers op coreDNS gebruikt, moet u er rekening mee houden dat DNS veel afzonderlijke stromen op volume kan introduceren wanneer de client het resultaat van de DNS-resolvers niet in de cache opstuurt. Zorg ervoor dat u coreDNS eerst aanpast in plaats van aangepaste DNS-servers te gebruiken en een goede cachewaarde te definiëren.
• UDP-stromen (bijvoorbeeld DNS-zoekacties) wijzen SNAT-poorten toe tijdens de time-out voor inactiviteit. Hoe langer de time-out voor inactiviteit, hoe hoger de druk op de SNAT-poorten. Gebruik korte time-out voor inactiviteit (bijvoorbeeld 4 minuten).
• Gebruik verbindingspools om vorm te geven aan het volume van uw verbindingen.
• Verlaat nooit zo maar een TCP-stroom en maak gebruik van TCP-timers om de stroom op te schonen. Als u TCP de verbinding niet expliciet laat sluiten, blijft de status toegewezen op tussenliggende systemen en eindpunten en is SNAT-poorten niet beschikbaar voor andere verbindingen. Dit patroon kan fouten in de app en SNAT-uitputting veroorzaken.
• Wijzig timerwaarden voor het sluiten door TCP op besturingssysteemniveau alleen als u uitgebreide kennis hebt van de gevolgen hiervan. Hoewel de TCP-stack wordt hersteld, kunnen de prestaties van uw toepassing negatief worden beïnvloed wanneer de eindpunten van een verbinding niet overeenkomen met de verwachtingen. Het wijzigen van timers is meestal een teken van een onderliggend ontwerpprobleem. Bestudeer de volgende aanbevelingen.

Overstappen van een Basic SKU load balancer naar Standard SKU

Als u een bestaand cluster met de Basic SKU load balancer hebt, zijn er belangrijke gedragsverschillen die u moet noteren bij het migreren naar de Standard SKU-load balancer.

Het maken van blauw-groene implementaties voor het migreren van clusters is bijvoorbeeld gebruikelijk, gezien het load-balancer-sku type cluster en kan alleen worden gedefinieerd tijdens het maken van clusters. Basic SKU-load balancers maken echter gebruik van BASIC SKU-IP-adressen, die niet compatibel zijn met Standard SKU-load balancers. Standard-SKU-load balancers vereisen Standaard-SKU-IP-adressen . Wanneer u clusters migreert om load balancer-SKU's te upgraden, is een nieuw IP-adres met een compatibele SKU voor IP-adressen vereist.

Raadpleeg onze documentatie over migratieoverwegingen voor meer overwegingen over het migreren van clusters.

Beperkingen

De volgende beperkingen gelden wanneer u AKS-clusters maakt en beheert die ondersteuning bieden voor een load balancer met de Standard-SKU :

• Er is ten minste één openbaar IP-adres of IP-adresvoorvoegsel vereist om uitgaand verkeer van het AKS-cluster toe te staan. Het openbare IP-adres of IP-adresvoorvoegsel is vereist om de connectiviteit tussen het besturingsvlak en agentknooppunten te behouden en om de compatibiliteit met eerdere versies van AKS te behouden. U hebt de volgende opties voor het opgeven van openbare IP-adressen of IP-voorvoegsels met een Standard SKU-load balancer:
  • Geef uw eigen openbare IP-adressen op.
  • Geef uw eigen openbare IP-adresvoorvoegsels op.
  • Geef een getal op tot 100, zodat het AKS-cluster zoveel openbare IP-adressen van de Standard-SKU kan maken in dezelfde resourcegroep als het AKS-cluster. Deze resourcegroep heeft meestal de naam MC_ aan het begin. AKS wijst het openbare IP-adres toe aan de standard-SKU-load balancer. Standaard wordt er automatisch één openbaar IP-adres gemaakt in dezelfde resourcegroep als het AKS-cluster als er geen openbaar IP-adres, openbaar IP-voorvoegsel of aantal IP-adressen is opgegeven. U moet ook openbare adressen toestaan en voorkomen dat u Azure-beleid maakt waardoor het maken van IP-adressen wordt verboden.
• Een openbaar IP-adres dat door AKS is gemaakt, kan niet opnieuw worden gebruikt als een eigen aangepast openbaar IP-adres. Gebruikers moeten alle aangepaste IP-adressen maken en beheren.
• Het definiëren van de load balancer-SKU kan alleen worden uitgevoerd wanneer u een AKS-cluster maakt. U kunt de load balancer-SKU niet wijzigen nadat een AKS-cluster is gemaakt.
• U kunt slechts één type load balancer-SKU (Basic of Standard) in één cluster gebruiken.
• Standard-SKU-load balancers bieden alleen ondersteuning voor IP-adressen van standard-SKU's .

Volgende stappen

Zie de Documentatie voor Kubernetes-services voor meer informatie over Kubernetes-services.

Zie de documentatie van de interne load balancer van AKS voor meer informatie over het gebruik van interne load balancer voor inkomend verkeer.