Migrera AKS Automatic-kluster och hanterade systemnodpooler

Gäller för: ✔️ AKS Automatic ✔️ AKS Standard

Den här artikeln visar hur du migrerar AUTOMATISKA AKS-kluster mellan den hanterade systemnodpoolen som stöds och AKS Standard-konfigurationer.

Migreringsvägar som stöds

Genom att använda hanterade systemnodpooler etablerar, skalar och uppgraderar AKS systemnodpoolerna och systemkomponenterna åt dig och isolerar dem från dina arbetsbelastningar. AUTOMATISKA AKS-kluster backas också upp av ett SLA för poddberedskap och ett drifttids-SLA. Mer information finns i Översikt över AUTOMATISKA AKS-kluster med hanterade systemnodpooler.

Migrera från ett AKS-automatiskt kluster med hanterade systemnodpooler till ett AKS Standard-kluster

Så här fungerar migreringen

Ett AKS-automatiskt kluster med hanterade systemnodpooler kör sina systemkomponenter på systemnodpooler som AKS etablerar, skalar och uppgraderingar åt dig.

Utför följande steg på hög nivå för att migrera från AKS Automatic till AKS Standard:

1. Lägg till en självhanterad systemnodpool i ditt AKS-automatiska kluster.
2. Uppdatera kluster-SKU:n från automatic till base.

När du har uppdaterat SKU:n körs klustret som ett AKS Standard-kluster och systemkomponenterna körs på systemnodpoolen som du har lagt till och hanterar.

Migrera till ett AKS Standard-kluster

1. Lägg till en självhanterad nodpool för systemnoder i ditt befintliga AKS Automatic-kluster med hjälp av kommandot az aks nodepool add. Ställ in nodpoolläget så att System det kan köra systemkomponenter efter migreringen.

   az aks nodepool add \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name systempool \
       --mode System \
       --node-count 3
   

2. Uppdatera kluster-SKU:n från automatic till base med hjälp az aks update av kommandot .

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --sku base
   

Verifiera migreringen

1. Bekräfta att klustret nu använder base-SKU:n genom att använda kommandot az aks show.

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "sku" \
       --output table
   

2. Lista nodpoolerna i klustret för att bekräfta att din självhanterade systemnodpool finns och är i läget System med kommandot az aks nodepool list.

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[].{Name:name, Mode:mode, Count:count}" \
       --output table
   

Migrera från ett AKS-automatiskt kluster utan hanterade systemnodpooler till AKS Automatic med hanterade systemnodpooler (förhandsversion)

AKS Automatic stöder förhandsversionsmigrering från icke-hanterade systemnodpooler till hanterade systemnodpooler i regioner där hanterade systemnodpooler är allmänt tillgängliga. Den här migreringen behåller klustret på SKU: automatic n och flyttar AKS-systemkomponenter till en systemnodpool som hanteras av AKS.

Förutsättningar

• Ett befintligt AKS-automatiskt kluster utan hanterade systemnodpooler.
• Azure CLI version 2.86.0 eller senare. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera, se Installera Azure CLI.
• Den senaste versionen av aks-preview Azure CLI-tillägget.
• Funktionsflaggan Microsoft.ContainerService/NonHoboToHoboConversionPreview som är registrerad i din prenumeration.

Registrera funktionsflaggan NonHoboToHoboConversionPreviewaz feature register med hjälp av kommandot :

az feature register \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview

Kontrollera registreringsstatusen az feature show med hjälp av kommandot :

az feature show \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview \
    --query properties.state \
    --output tsv

Vänta tills kommandot returneras Registered innan du fortsätter. Uppdatera sedan registreringen av resursprovidern Microsoft.ContainerService .

az provider register --namespace Microsoft.ContainerService

Installera eller uppdatera aks-preview tillägget:

az extension add --name aks-preview
az extension update --name aks-preview

Migrera ett AKS-hanterat virtuellt nätverkskluster

För ett AKS-automatiskt kluster som använder AKS-hanterat nätverk migrerar du till hanterade systemnodpooler med hjälp az aks update av kommandot med parametern --enable-hosted-system :

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system

Migrera ett anpassat virtuellt nätverkskluster

För ett AKS-automatiskt kluster som använder ett anpassat virtuellt nätverk anger du ett undernät för den hanterade systemnodpoolen med hjälp av parametern --system-node-subnet-id . Systemnodens undernät måste:

