Options de mise à niveau et recommandations pour les clusters Azure Kubernetes Service (AKS)

Cet article fournit une base technique pour les mises à niveau de cluster Azure Kubernetes Service (AKS) en abordant les options de mise à niveau et les scénarios courants. Pour obtenir des instructions détaillées adaptées à vos besoins, utilisez les chemins de navigation basés sur des scénarios à la fin de cet article.

Ce qu’aborde cet article

Cette référence technique fournit des notions de base complètes de la mise à niveau AKS sur :

• Les options de mise à niveau manuelles et automatisées et quand utiliser chacune d’elles.
• Les scénarios de mise à niveau courants avec des suggestions spécifiques.
• Les techniques d’optimisation des performances et d’interruption minimale.
• Les conseils de dépannage pour la capacité, les défaillances de drainage et les problèmes de chronologie.
• Les processus de validation et les vérifications préalables à la mise à niveau.

Ce hub est idéal pour vous aider à comprendre les mécanismes de mise à niveau, à résoudre les problèmes, à optimiser les paramètres de mise à niveau et à en savoir plus sur l’implémentation technique.

Pour plus d’informations, consultez les articles connexes suivants :

• Pour mettre à niveau vos clusters AKS de production, consultez Stratégies de mise à niveau de production AKS.
• Pour obtenir des modèles de mise à niveau pour les clusters AKS avec des charges de travail avec état, consultez Modèles de mise à niveau de charge de travail avec état.
• Pour utiliser le hub de scénarios pour vous aider à choisir l’approche de mise à niveau AKS appropriée, consultez Scénarios de mise à niveau AKS : choisissez votre chemin.

Si vous débutez avec les mises à niveau AKS, commencez par le hub de scénarios de mise à niveau pour obtenir une assistance guidée basée sur des scénarios.

Navigation rapide

Options de mise à niveau

Effectuer des mises à niveau manuelles

Les mises à niveau manuelles vous permettent de contrôler quand votre cluster effectue une mise à niveau vers une nouvelle version de Kubernetes. Ces mises à niveau sont utiles pour tester ou cibler une version spécifique :

• Mettre à niveau un cluster AKS
• Mettre à niveau plusieurs clusters AKS par le biais d’Azure Kubernetes Fleet Manager
• Mettre à niveau l’image de nœud
• Personnaliser l’augmentation du nombre de nœuds pendant une mise à niveau
• Mettre à jour le système d'exploitation des nœuds

Configurer des mises à niveau automatiques

Les mises à niveau automatiques conservent votre cluster sur une version prise en charge et à jour. Utilisez ces mises à niveau lorsque vous souhaitez automatiser vos paramètres :

• Mettre à niveau automatiquement un cluster AKS
• Mettre à niveau automatiquement plusieurs clusters AKS via Azure Kubernetes Fleet Manager
• Utiliser une maintenance planifiée pour planifier et contrôler les mises à niveau
• Arrêter automatiquement les mises à niveau de cluster AKS en cas de changements cassants d’API (préversion)
• Mettre à niveau automatiquement les images du système d’exploitation des nœuds de cluster AKS
• Appliquer automatiquement des correctifs de sécurité aux nœuds AKS en utilisant GitHub Actions

Considérations spéciales pour les pools de nœuds qui s’étendent sur plusieurs zones de disponibilité

AKS utilise l’équilibrage de zone best-effort dans les groupes de nœuds. Lors d’un pic de mise à niveau, les zones des nœuds de pic dans les groupes de machines virtuelles identiques sont inconnues à l’avance, ce qui peut entraîner temporairement une configuration de zone déséquilibré. AKS supprime les nœuds de surcroît après la mise à niveau et restaure l'équilibre des zones d'origine.

Pour maintenir l’équilibrage des zones, configurez la surcharge par groupes de trois nœuds. Les revendications de volume persistant qui utilisent des disques de stockage localement redondants Azure sont liées à une zone et peuvent entraîner un temps d’arrêt si les nœuds de pic se trouvent dans une autre zone. Utilisez un budget d’interruption de pod (PDB) pour maintenir la haute disponibilité pendant les drainages.

