Använda kubenet-nätverk med dina egna IP-adressintervall i Azure Kubernetes Service (AKS)

AKS-kluster använder kubenet och skapar ett virtuellt Azure-nätverk och undernät åt dig som standard. Med kubenet får noder en IP-adress från det virtuella Azure-nätverkets undernät. Poddar får en IP-adress från ett annat logiskt adressutrymme än det virtuella Azure Virtual Network undernät för noderna. Nätverksadressöversättning (NAT) konfigureras sedan så att poddarna kan nå resurser i det virtuella Azure-nätverket. Källans IP-adress för trafiken är NAT'd till nodens primära IP-adress. Den här metoden minskar avsevärt antalet IP-adresser som du behöver reservera i ditt nätverksutrymme för poddar att använda.

Med Azure Container Networking Interface (CNI) får varje podd en IP-adress från undernätet och kan nås direkt. Dessa IP-adresser måste planeras i förväg och vara unika i hela nätverket. Varje nod har en konfigurationsparameter för det maximala antalet poddar som den stöder. Motsvarande antal IP-adresser per nod reserveras sedan i förväg för den noden. Den här metoden kräver mer planering och leder ofta till överbelastning av IP-adresser eller behovet av att återskapa kluster i ett större undernät när programkraven växer. Du kan konfigurera maximalt antal poddar som kan distribueras till en nod när klustret skapas eller när du skapar nya nodpooler. Om du inte anger maxPods när du skapar nya nodpooler får du ett standardvärde på 110 för kubenet.

Den här artikeln visar hur du använder kubenet-nätverk för att skapa och använda ett virtuellt nätverksundernät för ett AKS-kluster. Mer information om nätverksalternativ och överväganden finns i Nätverksbegrepp för Kubernetes och AKS.

Förutsättningar

• Det virtuella nätverket för AKS-klustret måste tillåta utgående Internetanslutning.
• Skapa inte fler än ett AKS-kluster i samma undernät.
• 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 Kubernetes-tjänstens adressintervall, poddadressintervall eller klusteradressintervall för virtuella nätverk. Det går inte att uppdatera intervallet när du har skapat klustret.
• Klusteridentiteten som används av AKS-klustret måste minst ha rollen Nätverksdeltagare i undernätet i det virtuella nätverket. CLI hjälper till att ställa in rolltilldelningen automatiskt. Om du använder en ARM-mall eller andra klienter måste du ange rolltilldelningen manuellt. Du måste också ha rätt behörigheter, till exempel prenumerationsägaren, för att skapa en klusteridentitet och tilldela den behörigheter. Om du vill definiera en anpassad roll i stället för att använda den inbyggda rollen Nätverksdeltagare behöver du följande behörigheter:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Innan du börjar

Du behöver Azure CLI version 2.0.65 eller senare installerad och konfigurerad. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.

Översikt över kubenet-nätverk med ditt eget undernät

I många miljöer har du definierat virtuella nätverk och undernät med allokerade IP-adressintervall, och du använder dessa resurser för att stödja flera tjänster och program. För att tillhandahålla nätverksanslutning kan AKS-kluster använda kubenet (grundläggande nätverk) eller Azure CNI (avancerat nätverk).

Med kubenet får endast noderna en IP-adress i det virtuella nätverksundernätet. Poddar kan inte kommunicera direkt med varandra. I stället hanterar användardefinierad routning (UDR) och IP-vidarebefordran anslutningen mellan poddar mellan noder. KONFIGURATION av UDR och IP-vidarebefordran skapas och underhålls som standard av AKS-tjänsten, men du kan ta med din egen routningstabell för anpassad väghantering om du vill. Du kan också distribuera poddar bakom en tjänst som tar emot en tilldelad IP-adress och belastningsutjämning av trafik för programmet. Följande diagram visar hur AKS-noderna tar emot en IP-adress i det virtuella nätverksundernätet, men inte poddarna:

Azure Support högst 400 vägar i en UDR, så du kan inte ha ett AKS-kluster som är större än 400 noder. Virtuella AKS-noder och Azure-nätverksprinciper stöds inte med kubenet. Calico-nätverksprinciper stöds.

