Automatische AKS-clusters en beheerde systeemknooppuntgroepen migreren

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

In dit artikel leest u hoe u automatische AKS-clusters migreert tussen ondersteunde beheerde systeemknooppuntgroepen en AKS Standard-configuraties.

Ondersteunde migratiepaden

Door beheerde systeemknooppuntgroepen te gebruiken, richt AKS de systeemknooppuntgroepen en systeemonderdelen voor u in, schaalt deze op en upgradet deze, en isoleert ze van uw workloads. Automatische AKS-clusters worden ook ondersteund door een SLA voor podgereedheid en een SLA voor uptime. Zie Overzicht van automatische AKS-clusters met pools voor beheerde systeemknooppunten voor meer informatie.

Migreren van een automatisch AKS-cluster met beheerde systeemknooppuntgroepen naar een AKS Standard-cluster

Hoe de migratie werkt

Een automatisch AKS-cluster met beheerde systeemknooppuntgroepen voert de systeemonderdelen uit op systeemknooppuntgroepen die AKS voor u instelt, schaalt en upgradet.

Als u wilt migreren van AKS Automatic naar AKS Standard, voert u de volgende stappen op hoog niveau uit:

1. Voeg een zelfbeheerde systeemknooppuntgroep toe aan uw automatische AKS-cluster.
2. Werk de cluster-SKU bij van automatic naar base.

Nadat u de SKU hebt bijgewerkt, wordt het cluster uitgevoerd als een AKS Standard-cluster en worden uw systeemonderdelen uitgevoerd in de systeemknooppuntgroep die u hebt toegevoegd en beheerd.

Migreren naar een AKS Standard-cluster

1. Voeg een zelfbeheerde systeemknooppuntgroep toe aan uw bestaande automatische AKS-cluster met behulp van de az aks nodepool add opdracht. Stel de modus knooppuntgroep in op System zodat systeemonderdelen na de migratie kunnen worden uitgevoerd.

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

2. Werk de cluster-SKU bij van automatic naar base met behulp van de az aks update opdracht.

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

De migratie controleren

1. Controleer of het cluster nu gebruikmaakt van de base SKU met behulp van de az aks show opdracht.

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

2. Vermeld de knooppuntgroepen in het cluster om te bevestigen dat uw zelfbeheerde systeemknooppuntgroep aanwezig is en in de System modus met behulp van de az aks nodepool list opdracht.

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

Migreren van een automatisch AKS-cluster zonder beheerde systeemknooppuntgroepen naar AKS Automatisch met pools voor beheerde systeemknooppunten (preview)

AKS Automatic ondersteunt preview-migratie van niet-beheerde systeemknooppuntgroepen naar beheerde systeemknooppuntgroepen in regio's waar beheerde systeemknooppuntgroepen algemeen beschikbaar zijn. Deze migratie houdt het cluster op de automatic SKU en verplaatst AKS-systeemonderdelen naar een systeemknooppuntgroep die wordt beheerd door AKS.

Prerequisites

• Een bestaand automatisch AKS-cluster zonder beheerde systeemknooppuntgroepen.
• Azure CLI versie 2.86.0 of hoger. Voer az --version uit om de versie te vinden. Als u Azure CLI wilt installeren of upgraden, raadpleegt u Azure CLI installeren.
• De nieuwste versie van de aks-preview Azure CLI-extensie.
• De Microsoft.ContainerService/NonHoboToHoboConversionPreview functievlag die is geregistreerd in uw abonnement.

Registreer de NonHoboToHoboConversionPreview functievlag met behulp van de az feature register opdracht:

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

Controleer de registratiestatus met behulp van de az feature show opdracht:

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

Wacht totdat de opdracht wordt geretourneerd Registered voordat u doorgaat. Vernieuw vervolgens de registratie van de Microsoft.ContainerService resourceprovider.

az provider register --namespace Microsoft.ContainerService

Installeer of werk de aks-preview extensie bij:

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

Een door AKS beheerd virtueel netwerkcluster migreren

Voor een automatisch AKS-cluster dat gebruikmaakt van door AKS beheerde netwerken, migreert u naar beheerde systeemknooppuntgroepen met behulp van de az aks update opdracht met de --enable-hosted-system parameter:

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