• Vara i samma virtuella nätverk och region som klustret.
• Var minst /26.
• Inte delegeras till en annan tjänst.
• Ska skilja sig från nätverksnodens undernät.

Parametern --node-subnet-id är valfri. Om du inte anger det använder AKS det befintliga undernätet för systemnodspoolen.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

Verifiera migreringen

Bekräfta att klustret använder hanterade systemnodpooler med hjälp az aks show av kommandot :

az aks show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --query hostedSystemProfile \
    --output json

Följande exempelutdata visar att egenskapen hostedSystemProfile.enabled är inställd på true:

{
  "enabled": true,
  "nodeSubnetId": "<node-subnet-resource-id>",
  "systemNodeSubnetId": "<system-node-subnet-resource-id>"
}

Migrera från ett AKS Standard-kluster till ett AKS Automatic-kluster med hanterade systemnodpooler (förhandsversion)

AKS stöder förhandsversionsmigrering från AKS Standard-kluster (base SKU) till AKS Automatic-kluster med hanterade systemnodpooler i regioner där hanterade systemnodpooler är allmänt tillgängliga.

Om du vill migrera konfigurerar du först AKS Standard-klustret så att det matchar AKS Automatic-konfigurationen och uppdaterar sedan klustrets SKU. Det mesta av arbetet är att förbereda klustret. Slutför följande avsnitt i ordning eftersom flera inställningar är beroende av att andra konfigureras först.

Innan du börjar

• Ett befintligt AKS Standard-kluster (base SKU). Allmänna krav och begränsningar för AKS Automatic finns i Snabbstart: Skapa ett Azure Kubernetes Service (AKS) Automatic-kluster och Översikt över AKS Automatic-kluster med hanterade systemnodpooler.
• Azure CLI version 2.86.0 eller senare och den senaste versionen av aks-preview tillägget.
• Funktionsflaggan Microsoft.ContainerService/NonHoboToHoboConversionPreview som är registrerad i din prenumeration. Om du vill registrera funktionsflaggan och installera tillägget följer du stegen i Förutsättningar.

Ange miljövariabler för klustret:

export RESOURCE_GROUP="<resource-group>"
export RESOURCE_NAME="<cluster-name>"
export NODE_RESOURCE_GROUP=$(az aks show --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --query nodeResourceGroup --output tsv)

Migreringskrav

Innan du kan uppdatera SKU:n måste klustret uppfylla följande krav. Vissa krav varierar beroende på om klustret använder ett AKS-hanterat virtuellt nätverk eller ett anpassat virtuellt nätverk. Du kan konfigurera de här inställningarna med hjälp av Azure-portalen, Azure CLI, en ARM-mall eller andra verktyg. Resten av den här artikeln visar de Azure CLI stegen i den ordning som du bör tillämpa dem.

Planera migreringen

1. Avgör om klustret använder ett AKS-hanterat virtuellt nätverk eller ett anpassat virtuellt nätverk. Om följande kommando returnerar ett virtuellt nätverksnamn använder klustret ett AKS-hanterat virtuellt nätverk. Om det inte returnerar något använder klustret ett anpassat virtuellt nätverk.

   az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[].name" --output tsv
   

   Flera steg i den här artikeln skiljer sig beroende på typen av virtuellt nätverk.

2. Kontrollera klustrets aktuella nätverksplugin, utgående typ, SKU för lastbalanserare och begränsningsnivå för nodresursgrupper:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{networkPlugin:networkProfile.networkPlugin, networkPluginMode:networkProfile.networkPluginMode, outboundType:networkProfile.outboundType, loadBalancerSku:networkProfile.loadBalancerSku, nrgRestrictionLevel:nodeResourceGroupProfile.restrictionLevel}" \
       --output table
   

   • Nätverks-plugin: Måste vara azure med pluginläge overlay. Om klustret använder kubenet eller Azure CNI utan Overlay uppdaterar du det till Azure CNI Overlay innan du fortsätter. Mer information finns i Uppdatera IPAM-läget till Azure CNI Overlay.
   • SKU för lastbalanserare: Måste vara standard. Om klustret fortfarande använder basic, uppdaterar du det med az aks update --load-balancer-sku standard.
   • Begränsningsnivå för nodresursgrupp: För ett AKS-hanterat virtuellt nätverk måste du skapa ett undernät i nodresursgruppen. Om begränsningsnivån är inställd på ReadOnly, ändra den till Unrestricted innan du fortsätter. Du låser den igen i ett senare steg.