Med Azure CNI får varje podd en IP-adress i IP-undernätet och kan kommunicera direkt med andra poddar och tjänster. Dina kluster kan vara så stora som det IP-adressintervall som du anger. Du måste dock planera IP-adressintervallet i förväg och alla IP-adresser förbrukas av AKS-noderna baserat på det maximala antalet poddar som de kan stödja. Avancerade nätverksfunktioner och scenarier som virtuella noder eller nätverksprinciper (antingen Azure eller Calico) stöds med Azure CNI.

Begränsningar och överväganden för kubenet

• Ytterligare ett hopp krävs i utformningen av kubenet, vilket ger mindre svarstid i poddkommunikationen.
• Routningstabeller och användardefinierade vägar krävs för att använda kubenet, vilket ökar komplexiteten i åtgärderna.
  • Mer information finns i Anpassa klusterutgående med en användardefinierad routningstabell i AKS och Anpassa klusterutgående med utgående typer i AKS.
• Direkt podd-adressering stöds inte för kubenet på grund av kubenet-design.
• Till skillnad från Azure CNI-kluster kan flera kubenet-kluster inte dela ett undernät.
• AKS tillämpar inte nätverkssäkerhetsgrupper (NSG:er) på undernätet och ändrar inte 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 mellan noden och podd-CIDR. Mer information finns i Nätverkssäkerhetsgrupper.
• Funktioner som inte stöds på kubenet är:
  • Azure-nätverksprinciper
  • Windows-nodpooler
  • Tillägg för virtuella noder

TILLGÄNGLIGHET och överbelastning av IP-adresser

Ett vanligt problem med Azure CNI är att det tilldelade IP-adressintervallet är för litet för att sedan lägga till fler noder när du skalar eller uppgraderar ett kluster. Nätverksteamet kanske inte heller kan utfärda ett tillräckligt stort IP-adressintervall för att stödja dina förväntade programkrav.

Som en kompromiss kan du skapa ett AKS-kluster som använder kubenet och ansluta till ett befintligt virtuellt nätverksundernät. Med den här metoden kan noderna ta emot definierade IP-adresser utan att behöva reservera ett stort antal IP-adresser i förväg för eventuella poddar som kan köras i klustret. Med kubenet kan du använda ett mycket mindre IP-adressintervall och stödja stora kluster och programkrav. Med ip-adressintervallet /27 i undernätet kan du till exempel köra ett nodkluster med 20–25 noder med tillräckligt med utrymme för att skala eller uppgradera. Den här klusterstorleken har stöd för upp till 2 200–2 750 poddar (med ett standardvärde på högst 110 poddar per nod). Det maximala antalet poddar per nod som du kan konfigurera med kubenet i AKS är 250.

I följande grundläggande beräkningar jämförs skillnaden i nätverksmodeller:

• kubenet: Ett enkelt /24 IP-adressintervall kan stödja upp till 251 noder i klustret. Varje virtuellt Azure-nätverksundernät reserverar de tre första IP-adresserna för hanteringsåtgärder. Det här antalet noder kan ha stöd för upp till 27 610 poddar, med ett standardantal på högst 110 poddar per nod.
• Azure CNI: Samma grundläggande /24-undernätsintervall kan bara stödja högst åtta noder i klustret. Det här antalet noder kan bara stödja upp till 240 poddar, med ett standardantal på högst 30 poddar per nod.

Peering för virtuella nätverk och ExpressRoute-anslutningar

För att tillhandahålla lokal anslutning kan både kubenet - och Azure-CNI-nätverksmetoder använda Peering för virtuella Azure-nätverk eller ExpressRoute-anslutningar. Planera dina IP-adressintervall noggrant för att förhindra överlappning och felaktig trafikroutning. Till exempel använder många lokala nätverk ett adressintervall på 10.0.0.0/8 som annonseras via ExpressRoute-anslutningen. Vi rekommenderar att du skapar dina AKS-kluster i virtuella Azure-nätverksundernät utanför det här adressintervallet, till exempel 172.16.0.0/16.

Välj en nätverksmodell som ska användas

Följande överväganden hjälper dig att beskriva när varje nätverksmodell kan vara lämpligast:

Använd kubenet när:

• Du har begränsat IP-adressutrymme.
• Merparten av poddkommunikationen finns i klustret.
• Du behöver inte avancerade AKS-funktioner, till exempel virtuella noder eller Azure Network Policy.

Använd Azure CNI när:

