De Azure CNI Overlay-netwerken configureren in Azure Kubernetes Service (AKS)

De traditionele Azure Container Networking Interface (CNI) wijst een VNet-IP-adres toe aan elke pod. Het wijst dit IP-adres toe vanuit een vooraf gereserveerde set IP-adressen op elk knooppunt of een afzonderlijk subnet dat is gereserveerd voor pods. Voor deze aanpak is het plannen van IP-adressen vereist en kan dit leiden tot uitputting, wat problemen veroorzaakt bij het schalen van uw clusters naarmate de vraag naar uw toepassing toeneemt.

Met Azure CNI-overlay worden de clusterknooppunten geïmplementeerd in een VNet-subnet (Virtual Network) van Azure. Pods worden toegewezen IP-adressen van een privé-CIDR logisch anders dan het VNet dat als host fungeert voor de knooppunten. Pod- en knooppuntverkeer binnen het cluster maken gebruik van een Overlay-netwerk. Network Address Translation (NAT) gebruikt het IP-adres van het knooppunt om resources buiten het cluster te bereiken. Deze oplossing bespaart een aanzienlijke hoeveelheid VNet-IP-adressen en stelt u in staat om uw cluster te schalen naar grote grootten. Een extra voordeel is dat u de privé-CIDR opnieuw kunt gebruiken in verschillende AKS-clusters, waardoor de IP-ruimte die beschikbaar is voor toepassingen in containers in Azure Kubernetes Service (AKS) wordt uitgebreid.

Overzicht van Overlay-netwerken

In Overlay-netwerken krijgen alleen de Kubernetes-clusterknooppunten IP-adressen van subnetten toegewezen. Pods ontvangen IP-adressen van een persoonlijke CIDR die is opgegeven op het moment dat het cluster is gemaakt. Aan elk knooppunt wordt een /24 adresruimte toegewezen die is uitgesneden uit dezelfde CIDR. Extra knooppunten die zijn gemaakt wanneer u een cluster uitschaalt, ontvangen /24 automatisch adresruimten van dezelfde CIDR. Azure CNI wijst IP-adressen toe aan pods vanuit deze /24 ruimte.

Er wordt een afzonderlijk routeringsdomein gemaakt in de Azure-netwerkstack voor de privé-CIDR-ruimte van de pod, waarmee een Overlay-netwerk wordt gemaakt voor directe communicatie tussen pods. Het is niet nodig om aangepaste routes in te richten op het clustersubnet of een inkapselingsmethode te gebruiken om verkeer tussen pods te tunnelen. Dit biedt connectiviteitsprestaties tussen pods op dezelfde manier als virtuele machines in een VNet. Workloads die in de pods worden uitgevoerd, zijn niet eens op de hoogte dat het bewerken van netwerkadressen plaatsvindt.

Communicatie met eindpunten buiten het cluster, zoals on-premises en gekoppelde VNets, gebeurt met behulp van het IP-adres van het knooppunt via NAT. Azure CNI vertaalt het bron-IP-adres (Overlay-IP van de pod) van het verkeer naar het primaire IP-adres van de VIRTUELE machine, waardoor de Azure-netwerkstack het verkeer naar de bestemming kan routeren. Eindpunten buiten het cluster kunnen niet rechtstreeks verbinding maken met een pod. U moet de toepassing van de pod publiceren als een Kubernetes Load Balancer-service om deze bereikbaar te maken op het VNet.

U kunt uitgaande (uitgaande) connectiviteit met internet bieden voor Overlay-pods met behulp van een Standard SKU Load Balancer of Managed NAT Gateway. U kunt ook uitgaand verkeer beheren door het naar een firewall te leiden met behulp van door de gebruiker gedefinieerde routes in het clustersubnet.

U kunt toegangsbeheerobjectconnectiviteit met het cluster configureren met behulp van een ingangscontroller, zoals Nginx of HTTP-toepassingsroutering. U kunt geen toegangsbeheerobjectconnectiviteit configureren met behulp van Azure-app Gateway. Zie Beperkingen met Azure CNI-overlay voor meer informatie.

