Fonctionnement des mises à niveau de cluster Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) effectue des mises à niveau propagées pour réduire la perturbation des charges de travail en cours d’exécution.

Pour la plupart des charges de travail de production, AKS Automatic est la valeur par défaut recommandée le cas échéant. AKS Automatic inclut des valeurs par défaut prêtes pour la production pour les opérations de mise à niveau, telles que les mises à niveau automatiques des versions de Kubernetes, les mises à jour d’images du système d’exploitation automatique, les opérations de nœud système managé et les protections intégrées qui réduisent la surcharge manuelle. Pour plus d’informations, consultez Présentation d’AKS Automatic.

Cet article explique les mécanismes de mise à niveau AKS et met en évidence l’endroit où AKS Automatic et AKS Standard diffèrent.

Prerequisites

Modèle de mise à niveau : AKS Automatic et AKS Standard

Les modes de cluster AKS Automatic et AKS Standard utilisent les mêmes principes de base de mise à niveau Kubernetes, mais ils diffèrent en valeurs par défaut et en propriété opérationnelle.

Problème de mise à niveau AKS Automatic AKS Standard
Positionnement de la production Valeur par défaut recommandée pour la plupart des charges de travail de production, le cas échéant Modèle flexible avec une configuration plus manuelle par défaut
Mises à niveau des versions mineures de Kubernetes Canal de mise à niveau automatique préconfiguré Manuel par défaut, canal automatique facultatif
Mise à niveau des images d'OS de nœud Canal d’image de système d’exploitation de nœud automatique préconfiguré Manuel par défaut, canal automatique facultatif
Opérations du pool de nœuds système Géré par AKS Géré par le client
Fenêtres de maintenance planifiée Disponible par défaut Configuration facultative
Contrôles d’interruption de charge de travail Appartenant au client, y compris la stratégie de réplication, le comportement d’état de préparation et la politique de perturbation Appartenant au client, y compris la stratégie de réplication, le comportement d’état de préparation et la politique de perturbation

Note

AKS Automatic simplifie les opérations de plateforme, mais la responsabilité partagée s’applique toujours. La conception de la disponibilité à l’échelle de la charge de travail et le comportement de la stratégie d’éviction relèvent de la responsabilité du client.

Comportement de la mise à niveau continue dans AKS

AKS met à niveau les pools de nœuds en utilisant une méthode progressive qui préserve la capacité pendant le remplacement ou la recréation de l’image des nœuds. Ce comportement est le même pour tous les modes de cluster AKS.

Dans les grandes lignes, AKS :

  1. Ajoute une capacité d’augmentation temporaire en fonction des paramètres de mise à niveau.
  2. Met les nœuds en quarantaine et les draine pour déplacer les charges de travail.
  3. Réinstaller l’image des nœuds ou les remplacer vers la version cible.
  4. Supprime la capacité temporaire supplémentaire une fois l’opération terminée.

Exemple de mise à niveau propagée

Cet exemple illustre la mise à niveau d’un cluster à deux nœuds de Kubernetes 1.30 vers Kubernetes 1.31, avec maxSurge défini sur 1.

Étape 1 : Configuration initiale

Le cluster commence avec deux nœuds exécutant la version 1.30, chacun hébergeant des pods d'application.

Diagramme montrant la configuration initiale du cluster avec deux nœuds exécutant la version 1.30, chaque pod d’application d’hébergement et un nœud d’augmentation nouvellement créé.

  • Nœud 1 : Pod A, Pod B
  • Nœud 2 : Pod C, Pod D
  • Nœud d’augmentation : vide (à l’exception des DaemonSets et des nouveaux pods)

Étape 2 : Isoler et drainer le premier nœud

AKS bloque le nœud 1 pour empêcher la planification de nouveaux pods, puis vide les pods existants.

Schéma montrant le nœud 1 isolé et vidé, les pods évacués et remplacés sur d’autres nœuds disponibles.

  • Pod A → évincé et remplacé sur le nœud de surtension
  • Pod B → supprimé et remplacé sur le nœud 2

Étape 3 : Mettre à niveau le premier nœud

Le nœud 1 est réimagené avec Kubernetes version 1.31 pendant que les pods continuent de s’exécuter sur d’autres nœuds.

Diagramme montrant node 1 réimagené à la version 1.31 pendant que les pods d’application continuent à s’exécuter sur Node 2 et sur le nœud d’augmentation.

  • Nœud 1 : mis à niveau vers la version 1.31
  • Nœud 2 : Pod B, Pod C, Pod D
  • Nœud de surge : Pod A

Étape 4 : Isoler et vider le second nœud