Een aangepast virtueel netwerkcluster migreren

Voor een automatisch AKS-cluster dat gebruikmaakt van een aangepast virtueel netwerk, geeft u een subnet op voor de beheerde systeemknooppuntgroep met behulp van de --system-node-subnet-id parameter. Het subnet van het systeemknooppunt moet:

• Zich in hetzelfde virtuele netwerk en dezelfde regio bevinden als het cluster.
• Wees minimaal /26.
• Niet worden gedelegeerd aan een andere service.
• Moet verschillen van het subnet van de node.

Het --node-subnet-id-parameter is optioneel. Als u dit niet opgeeft, gebruikt AKS het bestaande subnet van de systeemknooppuntgroep.

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}"

De migratie controleren

Controleer of voor het cluster beheerde systeemknooppuntgroepen worden gebruikt met behulp van de az aks show opdracht:

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

In de volgende voorbeelduitvoer ziet u dat de hostedSystemProfile.enabled eigenschap is ingesteld op true:

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

Migreren van een AKS Standard-cluster naar een AKS Automatic-cluster met beheerde systeemknooppuntgroepen (preview)

AKS ondersteunt preview-migratie van AKS Standard-clusters (base SKU) naar AKS Automatic-clusters met beheerde systeemknooppuntgroepen in regio's waar beheerde systeemknooppuntgroepen algemeen beschikbaar zijn.

Als u wilt migreren, configureert u eerst uw AKS Standard-cluster zodat dit overeenkomt met de automatische AKS-configuratie en werkt u vervolgens de cluster-SKU bij. Het grootste deel van het werk zit in het voorbereiden van het cluster. Voltooi de volgende secties in de volgorde, omdat verschillende instellingen afhankelijk zijn van andere instellingen die eerst worden geconfigureerd.

Voordat u begint

• Een bestaand AKS Standard-cluster (base SKU). Zie voor algemene AKS Automatic-vereisten en -beperkingen Quickstart: Een Azure Kubernetes Service (AKS) Automatic-cluster maken en Overzicht van AKS Automatic-clusters met beheerde systeemknooppuntgroepen.
• Azure CLI versie 2.86.0 of hoger en de nieuwste versie van de aks-preview extensie.
• De Microsoft.ContainerService/NonHoboToHoboConversionPreview functievlag die is geregistreerd in uw abonnement. Als u de functievlag wilt registreren en de extensie wilt installeren, volgt u de stappen in Vereisten.

Omgevingsvariabelen instellen voor uw cluster:

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)

Migratievereisten

Voordat u de SKU kunt bijwerken, moet uw cluster aan de volgende vereisten voldoen. Sommige vereisten verschillen, afhankelijk van of uw cluster gebruikmaakt van een door AKS beheerd virtueel netwerk of een aangepast virtueel netwerk. U kunt deze instellingen configureren met behulp van de Azure-portal, Azure CLI, een ARM-sjabloon of andere hulpprogramma's. In de rest van dit artikel ziet u de Azure CLI stappen in de volgorde waarin u deze moet toepassen.

Uw migratie plannen

1. Bepaal of uw cluster gebruikmaakt van een door AKS beheerd virtueel netwerk of een aangepast virtueel netwerk. Als de volgende opdracht de naam van een virtueel netwerk retourneert, gebruikt uw cluster een door AKS beheerd virtueel netwerk. Als er niets wordt geretourneerd, gebruikt uw cluster een aangepast virtueel netwerk.

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

   Verschillende stappen in dit artikel verschillen, afhankelijk van het type virtueel netwerk.

2. Controleer de huidige netwerkinvoegtoepassing van uw cluster, het uitgaande type, de load balancer-SKU en het beperkingsniveau van de knooppuntresourcegroep:

   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
   

   • Netwerkplug-in: moet azure zijn met plug-inmodus overlay. Als uw cluster kubenet of Azure CNI zonder overlay gebruikt, werkt u het bij naar Azure CNI-overlay voordat u doorgaat. Zie De IPAM-modus bijwerken naar Azure CNI-overlay voor meer informatie.
   • Load balancer-SKU: moet zijn standard. Als uw cluster nog steeds basic gebruikt, werkt u het bij met az aks update --load-balancer-sku standard.
   • Beperkingsniveau voor knooppuntresourcegroep: voor een door AKS beheerd virtueel netwerk moet u een subnet maken in de knooppuntresourcegroep. Als het beperkingsniveau is ReadOnly, stelt u dit in op Unrestricted voordat u doorgaat. U vergrendelt het opnieuw in een latere stap.