Verschillen tussen Kubenet en Azure CNI-overlay

Net als Azure CNI Overlay wijst Kubenet IP-adressen toe aan pods vanuit een adresruimte die logisch verschilt van het VNet, maar het heeft schaalaanpassing en andere beperkingen. De onderstaande tabel bevat een gedetailleerde vergelijking tussen Kubenet en Azure CNI Overlay. Als u geen VNet-IP-adressen wilt toewijzen aan pods vanwege een tekort aan IP-adressen, raden we u aan Azure CNI-overlay te gebruiken.

Gebied	Azure CNI-overlay	Kubenet
Clusterschaal	5000 knooppunten en 250 pods/knooppunten	400 knooppunten en 250 pods/knooppunten
Netwerkconfiguratie	Eenvoudig- geen extra configuraties vereist voor podnetwerken	Complex: vereist routetabellen en UDR's in het clustersubnet voor podnetwerken
Prestaties van podconnectiviteit	Prestaties op basis van vm's in een VNet	Extra hop voegt latentie toe
Kubernetes-netwerkbeleid	Azure-netwerkbeleid, Calico, Cilium	Calico
Ondersteunde besturingssysteemplatforms	Linux en Windows Server 2022, 2019	Alleen Linux

PLANNING van IP-adressen

• Clusterknooppunten: zorg er bij het instellen van uw AKS-cluster voor dat uw VNet-subnetten voldoende ruimte hebben om te groeien voor toekomstige schaalaanpassing. U kunt elke knooppuntgroep toewijzen aan een toegewezen subnet. Een /24subnet kan maximaal 251 knooppunten bevatten, omdat de eerste drie IP-adressen zijn gereserveerd voor beheertaken.
• Pods: De Overlay-oplossing wijst een /24 adresruimte toe voor pods op elk knooppunt vanuit de persoonlijke CIDR die u opgeeft tijdens het maken van het cluster. De /24 grootte is vast en kan niet worden verhoogd of verlaagd. U kunt maximaal 250 pods uitvoeren op een knooppunt. Zorg er bij het plannen van de adresruimte voor pods voor dat de privé-CIDR groot genoeg is om adresruimten te bieden /24 voor nieuwe knooppunten om toekomstige clusteruitbreiding te ondersteunen.
  • Houd rekening met de volgende factoren bij het plannen van IP-adresruimte voor pods:
    • Dezelfde CIDR-ruimte voor pods kan worden gebruikt op meerdere onafhankelijke AKS-clusters in hetzelfde VNet.
    • De CIDR-ruimte voor pods mag niet overlappen met het clustersubnetbereik.
    • CiDR-ruimte voor pods mag niet overlappen met rechtstreeks verbonden netwerken (zoals VNet-peering, ExpressRoute of VPN). Als extern verkeer bron-IP-adressen in het podCIDR-bereik heeft, moet het worden omgezet naar een niet-overlappend IP-adres via SNAT om te communiceren met het cluster.
• Kubernetes-serviceadresbereik: de grootte van het serviceadres CIDR is afhankelijk van het aantal clusterservices dat u wilt maken. Het moet kleiner zijn dan /12. Dit bereik mag niet overlappen met het CIDR-bereik van de pod, het clustersubnetbereik en het IP-bereik dat wordt gebruikt in gekoppelde VNets en on-premises netwerken.
• IP-adres van kubernetes DNS-service: dit IP-adres bevindt zich binnen het Kubernetes-serviceadresbereik dat wordt gebruikt door clusterservicedetectie. Gebruik niet het eerste IP-adres in uw adresbereik, omdat dit adres wordt gebruikt voor het kubernetes.default.svc.cluster.local adres.

Netwerkbeveiligingsgroepen