AKS répète le processus pour le nœud 2, les pods sont expulsés et le planificateur les redistribue aux nœuds disponibles appropriés.

Diagramme montrant le nœud 2 mis en quarantaine et vidé, avec des pods expulsés puis remplacés sur le nœud 1 mis à niveau et le nœud de surcapacité.

  • Pod C, B → supprimé et remplacé sur le nœud 1
  • Pod D → expulsé et remplacé sur le Surge Node
  • Nœud 2 : isolé et réimagé en version 1.31

Étape 5 : Supprimer le nœud d’augmentation

Une fois tous les nœuds permanents mis à niveau, le nœud d’augmentation est cordonné, vidé et supprimé.

Diagramme montrant le nœud de surcharge en cours de vidage et de suppression, avec des pods évincés et remplacés sur les nœuds permanents mis à niveau.

  • Pod A → évincé et remplacé sur le nœud 1
  • Pod D → supprimé et remplacé sur le nœud 2
  • Nœud d’augmentation : supprimé

État final

Tous les nœuds fonctionnent désormais sous Kubernetes version 1.31 avec des pods programmés sur le cluster.

  • Nœud 1 (v1.31) : Pod A, Pod C
  • Nœud 2 (v1.31) : Pod B, Pod D

Comportement restrictif du Pod Disruption Budget (PDB)

Si une PDB restrictive bloque l’éviction, le drainage des nœuds peut être retardé ou empêché. AKS peut utiliser le Cordon comportement de nœud indrainable pour continuer à mettre à niveau d’autres nœuds éligibles en fonction du comportement configuré. Les nœuds bloqués peuvent rester sur une version antérieure jusqu’à ce que la condition de blocage soit résolue.

Exemple PDB restrictif

Cet exemple montre la mise à niveau d’un cluster à deux nœuds de Kubernetes 1.30 vers 1.31, avec maxSurge défini sur 2 et un PDB bloquant l’opération de vidage du premier nœud.

Étape 1 : Configuration initiale avec PDB restrictive

Le cluster commence par deux nœuds exécutant la version 1.30, avec une base de données PDB protégeant pod A contre l’éviction.

Diagramme illustrant le cluster initial avec deux nœuds, un nœud de surcharge et un budget de perturbation de pod protégeant le pod A contre l’éviction.

  • Nœud 1 : Pod A (protégé par PDB), Pod B
  • Nœud 2 : Pod C, Pod D
  • Nœuds de surcharge: 2 nouveaux nœuds créés
  • PDB : Empêche l’éviction d’un Pod A

Étape 2 : Tentative de drainage du premier nœud (bloqué)

AKS place le nœud 1 en indisponibilité, mais ne peut pas évacuer le pod A en raison des restrictions du PDB.

Diagramme montrant le nœud 1 isolé, mais avec une vidange bloquée par un Pod Disruption Budget, le pod A restant bloqué et le pod B étant évincé vers le nœud de surcharge.

  • Nœud 1 : cordonné et marqué comme mis en quarantaine (pod A bloqué)
  • Pod B → évincé et remplacé sur le nœud de surcharge 1, tandis que le nœud de surcharge 2 n’est temporairement pas utilisé
  • État : Mise à niveau du nœud 1 bloquée

Étape 3 : Passer au deuxième nœud

Avec le nœud 1 mis en quarantaine, AKS continue de mettre à niveau le nœud 2.

Diagramme montrant que le nœud 1 reste en quarantaine tandis que le nœud 2 est isolé et évacué avec succès, les pods étant déplacés vers le nœud Surge.

  • Nœud 1 : Reste mis en quarantaine (v1.30)
  • Nœud 2 : cordonné et vidé avec succès
  • Pod C → évincé et remplacé sur le nœud de surcharge 2
  • Pod D → supprimé et remplacé sur le nœud de surcharge 2

Étape 4 : Mettre à niveau le deuxième nœud

Le nœud 2 a été reconfiguré avec succès vers la version 1.31 de Kubernetes.

Diagramme montrant le nœud 2 mis à niveau avec succès vers la version 1.31 tandis que le nœud 1 reste mis en quarantaine avec Pod A.

  • Nœud 1 : Toujours en quarantaine (v1.30) avec Pod A
  • Nœud 2 : mis à niveau vers la version 1.31
  • Nœud de surtension 1 : Pod B
  • Nœud d’augmentation 2 : Pod C, Pod D

Étape 5 : un nœud d’augmentation devient un remplacement permanent à mesure qu’un autre est supprimé