3. Bekijk de wijzigingen die de actieve workloads of toegang verstoren en plan een onderhoudsvenster:

   • Als u het uitgaande type wijzigt, worden de UITGAANDE IP-adressen van uw cluster gewijzigd. Werk firewallregels bij die verkeer van het cluster toestaan.
   • Als u VNet-integratie van API Server inschakelt, wordt het IP-adres van de API-server gewijzigd en moet het cluster opnieuw worden opgestart. Deze wijziging is permanent.
   • Als u de dataplane van het netwerk, de SKU van het besturingssysteem en de SSH-toegangsinstellingen wijzigt, worden uw knooppunten opnieuw geïnstalleerd.
   • Als u lokale accounts uitschakelt, worden statische kubeconfig-aanmeldingsgegevens verwijderd. Zorg ervoor dat u toegang hebt via Microsoft Entra ID en een Azure RBAC-rol, zoals Azure Kubernetes Service RBAC-clusterbeheerder, voordat u deze uitschakelt.
   • Met de migratie kunt u Deployment Safeguards in de modus Enforce met basislijn-Pod Security Standards inschakelen. Deployments die niet voldoen, worden geweigerd. U kunt naamruimten uitsluiten, maar u kunt het clusterbrede niveau niet omschakelen naar Warn. Controleer uw workloads voordat u migreert. Zie Implementatiebeveiligingen gebruiken voor meer informatie.

Clusternetwerken voorbereiden

1. Uitgaand type: Voor een door AKS beheerd virtueel netwerk moet het uitgaande type een beheerde NAT-gateway zijn. Het loadBalancer uitgaande type wordt niet ondersteund. Werk indien nodig het uitgaande type bij:

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

   Voor een aangepast virtueel netwerk wordt elk uitgaand type ondersteund en is er geen wijziging vereist. Zie OutboundType bijwerken na het maken van het cluster voor meer informatie.

2. Clusteridentiteit: voor een door AKS beheerd virtueel netwerk moet u de door het systeem toegewezen beheerde identiteit van het cluster behouden. Voor een aangepast virtueel netwerk moet het cluster een door de gebruiker toegewezen beheerde identiteit gebruiken die de rol Netwerkbijdrager heeft voor het virtuele netwerk. Wijs indien nodig de identiteit toe:

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

   Vervang IDENTITY_RESOURCE_ID door de resource-id van uw door de gebruiker toegewezen beheerde identiteit. Zie Een door de gebruiker toegewezen beheerde identiteit gebruiken voor meer informatie.

3. Subnet api-server: maak een toegewezen subnet voor de API-server in hetzelfde virtuele netwerk als uw knooppunten. Het subnet moet gescheiden zijn van het subnet van het knooppunt, ten minste /28en moet worden gedelegeerd aan Microsoft.ContainerService/managedClusters.

   Voor een door AKS beheerd virtueel netwerk maakt u het subnet in het virtuele netwerk in de knooppuntresourcegroep:

   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)
   

   Voor een aangepast virtueel netwerk maakt u in plaats daarvan het subnet in uw eigen virtuele netwerk en stelt u APISERVER_SUBNET_ID in op de resource-id ervan.

4. VNet-integratie van API Server: Schakel VNet-integratie van API Server in met het subnet dat u hebt gemaakt en start vervolgens het cluster opnieuw op:

   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}"
   

   Zie Een bestaand AKS Standard-cluster converteren naar VNet-integratie van API Server voor meer informatie.

5. Netwerkdataplane: Werk de netwerkdataplane bij naar Cilium. Met deze opdracht wordt ook het netwerkbeleid ingesteld op Cilium.

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

   Zie Azure CNI Powered by Cilium voor meer informatie.

De systeemknooppuntgroep en het inrichten van knooppunten voorbereiden

