Migrer des clusters automatiques AKS et des pools de nœuds système managés

S’applique à : ✔️ AKS Automatic ✔️ AKS Standard

Cet article explique comment migrer des clusters automatiques AKS entre un pool de nœuds système managé pris en charge et des configurations AKS Standard.

Chemins de migration pris en charge

En utilisant des pools de nœuds système managés, AKS provisionne, met à l’échelle et met à niveau les pools de nœuds système et les composants système pour vous, et les isole de vos charges de travail. Les clusters automatiques AKS sont également couverts par un contrat SLA de préparation des pods et un contrat SLA de temps d’activité. Pour plus d’informations, consultez Vue d’ensemble des clusters automatiques AKS avec des pools de nœuds système managés.

Migrer à partir d’un cluster automatique AKS avec des pools de nœuds système managés vers un cluster AKS Standard

Fonctionnement de la migration

Un cluster AUTOMATIQUE AKS avec des pools de nœuds système managés exécute ses composants système sur les pools de nœuds système que AKS provisionne, met à l’échelle et met à niveau pour vous.

Pour migrer d’AKS Automatic vers AKS Standard, effectuez les étapes générales suivantes :

1. Ajoutez un pool de nœuds système auto-géré à votre cluster automatique AKS.
2. Mettez à jour le SKU du cluster de automatic à base.

Après avoir mis à jour la référence SKU, le cluster s’exécute en tant que cluster AKS Standard, et vos composants système s’exécutent sur le pool de nœuds système que vous avez ajouté et gérez.

Migrer vers un cluster AKS Standard

1. Ajoutez un pool de nœuds système autogérés à votre cluster automatique AKS existant à l’aide de la az aks nodepool add commande. Définissez le mode System de pool de nœuds pour qu’il puisse exécuter les composants système après la migration.

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

2. Mettez à jour le SKU du cluster de automatic à base à l’aide de la commande az aks update.

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

Vérifier la migration

1. Vérifiez que le cluster utilise désormais le SKU base à l’aide de la commande az aks show.

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

2. Répertoriez les pools de nœuds du cluster pour confirmer que votre pool de nœuds système autogéré est présent et en mode System à l’aide de la commande 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
   

Migrer à partir d’un cluster automatique AKS sans pools de nœuds système managés vers AKS Automatic avec des pools de nœuds système managés (préversion)

AKS Automatic prend en charge la migration en préversion des pools de nœuds système non managés vers des pools de nœuds système managés dans les régions où les pools de nœuds système managés sont généralement disponibles. Cette migration conserve le cluster sur le SKU automatic et déplace les composants système d’AKS vers un pool de nœuds système géré par AKS.

Prerequisites

• Un cluster AKS Automatic existant sans pools de nœuds système gérés.
• Azure CLI version 2.86.0 ou ultérieure. Pour connaître la version, exécutez az --version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
• La dernière version de l’extension Azure CLI aks-preview.
• L’indicateur de fonctionnalité Microsoft.ContainerService/NonHoboToHoboConversionPreview inscrit dans votre abonnement.

Inscrivez l’indicateur NonHoboToHoboConversionPreview de fonctionnalité à l’aide de la az feature register commande :

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

Vérifiez l’état de l’inscription à l’aide de la az feature show commande :

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

Attendez que la commande retourne Registered avant de continuer. Actualisez ensuite l’inscription du Microsoft.ContainerService fournisseur de ressources.

az provider register --namespace Microsoft.ContainerService

Installez ou mettez à jour l’extension aks-preview :

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

Migrer un cluster de réseau virtuel géré par AKS

Pour un cluster AKS automatique qui utilise la mise en réseau gérée par AKS, migrez vers des pools de nœuds système gérés à l’aide de la commande az aks update avec le paramètre --enable-hosted-system :

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

Migrer un cluster de réseau virtuel personnalisé