Pod-naar-podverkeer met Azure CNI-overlay wordt niet ingekapseld en regels voor subnetbeveiligingsgroepen worden toegepast. Als de subnet-NSG regels voor weigeren bevat die van invloed zijn op het CIDR-verkeer van de pod, moet u ervoor zorgen dat de volgende regels zijn ingesteld om de juiste clusterfunctionaliteit te garanderen (naast alle AKS-vereisten voor uitgaand verkeer):

• Verkeer van het knooppunt CIDR naar het knooppunt CIDR op alle poorten en protocollen
• Verkeer van het knooppunt CIDR naar de POD CIDR op alle poorten en protocollen (vereist voor routering van serviceverkeer)
• Verkeer van de POD CIDR naar de POD CIDR op alle poorten en protocollen (vereist voor pod-naar-pod- en pod-naar-serviceverkeer, inclusief DNS)

Verkeer van een pod naar een bestemming buiten het CIDR-blok van de pod maakt gebruik van SNAT om het bron-IP-adres in te stellen op het IP-adres van het knooppunt waarop de pod wordt uitgevoerd.

Als u verkeer tussen workloads in het cluster wilt beperken, raden we u aan netwerkbeleid te gebruiken.

Maximum aantal pods per knooppunt

U kunt het maximum aantal pods per knooppunt configureren op het moment dat het cluster wordt gemaakt of wanneer u een nieuwe knooppuntgroep toevoegt. De standaardinstelling voor Azure CNI-overlay is 250. De maximumwaarde die u kunt opgeven in Azure CNI Overlay is 250 en de minimumwaarde is 10. De maximale pods per knooppuntwaarde die tijdens het maken van een knooppuntgroep zijn geconfigureerd, zijn alleen van toepassing op de knooppunten in die knooppuntgroep.

Een netwerkmodel kiezen dat moet worden gebruikt

Azure CNI biedt twee IP-adresseringsopties voor pods: de traditionele configuratie waarmee VNet-IP's worden toegewezen aan pods en Overlay-netwerken. De keuze welke optie u voor uw AKS-cluster wilt gebruiken, is een balans tussen flexibiliteit en geavanceerde configuratiebehoeften. De volgende overwegingen helpen om een overzicht te geven wanneer elk netwerkmodel mogelijk het meest geschikt is.

Gebruik Overlay-netwerken wanneer:

• U wilt schalen naar een groot aantal pods, maar u hebt beperkte IP-adresruimte in uw VNet.
• De meeste podcommunicatie bevindt zich in het cluster.
• U hebt geen geavanceerde AKS-functies nodig, zoals virtuele knooppunten.

Gebruik de traditionele VNet-optie wanneer:

• U hebt beschikbare IP-adresruimte.
• De meeste podcommunicatie is naar resources buiten het cluster.
• Resources buiten het cluster moeten pods rechtstreeks bereiken.
• U hebt geavanceerde AKS-functies nodig, zoals virtuele knooppunten.

Beperkingen met Azure CNI-overlay

Azure CNI Overlay heeft de volgende beperkingen:

• U kunt Application Gateway niet gebruiken als een ingangscontroller (AGIC) voor een Overlay-cluster.
• U kunt Application Gateway voor containers niet gebruiken voor een Overlay-cluster.
• Beschikbaarheidssets voor virtuele machines (VMAS) worden niet ondersteund voor Overlay.
• U kunt virtuele machines uit de DCsv2-serie niet gebruiken in knooppuntgroepen. Als u wilt voldoen aan de vereisten voor Confidential Computing, kunt u in plaats daarvan vertrouwelijke VM's uit de DCasv5- of DCadsv5-serie gebruiken.
• Als u uw eigen subnet gebruikt om het cluster te implementeren, moeten de namen van het subnet, het VNET en de resourcegroep die het VNET bevat, 63 tekens of minder zijn. Dit komt van het feit dat deze namen worden gebruikt als labels in AKS-werkknooppunten en daarom worden onderworpen aan kubernetes-labelsyntaxisregels.