• Du har tillgängligt IP-adressutrymme.
• Merparten av poddkommunikationen är till resurser utanför klustret.
• Du vill inte hantera användardefinierade vägar för poddanslutning.
• Du behöver avancerade AKS-funktioner, till exempel virtuella noder eller Azure Network Policy.

Mer information som hjälper dig att avgöra vilken nätverksmodell som ska användas finns i Jämför nätverksmodeller och deras supportomfång.

Skapa ett virtuellt nätverk och ett undernät

1. Skapa en resursgrupp med kommandot az group create .

   az group create --name myResourceGroup --location eastus
   

2. Om du inte har ett befintligt virtuellt nätverk och undernät att använda skapar du dessa nätverksresurser med kommandot az network vnet create . Följande exempelkommando skapar ett virtuellt nätverk med namnet myAKSVnet med adressprefixet 192.168.0.0/16 och ett undernät med namnet myAKSSubnet med adressprefixet 192.168.1.0/24:

   az network vnet create \
       --resource-group myResourceGroup \
       --name myAKSVnet \
       --address-prefixes 192.168.0.0/16 \
       --subnet-name myAKSSubnet \
       --subnet-prefix 192.168.1.0/24 \
       --location eastus
   

3. Hämta resurs-ID:t för undernätet med kommandot az network vnet subnet show och lagra det som en variabel med namnet SUBNET_ID för senare användning.

   SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
   

Skapa ett AKS-kluster i det virtuella nätverket

Skapa ett AKS-kluster med systemtilldelade hanterade identiteter

• Skapa ett AKS-kluster med systemtilldelade hanterade identiteter med kommandot az aks create .

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID \
      --generate-ssh-keys 
  

  Distributionsparametrar:

  • --service-cidr är valfritt. Den här adressen används för att tilldela interna tjänster i AKS-klustret en IP-adress. Det här IP-adressintervallet ska vara ett adressutrymme som inte används någon annanstans i nätverksmiljön, inklusive eventuella lokala nätverksintervall om du ansluter eller planerar att ansluta, dina virtuella Azure-nätverk med Express Route eller en VPN-anslutning från plats till plats. Standardvärdet är 10.0.0.0/16.
  • --dns-service-ip är valfritt. Adressen ska vara .10-adressen för tjänstens IP-adressintervall. Standardvärdet är 10.0.0.10.
  • --pod-cidr är valfritt. Den här adressen ska vara ett stort adressutrymme som inte används någon annanstans i nätverksmiljön. Det här intervallet omfattar alla lokala nätverksintervall om du ansluter, eller planerar att ansluta, dina virtuella Azure-nätverk med Express Route eller en VPN-anslutning från plats till plats. Standardvärdet är 10.244.0.0/16.
    • Det här adressintervallet måste vara tillräckligt stort för att rymma det antal noder som du förväntar dig att skala upp till. Du kan inte ändra det här adressintervallet när klustret har distribuerats.
    • Ip-adressintervallet för podden används för att tilldela ett /24-adressutrymme till varje nod i klustret. I följande exempel tilldelar --pod-cidr på 10.244.0.0/16 den första noden 10.244.0.0/24, den andra noden 10.244.1.0/24 och den tredje noden 10.244.2.0/24.
    • När klustret skalas eller uppgraderas fortsätter Azure-plattformen att tilldela en podd-IP-adressintervall till varje ny nod.

Skapa ett AKS-kluster med användartilldelad hanterad identitet

Skapa en hanterad identitet

• Skapa en hanterad identitet med kommandot az identity . Om du har en befintlig hanterad identitet letar du upp huvud-ID:t med kommandot az identity show --ids <identity-resource-id> i stället.

  az identity create --name myIdentity --resource-group myResourceGroup
  

  Dina utdata bör likna följande exempelutdata:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Lägga till rolltilldelning för hanterad identitet

Om du använder Azure CLI läggs rollen automatiskt till och du kan hoppa över det här steget. Om du använder en ARM-mall eller andra klienter måste du använda huvud-ID:t för den klusterhanterade identiteten för att utföra en rolltilldelning.

• Hämta resurs-ID:t för az network vnet show det virtuella nätverket med kommandot och lagra det som en variabel med namnet VNET_ID.

  VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
  