Pour un cluster automatique AKS qui utilise un réseau virtuel personnalisé, fournissez un sous-réseau pour le pool de nœuds système managé à l’aide du --system-node-subnet-id paramètre. Le sous-réseau du nœud système doit :

• Se trouver dans le même réseau virtuel et la même région que le cluster.
• Être au moins /26.
• Ne pas être délégué à un autre service.
• Doit être différent du sous-réseau du nœud.

Le paramètre --node-subnet-id est facultatif. Si vous ne le spécifiez pas, AKS utilise le sous-réseau existant du pool de nœuds système.

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

Vérifier la migration

Vérifiez que le cluster utilise des pools de nœuds système managés à l’aide de la az aks show commande :

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

L’exemple de sortie suivant montre la hostedSystemProfile.enabled propriété définie sur true:

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

Migrer d’un cluster AKS Standard vers un cluster AKS Automatic avec des pools de nœuds système managés (préversion)

AKS prend en charge la migration en préversion des clusters AKS Standard (base SKU) vers des clusters AKS Automatic avec des pools de nœuds système managés dans les régions où les pools de nœuds système managés sont généralement disponibles.

Pour migrer, vous devez d’abord configurer votre cluster AKS Standard pour qu’il corresponde à la configuration automatique AKS, puis mettre à jour le SKU du cluster. La plupart du travail consiste à préparer le cluster. Effectuez les sections suivantes dans l’ordre, car plusieurs paramètres dépendent d’autres configurés en premier.

Avant de commencer

• Un cluster AKS Standard (base SKU) existant. Pour connaître les exigences et limitations générales d’AKS Automatic, consultez Démarrage rapide : Créer un cluster AKS Automatic et Vue d’ensemble des clusters automatiques AKS avec des pools de nœuds système managés.
• Azure CLI version 2.86.0 ou ultérieure et la dernière version de l’extensionaks-preview.
• L’indicateur de fonctionnalité Microsoft.ContainerService/NonHoboToHoboConversionPreview inscrit dans votre abonnement. Pour inscrire l'indicateur de fonctionnalité et installer l’extension, suivez les étapes décrites dans Prérequis.

Définissez des variables d’environnement pour votre 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)

Prérequis de migration

Avant de pouvoir mettre à jour la référence SKU, votre cluster doit répondre aux exigences suivantes. Certaines exigences diffèrent selon que votre cluster utilise un réseau virtuel géré par AKS ou un réseau virtuel personnalisé. Vous pouvez configurer ces paramètres à l’aide du portail Azure, de Azure CLI, d’un modèle ARM ou d’autres outils. Le reste de cet article présente les étapes Azure CLI dans l’ordre dans lequel vous devez les appliquer.

Planifier votre migration

1. Déterminez si votre cluster utilise un réseau virtuel géré par AKS ou un réseau virtuel personnalisé. Si la commande suivante retourne un nom de réseau virtuel, votre cluster utilise un réseau virtuel géré par AKS. S’il ne retourne rien, votre cluster utilise un réseau virtuel personnalisé.

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

   Plusieurs étapes de cet article diffèrent selon le type de votre réseau virtuel.

2. Vérifiez le plug-in réseau actuel de votre cluster, le type sortant, la référence SKU de l’équilibreur de charge et le niveau de restriction du groupe de ressources de nœud :

   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
   

   • Plug-in réseau : doit être azure avec le mode plug-in overlay. Si votre cluster utilise kubenet ou Azure CNI sans Overlay, mettez-le à niveau vers Azure CNI Overlay avant de continuer. Pour plus d’informations, consultez Mettre à jour le mode IPAM pour Azure CNI Overlay.
   • La référence SKU de l’équilibreur de charge : doit être standard. Si votre cluster utilise basictoujours, mettez-le à jour avec az aks update --load-balancer-sku standard.
   • Niveau de restriction du groupe de ressources de nœud : pour un réseau virtuel géré par AKS, vous devez créer un sous-réseau dans le groupe de ressources de nœud. Si le niveau de restriction est ReadOnly, définissez-le à Unrestricted avant de continuer. Vous le verrouillez à nouveau dans une étape ultérieure.

3. Passez en revue les modifications qui perturbent l’exécution des charges de travail ou l’accès, et planifiez une fenêtre de maintenance :

   • La modification du type sortant modifie les adresses IP de sortie de votre cluster. Mettez à jour toutes les règles de pare-feu qui autorisent le trafic en provenance du cluster.
   • L’activation de l’intégration au réseau virtuel du serveur d’API modifie l’adresse IP du serveur d’API et nécessite un redémarrage du cluster. Ce changement est permanent.
   • La modification du plan de données réseau, de la référence SKU du système d’exploitation et des paramètres d’accès SSH recrée l’image de vos nœuds.
   • La désactivation des comptes locaux supprime les informations d’identification kubeconfig statiques. Vérifiez que vous disposez d’un accès via Microsoft Entra ID et d’un rôle RBAC Azure, tel que Azure Kubernetes Service RBAC Cluster Admin, avant de les désactiver.
   • La migration active Deployment Safeguards en mode Enforce avec les Pod Security Standards de base. Les déploiements qui ne sont pas conformes sont rejetés. Vous pouvez exclure des namespaces, mais vous ne pouvez pas basculer le niveau à l’échelle du cluster vers Warn. Passez en revue vos charges de travail avant de migrer. Pour plus d’informations, consultez Utiliser les protections de déploiement.

Préparer la mise en réseau du cluster

1. Type de trafic sortant : pour un réseau virtuel géré par AKS, le type sortant doit être une passerelle NAT managée. Le loadBalancer type sortant n’est pas pris en charge. Si nécessaire, mettez à jour le type sortant :

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

   Pour un réseau virtuel personnalisé, tout type sortant est pris en charge et aucune modification n’est requise. Pour plus d’informations, consultez Mettre à jour outboundType après la création du cluster.

2. Identité du cluster : pour un réseau virtuel géré par AKS, conservez l’identité managée affectée par le système du cluster. Pour un réseau virtuel personnalisé, le cluster doit utiliser une identité managée affectée par l’utilisateur qui a le rôle Contributeur réseau sur le réseau virtuel. Si nécessaire, attribuez l’identité :

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

   Remplacez IDENTITY_RESOURCE_ID par l’ID de ressource de votre identité managée affectée par l’utilisateur. Pour plus d’informations, consultez Utiliser une identité managée affectée par l’utilisateur.

3. Sous-réseau du serveur d’API : créez un sous-réseau dédié pour le serveur d’API dans le même réseau virtuel que vos nœuds. Le sous-réseau doit être distinct de votre sous-réseau de nœuds, avoir une taille d’au moins /28 et être délégué à Microsoft.ContainerService/managedClusters.

   Pour un réseau virtuel géré par AKS, créez le sous-réseau dans le réseau virtuel du groupe de ressources de nœud :

   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)
   

   Pour un réseau virtuel personnalisé, créez le sous-réseau dans votre propre réseau virtuel à la place et définissez APISERVER_SUBNET_ID sur son ID de ressource.

4. Intégration au réseau virtuel du serveur d’API : activez l’intégration au réseau virtuel du serveur d’API avec le sous-réseau que vous avez créé, puis redémarrez le cluster :

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

   Pour plus d’informations, consultez Convertir un cluster AKS Standard existant en intégration de réseau virtuel du serveur d’API.

5. Dataplane réseau : Mettez à jour le dataplane réseau vers Cilium. Cette commande définit également la politique réseau sur Cilium.

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

   Pour plus d’informations, consultez Azure CNI Powered by Cilium.

Préparer le pool de nœuds système et l’approvisionnement de nœuds