Overlayclusters instellen

Notitie

U moet CLI-versie 2.48.0 of hoger hebben om het --network-plugin-mode argument te kunnen gebruiken. Voor Windows moet de nieuwste Azure CLI-extensie aks-preview zijn geïnstalleerd en kunt u de onderstaande instructies volgen.

Maak een cluster met Azure CNI Overlay met behulp van de az aks create opdracht. Zorg ervoor dat u het argument --network-plugin-mode gebruikt om een overlaycluster op te geven. Als de POD CIDR niet is opgegeven, wijst AKS een standaardruimte toe: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --generate-ssh-keys

Een nieuwe knooppuntpool toevoegen aan een toegewezen subnet

Nadat u een cluster hebt gemaakt met Azure CNI Overlay, kunt u een andere knooppuntpool maken en de knooppunten toewijzen aan een nieuw subnet van hetzelfde VNet. Deze benadering kan handig zijn als u de ip-adressen voor inkomend of uitgaand verkeer van de host wilt beheren van/naar doelen in hetzelfde VNET of gekoppelde VNets.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add --resource-group $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Een bestaand cluster upgraden naar CNI-overlay

Notitie

U kunt een bestaand Azure CNI-cluster bijwerken naar Overlay als het cluster voldoet aan de volgende criteria:

• Het cluster bevindt zich op Kubernetes versie 1.22+.
• Maakt geen gebruik van de functie ip-toewijzing van dynamische pods.
• Netwerkbeleid is niet ingeschakeld. Network Policy Engine kan worden verwijderd vóór de upgrade, zie Azure Network Policy Manager of Calico verwijderen
• Gebruikt geen Windows-knooppuntgroepen met docker als containerruntime.

Notitie

Het upgraden van een bestaand cluster naar CNI Overlay is een niet-omkeerbaar proces.

Waarschuwing

Vóór Windows OS Build 20348.1668 was er een beperking rond Windows Overlay-pods die onjuist SNATing-pakketten van hostnetwerkpods hadden, wat een nadeliger effect had voor clusters die upgraden naar Overlay. Gebruik Windows OS Build groter dan of gelijk aan 20348.1668 om dit probleem te voorkomen.

Waarschuwing

Als u een aangepaste configuratie van azure-ip-masq-agent gebruikt om extra IP-bereiken op te nemen die geen SNAT-pakketten van pods mogen bevatten, kan een upgrade naar Azure CNI Overlay de connectiviteit met deze bereiken verbreken. Pod-IP's vanuit de overlayruimte zijn niet bereikbaar door iets buiten de clusterknooppunten. Bovendien kan er voor voldoende oude clusters een ConfigMap overblijven van een eerdere versie van azure-ip-masq-agent. Als deze ConfigMap, benoemd azure-ip-masq-agent-config, bestaat en niet opzettelijk in-place is, moet deze worden verwijderd voordat u de updateopdracht uitvoert. Als u geen aangepaste ip-masq-agent-configuratie gebruikt, moet alleen de azure-ip-masq-agent-config-reconciled ConfigMap bestaan met betrekking tot Azure ip-masq-agent ConfigMaps. Dit wordt automatisch bijgewerkt tijdens het upgradeproces.

Tijdens het upgradeproces wordt elke knooppuntgroep geactiveerd om tegelijkertijd opnieuw te worden geinstallatiekopieën. Het afzonderlijk bijwerken van elke knooppuntgroep naar Overlay wordt niet ondersteund. Eventuele onderbrekingen in clusternetwerken zijn vergelijkbaar met een upgrade van de installatiekopie van een knooppunt of een upgrade van de Kubernetes-versie waarbij elk knooppunt in een knooppuntgroep opnieuw wordt geinstallatiekopie gemaakt.

Upgrade van Azure CNI-cluster

Werk een bestaand Azure CNI-cluster bij om Overlay te gebruiken met behulp van de az aks update opdracht.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