3. Granska de ändringar som stör körningen av arbetsbelastningar eller åtkomst och planera en underhållsperiod:

   • Om du ändrar utgående typ ändras klustrets utgående IP-adresser. Uppdatera alla brandväggsregler som tillåter trafik från klustret.
   • Aktivering av API Server VNet-integrering ändrar API-serverns IP-adress och kräver en omstart av klustret. Den här ändringen är permanent.
   • När du ändrar inställningarna för nätverksdataplan, OS SKU och SSH-åtkomst avbildas dina noder om.
   • Inaktivering av lokala konton tar bort statiska kubeconfig-autentiseringsuppgifter. Se till att du har åtkomst via Microsoft Entra ID och en Azure RBAC-roll, till exempel Azure Kubernetes Service RBAC-klusteradministratör, innan du inaktiverar dem.
   • Migreringen möjliggör Deployment Safeguards i Enforce-läge med baseline Pod Security Standards. Driftsättningar som inte uppfyller kraven avvisas. Du kan exkludera namnområden, men du kan inte ändra den klusteromfattande nivån till Warn. Granska dina arbetsbelastningar innan du migrerar. Mer information finns i Använd distributionsspärrar.

Förbereda klusternätverk

1. Utgående typ: För ett AKS-hanterat virtuellt nätverk måste den utgående typen vara en hanterad NAT-gateway. Den loadBalancer utgående typen stöds inte. Om det behövs, uppdatera utgående typ:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --outbound-type managedNATGateway \
       --outbound-type-sku StandardV2
   

   För ett anpassat virtuellt nätverk stöds alla utgående typer och ingen ändring krävs. Mer information finns i Uppdatera outboundType när klustret har skapats.

2. Klusteridentitet: För ett AKS-hanterat virtuellt nätverk behåller du klustrets systemtilldelade hanterade identitet. För ett anpassat virtuellt nätverk måste klustret använda en användartilldelad hanterad identitet som har rollen Network Contributor på det virtuella nätverket. Tilldela identiteten om det behövs:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-managed-identity \
       --assign-identity "${IDENTITY_RESOURCE_ID}" \
       --yes
   

   Ersätt IDENTITY_RESOURCE_ID med resurs-ID för din användartilldelade hanterade identitet. Mer information finns i Användning av en användartilldelad hanterad identitet.