Optimiser les mises à niveau pour améliorer les performances et réduire les interruptions

Combinez la fenêtre de maintenance planifiée, le pic maximal, le PDB, le délai d’expiration du drainage du nœud et le temps d’attente du nœud pour augmenter la probabilité de mises à niveau réussies et à faible interruption :

• Fenêtre de maintenance planifiée : planifier la mise à niveau automatique pendant les périodes de faible trafic. Nous vous recommandons au moins quatre heures.
• Pic maximal : des valeurs supérieures accélèrent les mises à niveau, mais peuvent perturber les charges de travail. Nous vous recommandons 33 % pour la production.
• Max indisponible : à utiliser lorsque la capacité est limitée.
• Budget d’interruption de pod : défini pour limiter les pods indisponibles pendant les mises à niveau. Validez pour votre service.
• Délai d’expiration du drainage du nœud : configurer la durée d’attente d’éviction de pod. La valeur par défaut est de 30 minutes.
• Temps d’absorption du nœud : échelonnez les mises à niveau pour réduire les temps d’arrêt. La valeur par défaut est 0 minute.

Validations utilisées dans le processus de mise à niveau

AKS effectue des validations de pré-mise à niveau pour garantir l’intégrité du cluster :

• Changements cassants d’API : Détecte les API déconseillées.
• Version de mise à niveau Kubernetes : garantit un chemin de mise à niveau valide.
• Configuration PDB : recherche les PDB mal configurés (par exemple, maxUnavailable=0).
• Quota : Confirme un quota suffisant pour les nœuds en surcharge.
• Sous-réseau: Vérifie les adresses IP suffisantes.
• Certificats/principaux de service : détecte les identifiants expirés.

Ces vérifications permettent de minimiser les échecs de mise à niveau et de fournir une visibilité anticipée des problèmes.

Scénarios et recommandations de mise à niveau courants

Scénario 1 : Contraintes de capacité

Si votre cluster est limité par le niveau de produit ou la capacité régionale, les mises à niveau peuvent échouer lorsque les nœuds de pic ne peuvent pas être approvisionnés. Cette situation est courante avec les niveaux de produit spécialisés (tels que les nœuds GPU) ou dans les régions avec des ressources limitées. Des erreurs telles que SKUNotAvailable, AllocationFailedou OverconstrainedAllocationRequest peuvent se produire si maxSurge elle est définie trop élevée pour la capacité disponible.

Recommandations pour empêcher ou résoudre

• Utilisez maxUnavailable pour effectuer une mise à niveau à l’aide de nœuds existants au lieu d’en augmenter de nouveaux. Pour plus d’informations, consultez Personnaliser les nœuds non disponibles pendant une mise à niveau.
• Réduisez maxSurge pour diminuer les besoins en capacité supplémentaire. Pour plus d’informations, consultez Personnaliser la mise à niveau de l’augmentation des nœuds.
• Pour les mises à jour de sécurité uniquement, utilisez les réinitialisations de correctifs de sécurité qui ne nécessitent pas de nœuds de surtension. Pour plus d’informations, consultez Appliquer des mises à jour de sécurité et du noyau à des nœuds Linux dans Azure Kubernetes Service.

Scénario 2 : Échecs de drainage de nœud et PDB

Les mises à niveau nécessitent le vidage des nœuds (éjection des pods). Les drainages peuvent échouer lorsque les pods sont lents à s’arrêter ou que des budgets d’interruption des pods bloquent les évictions de pods.

Exemple d’erreur :

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

Option 1 : forcer la mise à niveau (contourner le PDB)

Utilisez la mise à niveau forcée uniquement lorsque les PDB empêchent les mises à niveau critiques et ne peuvent pas être résolues. Cela remplace les protections PDB et entraîne potentiellement une indisponibilité complète du service pendant la mise à niveau.

