Konfigurera Azure CNI-överläggsnätverk i Azure Kubernetes Service (AKS)
Det traditionella Azure Container Networking Interface (CNI) tilldelar varje podd en VNet-IP-adress. Den tilldelar den här IP-adressen från en förreserverad uppsättning IP-adresser på varje nod eller ett separat undernät som är reserverat för poddar. Den här metoden kräver IP-adressplanering och kan leda till överbelastning, vilket medför problem med att skala dina kluster när programkraven ökar.
Med Azure CNI Overlay distribueras klusternoderna till ett undernät för Azure Virtual Network (VNet). Poddar tilldelas IP-adresser från en privat CIDR som logiskt skiljer sig från det virtuella nätverk som är värd för noderna. Podd- och nodtrafik i klustret använder ett Overlay-nätverk. NAT (Network Address Translation) använder nodens IP-adress för att nå resurser utanför klustret. Den här lösningen sparar en betydande mängd VNet-IP-adresser och gör att du kan skala klustret till stora storlekar. En extra fördel är att du kan återanvända den privata CIDR i olika AKS-kluster, vilket utökar det TILLGÄNGLIGA IP-utrymmet för containerbaserade program i Azure Kubernetes Service (AKS).
I Overlay-nätverk tilldelas endast Kubernetes-klusternoderna IP-adresser från undernät. Poddar tar emot IP-adresser från en privat CIDR som tillhandahålls när klustret skapas. Varje nod tilldelas ett /24
adressutrymme som är utskuret från samma CIDR. Extra noder som skapas när du skalar ut ett kluster tar automatiskt emot /24
adressutrymmen från samma CIDR. Azure CNI tilldelar IP-adresser till poddar från det här /24
utrymmet.
En separat routningsdomän skapas i Azure Networking-stacken för poddens privata CIDR-utrymme, vilket skapar ett Overlay-nätverk för direkt kommunikation mellan poddar. Du behöver inte etablera anpassade vägar i klustrets undernät eller använda en inkapslingsmetod för att tunneltrafik mellan poddar, vilket ger anslutningsprestanda mellan poddar i nivå med virtuella datorer i ett virtuellt nätverk. Arbetsbelastningar som körs i poddarna är inte ens medvetna om att nätverksadressmanipulering sker.
Kommunikation med slutpunkter utanför klustret, till exempel lokala och peerkopplade virtuella nätverk, sker med nod-IP via NAT. Azure CNI översätter käll-IP-adressen (overlay IP för podden) för trafiken till den virtuella datorns primära IP-adress, vilket gör att Azure Networking-stacken kan dirigera trafiken till målet. Slutpunkter utanför klustret kan inte ansluta direkt till en podd. Du måste publicera poddens program som en Kubernetes Load Balancer-tjänst för att den ska kunna nås på det virtuella nätverket.
Du kan tillhandahålla utgående (utgående) anslutning till Internet för Overlay-poddar med hjälp av en Standard SKU Load Balancer eller Managed NAT Gateway. Du kan också styra utgående trafik genom att dirigera den till en brandvägg med hjälp av användardefinierade vägar i klustrets undernät.
Du kan konfigurera ingressanslutning till klustret med hjälp av en ingresskontrollant, till exempel Nginx- eller HTTP-programroutning. Du kan inte konfigurera inkommande anslutning med Hjälp av Azure App Gateway. Mer information finns i Begränsningar med Azure CNI-överlägg.
Precis som Azure CNI Overlay tilldelar Kubenet IP-adresser till poddar från ett adressutrymme som skiljer sig logiskt från det virtuella nätverket, men det har skalning och andra begränsningar. Tabellen nedan innehåller en detaljerad jämförelse mellan Kubenet och Azure CNI Overlay. Om du inte vill tilldela virtuella nätverks-IP-adresser till poddar på grund av IP-brist rekommenderar vi att du använder Azure CNI Overlay.
Ytdiagram | Azure CNI-överlägg | Kubenet |
---|---|---|
Klusterskala | 5 000 noder och 250 poddar/noder | 400 noder och 250 poddar/nod |
Konfiguration av nätverk | Enkelt – inga extra konfigurationer krävs för poddnätverk | Komplext – kräver routningstabeller och UDR i klusterundernät för poddnätverk |
Prestanda för poddanslutning | Prestanda i nivå med virtuella datorer i ett virtuellt nätverk | Extra hopp lägger till svarstid |
Kubernetes-nätverksprinciper | Azure-nätverksprinciper, Calico, Cilium | Kalikå |
Operativsystemplattformar som stöds | Linux och Windows Server 2022, 2019 | Endast Linux |
- Klusternoder: När du konfigurerar AKS-klustret kontrollerar du att dina VNet-undernät har tillräckligt med utrymme för att växa för framtida skalning. Du kan tilldela varje nodpool till ett dedikerat undernät. Ett
/24
undernät får plats med upp till 251 noder eftersom de tre första IP-adresserna är reserverade för hanteringsuppgifter. - Poddar: Överläggslösningen tilldelar ett
/24
adressutrymme för poddar på varje nod från den privata CIDR som du anger när klustret skapas. Storleken/24
är fast och kan inte ökas eller minskas. Du kan köra upp till 250 poddar på en nod. När du planerar poddadressutrymmet kontrollerar du att den privata CIDR är tillräckligt stor för att tillhandahålla/24
adressutrymmen för nya noder för att stödja framtida klusterexpansion.- När du planerar IP-adressutrymme för poddar bör du tänka på följande faktorer:
- Samma podd-CIDR-utrymme kan användas på flera oberoende AKS-kluster i samma virtuella nätverk.
- Podd-CIDR-utrymme får inte överlappa klustrets undernätsintervall.
- Podd-CIDR-utrymme får inte överlappa direktanslutna nätverk (till exempel VNet-peering, ExpressRoute eller VPN). Om extern trafik har käll-IP-adresser i podCIDR-intervallet behöver den översättning till en icke-överlappande IP-adress via SNAT för att kommunicera med klustret.
- När du planerar IP-adressutrymme för poddar bör du tänka på följande faktorer:
- Adressintervall för Kubernetes-tjänsten: Storleken på tjänstadressens CIDR beror på antalet klustertjänster som du planerar att skapa. Den måste vara mindre än
/12
. Det här intervallet får inte överlappa poddens CIDR-intervall, klusterundernätsintervall och IP-intervall som används i peerkopplade virtuella nätverk och lokala nätverk. - Ip-adress för Kubernetes DNS-tjänsten: Den här IP-adressen ligger inom kubernetes-tjänstens adressintervall som används av identifiering av klustertjänster. Använd inte den första IP-adressen i adressintervallet eftersom den här adressen används för
kubernetes.default.svc.cluster.local
adressen.
Podd-till-poddtrafik med Azure CNI-överlägg är inte inkapslat och regler för nätverkssäkerhetsgrupper för undernät tillämpas. Om undernätets NSG innehåller nekanderegler som skulle påverka poddens CIDR-trafik kontrollerar du att följande regler finns på plats för att säkerställa rätt klusterfunktioner (förutom alla KRAV på AKS-utgående trafik):
- Trafik från nodens CIDR till nodens CIDR på alla portar och protokoll
- Trafik från nodens CIDR till podd-CIDR på alla portar och protokoll (krävs för tjänsttrafikroutning)
- Trafik från podd-CIDR till podd-CIDR på alla portar och protokoll (krävs för podd-till-podd- och poddtrafik till tjänst, inklusive DNS)
Trafik från en podd till ett mål utanför podd-CIDR-blocket använder SNAT för att ange käll-IP till IP-adressen för noden där podden körs.
Om du vill begränsa trafiken mellan arbetsbelastningar i klustret rekommenderar vi att du använder nätverksprinciper.
Du kan konfigurera det maximala antalet poddar per nod när klustret skapas eller när du lägger till en ny nodpool. Standardvärdet för Azure CNI Overlay är 250. Det maximala värdet som du kan ange i Azure CNI Overlay är 250 och det minsta värdet är 10. Det maximala poddvärdet per nod som konfigurerades när en nodpool skapades gäller endast noderna i den nodpoolen.
Azure CNI erbjuder två IP-adresseringsalternativ för poddar: Den traditionella konfigurationen som tilldelar virtuella nätverks-IP-adresser till poddar och Overlay-nätverk. Valet av vilket alternativ som ska användas för ditt AKS-kluster är en balans mellan flexibilitet och avancerade konfigurationsbehov. Följande överväganden hjälper dig att beskriva när varje nätverksmodell kan vara lämpligast.
Använd Overlay-nätverk när:
- Du vill skala till ett stort antal poddar, men har begränsat IP-adressutrymme i ditt virtuella nätverk.
- Merparten av poddkommunikationen finns i klustret.
- Du behöver inte avancerade AKS-funktioner, till exempel virtuella noder.
Använd det traditionella VNet-alternativet när:
- Du har tillgängligt IP-adressutrymme.
- Merparten av poddkommunikationen är till resurser utanför klustret.
- Resurser utanför klustret måste nå poddar direkt.
- Du behöver avancerade AKS-funktioner, till exempel virtuella noder.
Azure CNI Overlay har följande begränsningar:
- Du kan inte använda Application Gateway som ingresskontrollant (AGIC) för ett Överläggskluster.
- Du kan inte använda Application Gateway för containrar för ett Overlay-kluster.
- Virtuella datortillgänglighetsuppsättningar (VMAS) stöds inte för överlägg.
- Du kan inte använda virtuella datorer i DCsv2-serien i nodpooler. Om du vill uppfylla kraven för konfidentiell databehandling bör du överväga att använda konfidentiella virtuella datorer i DCasv5- eller DCadsv5-serien i stället.
- Om du använder ditt eget undernät för att distribuera klustret måste namnen på undernätet, VNET och resursgruppen som innehåller det virtuella nätverket vara högst 63 tecken. Detta kommer från det faktum att dessa namn kommer att användas som etiketter i AKS-arbetsnoder och därför omfattas av Kubernetes-etikettsyntaxregler.
Anteckning
Du måste ha CLI version 2.48.0 eller senare för att kunna använda --network-plugin-mode
argumentet. För Windows måste du ha det senaste Azure CLI-tillägget aks-preview installerat och kan följa anvisningarna nedan.
Skapa ett kluster med Azure CNI Overlay med kommandot az aks create
. Använd argumentet --network-plugin-mode
för att ange ett överläggskluster. Om podd-CIDR inte har angetts tilldelar AKS ett standardutrymme: 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
När du har skapat ett kluster med Azure CNI Overlay kan du skapa en annan nodpool och tilldela noderna till ett nytt undernät för samma virtuella nätverk. Den här metoden kan vara användbar om du vill styra värdens inkommande eller utgående IP-adresser från/mot mål i samma virtuella nätverk eller peer-kopplade virtuella nätverk.
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
Anteckning
Du kan uppdatera ett befintligt Azure CNI-kluster till Overlay om klustret uppfyller följande villkor:
- Klustret finns på Kubernetes version 1.22+.
- Använder inte funktionen för dynamisk podd-IP-allokering.
- Nätverksprinciper är inte aktiverade. Nätverksprincipmotorn kan avinstalleras före uppgraderingen. Mer information finns i Avinstallera Azure Network Policy Manager eller Calico
- Använder inte några Windows-nodpooler med Docker som containerkörning.
Anteckning
Att uppgradera ett befintligt kluster till CNI Overlay är en icke-reversibel process.
Varning
Före Windows OS Build 20348.1668 fanns det en begränsning kring Windows Overlay-poddar som felaktigt SNATing-paket från värdnätverkspoddar, vilket hade en mer skadlig effekt för kluster som uppgraderade till Overlay. Undvik det här problemet genom att använda Windows OS Build som är större än eller lika med 20348.1668.
Varning
Om du använder en anpassad azure-ip-masq-agent-konfiguration för att inkludera ytterligare IP-intervall som inte ska SNAT-paket från poddar kan uppgradering till Azure CNI Overlay bryta anslutningen till dessa intervall. Podd-IP-adresser från överläggsutrymmet kan inte nås av något utanför klusternoderna.
För tillräckligt gamla kluster kan det dessutom finnas en ConfigMap kvar från en tidigare version av azure-ip-masq-agent. Om den här ConfigMap med namnet azure-ip-masq-agent-config
finns och inte avsiktligt är på plats bör den tas bort innan du kör uppdateringskommandot.
Om du inte använder en anpassad ip-masq-agent-konfiguration bör endast azure-ip-masq-agent-config-reconciled
ConfigMap finnas med avseende på Azure ip-masq-agent ConfigMaps och detta uppdateras automatiskt under uppgraderingsprocessen.
Uppgraderingsprocessen utlöser att varje nodpool avbildas på nytt samtidigt. Det går inte att uppgradera varje nodpool separat till Overlay. Eventuella avbrott i klusternätverk liknar en uppgradering av nodavbildningen eller uppgradering av Kubernetes-versionen där varje nod i en nodpool avbildas på nytt.
Uppdatera ett befintligt Azure CNI-kluster för att använda Overlay med kommandot az aks update
.
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
Parametern --pod-cidr
krävs vid uppgradering från äldre CNI eftersom poddarna måste hämta IP-adresser från ett nytt överläggsutrymme, vilket inte överlappar det befintliga nodundernätet. Podd-CIDR kan inte heller överlappa med någon VNet-adress för nodpoolerna. Om din VNet-adress till exempel är 10.0.0.0/8 och noderna finns i undernätet 10.240.0.0/16, --pod-cidr
kan det inte överlappa med 10.0.0.0/8 eller den befintliga tjänsten CIDR i klustret.
Uppdatera ett befintligt Kubenet-kluster för att använda Azure CNI Overlay med hjälp av az aks update
kommandot .
clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay
Eftersom klustret redan använder en privat CIDR för poddar som inte överlappar det virtuella nätverkets IP-utrymme behöver du inte ange parametern --pod-cidr
och Pod CIDR förblir densamma om parametern inte används.
Anteckning
När du uppgraderar från Kubenet till CNI Overlay krävs inte längre routningstabellen för poddroutning. Om klustret använder en kund tillhandahållen routningstabell tas de vägar som användes för att dirigera poddtrafik till rätt nod automatiskt bort under migreringsåtgärden. Om klustret använder en hanterad routningstabell (routningstabellen skapades av AKS och finns i nodresursgruppen) tas routningstabellen bort som en del av migreringen.
Du kan distribuera dina AKS-kluster i ett läge med dubbla staplar när du använder Overlay-nätverk och ett virtuellt Azure-nätverk med dubbla staplar. I den här konfigurationen får noderna både en IPv4- och IPv6-adress från det virtuella Azure-nätverkets undernät. Poddar får både en IPv4- och IPv6-adress från ett logiskt annat adressutrymme än det virtuella Azure-nätverksundernätet för noderna. NAT (Network Address Translation) konfigureras sedan så att poddarna kan komma åt resurser i Azure Virtual Network. Källans IP-adress för trafiken är NAT'd till nodens primära IP-adress för samma familj (IPv4 till IPv4 och IPv6 till IPv6).
- Du måste ha Azure CLI 2.48.0 eller senare installerat.
- Kubernetes version 1.26.3 eller senare.
Följande funktioner stöds inte med nätverk med dubbla staplar:
- Azure-nätverksprinciper
- Calico-nätverksprinciper
- NAT Gateway
- Tillägg för virtuella noder
Följande attribut tillhandahålls för att stödja kluster med dubbla staplar:
--ip-families
: Tar en kommaavgränsad lista över IP-familjer som ska aktiveras i klustret.- Endast
ipv4
elleripv4,ipv6
stöds.
- Endast
--pod-cidrs
: Tar en kommaavgränsad lista över IP-intervall för CIDR-notering att tilldela podd-IP-adresser från.- Antalet och ordningen på intervallen i den här listan måste matcha värdet som anges till
--ip-families
. - Om inga värden anges används standardvärdet
10.244.0.0/16,fd12:3456:789a::/64
.
- Antalet och ordningen på intervallen i den här listan måste matcha värdet som anges till
--service-cidrs
: Tar en kommaavgränsad lista över IP-intervall för CIDR-notering att tilldela tjänst-IP-adresser från.- Antalet och ordningen på intervallen i den här listan måste matcha värdet som anges till
--ip-families
. - Om inga värden anges används standardvärdet
10.0.0.0/16,fd12:3456:789a:1::/108
. - Det IPv6-undernät som tilldelats får
--service-cidrs
inte vara större än /108.
- Antalet och ordningen på intervallen i den här listan måste matcha värdet som anges till
Skapa en Azure-resursgrupp för klustret med kommandot [
az group create
][az-group-create].az group create --location <region> --name <resourceGroupName>
Skapa ett AKS-kluster med dubbla staplar med
az aks create
kommandot med parametern inställd på--ip-families
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
När klustret har skapats kan du distribuera dina arbetsbelastningar. Den här artikeln beskriver ett exempel på en arbetsbelastningsdistribution av en NGINX-webbserver.
Tillägget för programroutning är det rekommenderade sättet för ingress i ett AKS-kluster. Mer information om tillägget för programroutning och ett exempel på hur du distribuerar ett program med tillägget finns i Hanterad NGINX-ingress med tillägget för programroutning.
Viktigt
Det finns för närvarande två begränsningar som gäller IPv6-tjänster i AKS.
- Azure Load Balancer skickar hälsoavsökningar till IPv6-mål från en länklokal adress. I Azure Linux-nodpooler kan den här trafiken inte dirigeras till en podd, så trafik som flödar till IPv6-tjänster som distribueras utan
externalTrafficPolicy: Cluster
fel. IPv6-tjänster måste distribueras medexternalTrafficPolicy: Local
, vilket görkube-proxy
att den svarar på avsökningen på noden. - Före Kubernetes version 1.27 kommer endast den första IP-adressen för en tjänst att etableras till lastbalanseraren, så en tjänst med dubbla staplar tar bara emot en offentlig IP-adress för sin första ip-familj. Om du vill tillhandahålla en tjänst med dubbla staplar för en enda distribution skapar du två tjänster som riktar sig till samma väljare, en för IPv4 och en för IPv6. Detta är inte längre en begränsning i kubernetes 1.27 eller senare.
Exponera NGINX-distributionen med kommandot
kubectl expose deployment nginx
.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"]}}'
Du får utdata som visar att tjänsterna har exponerats.
service/nginx-ipv4 exposed service/nginx-ipv6 exposed
När distributionen har exponerats och
LoadBalancer
tjänsterna har etablerats fullständigt hämtar du IP-adresserna för tjänsterna med kommandotkubectl get services
.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
Verifiera funktioner via en kommandoradswebbbegäran från en IPv6-kompatibel värd. Azure Cloud Shell är inte IPv6-kompatibelt.
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>
Du kan distribuera dina AKS-kluster med dubbla staplar med Azure CNI Som drivs av Cilium. På så sätt kan du också styra din IPv6-trafik med Cilium Network Policy-motorn.
Viktigt
AKS-förhandsversionsfunktioner är tillgängliga via självbetjäning och anmäl dig. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. AKS-förhandsversioner omfattas delvis av kundsupport på bästa sätt. Därför är dessa funktioner inte avsedda för produktionsanvändning. Mer information finns i följande supportartiklar:
- Du måste ha den senaste versionen av AKS-förhandsgranskningstillägget.
- Du måste ha Kubernetes version 1.29 eller senare.
Installera aks-preview-tillägget med kommandot
az extension add
.az extension add --name aks-preview
Uppdatera till den senaste versionen av tillägget som släpptes med kommandot
az extension update
.az extension update --name aks-preview
Registrera funktionsflaggan
AzureOverlayDualStackPreview
az feature register
med kommandot .az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
Det tar några minuter för statusen att visa Registrerad.
Kontrollera registreringsstatusen med hjälp av
az feature show
kommandot:az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
När statusen visar Registrerad uppdaterar du registreringen av resursprovidern Microsoft.ContainerService med hjälp av
az provider register
kommandot .az provider register --namespace Microsoft.ContainerService
Skapa ett kluster med Azure CNI Overlay med kommandot az aks create
. Använd argumentet --network-dataplane cilium
för att ange Cilium-dataplanen.
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\
Mer information om Azure CNI som drivs av Cilium finns i Azure CNI Powered by Cilium (Azure CNI Powered by Cilium).
Du kan distribuera dina AKS-kluster med dubbla staplar med Windows-nodpooler.
Viktigt
AKS-förhandsversionsfunktioner är tillgängliga via självbetjäning och anmäl dig. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. AKS-förhandsversioner omfattas delvis av kundsupport på bästa sätt. Därför är dessa funktioner inte avsedda för produktionsanvändning. Mer information finns i följande supportartiklar:
Installera aks-preview-tillägget med kommandot
az extension add
.az extension add --name aks-preview
Uppdatera till den senaste versionen av tillägget som släpptes med kommandot
az extension update
.az extension update --name aks-preview
Registrera funktionsflaggan
AzureOverlayDualStackPreview
az feature register
med kommandot .az feature register --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
Det tar några minuter för statusen att visa Registrerad.
Kontrollera registreringsstatusen med hjälp av
az feature show
kommandot:az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayDualStackPreview"
När statusen visar Registrerad uppdaterar du registreringen av resursprovidern Microsoft.ContainerService med hjälp av
az provider register
kommandot .az provider register --namespace Microsoft.ContainerService
Skapa ett kluster med Azure CNI Overlay med kommandot az aks create
.
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\
Lägg till en Windows-nodpool i klustret med kommandot [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
Mer information om hur du använder AKS med ditt eget CNI-plugin-program (Container Network Interface) finns i Ta med ditt eget CNI-plugin-program (Container Network Interface).
Feedback om Azure Kubernetes Service
Azure Kubernetes Service är ett öppen källkod projekt. Välj en länk för att ge feedback: