Mise à niveau à partir de Basic Load Balancer sur Azure Kubernetes Service (AKS)

Dans cet article, vous allez apprendre à mettre à niveau vos instances Load Balancer de base vers Standard Load Balancer sur Azure Kubernetes Services (AKS). Nous vous recommandons d’utiliser Standard Load Balancer pour toutes les instances de production. Il fournit de nombreuses différences clés à votre infrastructure. Pour obtenir des conseils sur la mise à niveau de Basic Load Balancer vers Standard Load Balancer en dehors d’AKS, consultez les instructions officielles pour la mise à niveau de Basic Load Balancer.

Important

À compter du 30 septembre 2025, Azure Kubernetes Service (AKS) ne prend plus en charge l’équilibreur de charge de base. Pour éviter toute interruption de service potentielle, nous vous recommandons d’utiliser Standard Load Balancer pour les nouveaux déploiements et de mettre à niveau tous les déploiements existants vers Standard Load Balancer. Pour plus d'informations sur cette mise hors service, consultez le sujet GitHub relatif à la fin de service et l'annonce de mise hors service des mises à jour Azure. Pour rester informé des annonces et des mises à jour, suivez les notes de publication d’AKS.

Note

Pour les clusters utilisant les groupes à haute disponibilité et l’équilibreur de charge de base, vous devez exécuter une commande distincte az aks update pour effectuer les deux migrations à la fois (groupes à haute disponibilité vers des pools de nœuds de machine virtuelle et Équilibreur de charge de base vers Standard Load Balancer). Pour connaître les étapes d’exécution de cette migration, consultez les instructions de migration des groupes à haute disponibilité .

Avant de commencer

Avant de commencer la migration, passez en revue les informations suivantes :

  • Un temps d’arrêt se produit pendant la migration. Planifiez les temps d’arrêt en conséquence.
  • Une fois la migration commencée, le retour en arrière n'est pas autorisé.
  • Ce processus migre également votre adresse IP de base vers une adresse IP standard, tout en conservant les adresses IP entrantes associées à l’équilibreur de charge identique. De nouvelles adresses IPs publiques sont créées et associées aux règles sortantes Standard Load Balancer pour traiter le trafic de sortie du cluster.

Prerequisites

Votre cluster doit respecter les conditions préalables suivantes avant de pouvoir effectuer la migration :

  • 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 d’Azure CLI installé. La version minimale dont vous avez besoin est 2.76.0.
  • Si le cluster exécute le service de gestion des clés avec un coffre de clés privé, vous devez désactiver le service de gestion des clés avant d’effectuer la migration. Pour plus d’informations, consultez Désactiver KMS.
  • Vous devez désactiver tout ValidatingAdmissionWebhooks ou MutatingAdmissionWebhooks avant d’effectuer la migration.

Mettre à niveau Basic Load Balancer vers Standard Load Balancer

  1. Mettez à niveau votre équilibreur de charge de base vers Standard Load Balancer à l’aide de la az aks update commande avec l’indicateur --load-balancer-sku défini sur Standard.

    az aks update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku=Standard

  2. Vérifiez que la migration a réussi en utilisant la commande az aks show.

    az aks show \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP

    Dans la sortie, vérifiez que le load-balancer type est défini sur 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

Confirmer les nouvelles adresses IP sortantes

Vous pouvez confirmer les nouvelles adresses IP associées aux règles de trafic sortant en confirmant les ID de ressource des adresses IP, puis en répertoriant les adresses IP.

  1. Obtenez l’ID de ressource pour les adresses IP sortantes à l’aide de la az aks show commande.

    az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id

  2. Obtenez la nouvelle adresse IP pour chaque ID de ressource à l’aide de la az network public-ip show commande.

    az network public-ip show --ids $IP_RESOURCE_ID --query ipAddress -o tsv

Questions fréquentes (FAQ)

Pourquoi est-ce que je vois Error: “Load Balancer SKU 'basic' is invalid; must use 'standard'. lors de la création d’un nouveau cluster AKS ou d’une mise à niveau ?

Microsoft a abandonné le SKU Basic Load Balancer pour certaines opérations AKS, et la création est désormais bloquée dans certaines régions.

Pour résoudre ce problème, veillez à spécifier --load-balancer-sku standard lors de la création d’un cluster. Par exemple:

az aks create \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku standard

Pourquoi ne puis-je pas modifier mon équilibreur de charge de base en équilibreur de charge standard en place ?

La référence SKU Load Balancer est immuable après la création dans AKS, car il s’agit d’une ressource managée appartenant au cluster.