De --pod-cidr parameter is vereist bij het upgraden van verouderde CNI, omdat de pods IP-adressen moeten ophalen uit een nieuwe overlayruimte, die niet overlapt met het bestaande subnet van het knooppunt. De pod CIDR kan ook niet overlappen met een VNet-adres van de knooppuntgroepen. Als uw VNet-adres bijvoorbeeld 10.0.0.0/8 is en uw knooppunten zich in het subnet 10.240.0.0/16 bevinden, kan het --pod-cidr niet overlappen met 10.0.0.0/8 of de bestaande service-CIDR op het cluster.

Upgrade van Kubenet-cluster

Werk een bestaand Kubenet-cluster bij om Azure CNI Overlay te gebruiken met behulp van de az aks update opdracht.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay 

Omdat het cluster al een privé-CIDR gebruikt voor pods die niet overlappen met de VNet-IP-ruimte, hoeft u de --pod-cidr parameter niet op te geven en blijft de POD CIDR hetzelfde als de parameter niet wordt gebruikt.

Notitie

Wanneer u een upgrade uitvoert van Kubenet naar CNI Overlay, is de routetabel niet meer vereist voor podroutering. Als het cluster gebruikmaakt van een door de klant verstrekte routetabel, worden de routes die worden gebruikt om podverkeer naar het juiste knooppunt te leiden, automatisch verwijderd tijdens de migratiebewerking. Als het cluster een beheerde routetabel gebruikt (de routetabel is gemaakt door AKS en zich in de resourcegroep van het knooppunt bevindt), wordt die routetabel verwijderd als onderdeel van de migratie.

Dual-stack-netwerken

U kunt uw AKS-clusters implementeren in een dual-stackmodus wanneer u Overlay-netwerken en een virtueel Azure-netwerk met twee stacks gebruikt. In deze configuratie ontvangen knooppunten zowel een IPv4- als IPv6-adres van het subnet van het virtuele Azure-netwerk. Pods ontvangen zowel een IPv4- als IPv6-adres van een logisch andere adresruimte naar het subnet van het virtuele Azure-netwerk van de knooppunten. NAT (Network Address Translation) wordt vervolgens zo geconfigureerd dat de pods resources kunnen bereiken in het virtuele Azure-netwerk. Het bron-IP-adres van het verkeer is NAT naar het primaire IP-adres van het knooppunt van dezelfde familie (IPv4 naar IPv4 en IPv6 naar IPv6).

Vereisten

• U moet Azure CLI 2.48.0 of hoger hebben geïnstalleerd.
• Kubernetes versie 1.26.3 of hoger.

Beperkingen

De volgende functies worden niet ondersteund met dual-stack-netwerken:

• Azure-netwerkbeleid
• Calico-netwerkbeleid
• NAT-gateway
• Invoegtoepassing voor virtuele knooppunten

Een AKS-cluster met twee stacks implementeren

De volgende kenmerken zijn beschikbaar ter ondersteuning van clusters met dubbele stack:

• --ip-families: maakt gebruik van een door komma's gescheiden lijst met IP-families om het cluster in te schakelen.
  • Alleen ipv4 of ipv4,ipv6 worden ondersteund.
• --pod-cidrs: Maakt gebruik van een door komma's gescheiden lijst met IP-adresbereiken voor CIDR-notatie om POD-IP-adressen toe te wijzen.
  • Het aantal en de volgorde van bereiken in deze lijst moeten overeenkomen met de waarde die is opgegeven.--ip-families
  • Als er geen waarden worden opgegeven, wordt de standaardwaarde 10.244.0.0/16,fd12:3456:789a::/64 gebruikt.
