Migrer à partir de groupes à haute disponibilité dans Azure Kubernetes Service (AKS)

Cet article explique comment Azure Kubernetes Service (AKS) supprime progressivement la prise en charge des groupes à haute disponibilité de machines virtuelles (VMAS) en faveur des machines virtuelles. Nous vous recommandons d’utiliser des pools de nœuds de machine virtuelle pour les machines virtuelles optimisées par AKS.

Pools de nœuds de machine virtuelle :

• Autoriser les instances de machine virtuelle à gérer, configurer et mettre à jour de manière centralisée.
• Autorisez une augmentation ou une diminution du nombre d’instances de machine virtuelle en réponse à la demande ou à une planification définie.
• Autorisez les contrôles de niveau nœud unique et le mélange de même famille de nœuds de différentes tailles, ce qui augmente la flexibilité et améliore la cohérence.

Vue d’ensemble des groupes de disponibilité

Les groupes à haute disponibilité sont des regroupements logiques de machines virtuelles qui réduisent le risque de défaillances corrélées entraînant des pannes simultanées sur les machines virtuelles associées. Les groupes à haute disponibilité placent des machines virtuelles dans différents domaines d’erreur pour une meilleure fiabilité.

Supprimer les groupes à haute disponibilité

Depuis 2019, nous ne prévoyons plus d'ajouter d'autres fonctionnalités aux Availability Sets dans AKS. Toutes les fonctionnalités introduites depuis 2019, telles que la sauvegarde AKS, ne sont pas prises en charge dans les groupes à haute disponibilité.

Migrer des groupes à haute disponibilité vers des pools de nœuds de machines virtuelles

Il existe maintenant un moyen d’utiliser un script pour migrer votre cluster AKS des groupes de disponibilité vers des pools de nœuds de machines virtuelles. Ce script met également automatiquement à niveau les équilibreurs de charge de niveau Essentiel de votre cluster vers le niveau Standard.

Avant de commencer

Exigences

• La version minimale de Kubernetes pour ce script est 1.27. Si vous devez mettre à niveau votre cluster AKS, consultez mettre à niveau un cluster AKS.
• Vous avez besoin de la version 2.76.0 d’Azure CLI installée.
• Si le cluster exécute le service de gestion des clés avec un coffre de clés privé, le service de gestion des clés doit être désactivé pendant toute la migration.
• Si le cluster utilise un ValidatingAdmissionWebhooks ou MutatingAdmissionWebhooks, ces webhooks doivent être désactivés avant la migration. Les webhooks par défaut du plan de contrôle ne doivent pas être désactivés. Par exempleaks-node-mutating-webhook, et webhook-admission-controlleraks-node-validating-webhook.

Préparation de la migration

• Créez un plan de migration pour les temps d’arrêt planifiés.
• Une fois la migration démarrée, l’annulation n’est pas autorisée.

Exécuter le script de migration pour la migration d’un groupe à haute disponibilité

Dans les commandes suivantes, remplacez <myResourceGroup> et <myAKSCluster> par le nom de votre groupe de ressources et le nom du cluster AKS.

1. La commande suivante lance un script pour migrer un cluster à l’aide de groupes à haute disponibilité vers des pools de nœuds de machines virtuelles à l’aide de la commande az aks update, ainsi que la définition --migrate-vmas-to-vms. Ce script met également à niveau l’équilibreur de charge de base et l’adresse IP de base vers l’équilibreur de charge standard et l’adresse IP standard, le cas échéant.

   az aks update \
     --name <myAKSCluster> \
     --resource-group <myResourceGroup> \
     --migrate-vmas-to-vms \
   

2. Vérifiez que la migration a réussi à utiliser la commande az aks show. La sortie de la commande affiche les détails du cluster.

   az aks show \
     --name <myAKSCluster> \
     --resource-group <myResourceGroup>
   

   Une migration réussie peut être vérifiée lorsque les détails du cluster à l’aide de la commande az aks show incluent un type défini sur VirtualMachines, et loadbalancerSku sur Standard.

     "type": "VirtualMachines"
     "loadBalancerSku": "standard",
   

3. Vérifiez que tous les pods et services s’exécutent correctement à l’aide des commandes kubectl get pods et kubectl get svc.

   kubectl get svc -A \
   kubectl get pods -A
   

4. Vous pouvez confirmer les nouvelles adresses IP associées aux règles de trafic sortant en répertoriant les adresses IP sortantes. Cette étape est effectuée en confirmant les ID de ressource pour les adresses IP, puis en répertoriant les adresses IP.

   Utilisez la commande suivante pour obtenir l’ID de ressource pour les adresses IP sortantes :

   # Get the outbound IP Resource ID
   az aks show \
     --resource-group <myResourceGroup> \
     --name <myAKSCluster> \
     --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id
   

   Utilisez la commande suivante pour obtenir chaque adresse IP de l’ID de ressource et remplacer <IPResourceID> par l’ID de ressource de la commande précédente :

   # get the new IP for each IP Resource ID
   az network public-ip show --ids <IPResourceID> --query ipAddress -o tsv
   

Contenu connexe

• Plus d’informations sur les pools de nœuds de machine virtuelle
• Mise à niveau à partir de Basic Load Balancer sur Azure Kubernetes Service