Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans ce tutoriel, troisième partie sur cinq, vous migrez vos nœuds existants vers ACL. Vous pouvez migrer vos nœuds existants à l’aide de l’une des méthodes suivantes :
- Supprimez les pools de nœuds existants et ajoutez de nouveaux pools de nœuds ACL.
- Effectuez une migration sur place du SKU du système d’exploitation.
Les commandes de ce didacticiel utilisent les variables d’environnement définies dans le tutoriel 1 : Créer un cluster avec ACL pour AKS.
Si vous n’avez aucun nœud existant à migrer, passez au tutoriel suivant. Dans les didacticiels ultérieurs, vous allez apprendre à activer la télémétrie et la surveillance dans vos clusters et à mettre à niveau des nœuds ACL.
Prerequisites
- Dans les didacticiels précédents, vous avez créé et déployé un cluster ACL. Si vous n’avez pas effectué ces étapes et que vous souhaitez le suivre, consultez le tutoriel 1 : Créer un cluster avec ACL pour AKS.
- Azure Container Linux nécessite Azure CLI version 2.86.0 ou ultérieure. Utilisez la
az versioncommande pour rechercher la version. Pour effectuer une mise à niveau vers la dernière version, utilisez laaz upgradecommande.
considérations et limitations relatives aux Azure Container Linux (ACL)
Avant de commencer, passez en revue les considérations et limites suivantes concernant l'ACL :
- ACL est disponible de manière générale à partir d’AKS v1.34.
- ACL nécessite Trusted Launch avec démarrage sécurisé et vTPM. Les variantes de lancement non approuvées ne sont pas disponibles.
- ACL sur Arm64 nécessite des SKU basés sur Cobalt (v6) pour assurer la compatibilité avec Trusted Launch.
-
NodeImageetNonesont les seuls canaux de mise à niveau de système d’exploitation pris en charge.UnmanagedetSecurityPatchsont incompatibles avec la liste de contrôle d’accès en raison du répertoire immuable/usr. - Le streaming d’artéfacts n’est pas pris en charge.
- Le sandboxing des pods n’est pas pris en charge.
- Les machines virtuelles confidentielles ne sont pas prises en charge.
- Les machines virtuelles de génération 1 ne sont pas prises en charge.
Ajouter des pools de nœuds ACL et supprimer des pools de nœuds existants
Ajoutez un nouveau pool de nœuds ACL à l’aide de la
az aks nodepool addcommande. Utilisez--mode Systemce paramètre pour que le nouveau pool puisse servir de pool d’agents système, ce qui vous permet de supprimer le pool de nœuds d’origine à l’étape suivante. L’exemple suivant crée un pool de nœuds nommé aclsystem qui ajoute trois nœuds au cluster :az aks nodepool add \ --resource-group $RESOURCE_GROUP \ --cluster-name $CLUSTER_NAME \ --name aclsystem \ --mode System \ --os-sku AzureContainerLinux \ --node-count 3Exemple de sortie :
{ "id": "/subscriptions/xxxxx/resourceGroups/myACLResourceGroup/providers/Microsoft.ContainerService/managedClusters/myACLCluster/nodePools/aclsystem", "name": "aclsystem", "osSku": "AzureContainerLinux", "provisioningState": "Succeeded" }Supprimez votre pool de nœuds existant à l’aide de la
az aks nodepool deletecommande.az aks nodepool delete \ --resource-group $RESOURCE_GROUP \ --cluster-name $CLUSTER_NAME \ --name <existing-node-pool-name>
Migration de la référence SKU du système d’exploitation sur place
Limitations de la migration de référence SKU du système d’exploitation sur place
Il existe plusieurs paramètres qui peuvent bloquer la requête de migration de référence SKU du système d’exploitation. Pour garantir une migration réussie, passez en revue les instructions et limitations suivantes :
- La fonctionnalité de migration de la référence SKU du système d’exploitation n’est pas disponible via PowerShell ou le portail Azure.
- La fonctionnalité de migration des SKU du système d’exploitation ne prend pas en charge le renommage des pools de nœuds existants.
- Ubuntu, Azure Linux et AzureContainerLinux sont les seules cibles de migration de référence SKU du système d’exploitation Linux prises en charge.
- ACL requiert Trusted Launch. S’il n’est pas déjà activé sur votre pool de nœuds, vous devez inclure
--enable-secure-bootet--enable-vtpmlors de la migration vers la référence SKU du système d’exploitationAzureContainerLinux. La taille de VM de votre pool de nœuds doit également être compatible avec Trusted Launch. Si la taille actuelle de votre machine virtuelle ne la prend pas en charge, vous devez redimensionner ou recréer le pool de nœuds avec une taille de machine virtuelle prise en charge avant de migrer. - Les machines virtuelles de génération 1 ne sont pas prises en charge.
- Une référence SKU du système d’exploitation Ubuntu avec
UseGPUDedicatedVHDactivé ne peut pas effectuer une migration de référence SKU du système d’exploitation. - Les machines virtuelles confidentielles ne sont pas prises en charge.
- Le sandboxing des pods n’est pas pris en charge.
- La migration de référence SKU du système d’exploitation Windows n’est pas prise en charge.
Conditions préalables à la migration de version SKU du système d’exploitation sur site
- Un cluster AKS existant avec au moins un pool de nœuds Linux.
- Nous vous recommandons de vérifier que vos charges de travail fonctionnent correctement sur ACL en déployant un cluster ACL dans un environnement de développement ou de préproduction avant de migrer vos clusters de production.
- Vérifiez que la fonctionnalité de migration fonctionne pour vous en test/développement avant d’utiliser le processus sur un cluster de production.
- Assurez-vous que vos pods ont suffisamment de budget d’interruption de pod (PDB) pour permettre à AKS de déplacer des pods entre des machines virtuelles pendant la mise à niveau.
- Vous avez besoin d’Azure CLI version 2.61.0 ou ultérieure. Utilisez la
az versioncommande pour rechercher la version. Pour effectuer une mise à niveau vers la dernière version, utilisez laaz upgradecommande.
Migrer vers ACL en utilisant la migration sur place du SKU du système d’exploitation
Vous pouvez migrer vos pools de nœuds Ubuntu ou Azure Linux existants vers ACL en modifiant le SKU du système d’exploitation du pool de nœuds, ce qui fait passer le cluster par le processus standard de mise à niveau de l’image des nœuds. Cette méthode ne nécessite pas de création de pools de nœuds ; Au lieu de cela, vos pools de nœuds existants sont automatiquement réimageés.
Important
ACL requiert Trusted Launch. Vous devez inclure --enable-secure-boot et --enable-vtpm lors de la migration vers la référence SKU du système d’exploitation AzureContainerLinux . La taille de VM de votre pool de nœuds doit également être compatible avec Trusted Launch.
Migrez le SKU du système d’exploitation de votre pool de nœuds vers ACL à l’aide de la commande az aks nodepool update. Cette commande déclenche une nouvelle image de votre pool de nœuds. La modification de la référence SKU du système d’exploitation déclenche une opération de mise à niveau immédiate, ce qui prend plusieurs minutes.
az aks nodepool update \
--resource-group $RESOURCE_GROUP \
--cluster-name $CLUSTER_NAME \
--name <existing-node-pool-name> \
--os-sku AzureContainerLinux \
--enable-secure-boot \
--enable-vtpm
Exemple de sortie :
{
"id": "/subscriptions/xxxxx/resourceGroups/myACLResourceGroup/providers/Microsoft.ContainerService/managedClusters/myACLCluster/nodePools/nodepool1",
"name": "nodepool1",
"osSku": "AzureContainerLinux",
"provisioningState": "Succeeded"
}
Note
Si vous rencontrez des problèmes lors de la migration de la référence SKU du système d’exploitation, vous pouvez restaurer votre référence SKU de système d’exploitation précédente.
Vérifier la migration de la référence SKU de système d’exploitation
Une fois la migration terminée sur vos clusters de test, vérifiez ce qui suit pour garantir une migration réussie :
Vérifiez que les nouveaux nœuds utilisent ACL à l’aide de la commande suivante :
kubectl get nodes -o wideVérifiez que tous vos pods et démonsets s’exécutent sur le nouveau pool de nœuds à l’aide de la commande suivante :
kubectl get pods -o wide -AVérifiez que toutes les étiquettes de nœud de votre pool de nœuds mis à niveau sont ce que vous attendez à l’aide de la commande suivante :
kubectl get nodes --show-labelsVérifiez la version de l’image de nœud à l’aide de la
az aks nodepool listcommande.az aks nodepool list \ --resource-group $RESOURCE_GROUP \ --cluster-name $CLUSTER_NAME \ --query '[].{name: name, osSku: osSku, nodeImageVersion: nodeImageVersion}'Exemple de sortie :
[ { "name": "nodepool1", "nodeImageVersion": "AKSAzureContainerLinux-202606.01.0", "osSku": "AzureContainerLinux" } ]
Conseil / Astuce
Nous vous recommandons de surveiller l’intégrité de votre service pendant quelques semaines avant de migrer vos clusters de production.
Revenir à votre référence SKU de système d’exploitation précédente
Si vous rencontrez des problèmes lors de la migration de la référence SKU du système d’exploitation, vous pouvez restaurer votre référence SKU de système d’exploitation précédente. Pour ce faire, remplacez le champ de référence SKU du système d’exploitation par votre valeur précédente et soumettez à nouveau le déploiement, ce qui déclenche une autre opération de mise à niveau et réimage le pool de nœuds à sa référence SKU de système d’exploitation précédente.
Restaurez votre référence SKU de système d’exploitation précédente à l’aide de la commande az aks nodepool update. Cet exemple revient de ACL à Azure Linux :
az aks nodepool update \
--resource-group $RESOURCE_GROUP \
--cluster-name $CLUSTER_NAME \
--name <existing-node-pool-name> \
--os-sku AzureLinux
Étape suivante
Dans ce tutoriel, vous avez migré des nœuds existants vers ACL. Dans le tutoriel suivant, vous allez apprendre à activer la télémétrie et la surveillance de votre cluster ACL.