Dela via


CNI-plugin-programmet Bring Your Own (BYO) med Azure Kubernetes Service (AKS)

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/16eller 192.0.2.0/24 fö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/action
    • Microsoft.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/16eller 192.0.2.0/24. Du kan till exempel använda ett intervall som 10.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

  1. Skapa en Azure-resursgrupp för ditt AKS-kluster med hjälp az group create av kommandot .

    az group create --location eastus --name myResourceGroup
    
  2. Skapa ett AKS-kluster med hjälp az aks create av kommandot . Skicka parametern --network-plugin med parametervärdet none.

    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.