Étant donné que le nœud 1 reste en quarantaine, le nœud de surcharge 1 devient le remplaçant permanent exécutant la version 1.31, et le nœud de surcharge 2 est supprimé.

Diagramme montrant le nœud de surcharge devenant le remplacement permanent exécutant la version 1.31, tandis que le nœud 1 reste mis en quarantaine.

  • Nœud 1 : mis en quarantaine (v1.30) - nécessite une intervention manuelle
  • Pod C, Pod D → évincés du nœud de surcharge 2 et remplacés sur le nœud 2
  • Nœud d’augmentation 1 (v1.31) : Pod B (maintenant permanent)
  • Nœud d’augmentation 2 (v1.31) : supprimé

État final

La mise à niveau se termine avec un nœud mis en quarantaine nécessitant une intervention manuelle.

  • Nœud 1 : mis en quarantaine (v1.30) avec le pod A - Le client doit résoudre manuellement (voir Résoudre les nœuds indrainables)
  • Nœud 2 (v1.31) : en cours d’exécution normale
  • Ancien nœud d’augmentation (v1.31) : remplacement permanent

Important

Le nœud mis en quarantaine (nœud 1) est à la charge du client de le gérer. Vous devez soit :

  • Ajustez la base de données PDB pour autoriser l’éviction du pod A.
  • Supprimez manuellement pod A.
  • Supprimez et recréez le nœud après avoir corrigé la condition de blocage.

Considérations clés relatives aux mises à niveau bloquées par PDB

  • Comportement de nœud insécurisable : défini sur pour Cordon le pool de nœuds afin d’activer ce comportement de mise en quarantaine.
  • Responsabilité du client : les nœuds mis en quarantaine nécessitent une intervention manuelle pour être résolus.
  • Capacité du cluster : le nœud de surtension devient permanent, ce qui peut affecter la planification de la capacité du cluster.
  • Surveillance : effectuez le suivi des nœuds mis en quarantaine via Azure Monitor ou kubectl pour garantir la résolution en temps voulu.

Tip

Pour éviter complètement le scénario de mise en quarantaine, vous pouvez utiliser la gestion automatique des PDB pour augmenter automatiquement le nombre de réplicas du déploiement afin que les contraintes des PDB soient respectées avant le début du drain. Cela permet à l’éviction de continuer sans bloquer, ce qui élimine la nécessité d’une résolution manuelle de mise en quarantaine.

Mises à niveau bleu-vert du pool de nœuds (contrôle manuel)

Les mises à niveau blue-green offrent une approche de mise à niveau plus contrôlée en créant manuellement un ensemble complet de nouveaux pools de nœuds avant de migrer les charges de travail. Cette approche manuelle vous donne un contrôle total sur le processus de mise à niveau et le minutage.

Pour plus d’informations, consultez les mises à niveau Blue-Green de pools de nœuds dans AKS.

Quand utiliser des mises à niveau Blue-Green

Les mises à niveau manuelles de pool de nœuds Blue-Green sont une stratégie avancée pour les exigences spécialisées, telles que les points de contrôle de migration explicites, les portes de validation personnalisées ou les basculements étroitement contrôlés.

Utilisez des Blue-Green manuelles lorsque vous avez besoin des éléments suivants :

  • Phases de migration contrôlées par les opérateurs.
  • Critères personnalisés de validation et d’acceptation avant le commit.
  • Chorégraphie explicite de retour arrière associée aux procédures d’exploitation internes.

Pour la plupart des charges de travail de production, le cas échéant, le comportement de mise à niveau par défaut automatique AKS est le point de départ préféré et les Blue-Green manuels sont généralement réservés pour des cas exceptionnels.

Concepts clés

  • Pool de nœuds bleus : votre pool de nœuds existant exécutant la version actuelle de Kubernetes.
  • Pool de nœuds verts : nouveau pool de nœuds que vous créez en exécutant la version de Kubernetes cible.
  • Contrôle manuel : vous gérez tous les aspects du processus de migration.
  • Points de validation : vous décidez quand continuer, mettre en pause ou revenir en arrière.

Avantages des mises à niveau de Blue-Green

  • Contrôle total : vous décidez exactement quand chaque étape se produit.
  • Validation personnalisée : implémentez vos propres critères et délais de validation.
  • Migration progressive : déplacez les charges de travail à votre rythme préféré.
  • Retour en arrière facile : les nœuds d’origine restent disponibles jusqu’à ce que vous les supprimiez.

Considérations clés relatives aux mises à niveau de Blue-Green

  • Effort manuel : nécessite une gestion active tout au long du processus.
  • Conditions requises pour le quota : nécessite 2 fois la capacité du nœud pendant la mise à niveau.
  • Planification : documentez vos critères de validation et vos procédures de retour arrière.