1. Disque de système d’exploitation éphémère : le pool de nœuds système doit utiliser un disque de système d’exploitation éphémère. Vérifiez le type de disque de système d’exploitation actuel :

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

   Vous ne pouvez pas modifier le type de disque du système d’exploitation d’un pool de nœuds existant. Si votre pool de nœuds système utilise un disque du système d’exploitation Managed, ajoutez un nouveau pool de nœuds système avec --mode System --node-osdisk-type Ephemeral --os-sku AzureLinux --ssh-access disabled, déplacez vos charges de travail système vers celui-ci, puis supprimez l’ancien pool de nœuds. Vous pouvez ensuite ignorer l’étape suivante.

2. SKU du système d’exploitation et accès SSH : mettez à jour le pool de nœuds système pour utiliser Azure Linux et désactiver l’accès SSH :

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

   Cette commande recrée l’image du pool de nœuds. Attendez qu’elle se termine avant d’apporter d’autres modifications au pool de nœuds. Pour plus d’informations, consultez Utiliser l’hôte de conteneur Linux Azure et gérer l’accès SSH sur les nœuds de cluster AKS.

3. Mode de provisionnement de nœud : activez le mode de provisionnement automatique des nœuds :

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

   Après avoir activé le mode Automatique, vous ne pouvez pas revenir au mode Manuel sans supprimer d’abord tous les nœuds autoprovisionnés. Pour plus d’informations, consultez Provisionnement automatique de nœuds.

Activer les fonctionnalités requises et les modules complémentaires

1. Mettez à jour le niveau du cluster sur Standard et activez les extensions Azure Policy et fournisseur de secrets Azure Key Vault avec rotation des secrets :

   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. Activez les fonctionnalités requises restantes :

   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
   

Verrouiller le groupe de ressources du nœud

Définissez le niveau de restriction du groupe de ressources de nœud sur ReadOnly. Effectuez cette étape en dernier, car le verrouillage bloque les modifications apportées aux ressources dans le groupe de ressources de nœud, y compris le sous-réseau du serveur d’API que vous avez créé précédemment.

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

Pour plus d’informations, consultez verrouillage du groupe de ressources de nœud.

Migrer le cluster vers AKS Automatic

Si une exigence n’est toujours pas satisfaite, la commande de migration échoue et répertorie les exigences non satisfaites qu’elle a détectées. Certaines vérifications ne s’exécutent qu’après la réussite des précédentes. Résolvez donc les éléments répertoriés et réexécutez la commande jusqu’à ce qu’elle réussisse.

Réseau virtuel géré par AKS

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

Réseau virtuel personnalisé

Fournissez un sous-réseau pour le pool de nœuds système managé à l’aide du --system-node-subnet-id paramètre. Pour connaître la configuration requise pour les sous-réseaux, consultez Migrer un cluster automatique AKS existant vers des pools de nœuds système managés. Le paramètre --node-subnet-id est facultatif. Si vous ne le spécifiez pas, AKS utilise le sous-réseau existant du pool de nœuds système.

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

Vérifier la migration

1. Vérifiez que le cluster utilise la Standard référence SKU et le automatic niveau, et que la mise à jour s’est terminée correctement :

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

   Vérifiez que sku.name est Automatic, sku.tier est Standard, et provisioningState est Succeeded.

2. Vérifiez que le cluster utilise des pools de nœuds système managés :

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

   Confirmez que hostedSystemProfile.enabled est true. Pour un réseau virtuel personnalisé, systemNodeSubnetId et nodeSubnetId affichent vos ID de ressource de sous-réseau. Pour un réseau virtuel géré par AKS, ces valeurs sont null.

3. Obtenez les informations d’identification du cluster et vérifiez que tous les nœuds sont à l’état Ready :

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

Comportement d’échec

Si la migration ne peut pas approvisionner l’infrastructure de pool de systèmes managés (par exemple, en raison de contraintes de capacité régionale), AKS conserve les pools de nœuds système et utilisateur existants dans leur état de pré-migration.