1. Ephemeral OS-schijf: de systeemknooppuntpool moet een tijdelijke besturingssysteemschijf gebruiken. Controleer het huidige type besturingssysteemschijf:

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

   U kunt het type besturingssysteemschijf van een bestaande knooppuntgroep niet wijzigen. Als uw systeemknooppuntgroep gebruikmaakt van een Managed besturingssysteemschijf, voegt u een nieuwe systeemknooppuntgroep toe met --mode System --node-osdisk-type Ephemeral --os-sku AzureLinux --ssh-access disabled, verplaatst u uw systeemworkloads ernaar en verwijdert u vervolgens de oude knooppuntgroep. Vervolgens kunt u de volgende stap overslaan.

2. SKU van het besturingssysteem en SSH-toegang: werk de systeemknooppuntpool bij om Azure Linux te gebruiken en SSH-toegang uit te schakelen:

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

   Met deze opdracht wordt de knooppuntgroep opnieuw van een installatiekopie voorzien. Wacht totdat deze is voltooid voordat u andere wijzigingen aanbrengt in de nodepool. Zie De Azure Linux-containerhost gebruiken en SSH-toegang beheren op AKS-clusterknooppunten voor meer informatie.

3. Provisioningmodus voor knooppunten: automatische inrichtingsmodus voor knooppunten inschakelen:

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

   Nadat u de automatische modus hebt ingeschakeld, kunt u niet teruggaan naar de handmatige modus zonder eerst alle automatisch ingerichte knooppunten te verwijderen. Zie Automatisch inrichten van knooppunten voor meer informatie.

Vereiste functies en invoegtoepassingen inschakelen

1. Werk de clusterlaag bij naar Standard en schakel de invoegtoepassingen Azure Policy en Azure Key Vault Secrets Provider in met geheimrotatie:

   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. Schakel de resterende vereiste functies in:

   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
   

De knooppuntresourcegroep vergrendelen

Stel het beperkingsniveau van de knooppuntresourcegroep in op ReadOnly. Voer deze stap als laatste uit, omdat de vergrendeling wijzigingen in resources in de knooppuntresourcegroep blokkeert, inclusief het API-serversubnet dat u eerder hebt gemaakt.

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

Zie Vergrendeling van knooppuntresourcegroepen voor meer informatie.

Het cluster migreren naar AKS Automatic

Als een vereiste nog steeds niet is voldaan, mislukt de migratieopdracht en worden de niet-vervulde vereisten vermeld die zijn gedetecteerd. Sommige controles worden pas uitgevoerd nadat eerdere controles zijn geslaagd, dus los de vermelde items op en voer de opdracht opnieuw uit totdat dit lukt.

virtueel netwerk beheerd door AKS

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

Aangepast virtueel netwerk

Geef een subnet op voor de beheerde systeemknooppuntgroep met behulp van de --system-node-subnet-id parameter. Zie Een bestaand automatisch AKS-cluster migreren naar beheerde systeemknooppuntgroepen voor subnetvereisten. Het --node-subnet-id-parameter is optioneel. Als u dit niet opgeeft, gebruikt AKS het bestaande subnet van de systeemknooppuntgroep.

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}"

De migratie controleren

1. Controleer of het cluster gebruikmaakt van de automatic SKU en het serviceniveau Standard, en of de update is voltooid:

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

   Bevestig dat sku.nameAutomatic is, sku.tierStandard is en provisioningStateSucceeded is.

2. Controleer of voor het cluster beheerde systeemknooppuntgroepen worden gebruikt:

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

   Bevestig hostedSystemProfile.enabled dit.true Voor een aangepast virtueel netwerk geven systemNodeSubnetId en nodeSubnetId uw subnetresource-id's weer. Voor een door AKS beheerd virtueel netwerk zijn deze waarden null.

3. Haal aanmeldingsgegevens voor het cluster op en controleer of alle knooppunten zich in de status Ready bevinden:

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

Foutgedrag

Als migratie geen infrastructuur van de beheerde systeempool kan inrichten (bijvoorbeeld vanwege regionale capaciteitsbeperkingen), behoudt AKS bestaande systeem- en gebruikersknooppuntgroepen in hun status vóór de migratie.