Exigences: Azure CLI 2.79.0+ ou API AKS version 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until 2023-10-01T13:00:00Z

Option 2 : Gérer les nœuds impossibles à drainer (respecter le PDB)

Utilisez cette approche conservatrice pour honorer les PDB tout en empêchant les échecs de mise à niveau.

Configurer le comportement de nœud indrainable :

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Options de comportement :

• Planification (par défaut) : supprime le nœud bloqué et force le remplacement
• Cordon (recommandé) : cordonise le nœud et l’étiquette en tant que kubernetes.azure.com/upgrade-status=Quarantined

Nombre maximal de nœuds bloqués (préversion) :

• Spécifie le nombre de nœuds qui ne parviennent pas à se vider toléré
• Doit undrainable-node-behavior être défini
• maxSurge Valeur par défaut (généralement 10%) si elle n’est pas spécifiée

Conditions préalables pour les nœuds bloqués max

• L’extension Azure CLI aks-preview version 18.0.0b9 ou ultérieure est nécessaire pour utiliser la fonctionnalité maximale de nœuds bloqués.

  # Install or update the aks-preview extension
  az extension add --name aks-preview
  az extension update --name aks-preview
  

Exemple de configuration avec un nombre maximal de nœuds bloqués

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

Recommandations pour éviter les défaillances de drainage

• Définissez maxUnavailable dans les PDB pour autoriser au moins une éviction de pod
• Augmenter les réplicas de pod pour répondre aux exigences du budget d’interruption
• Étendez le délai d’expiration du drainage si les charges de travail ont besoin de plus de temps. (La valeur par défaut est de 30 minutes.)
• Testez les bases de données en préproduction, surveillez les événements de mise à niveau et utilisez des déploiements bleu-vert pour les charges de travail critiques. Pour plus d’informations, consultez Déploiement bleu-vert des clusters AKS.

Vérifier les nœuds non vidables

• Les nœuds bloqués sont non planifiés pour les pods et étiquetés comme étant "kubernetes.azure.com/upgrade-status: Quarantined".

• Vérifiez l’étiquette sur les nœuds bloqués en cas de défaillance de nœud de drainage lors de la mise à niveau :

  kubectl get nodes --show-labels=true
  

Résoudre les nœuds indrainables

1. Supprimez la base de données PDB responsable :

   kubectl delete pdb <pdb-name>
   

2. Supprimez l’étiquette kubernetes.azure.com/upgrade-status: Quarantined :

   kubectl label nodes <node-name> <label-name>
   

3. Si vous le souhaitez, supprimez le nœud bloqué :

   az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
   

4. Une fois cette étape terminée, vous pouvez rapprocher l’état du cluster en effectuant une opération de mise à jour sans les champs facultatifs, comme indiqué dans az aks. Vous pouvez également mettre à l’échelle le pool de nœuds sur le même nombre de nœuds que le nombre de nœuds mis à niveau. Cette action garantit que le pool de nœuds arrive à sa taille d’origine prévue. AKS hiérarchise la suppression des nœuds bloqués. Cette commande restaure également l’état d’approvisionnement du cluster sur Succeeded. Dans l’exemple suivant, 2 indique le nombre total de nœuds mis à niveau.

   # Update the cluster to restore the provisioning status
   az aks update --resource-group <resource-group-name> --name <cluster-name>
   
   # Scale the node pool to restore the original size
   az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
   

Scénario 3 : Mises à niveau lentes

Des paramètres conservateurs ou des problèmes au niveau du nœud peuvent retarder les mises à niveau, ce qui affecte votre capacité à rester à jour avec les correctifs et les améliorations.

Les causes courantes des mises à niveau lentes sont les suivantes :

• Valeurs faibles de maxSurge ou maxUnavailable limitent le parallélisme.
• Temps d'attente élevé (longues attentes entre les mises à niveau de nœud).
• Échecs de drainage (voir Échecs de drainage de nœud).