• Tilldela den hanterade identiteten för aks-klustrets nätverksdeltagarebehörigheter i det virtuella nätverket med hjälp av az role assignment create kommandot och ange <principalId>.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Skapa ett AKS-kluster

• Skapa ett AKS-kluster med kommandot az aks create och ange kontrollplanets resurs-ID för hanterad identitet för argumentet för assign-identity att tilldela den användartilldelade hanterade identiteten.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --assign-identity <identity-resource-id> \
      --generate-ssh-keys
  

När du skapar ett AKS-kluster skapas automatiskt en nätverkssäkerhetsgrupp och routningstabell. Dessa nätverksresurser hanteras av AKS-kontrollplanet. Nätverkssäkerhetsgruppen associeras automatiskt med de virtuella nätverkskorten på dina noder. Routningstabellen associeras automatiskt med det virtuella nätverkets undernät. Regler för nätverkssäkerhetsgrupper och routningstabeller uppdateras automatiskt när du skapar och exponerar tjänster.

Använd ditt eget undernät och din egen routningstabell med Kubenet

Med kubenet måste det finnas en routningstabell i klustrets undernät. AKS har stöd för att ta med ett eget befintligt undernät och en routningstabell. Om ditt anpassade undernät inte innehåller en routningstabell skapar AKS en åt dig och lägger till regler under hela klusterlivscykeln. Om ditt anpassade undernät innehåller en routningstabell när du skapar klustret bekräftar AKS den befintliga routningstabellen under klusteråtgärder och lägger till/uppdaterar regler i enlighet med detta för molnleverantörsåtgärder.

Läs mer om hur du konfigurerar en anpassad routningstabell.

Kubenet-nätverk kräver organiserade routningstabellregler för att dirigera begäranden. På grund av den här designen måste routningstabeller underhållas noggrant för varje kluster som förlitar sig på det. Flera kluster kan inte dela en routningstabell eftersom podd-CIDR från olika kluster kan överlappa, vilket orsakar oväntade och brutna routningsscenarier. När du konfigurerar flera kluster i samma virtuella nätverk eller anger ett virtuellt nätverk för varje kluster bör du överväga följande begränsningar:

• En anpassad routningstabell måste vara associerad med undernätet innan du skapar AKS-klustret.
• Den associerade routningstabellresursen kan inte uppdateras när klustret har skapats. Anpassade regler kan dock ändras i routningstabellen.
• Varje AKS-kluster måste använda en enda unik routningstabell för alla undernät som är associerade med klustret. Du kan inte återanvända en routningstabell med flera kluster på grund av risken för överlappande podd-CIDR och motstridiga routningsregler.
• För systemtilldelad hanterad identitet stöds det bara för att tillhandahålla ett eget undernät och en egen routningstabell via Azure CLI eftersom Azure CLI automatiskt lägger till rolltilldelningen. Om du använder en ARM-mall eller andra klienter måste du använda en användartilldelad hanterad identitet, tilldela behörigheter innan klustret skapas och se till att den användartilldelade identiteten har skrivbehörighet till ditt anpassade undernät och din anpassade routningstabell.
• Det går inte att använda samma routningstabell med flera AKS-kluster.

Lägga till en routningstabell med en användartilldelad hanterad identitet i DITT AKS-kluster

När du har skapat en anpassad routningstabell och associerat den med ett undernät i det virtuella nätverket kan du skapa ett nytt AKS-kluster som anger routningstabellen med en användartilldelad hanterad identitet. Du måste använda undernäts-ID:t där du planerar att distribuera ditt AKS-kluster. Det här undernätet måste också associeras med din anpassade routningstabell.

1. Hämta undernäts-ID:t med kommandot az network vnet subnet list .

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. Skapa ett AKS-kluster med ett anpassat undernät som är förkonfigurerat med en routningstabell med kommandot az aks create och ange dina värden för parametrarna --vnet-subnet-id och --assign-identity .

   az aks create \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --vnet-subnet-id mySubnetIDResourceID \
       --assign-identity controlPlaneIdentityResourceID \
       --generate-ssh-keys
   

Nästa steg

Den här artikeln visar hur du distribuerar AKS-klustret till ditt befintliga virtuella nätverksundernät. Nu kan du börja skapa nya appar med Helm eller distribuera befintliga appar med Hjälp av Helm.