3. API-serverundernät: Skapa ett dedikerat undernät för API-servern i samma virtuella nätverk som dina noder. Undernätet måste vara separat från ditt nodundernät, vara minst /28 och delegeras till Microsoft.ContainerService/managedClusters.

   För ett AKS-hanterat virtuellt nätverk skapar du undernätet i det virtuella nätverket i nodresursgruppen:

   export VNET_NAME=$(az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[0].name" --output tsv)
   
   export APISERVER_SUBNET_ID=$(az network vnet subnet create \
       --resource-group "${NODE_RESOURCE_GROUP}" \
       --vnet-name "${VNET_NAME}" \
       --name apiserver-subnet \
       --address-prefixes "<unused-address-range>" \
       --delegations Microsoft.ContainerService/managedClusters \
       --query id --output tsv)
   

   För ett anpassat virtuellt nätverk skapar du undernätet i ditt eget virtuella nätverk i stället och anger APISERVER_SUBNET_ID till dess resurs-ID.

4. API Server VNet-integrering: Aktivera API Server VNet-integrering med det undernät som du skapade och starta sedan om klustret:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-apiserver-vnet-integration \
       --apiserver-subnet-id "${APISERVER_SUBNET_ID}"
   
   az aks stop --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   az aks start --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   

   Mer information finns i Konvertera ett befintligt AKS Standard-kluster till API Server VNet-integrering.

5. Nätverksdataplan: Uppdatera nätverksdataplanen till Cilium. Det här kommandot ställer även in nätverkspolicyn till Cilium.

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --network-dataplane cilium
   

   Mer information finns i Azure CNI Powered by Cilium.

Förbered systemnodpoolen och nodetablering

1. Tillfällig OS-disk: Systemnodpoolen måste använda en tillfällig OS-disk. Kontrollera den aktuella operativsystemdisktypen:

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[?mode=='System'].{name:name, osDiskType:osDiskType}" \
       --output table
   

   Du kan inte ändra operativsystemdisktypen för en befintlig nodpool. Om systemnodpoolen använder en Managed OS-disk, lägger du till en ny systemnodpool med --mode System --node-osdisk-type Ephemeral --os-sku AzureLinux --ssh-access disabled, flyttar systemarbetsbelastningarna till den och tar sedan bort den gamla nodpoolen. Du kan sedan hoppa över nästa steg.

2. OS SKU- och SSH-åtkomst: Uppdatera systemnodpoolen så att den använder Azure Linux och inaktivera SSH-åtkomst:

   az aks nodepool update \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name "<system-node-pool-name>" \
       --os-sku AzureLinux \
       --ssh-access disabled \
       --yes
   

   Det här kommandot installerar om avbilden för nodpoolen. Vänta tills den har slutförts innan du gör andra ändringar i nodpoolen. Mer information finns i Använda Azure Linux Container Host och Hantera SSH-åtkomst på AKS-klusternoder.

3. Nodetableringsläge: Aktivera etableringsläge för automatisk nod:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --node-provisioning-mode Auto
   

   När du har aktiverat automatiskt läge kan du inte återgå till manuellt läge utan att först ta bort alla autoetablerade noder. Läs mer i automatisk nodetablering.

Aktivera nödvändiga funktioner och tillägg

1. Uppdatera klusternivån till Standard och aktivera tilläggen Azure Policy och Azure Key Vault Secrets Provider med hemlighetsrotation:

   az aks update --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --tier standard
   
   az aks enable-addons \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --addons azure-policy,azure-keyvault-secrets-provider \
       --enable-secret-rotation
   

2. Aktivera de återstående nödvändiga funktionerna:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --auto-upgrade-channel stable \
       --node-os-upgrade-channel NodeImage \
       --enable-workload-identity \
       --enable-oidc-issuer \
       --enable-aad \
       --enable-azure-rbac \
       --disable-local-accounts \
       --enable-image-cleaner \
       --enable-vpa \
       --enable-keda \
       --yes
   

Lås nodresursgruppen

Ange begränsningsnivån för nodens resursgrupp till ReadOnly. Gör det här steget sist eftersom låsning blockerar ändringar av resurser i nodresursgruppen, inklusive API-serverundernätet som du skapade tidigare.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --nrg-lockdown-restriction-level ReadOnly

Mer information finns i Låsning av nodresursgrupp.

Migrera klustret till AKS Automatic

Om något krav fortfarande är ouppfyllt misslyckas migreringskommandot och visar en lista över de ouppfyllda krav som identifierats. Vissa kontroller körs först efter att tidigare kontroller har passerat, så lös de angivna objekten och kör kommandot igen tills det lyckas.

AKS-hanterade virtuellt nätverk

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system

Anpassat virtuellt nätverk

Ange ett undernät för den hanterade systemnodpoolen med hjälp av parametern --system-node-subnet-id . Information om undernätskrav finns i Migrera ett befintligt AKS Automatic-kluster till hanterade systemnodpooler. Parametern --node-subnet-id är valfri. Om du inte anger det använder AKS det befintliga undernätet för systemnodspoolen.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

Verifiera migreringen

1. Bekräfta att klustret använder automatic SKU:n och Standard nivån och att uppdateringen har slutförts:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{sku:sku, provisioningState:provisioningState}" \
       --output json
   

   Bekräfta att sku.name är Automatic, att sku.tier är Standard, och att provisioningState är Succeeded.

2. Bekräfta att klustret använder hanterade systemnodpooler:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query hostedSystemProfile \
       --output json
   

   Bekräfta hostedSystemProfile.enabled är true. För ett anpassat virtuellt nätverk, systemNodeSubnetId och nodeSubnetId visar resurs-ID:n för undernätet. För ett AKS-hanterat virtuellt nätverk är dessa värden null.

3. Hämta autentiseringsuppgifter för klustret och bekräfta att alla noder är i Ready:

   az aks get-credentials --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   kubectl get nodes -o wide
   

Beteende vid fel

Om migrering inte kan provisionera infrastruktur för hanterade systempooler (till exempel på grund av regionala kapacitetsbegränsningar) bevarar AKS befintliga system- och användarnodpooler i sitt tillstånd före migreringen.