Recommandations pour empêcher ou résoudre

• Utilisez maxSurge=33%, maxUnavailable=1 pour la production.
• Utilisez maxSurge=50%, maxUnavailable=2 pour dev/test.
• Utilisez le correctif de sécurité du système d’exploitation pour une application de correctifs rapide et ciblée (évite le reformatage complet du nœud).
• Activez cette option undrainableNodeBehavior pour éviter les bloqueurs de mise à niveau.

Scénario 4 : Épuisement des adresses IP

Les nœuds de pic nécessitent plus d’adresses IP. Si le sous-réseau est proche de sa capacité, l’approvisionnement du nœud peut échouer (par exemple, Error: SubnetIsFull). Ce scénario est courant avec Azure Container Networking Interface, un maxPods élevé ou un nombre de nœuds important.

Recommandations pour empêcher ou résoudre

• Assurez-vous que votre sous-réseau dispose de suffisamment d’adresses IP pour tous les nœuds, nœuds de pic et les pods. La formule est Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

• Récupérez les adresses IP inutilisées ou développez le sous-réseau (par exemple, de /24 à /22).

• Réduire maxSurge si l’extension du sous-réseau n’est pas possible :

  az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --max-surge 10%
  

• Surveillez l’utilisation des adresses IP avec Azure Monitor ou des alertes personnalisées.

• Réduisez maxPods par nœud, nettoyez les adresses IP d’équilibreur de charge orphelines et planifiez le dimensionnement du sous-réseau pour les clusters à grande échelle.

Questions fréquemment posées

Puis-je utiliser des outils open source pour la validation ?

Yes. De nombreux outils open source s’intègrent bien aux processus de mise à niveau AKS :

• kube-no-trouble (kubent) : recherche les API déconseillées avant les mises à niveau.
• Trivy : analyse de sécurité pour les images conteneur et les configurations Kubernetes.
• Sonobuoy : test de conformité Kubernetes et validation de cluster.
• kube-bench: vérifications du benchmark de sécurité par rapport aux normes Center for Internet Security.
• Polaris : validation des meilleures pratiques Kubernetes.
• kubectl-clean : nettoyer les manifestes Kubernetes pour validation.

Comment faire pour valider la compatibilité des API avant la mise à niveau ?

Exécutez des vérifications de dépréciation à l’aide d’outils tels que kubent :

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

Qu’est-ce qui différencie les mises à niveau AKS des autres plateformes Kubernetes ?

AKS offre plusieurs avantages uniques :

• Intégration native d’Azure avec Azure Traffic Manager, Azure Load Balancer et la mise en réseau.
• Azure Kubernetes Fleet Manager pour les mises à niveau multicluster coordonnées.
• Mise à jour corrective automatique de l’image de nœud sans gestion manuelle des nœuds.
• Validation intégrée pour le quota, la mise en réseau et les identifiants.
• Support Azure pour les problèmes liés à la mise à niveau.

Choisir votre chemin de mise à niveau

Cet article vous a fourni une base technique. Sélectionnez maintenant votre chemin basé sur un scénario.

Vous êtes prêt à exécuter ?

Vous hésitez encore ?

Utilisez le hub de scénarios de mise à niveau pour un arbre de décision guidé qui prend en compte les éléments suivants :

• Tolérance de temps d’arrêt
• Complexité de l’environnement
• Profil de risque
• Contraintes de chronologie

Tâches suivantes

• Consultez les conseils relatifs aux correctifs et à la mise à niveau AKS pour connaître les meilleures pratiques et les conseils de planification avant de commencer une mise à niveau.
• Recherchez toujours les changements cassants d’API et validez la compatibilité de votre charge de travail avec la version Kubernetes cible.
• Testez les paramètres de mise à niveau (tels que maxSurge, maxUnavailableet les PDB) dans un environnement intermédiaire pour réduire les risques de production.
• Surveillez les événements de mise à niveau et l’intégrité du cluster tout au long du processus.