Stratégie d’interruption de nœud dans Azure Kubernetes Service (AKS) (préversion)

Lorsque vous gérez et assurez la maintenance de vos clusters AKS, certaines modifications de configuration nécessitent la réinitialisation des nœuds. Cette opération de reimageage déclenche une mise à jour propagée qui recrée les nœuds. Lors d’une opération de réinitialisation, AKS cordonne le nœud (empêche la planification de nouveaux pods), draine les pods existants (les supprime et les réécriture sur d’autres nœuds disponibles tout en respectant les budgets d’interruption de pod), puis réimage le nœud avec la configuration mise à jour. Ce processus correspond à une recréation complète du nœud, et non à un redémarrage : la machine virtuelle sous-jacente est recréée à partir d’une nouvelle image du système d’exploitation. Bien que les volumes persistants correctement configurés (à l'aide de disques Azure, de Azure Files ou d'un autre stockage externe) ne soient pas affectés, les données stockées dans le stockage éphémère local du nœud (tels que les volumes EmptyDir ou les chemins d'accès locaux) sont définitivement perdues. Ces opérations sont nécessaires pour appliquer des mises à jour importantes, mais elles peuvent perturber l’exécution des charges de travail et affecter la disponibilité des applications. La stratégie d’interruption de nœud vous donne un contrôle précis sur le moment où ces opérations perturbatrices sont autorisées à continuer, ce qui vous permet d’équilibrer la nécessité de mises à jour avec une stabilité opérationnelle.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions préliminaires sont fournies « en l’état » et « selon leur disponibilité » et ne sont pas couvertes par les accords de niveau de service ni par la garantie limitée. Les versions préliminaires d’AKS sont partiellement couvertes par le support client, dans la limite du raisonnable. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Qu’est-ce que la stratégie d’interruption de nœud ?

La stratégie d’interruption de nœud est une configuration au niveau du cluster qui régit le moment où les opérations nécessitant une réinitialisation de nœud et un redéploiement peuvent être exécutés. Il agit comme une porte de contrôle, ce qui vous permet de :

  • Aligner les opérations perturbatrices avec vos fenêtres de maintenance.
  • Bloquer les modifications de configuration pendant les périodes métier critiques tout en autorisant les mises à niveau d’images de nœud et les correctifs de sécurité à continuer.
  • Maintenez le comportement prévisible du cluster pendant les événements à trafic élevé.

La politique s’applique aux modifications de configuration initiées par l’utilisateur qui nécessitent la recréation des nœuds, telles que la mise à jour des certificats de confiance d’autorité de certification (AC) personnalisés, la modification des paramètres du profil de sécurité ou la modification de la configuration du système d’exploitation des nœuds.

Note

Il est important de préciser que la stratégie ne bloque pas les mises à jour de la version de l’image du nœud (y compris les canaux de mise à niveau SecurityPatch et NodeImage) ni les mises à niveau de la version de Kubernetes. Ces opérations continuent de s’exécuter selon leur planification configurée, même lorsque la stratégie est définie sur Block. Pour plus d’informations, consultez Les opérations de mise à niveau non contrôlées par la stratégie d’interruption de nœud. En outre, certaines opérations de récupération ne sont pas contrôlées par cette stratégie pour garantir l’intégrité et la disponibilité du cluster. Pour plus d’informations, consultez les opérations de récupération non contrôlées par la stratégie d’interruption de nœud.

Fonctionnement de la stratégie d’interruption de nœud

Vous configurez la stratégie d’interruption de nœud au niveau du cluster via la nodeDisruptionProfile propriété. Lorsque vous tentez une opération qui nécessite une réinitialisation de nœud, AKS vérifie le paramètre de stratégie actuel :

  • Évaluation de la stratégie : AKS évalue si l’opération est autorisée en fonction de la stratégie actuelle.
  • Vérification de la fenêtre de maintenance (le cas échéant) : si vous utilisez AllowDuringMaintenanceWindow, AKS vérifie si l’heure actuelle se situe dans la fenêtre de maintenance configurée.
  • Exécution ou blocage de l’opération : l’opération de perturbation du nœud se poursuit si elle est autorisée ou rejetée avec un message d’erreur s’il est bloqué.

Options de stratégie

La stratégie d’interruption de nœud prend en charge trois configurations de stratégie :

Policy Description Cas d’utilisation
Allow Autorise les opérations nécessitant une réimage de nœud à tout moment. Il s’agit du comportement par défaut. Utilisez quand vous souhaitez hiérarchiser l’application des mises à jour rapidement et pouvez tolérer une interruption de charge de travail.
AllowDuringMaintenanceWindow Bloque les opérations qui nécessitent une réimage de nœud, sauf si elles se produisent dans la fenêtre de aksManagedNodeOSUpgradeSchedule maintenance. Utilisez quand vous souhaitez limiter les interruptions à des fenêtres de maintenance spécifiques qui s’alignent sur votre planification opérationnelle.
Block Bloque toutes les opérations qui nécessitent la recréation de l’image d’un nœud. Utilisez quand vous devez éviter toute interruption de nœud, par exemple pendant les périodes d’activité critiques ou les événements à trafic élevé.

Note

Lorsque vous utilisez AllowDuringMaintenanceWindow, vous devez configurer une fenêtre de maintenance aksManagedNodeOSUpgradeSchedule. Pour plus d’informations sur la configuration des fenêtres de maintenance, consultez Utiliser la maintenance planifiée pour planifier et contrôler les mises à niveau de votre cluster Azure Kubernetes Service. Si vous ne configurez pas la fenêtre de maintenance, les opérations perturbatrices de nœud sont autorisées.

Considerations

Gardez à l’esprit les considérations suivantes lors de l’utilisation de la stratégie d’interruption de nœud :

Opérations couvertes par la stratégie d’interruption de nœud

Opérations au niveau du cluster

Activation de la stratégie réseau et mise à niveau de Azure CNI Overlay

Pour installer les composants réseau requis et configurer des règles réseau qui sécurisent et gèrent la communication pod-à-pod, vous devez réimager les nœuds.

Le tableau suivant décrit les mises à niveau de stratégie réseau qui déclenchent une nouvelle image :

De À
Aucun (aucune stratégie réseau) stratégie réseau Azure
Aucun (aucune stratégie réseau) Calico
Azure CNI Superposition Azure CNI
stratégie réseau Azure Aucun (aucune stratégie réseau)
Calico Aucun (aucune stratégie réseau)

Note

Le passage des stratégies réseau Azure aux stratégies réseau Calico, ou inversement, une fois que l’une d’elles est déjà activée, ne nécessite pas de réimageage.

Modifications apportées au canal de mise à niveau du système d’exploitation de nœud

Chaque canal utilise une infrastructure et une configuration de mise à jour corrective de système d’exploitation différentes que vous ne pouvez pas modifier sur les nœuds en cours d’exécution.

Le tableau suivant présente les modifications apportées au canal de mise à niveau du système d’exploitation de nœud qui déclenchent une nouvelle image :

De À
Non géré None
Non spécifié Non géré
Correctif de sécurité Non géré
NodeImage Non géré
None Non géré
Non spécifié Non géré
Non géré Correctif de sécurité
Non géré NodeImage

Activation du mode double pile IPv6

Pour prendre en charge la communication en double pile, les nœuds doivent disposer de configurations IP IPv4 et IPv6 ainsi que de mises à jour de la pile réseau (telles que des règles nftables).

Le tableau suivant présente les mises à jour de la configuration IP et de la pile réseau qui déclenchent une réimagerie :

De À
IPv4 uniquement IPv4 + IPv6 (dual-stack)

Modifications apportées au plan de données Cilium

Vous devez installer ou supprimer des programmes eBPF qui gèrent le traitement des paquets au niveau du noyau.

Le tableau suivant présente les modifications apportées au plan de données Cilium qui déclenchent une nouvelle image :

De À
None Cilium
Cilium None

Mises à jour de configuration du proxy HTTP

Tous les composants de nœud (conteneur, kubelet, services système) ont besoin de la configuration de proxy mise à jour appliquée à l’échelle du système. Lorsque vous mettez à jour la configuration du proxy HTTP, AKS réimage automatiquement tous les pools de nœuds dans le cluster.

La stratégie d’interruption de nœud déclenche une nouvelle image lorsque vous modifiez l’une des propriétés de configuration de proxy HTTP suivantes ou effectuez l’une des opérations suivantes :

  • httpProxy: URL du proxy pour les connexions HTTP
  • httpsProxy: URL du proxy pour les connexions HTTPS
  • noProxy: Liste des destinations à exclure du serveur proxy
  • trustedCa: autre certificat d’autorité de certification encodé en Base64
  • Activer le proxy HTTP sur un cluster (avec --enable-http-proxy)
  • Désactiver le proxy HTTP sur un cluster (avec --disable-http-proxy)
  • Réactiver le proxy HTTP pour un cluster sur lequel il avait été précédemment désactivé

Mises à jour des certificats d’autorité de certification personnalisés

Vous devez installer les certificats de nouvelles autorités de certification (CA) dans le magasin de certificats de confiance du système d’exploitation afin que la validation TLS s’applique aux services internes et aux registres privés.

La stratégie de perturbation des nœuds déclenche le réimage lorsque vous ajoutez, supprimez ou mettez à jour des certificats CA personnalisés.

Modifications de l’identité du Kubelet

Vous devez appliquer de nouvelles informations d’identification d’identité à la configuration du nœud. Cela inclut l’attribution d’identité initiale, les mises à jour d’identité et les réinitialisations de profil de principal de service.

La stratégie d’interruption de nœud déclenche le réimage lorsque vous mettez à jour une identité managée ou une identité managée attribuée par l’utilisateur du kubelet.

modifications apportées à la zone DNS privé

Vous devez mettre à jour les paramètres du programme de résolution DNS pour résoudre le point de terminaison du serveur d’API privé à l’aide de la nouvelle zone DNS.

La stratégie d’interruption de nœud déclenche le réimageage lorsque vous modifiez la configuration d’une zone DNS privée dans un cluster privé.

Activation de l’intégration au réseau virtuel du serveur d’API

Vous devez reconfigurer les nœuds pour communiquer avec le serveur d’API via l’adresse IP de l’équilibreur de charge interne projetée dans le sous-réseau délégué.

La stratégie d’interruption de nœud déclenche une nouvelle image lorsque vous activez l’intégration au réseau virtuel du serveur d’API sur un cluster existant qui ne l’a pas utilisé précédemment. Cette modification consiste à faire passer la propriété apiServerAccessProfile.enableVnetIntegration (en interne, le champ privateConnectProfile.enabled) de false (ou non définie) à true:

De À
apiServerAccessProfile.enableVnetIntegration: false ou non défini apiServerAccessProfile.enableVnetIntegration : true

Modifications du routage de l’hôte eBPF

Vous devez installer ou supprimer des programmes eBPF qui fournissent un transfert de paquets hautes performances (mode d’accélération BpfVeth).

Le tableau suivant présente les modifications de routage des hôtes eBPF qui déclenchent une nouvelle image :

De À
Routage standard Routage de l’hôte eBPF activé
Routage de l’hôte eBPF activé Routage standard

Opérations au niveau du pool de nœuds

Ces opérations affectent uniquement les pools de nœuds spécifiques dans lesquels vous apportez des modifications. Ils déclenchent un réimage progressif au sein de ces pools de nœuds :

Mises à jour du profil DNS local

Vous devez appliquer des modifications aux règles de démon de mise en cache DNS et de transfert DNS au niveau du nœud.

La politique de perturbation des nœuds déclenche le réimageage lorsque vous modifiez la configuration d’un profil LocalDNS.

Modifications de sécurité de Trusted Launch

Vous ne pouvez pas modifier la configuration du microprogramme de machine virtuelle et les paramètres de processus de démarrage sur les machines virtuelles en cours d’exécution. Ces modifications vous obligent à recréer les machines virtuelles.

Le tableau suivant présente les modifications de sécurité de lancement approuvée qui déclenchent une nouvelle image :

Configuration De À
vTPM (module de plateforme sécurisée virtuelle) Désactivé Enabled
vTPM (module de plateforme sécurisée virtuelle) Enabled Désactivé
Démarrage sécurisé Désactivé Enabled
Démarrage sécurisé Enabled Désactivé

Modifications de streaming d’artefacts

Vous devez installer ou supprimer des composants de streaming des artefacts pour permettre un téléchargement plus rapide des images de conteneur en diffusant les couches d’image à la demande.

Le tableau suivant présente les modifications du streaming d’artefacts qui déclenchent un réimageage :

De À
Désactivé Enabled
Enabled Désactivé

Mises à jour du profil Windows GMSA (groupes de nœuds Windows uniquement)

Vous devez appliquer de nouveaux paramètres GMSA, la configuration du serveur DNS et les informations d’identification pour joindre le domaine pour l’intégration à Active Directory sur les nœuds Windows.

La stratégie d’interruption de nœud déclenche la réimage des pools de nœuds Windows lorsqu’une modification GMSA nécessite l’application de la nouvelle configuration de nœud :

De À Déclenche la réinstallation de l’image
GMSA désactivé GMSA activé Yes
GMSA activé (serveur DNS / domaine racine défini ou modifié) GMSA activé avec le serveur DNS ou le domaine racine mis à jour Yes
GMSA activé (serveur DNS défini) GMSA désactivé Yes
GMSA activé (aucun serveur DNS défini) GMSA désactivé Non (aucune configuration de nœud à appliquer)

Pièce jointe du groupe de réservations de capacité

Vous devez recréer les machines virtuelles sous-jacentes afin qu’elles soient allouées à partir de la capacité réservée dans le groupe de réservations de capacité (CRG). Les nœuds existants n’ont pas été provisionnés pour le CRG. AKS doit donc réimager le pool de nœuds afin de les associer à la réservation.

La stratégie de perturbation des nœuds déclenche le rétablissement de l’image lorsque vous attachez un groupe de réservations de capacité à un pool de nœuds existant qui n’en a pas déjà un.

De À Déclencheurs de réinitialisation
Aucun groupe de réservation de capacité associé Groupe de réservations de capacité attaché Yes

Opérations non encore couvertes par la stratégie d’interruption de nœud

Les modifications de configuration suivantes nécessitent une nouvelle image de nœud, mais ne sont pas encore couvertes par la stratégie d’interruption de nœud. Une prochaine mise à jour de version mineure Kubernetes couvrira ces modifications, car cette modification introduit un nouveau comportement.
Après avoir apporté ces modifications de configuration, vous devez exécuter az aks nodepool upgrade manuellement avec --node-image-only pour appliquer les modifications à vos nœuds.

  • Modifications de configuration SSH : modification des méthodes d’accès SSH (SSH désactivé, Entra ID ssh basé sur SSH ou utilisateur local) ou mise à jour des clés publiques SSH sur les pools de nœuds.
  • Modifications de restriction IMDS : activation ou désactivation de la restriction IMDS (Instance Metadata Service) pour bloquer l’accès des pods au point de terminaison IMDS.
  • Changements de profil de démarrage : modification du profil de démarrage, par exemple le basculement entre artifactSourceDirect et Cache, ou modification du containerRegistryId profil (le Azure Container Registry utilisé pour les clusters isolés réseau).
  • Modifications de type sortant : modification du type de connectivité sortante du cluster (loadBalancer, userDefinedRouting, managedNATGateway ou userAssignedNATGateway).

Opérations de mise à niveau non contrôlées par la stratégie d’interruption de nœud

La stratégie d’interruption de nœud ne contrôle pas les opérations de mise à niveau suivantes. Ces opérations de mise à niveau continuent indépendamment de votre paramètre de stratégie. Les mises à niveau sont initiées par le client ou initiées par AKS dans les fenêtres de maintenance planifiée. Pour permettre à ces opérations de continuer comme prévu, conservez-les intentionnellement hors de l’étendue de la stratégie d’interruption de nœud. Par ailleurs, si les opérations couvertes par la stratégie d’interruption de nœud sont incluses dans les mêmes modifications de configuration avec les mises à niveau, elles ne seront pas contrôlées par la stratégie d’interruption de nœud.

  • Mises à jour de la version d’image du nœud : mise à niveau vers une nouvelle version de l’image du système d’exploitation du nœud (manuellement ou via des canaux de mise à niveau automatiques). Cette opération est l’opération de réinitialisation la plus courante et inclut des correctifs de sécurité, des mises à jour du système d’exploitation et des versions d’images de nœud AKS.
  • Mises à niveau des versions de Kubernetes : mise à niveau de la version Kubernetes sur un pool de nœuds, qui applique de nouveaux fichiers binaires Kubernetes, une configuration kubelet mise à jour et des modifications au niveau du système d’exploitation.

Opérations de récupération non contrôlées par la stratégie d’interruption de nœud

La stratégie d’interruption de nœud ne contrôle pas les opérations de récupération automatisées suivantes. Ces opérations peuvent se produire indépendamment de votre paramètre de stratégie pour garantir l’intégrité et la récupération du cluster.

  • Restauration de la configuration du pool de nœuds : lorsqu’une opération de mise à jour de pool de nœuds échoue en raison de problèmes de configuration ou d’infrastructure non valides, AKS restaure automatiquement le dernier état correct connu et réimage les nœuds pour rétablir la configuration.
  • Opérations de restauration administrative du cluster : lorsque les ingénieurs du support Azure effectuent une restauration administrative du cluster lors de la résolution d’un incident, les nœuds sont réinitialisés avec une nouvelle image afin de garantir la cohérence entre l’état du plan de contrôle et la configuration des nœuds.
  • Mises à jour des informations d’identification des identités de nœud : AKS met régulièrement à jour les informations d’identification d’identité de nœud pour la sécurité et la conformité. Ces mises à jour initiées par le système déclenchent des réimages de nœud pour appliquer les nouvelles informations d’identification sur tous les pools de nœuds.

Intégration à la maintenance planifiée

La stratégie de perturbation des nœuds s’intègre de manière transparente aux fenêtres de maintenance planifiée d’AKS. Lorsque vous définissez la stratégie sur AllowDuringMaintenanceWindow, les opérations perturbantes s’alignent sur votre fenêtre de maintenance aksManagedNodeOSUpgradeSchedule, ce qui garantit que :

  • Les modifications se produisent uniquement pendant les fenêtres de temps approuvées.
  • Les opérations se coordonnent avec d’autres maintenances planifiées.
  • Les équipes sont conscientes du moment où des interruptions peuvent se produire.

Cette intégration offre une approche complète de la gestion des modifications de cluster et réduit l’impact sur les charges de travail en cours d’exécution.

Note

Lorsque vous utilisez AllowDuringMaintenanceWindow, vous devez configurer une fenêtre de maintenance aksManagedNodeOSUpgradeSchedule. L’utilisation de la default fenêtre de maintenance ou aksManagedAutoUpgradeSchedule (mise à niveau automatique du cluster) ne répond pas à cette exigence. Si vous définissez AllowDuringMaintenanceWindow sans qu’une fenêtre aksManagedNodeOSUpgradeSchedule soit configurée, toutes les opérations perturbatrices sont autorisées (la stratégie n’a aucune fenêtre sur laquelle s’appuyer). Pour plus d’informations sur la configuration des fenêtres de maintenance, consultez Utiliser la maintenance planifiée pour planifier et contrôler les mises à niveau de votre cluster Azure Kubernetes Service.

Bonnes pratiques

Tenez compte de ces recommandations lors de l’implémentation de la stratégie d’interruption de nœud :

  • Utilisez AllowDuringMaintenanceWindow en production : combinez avec des fenêtres de maintenance planifiées pour maîtriser le moment où des perturbations surviennent en environnement de production.
  • Défini Block pendant les périodes critiques : bloquez temporairement les opérations perturbatrices pendant les événements à trafic élevé, les lancements de produits ou la réponse aux incidents. N’utilisez Block pas indéfiniment. Bien que Block soit approprié pour les gels de courte durée (événements planifiés, réponse à incident).
  • Autoriser la flexibilité dans la non-production : utiliser Allow dans les environnements de développement et de test où l’itération rapide est plus importante que la stabilité.
  • Communiquer les modifications de stratégie : assurez-vous que votre équipe comprend la stratégie actuelle et sait quand les opérations peuvent être bloquées.
  • Planifier les fenêtres de maintenance de manière appropriée : dimensionner vos fenêtres de maintenance pour prendre en charge les opérations que vous devez effectuer.
  • Tester le comportement de la stratégie : validez les paramètres de la stratégie dans des environnements non productifs avant de les appliquer aux clusters de production.
  • Surveiller les opérations bloquées : suivez le moment où les opérations sont bloquées pour optimiser votre planification de maintenance.

Contenu connexe

  • Last updated on