Exemple de processus de mise à niveau manuel Blue-Green

Cet exemple illustre la mise à niveau manuelle d’un cluster à deux nœuds de Kubernetes 1.30 vers la version 1.31 à l’aide de Blue-Green déploiement.

Étape 1 : Créer un pool de nœuds verts

Vous commencez par créer manuellement un pool de nœuds avec la version de Kubernetes cible en même temps que votre pool de nœuds existant.

Diagramme montrant Blue-Green configuration initiale avec le pool de nœuds Bleu exécutant la version 1.30 et le pool de nœuds verts nouvellement créé exécutant la version 1.31.

  • Pool de nœuds bleus (v1.30) : Pod A, Pod B, Pod C, Pod D (existant)
  • Pool de nœuds verts (v1.31) : vide (créé manuellement par vous)
  • Votre action : az aks nodepool add avec la nouvelle version de Kubernetes

Étape 2 : Cordon manuel des nœuds bleus

Cordon des nœuds bleus pour empêcher la planification de nouveaux pods tout en conservant les pods existants en cours d’exécution.

  • Votre action : kubectl cordon sur chaque nœud bleu
  • Nœuds bleus : Isolés, aucun nouveau pod prévu
  • Nœuds verts : prêt à recevoir des charges de travail

Étape 3 : vider manuellement les nœuds bleus (rythme contrôlé)

Vous contrôlez le rythme de migration en drainant manuellement les nœuds un par un ou par lots.

Diagramme montrant le nœud Bleu drainé avec les pods supprimés et remplacés sur le pool de nœuds verts et le deuxième nœud Bleu drainé avec les pods restants migrés vers le pool de nœuds verts.

  • Votre action : kubectl drain sur les nœuds bleus sélectionnés
  • Migration des pods : les pods sont automatiquement replanifiés vers des nœuds verts.
  • Validation : vérifier les charges de travail sur les nœuds verts avant de continuer

Étape 4 : Valider et décider

Après la migration des charges de travail, validez les performances de l’application sur les nœuds verts.

Diagramme illustrant la phase de validation, avec toutes les charges de travail exécutées sur le pool de nœuds Green, tandis que le pool de nœuds Blue reste disponible pour un retour arrière.

Pendant cette phase, vous pouvez :

  • Surveiller : vérifier les métriques et les journaux d’activité des applications
  • Test : Exécuter des tests de validation sur un pool de nœuds verts
  • Décider : S'engager en vert ou retourner au bleu

Étape 5 : Valider ou annuler

En fonction de votre validation, vous effectuez manuellement la mise à niveau ou la restauration.

Option A - Validation (réussite) :

Diagramme montrant la validation réussie avec le pool de nœuds Bleu supprimé et le pool de nœuds verts devenant le pool de nœuds principal.

  • Votre action : supprimer le pool de nœuds bleus à l’aide de az aks nodepool delete
  • Résultat : le pool de nœuds verts devient principal

Option B - Retour en arrière (Problèmes détectés) :

Diagramme montrant un retour arrière, avec les charges de travail revenant au pool de nœuds Blue et le pool de nœuds Green en cours de suppression.

  • Votre action : Désenregistrer les nœuds bleus à l’aide kubectl uncordonde , vider les nœuds verts à l’aide kubectl drainde , et supprimer le pool de nœuds verts à l’aide de az aks nodepool delete
  • Résultat : les charges de travail retournent aux nœuds bleus

Considérations relatives à la production pour la planification de la mise à niveau

  • Configuration de l’augmentation (maxSurge) : contrôle le nombre de nœuds d’augmentation créés pendant les mises à niveau. Des valeurs plus élevées accélèrent les mises à niveau, mais consomment plus de ressources.
  • Budgets d’interruption des pods (PDB) : configurez les bases de données pour garantir la disponibilité des applications pendant le processus de mise à niveau.
  • Mises à niveau des pools de nœuds : chaque pool de nœuds est mis à niveau indépendamment. Planifiez votre stratégie de mise à niveau en conséquence.
  • Capacité et quota : valider les exigences de capacité temporaires et en régime permanent avant les fenêtres de mise à niveau.
  • Surveillance et alertes : configurez la surveillance et les alertes avant le démarrage de la mise à niveau.

Dans AKS Automatic, plusieurs choix de mise à niveau au niveau de la plateforme sont préconfigurés pour la préparation de la production. Dans AKS Standard, les équipes effectuent généralement ces choix explicitement.

Contenu connexe

  • Last updated on