• --service-cidrs: Maakt gebruik van een door komma's gescheiden lijst met IP-adresbereiken voor CIDR-notatie om service-IP-adressen toe te wijzen.
  • Het aantal en de volgorde van bereiken in deze lijst moeten overeenkomen met de waarde die is opgegeven.--ip-families
  • Als er geen waarden worden opgegeven, wordt de standaardwaarde 10.0.0.0/16,fd12:3456:789a:1::/108 gebruikt.
  • Het toegewezen IPv6-subnet --service-cidrs mag niet groter zijn dan een /108.

Een AKS-cluster met dubbele stack maken

1. Maak een Azure-resourcegroep voor het cluster met behulp van de opdracht [az group create][az-group-create].

   az group create --location <region> --name <resourceGroupName>
   

2. Maak een AKS-cluster met dubbele stack met behulp van de az aks create opdracht waarop de --ip-families parameter is ingesteld ipv4,ipv6.

   az aks create \
       --location <region> \
       --resource-group <resourceGroupName> \
       --name <clusterName> \
       --network-plugin azure \
       --network-plugin-mode overlay \
       --ip-families ipv4,ipv6 \
       --generate-ssh-keys
   

Een voorbeeldworkload maken

Zodra het cluster is gemaakt, kunt u uw workloads implementeren. In dit artikel wordt een voorbeeld van een workloadimplementatie van een NGINX-webserver beschreven.

Een NGINX-webserver implementeren

De invoegtoepassing voor toepassingsroutering is de aanbevolen manier voor inkomend verkeer in een AKS-cluster. Zie Voor meer informatie over de invoegtoepassing voor toepassingsroutering en een voorbeeld van het implementeren van een toepassing met de invoegtoepassing beheerde NGINX met de invoegtoepassing voor toepassingsroutering.

De workload beschikbaar maken via een LoadBalancer typeservice

Belangrijk

Er zijn momenteel twee beperkingen met betrekking tot IPv6-services in AKS.

• Azure Load Balancer verzendt statustests naar IPv6-bestemmingen vanaf een koppelingsadres. In Azure Linux-knooppuntgroepen kan dit verkeer niet worden gerouteerd naar een pod, zodat verkeer dat naar IPv6-services stroomt die zijn geïmplementeerd, externalTrafficPolicy: Cluster mislukt. IPv6-services moeten worden geïmplementeerd met externalTrafficPolicy: Local, waardoor kube-proxy de test op het knooppunt reageert.
• Vóór Kubernetes versie 1.27 wordt alleen het eerste IP-adres voor een service ingericht voor de load balancer, zodat een dual-stack-service alleen een openbaar IP-adres ontvangt voor de eerst vermelde IP-familie. Als u een service met twee stacks voor één implementatie wilt bieden, maakt u twee services die gericht zijn op dezelfde selector, één voor IPv4 en één voor IPv6. Dit is geen beperking meer in kubernetes 1.27 of hoger.

kubectl

1. Stel de NGINX-implementatie beschikbaar met behulp van de kubectl expose deployment nginx opdracht.

   kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
   kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'
   

   U ontvangt een uitvoer met de weergegeven services.

   service/nginx-ipv4 exposed
   service/nginx-ipv6 exposed
   

2. Zodra de implementatie beschikbaar is en de LoadBalancer services volledig zijn ingericht, haalt u de IP-adressen van de services op met behulp van de kubectl get services opdracht.

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

3. Controleer de functionaliteit via een opdrachtregelwebaanvraag van een host die geschikt is voor IPv6. Azure Cloud Shell is niet geschikt voor IPv6.

   SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   curl -s "http://[${SERVICE_IP}]" | head -n5
   

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   

YAML

1. Stel de NGINX-implementatie beschikbaar met behulp van het volgende YAML-manifest.

   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv4
   spec:
     externalTrafficPolicy: Cluster
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: nginx
     name: nginx-ipv6
   spec:
     externalTrafficPolicy: Cluster
     ipFamilies:
    - IPv6
     ports:
    - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       app: nginx
     type: LoadBalancer
   

