Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Kubernetes tillhandahåller inte något nätverksgränssnittssystem som standard. I stället tillhandahåller nätverksinsticksprogram den här funktionen. Azure Kubernetes Service (AKS) erbjuder flera stödda CNI-plugins (Container Network Interface). Information om plugin-program som stöds finns i Nätverksbegrepp för program i Azure Kubernetes Service.
Plugin-program som stöds uppfyller de flesta nätverksbehoven i Kubernetes. Avancerade AKS-användare kanske dock vill ha samma CNI-plugin-program som de använde i lokala Kubernetes-miljöer. Eller så kanske dessa användare vill använda avancerade funktioner som är tillgängliga i andra CNI-plugin-program.
Den här artikeln visar hur du distribuerar ett AKS-kluster utan förinstallerat CNI-plugin-program. Därifrån kan du installera alla CNI-plugin-program som fungerar i Azure.
Support
Microsoft-supporten kan inte hjälpa till med CNI-relaterade problem i kluster som du distribuerar genom att ta med ditt eget CNI-plugin-program. Till exempel skulle CNI-relaterade problem täcka det mesta av trafiken i öst/väst (podd till podd) tillsammans med kubectl proxy och liknande kommandon. Om du vill ha CNI-relaterad support använder du ett AKS-nätverkstillägg som stöds eller söker support från CNI-plugin-leverantören.
Microsoft tillhandahåller fortfarande stöd för problem som inte är relaterade till CNI.
Planeringsöverväganden för IP-adresser
När du använder ett BYO CNI-plugin-program (Bring Your Own CNI) med AKS delas ansvaret för IP-adressplaneringen mellan AKS och det kundhanterade CNI:t. Till skillnad från AKS-hanterade CNI-plugin-program allokerar eller hanterar AKS inte podd-IP-adresser när en BYO CNI används.
Anmärkning
ARTIKELN OM IP-adressplanering för dina AKS-kluster (Azure Kubernetes Service) fokuserar på AKS-hanterade nätverksinsticksprogram. I BYO CNI-scenarier gäller endast vägledning om storlek, uppgradering och skalning av nodundernät och Kubernetes-tjänstadressintervall. Podd-IP-adressallokering, routning och skalningsbeteende bestäms av det valda CNI-plugin-programmet.
Storleksändring för virtuellt nätverk och undernät
AKS kräver fortfarande ett virtuellt nätverk och undernät som värd för klusternoder. Storleksändring för undernät ska ta hänsyn till:
- Maximalt antal noder per nodpool
- Ytterligare noder som krävs för uppgraderings- och skalningsåtgärder, till exempel överspänningsuppgraderingar
- Azure-resurser som allokerar IP-adresser från undernät i det virtuella nätverket, till exempel interna lastbalanserare
AKS-uppgraderingar och skalningsåtgärder förblir nodbaserade. Under dessa åtgärder kan AKS tillfälligt etablera ytterligare noder, så undernätet måste vara tillräckligt stort för att rymma det maximala antalet noder.
Podd-IP-adresser allokeras inte från AKS-undernätet när du använder BYO CNI om de inte uttryckligen implementeras av CNI-plugin-programmet.
Kubernetes Service-adressintervall
Alla AKS-kluster, inklusive de som använder BYO CNI, kräver ett Kubernetes-tjänstadressintervall (serviceCIDR) och en IP-adress för DNS-tjänsten (dnsServiceIP). Följande begränsningar gäller:
- Tjänstadressintervallet får inte överlappa det virtuella nätverket eller något anslutet nätverk.
- Tjänstens CIDR måste vara mindre än /12.
- DNS-tjänstens IP-adress måste ligga inom tjänst-CIDR-intervallet och får inte vara den första IP-adressen i intervallet.
Dessa krav är oberoende av CNI-plugin-programmet.
Poddnätverk och IP-hantering
Med BYO CNI bestäms ip-adresshantering för poddar (IPAM), routning och skalningsbeteende av CNI-plugin-programmet.
AKS gör inte:
- Allokera podd-IP-adresser
- Förtilldela pod-CIDR-intervall per nod
- Genomför återanvändning eller frigörande av pod-IP-adresser
Vägledning som rör överlägg eller platta nätverksmodeller, storleksändring av poddar per nod eller storleksformler för undernät som innehåller poddar gäller inte för BYO CNI-scenarier.
Maximalt antal poddar per nod
AKS tillämpar ett konfigurerbart maximalt antal poddar per nod (maxPods) på kubeletnivå. När du använder BYO CNI begränsar den här inställningen poddschemaläggningsdensiteten men avgör inte IP-kapacitet. Du ansvarar för att se till att det valda CNI-plugin-programmet har stöd för den konfigurerade podddensiteten och klusterskalan.
Prerequisites
- För Azure Resource Manager eller Bicep använder du minst mallversion 2022-01-02-preview eller 2022-06-01.
- För Azure CLI använder du minst version 2.39.0.
- Det virtuella nätverket för AKS-klustret måste tillåta utgående Internetanslutning.
- AKS-kluster kan inte använda
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16eller192.0.2.0/24för adressintervallet för Kubernetes-tjänsten, poddar eller det virtuella klustrets virtuella nätverk. - Klusteridentiteten som AKS-klustret använder måste ha minst behörighet för nätverksdeltagare i undernätet i det virtuella nätverket. Om du vill definiera en anpassad roll i stället för att använda den inbyggda rollen Nätverksdeltagare krävs följande behörigheter:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/read
- Det undernät som tilldelats AKS-nodpoolen kan inte vara ett delegerat undernät.
- AKS tillämpar inte nätverkssäkerhetsgrupper (NSG) på sitt undernät eller ändrar någon av de NSG:er som är associerade med det undernätet. Om du anger ett eget undernät och lägger till NSG:er som är associerade med det undernätet måste du se till att säkerhetsreglerna i NSG:erna tillåter trafik inom nodens CIDR-intervall (Classless Inter-Domain Routning). Mer information finns i Nätverkssäkerhetsgrupper.
- AKS skapar ingen routningstabell i det hanterade virtuella nätverket.
- Du måste ange en Pod CIDR (IP-adressintervall för poddar). AKS-kontrollplanet använder det här intervallet för intern dirigering av trafik till poddar, även om podd-IP-tilldelningen hanteras av ditt anpassade CNI. Om ingen podd-CIDR tillhandahålls kan kommunikationen från kontrollplanet till podden misslyckas eller bli felroutad. Du måste välja en podd-CIDR som inte är i konflikt med något annat nätverk i din miljö och undviker reserverade Azure-intervall, till exempel,
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16eller192.0.2.0/24. Du kan till exempel använda ett intervall som10.XX.0.0/16är unikt för klustret. Detta säkerställer att kontrollplanet kan dirigeras direkt till podd-IP-adresser på dina noder, och ingen IP-överlappning sker om du integrerar med andra nätverk eller kluster.
Skapa ett AKS-kluster utan förinstallerat CNI-plugin-program
Skapa en Azure-resursgrupp för ditt AKS-kluster med hjälp
az group createav kommandot .az group create --location eastus --name myResourceGroupSkapa ett AKS-kluster med hjälp
az aks createav kommandot . Skicka parametern--network-pluginmed parametervärdetnone.az aks create \ --location eastus \ --resource-group myResourceGroup \ --name myAKSCluster \ --network-plugin none \ --pod-cidr "10.10.0.0/16" \ --generate-ssh-keys
Distribuera ett CNI-plugin-program
När AKS-försörjningen är klar är klustret tillgängligt. Men alla noder är i ett NotReady tillstånd, vilket visas i följande exempel:
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-23902496-vmss000000 NotReady agent 6m9s v1.21.9
$ kubectl get node -o custom-columns='NAME:.metadata.name,STATUS:.status.conditions[?(@.type=="Ready")].message'
NAME STATUS
aks-nodepool1-23902496-vmss000000 container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Nu är klustret redo för installation av ett CNI-plugin-program.