Vous pouvez résoudre ce problème à l’aide de l’une des options suivantes :

  • Option 1 : Utilisez la az aks update run commande pour mettre à niveau Basic Load Balancer vers Standard. Pour plus d’informations, consultez Upgrade Basic Load Balancer sur Azure Kubernetes Service (AKS).
  • Option 2 : Créez un cluster AKS avec Standard Load Balancer (migration bleue-verte) et déplacez les charges de travail existantes.

Pourquoi ne puis-je pas trouver mon adresse IP publique après la mise à niveau de Basic vers Standard Load Balancer ?

L’objet Load Balancer a perdu la référence à votre ressource IP publique pendant la migration. Cela peut se produire si l'IP était liée à Basic SKU Load Balancer et n'a pas été rebondie.

Pour résoudre ce problème :

  1. Vérifiez que la nouvelle adresse IP publique Standard existe dans le groupe de ressources approprié.

  2. Réassociez-le dans le manifeste de service à l’aide de la configuration suivante :

    annotations:
  service.beta.kubernetes.io/azure-load-balancer-ipv4: <your-ip>

Lors de la migration de l’équilibreur de charge sur un cluster privé sans adresse IP publique, pourquoi une adresse IP publique est-elle toujours créée pendant la migration ?

Si outboundType est LoadBalancer, alors AKS provisionne automatiquement une adresse IP publique (PIP), quelle que soit la version SKU de Load Balancer.

Pour résoudre ce problème :

  1. Modifiez outboundType pour userDefinedRouting pour un cluster entièrement privé.
  2. Vérifiez que le routage sortant personnalisé est configuré via le Pare-feu Azure/NVA.

Pourquoi la migration échoue-t-elle dans la configuration de mon équilibreur de charge interne ?

Les outils de migration actuels ne prennent pas en charge les équilibreurs de charge de réseau virtuel (VNet) internes avec Basic to Standard sur place.

Pour résoudre ce problème :

  1. Recréez le cluster dans le même réseau virtuel avec Standard Load Balancer.
  2. Déployez des charges de travail et validez la résolution de noms interne.

Mes pools de nœuds utilisent des ensembles de disponibilité. Est-ce que j’ai toujours des problèmes même après la migration de Load Balancer ?

Yes. Si vos pools de nœuds utilisent des ensembles de disponibilité, ils sont également obsolètes dans AKS après le 30 septembre 2025.

Pour résoudre ce problème :

  1. Pour les clusters utilisant les groupes à haute disponibilité et l’équilibreur de charge de base, vous devez exécuter une commande distincte az aks update pour effectuer les deux migrations à la fois (groupes à haute disponibilité vers des pools de nœuds de machine virtuelle et Équilibreur de charge de base vers Standard Load Balancer). Pour connaître les étapes d’exécution de cette migration, consultez les instructions de migration des groupes à haute disponibilité .
  2. Après la mise à niveau, Azure CLI ou les API REST doivent être utilisées pour effectuer des opérations CRUD ou gérer le pool. Vérifiez les limitations.

Dois-je supprimer les webhooks par défaut avant la mise à niveau ?

Non. Si aucun autre ValidatingAdmissionWebhooks ou MutatingAdmissionWebhooks n'est présent dans le cluster, les webhooks par défaut dans le plan de contrôle devraient pouvoir être conservés pendant la migration.

Les webhooks par défaut sont les suivants :

  • aks-node-mutating-webhook
  • webhook-admission-controller
  • node-validating-webhook

Quel est l’accès nécessaire pour exécuter les commandes de migration ?

Pour exécuter les commandes de migration, vous avez besoin des éléments suivants :

  • Rôle Contributeur ou Propriétaire sur l’abonnement ou le groupe de ressources.
  • La version d’Azure CLI doit être ≥ 2.72.0.
  • La version de l'extension préliminaire d'AKS doit être ≥ 0.5.170.

Comment puis-je voir si le chiffrement KMS (Key Management Service) est désactivé ?

Vous pouvez vérifier si le chiffrement KMS est activé sur votre cluster AKS à l’aide de la az aks list commande.

az aks list --query "[].{Name:name, KmsEnabled:securityProfile.azureKeyVaultKms.enabled, KeyId:securityProfile.azureKeyVaultKms.keyId}"

  • Si la sortie s’affiche "KmsEnabled": null, cela signifie que le chiffrement KMS n’est pas activé pour ce cluster et que vous pouvez ignorer les étapes à suivre pour la désactiver. Par exemple:

      {

    "KeyId": null,

    "KmsEnabled": null,

    "Name": "myAKSCluster"

  },
...

  • Si KMS est activé et que vous souhaitez le désactiver, consultez Désactiver le chiffrement KMS.

Étapes suivantes

Pour plus d’informations sur la mise en réseau AKS, consultez Concepts de mise en réseau pour Azure Kubernetes Service (AKS).

  • Last updated on