2. Zodra de implementatie beschikbaar is en de LoadBalancer services volledig zijn ingericht, haalt u de IP-adressen van de services op met behulp van de kubectl get services opdracht.

   kubectl get services
   

   NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
   nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
   nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s
   

Dual-stack-netwerken met Azure CNI Powered by Cilium - (preview)

U kunt uw AKS-clusters met twee stacks implementeren met Azure CNI Powered by Cilium. Hiermee kunt u ook uw IPv6-verkeer beheren met de Cilium Network Policy-engine.

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning op basis van best effort. Daarom zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

• AKS-ondersteuningsbeleid
• Veelgestelde vragen over ondersteuning voor Azure

Vereisten

• U moet de nieuwste versie van de AKS Preview-extensie hebben.
• U moet Kubernetes versie 1.29 of hoger hebben.

De Azure CLI-extensie aks-preview installeren

• Installeer de aks-preview-extensie met behulp van de az extension add opdracht.

  az extension add --name aks-preview
  

• Werk bij naar de nieuwste versie van de extensie die is uitgebracht met behulp van de az extension update opdracht.

  az extension update --name aks-preview
  

De functievlag 'AzureOverlayDualStackPreview' registreren

1. Registreer de AzureOverlayDualStackPreview functievlag met behulp van de az feature register opdracht.

   az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

   Het duurt enkele minuten voordat de status Geregistreerd wordt weergegeven.

2. Controleer de registratiestatus met behulp van de az feature show opdracht:

   az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

3. Wanneer de status Geregistreerd weergeeft, vernieuwt u de registratie van de Microsoft.ContainerService-resourceprovider met behulp van de az provider register opdracht.

   az provider register --namespace Microsoft.ContainerService
   

Overlay-clusters instellen met Azure CNI Powered by Cilium

Maak een cluster met Azure CNI Overlay met behulp van de az aks create opdracht. Zorg ervoor dat u het argument --network-dataplane cilium gebruikt om het gegevensvlak Cilium op te geven.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Zie Azure CNI Powered by Cilium voor meer informatie over Azure CNI Powered by Cilium.

Dual-stack-netwerkknooppuntpools in Windows - (preview)

U kunt uw AKS-clusters met dubbele stack implementeren met Windows-knooppuntpools.

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning op basis van best effort. Daarom zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

• AKS-ondersteuningsbeleid
• Veelgestelde vragen over ondersteuning voor Azure

De Azure CLI-extensie aks-preview installeren

• Installeer de aks-preview-extensie met behulp van de az extension add opdracht.

  az extension add --name aks-preview
  

• Werk bij naar de nieuwste versie van de extensie die is uitgebracht met behulp van de az extension update opdracht.

  az extension update --name aks-preview
  

De functievlag 'AzureOverlayDualStackPreview' registreren

1. Registreer de AzureOverlayDualStackPreview functievlag met behulp van de az feature register opdracht.

   az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

   Het duurt enkele minuten voordat de status Geregistreerd wordt weergegeven.

2. Controleer de registratiestatus met behulp van de az feature show opdracht:

   az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
   

3. Wanneer de status Geregistreerd weergeeft, vernieuwt u de registratie van de Microsoft.ContainerService-resourceprovider met behulp van de az provider register opdracht.

   az provider register --namespace Microsoft.ContainerService
   

Een Overlay-cluster instellen

Maak een cluster met Azure CNI Overlay met behulp van de az aks create opdracht.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Een Windows-knooppuntpool toevoegen aan het cluster

Voeg een Windows-knooppuntpool toe aan het cluster met behulp van de opdracht [az aks nodepool add][az-aks-nodepool-add].

az aks nodepool add \
    --resource-group $resourceGroup \
    --cluster-name $clusterName \
    --os-type Windows \
    --name winpool1 \
    --node-count 2

Volgende stappen

Zie De CNI-invoegtoepassing (Bring Your Own Container Network Interface) voor meer informatie over het gebruik van AKS met uw eigen CNI-invoegtoepassing (Container Network Interface).