Renforcement des nœuds (préversion) dans Azure Kubernetes Service (AKS)

Le renforcement des nœuds est une fonctionnalité d’opt-in pour les pools de nœuds Linux qui protège la stabilité des nœuds lorsque les charges de travail placent les nœuds sous la pression du processeur, de la mémoire ou du disque. Lorsque vous activez le renforcement des nœuds sur un cluster, AKS modifie la façon dont chaque nœud réserve et applique des ressources pour les composants Kubernetes et les services hôtes, ainsi que la façon dont le kubelet expulse les pods lorsque les ressources viennent à manquer.

Cet article explique les modifications de renforcement des nœuds, compare les valeurs par défaut renforcées aux valeurs par défaut AKS standard et vous montre comment activer, vérifier, personnaliser et désactiver la fonctionnalité.

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 :

Avantages du durcissement de nœud

Sur les nœuds occupés ou soumis à des pointes de charge, les charges de travail peuvent consommer des ressources dont le kubelet, le runtime de conteneur et les services hôtes ont besoin. Lorsque cela se produit, les nœuds peuvent ne pas répondre, signaler un état NotReady ou mettre fin brusquement aux pods. Le renforcement des nœuds réduit ces risques de la manière suivante :

  • Réservations appliquées : Par défaut, AKS utilise des valeurs réservées kube uniquement pour calculer la capacité que le planificateur peut allouer aux pods. En utilisant le durcissement de nœud, le kubelet applique également la capacité de réserve kube et système via des groupes de contrôle Linux (cgroups). Le kubelet et containerd s’exécutent dans un cgroup kubereserved.slice dédié, de sorte qu’ils conservent leur partage d’UC et leur mémoire réservés même quand les pods saturent le nœud.
  • Capacité dédiée pour les services hôtes : le durcissement de nœud ajoute une allocation réservée par le système pour les services du système d’exploitation hôte, qui s’exécutent dans system.slice.
  • Plus de marge mémoire : Le seuil strict d’éviction pour la mémoire disponible évolue en fonction de la mémoire du nœud, de sorte que le kubelet évince les pods avant que le nœud ne manque cruellement de mémoire.
  • Éviction en douceur : Les seuils d’éviction souple permettent au kubelet d’évincer les pods en douceur, avec un délai de grâce avant arrêt, lorsque la mémoire ou l’espace disque viennent à manquer. L’éviction forcée, qui met immédiatement fin aux pods, agit alors comme un dernier recours.
  • Réservations qui évoluent avec la densité de pods : Le calcul de la mémoire réservée kube augmente avec le nombre maximal de pods par nœud, ce qui tient compte de la surcharge de kubelet et de containerd liée à l’exécution d’un plus grand nombre de pods.

Ce qui change lorsque vous activez le durcissement de nœud

Les tableaux suivants comparent les valeurs par défaut standard pour les nœuds Linux exécutant Kubernetes 1.29 ou version ultérieure avec les valeurs par défaut qu’AKS applique lorsque le renforcement des nœuds est activé.

Réservations de ressources

Setting Sans durcissement de Node Avec le durcissement de nœud
CPU réservé à Kube En fonction du nombre de cœurs de CPU. Pour plus d’informations, consultez réservations d’UC. Inchangé
Mémoire réservée à Kube min(20 × maxPods + 50, 25% of node memory) MiB min(35 × maxPods + max(250, 2% of node memory), 25% of node memory) MiB
ID de processus (PID) réservés à Kube 1000 Non réservé
CPU réservé par le système None 100m
Mémoire réservée par le système None 200 Mio, plus 100 Mio pour chaque tranche complète de 32 Gio de mémoire du nœud, plus 100 Mio pour les clusters qui utilisent Azure CNI
Stockage éphémère réservé par le système None 1Gi

Seuils d’éviction

Setting Sans durcissement de nœud Avec le durcissement de nœud
Éviction forcée : memory.available 100Mi 250Mi pour les nœuds avec 8 Gio de mémoire ou moins, 375Mi pour les nœuds avec plus de 8 Gio et moins de 32 Gio, et 512Mi pour les nœuds avec 32 Gio ou plus
Éviction forcée : nodefs.available et nodefs.inodesFree 10% et 5% Inchangé
Éviction forcée : pid.available 2000 Non défini
Éviction réversible : memory.available None 500Mi, 750Mi, ou 1Gi, en utilisant les mêmes niveaux de mémoire de nœud que l’éviction forcée, avec une période de grâce de 30 secondes
Éviction douce : nodefs.available et nodefs.inodesFree None 12% et 7%, chacun avec une période de grâce de 2 minutes
Période de grâce maximale de terminaison de pod pendant l’éviction douce Non défini 60 secondes

Application cgroup

Setting Sans durcissement de nœud Avec le durcissement de nœud
Allouable de nœud imposé pods pods, kube-reserved et system-reserved
Kubelet et cgroup containerd system.slice, sans limites kubereserved.slice, avec la mémoire limitée à la mémoire réservée kube et un partage de processeur proportionnel au processeur réservé kube
Cgroup des services hôtes system.slice, sans limites system.slice, avec la mémoire limitée à la mémoire réservée par le système et une part de processeur proportionnelle au processeur réservé par le système

Étant donné que le renforcement des nœuds réserve davantage de capacité, les nœuds signalent moins de capacité allouable pour les pods. Par exemple, sur un nœud avec 4 processeurs virtuels et 16 Gio de mémoire qui utilise Azure CNI, l’activation du renforcement des nœuds réduit la capacité allouable comme suit :

  • Avec le maximum par défaut de 250 pods par nœud, cela représente environ 570 Mio de mémoire, 100 millicores de processeur et 1 Gio de stockage éphémère.
  • Avec un maximum de 30 pods par nœud, le système est limité par environ 1,3 Gio de mémoire, 100 millicores de processeur et 1 Gio de stockage éphémère.

Les seuils d’éviction réversible ne réduisent pas la capacité allouable. Ils changent uniquement lorsque le kubelet commence à expulser les pods.

Considerations

Gardez à l’esprit les considérations suivantes avant d’activer le renforcement des nœuds :

  • Vous activez le durcissement de nœud au niveau du cluster, et cela s’applique à tous les pools de nœuds Linux du cluster. Vous ne pouvez pas l'activer pour des pools de nœuds individuels, et cela n'affecte pas les pools de nœuds Windows.
  • Les nœuds signalent moins de capacité allocatable, de sorte que les pods qui tiennent sur un nœud avant d’activer le renforcement des nœuds pourraient ne plus tenir ensuite. Passez en revue les demandes de ressources de pod et les tailles de pool de nœuds.
  • Les services hôtes dans system.slice partagent une limite stricte de mémoire égale à la mémoire réservée par le système. Si vous exécutez vos propres agents sur des nœuds en tant que services systemd, tels que des agents de sécurité, de surveillance ou de transfert de journaux, ces agents sont comptabilisés par rapport à cette limite. Validez leur utilisation de la mémoire et leur stabilité avant d’utiliser Node Hardening en production.
  • Les valeurs que vous définissez dans la configuration kubelet personnalisée d’un pool de nœuds remplacent les valeurs par défaut correspondantes de Node Hardening. Pour plus d’informations, consultez Personnaliser les paramètres de renforcement des nœuds.
  • Si vous désactivez le renforcement des nœuds ultérieurement, les pools de nœuds existants conservent les paramètres d’éviction douce renforcés, même après la réinitialisation de leurs nœuds. Pour supprimer ces paramètres, vous devez créer de nouveaux pools de nœuds. Pour plus d’informations, consultez Désactivation du durcissement de nœud.
  • Les valeurs par défaut peuvent changer pendant que la fonctionnalité est en préversion. Commencez par un cluster non productif et validez vos charges de travail dans des conditions représentatives de pression sur les nœuds.

Prerequisites

  • Un abonnement Azure. Si vous n’en avez pas, créez un compte gratuit.
  • Un cluster AKS avec des pools de nœuds Linux ou des autorisations pour en créer un.
  • Extension aks-preview Azure CLI et indicateur CustomNodeConfigPreview de fonctionnalité, comme décrit dans les sections suivantes.

Installer l’extension aks-preview Azure CLI

  1. Installez l'extension aks-preview en utilisant la commande az extension add.

    az extension add --name aks-preview

  2. Effectuez une mise à jour vers la dernière version de l’extension à l’aide de la az extension update commande.

    az extension update --name aks-preview

Inscrire l’indicateur de fonctionnalité CustomNodeConfigPreview

  1. Enregistrez l’indicateur de fonctionnalité CustomNodeConfigPreview à l’aide de la commande az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"

    Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

  2. Vérifiez l’état de l’inscription à l’aide de la az feature show commande.

    az feature show --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"

  3. Lorsque l’état indique Enregistré, actualisez l’enregistrement du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register.

    az provider register --namespace "Microsoft.ContainerService"

Activer le renforcement des nœuds

En version préliminaire, le durcissement de nœud n’est pas activé par défaut.

Activer le renforcement des nœuds sur un nouveau cluster

Créez un cluster avec le renforcement des nœuds activé à l’aide de la az aks create commande avec le --enable-node-hardening paramètre.

Cette commande nécessite l’extension aks-preview et l’indicateur de fonctionnalité CustomNodeConfigPreview. Si vous souhaitez en savoir plus, consultez la pageConditions préalables.

az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-node-hardening \
    --generate-ssh-keys

Pour confirmer la modification, consultez Vérifier les paramètres de renforcement des nœuds.

Activer le renforcement des nœuds sur un cluster existant

Activez le renforcement des nœuds sur un cluster existant à l’aide de la az aks update commande avec le --enable-node-hardening paramètre.

Cette commande nécessite l’extension aks-preview et l’indicateur de fonctionnalité CustomNodeConfigPreview. Si vous souhaitez en savoir plus, consultez la pageConditions préalables.

az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-node-hardening

Pour confirmer la modification, consultez Vérifier les paramètres de renforcement des nœuds.

Vérifier les paramètres de durcissement des nœuds

  1. Obtenez les informations d’identification de votre cluster à l’aide de la az aks get-credentials commande.

    az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>

  2. Passez en revue les paramètres de réservation et d’éviction kubelet effectifs sur un nœud en interrogeant le point de terminaison de configuration kubelet.

    kubectl get --raw "/api/v1/nodes/<node-name>/proxy/configz" | jq '.kubeletconfig | {kubeReserved, systemReserved, evictionHard, evictionSoft, evictionSoftGracePeriod, evictionMaxPodGracePeriod, enforceNodeAllocatable}'

    Sur un nœud durci, systemReserved et evictionSoft contiennent des valeurs, et enforceNodeAllocatable inclut kube-reserved et system-reserved.

  3. Comparez la capacité du nœud à ses ressources allouables.

    kubectl get node <node-name> -o jsonpath='{.status.capacity}{"\n"}{.status.allocatable}{"\n"}'

    Sur un nœud durci, le CPU allouable, la mémoire et le stockage éphémère sont inférieurs à la capacité totale. La différence est égale aux valeurs réservées à kube et réservées au système dans les réservations de ressources, plus les seuils d’éviction stricte dans les seuils d’éviction. Par exemple, sur un nœud avec 4 processeurs virtuels et 16 Gio de mémoire qui utilise Azure CNI, le processeur allouable est inférieur de 240 millicores à la capacité : 140 millicores de processeur réservé kube et 100 millicores de processeur réservé système.

Personnaliser les paramètres de renforcement des nœuds

Vous pouvez remplacer les valeurs par défaut de kube-reserved et d’éviction pour un pool de nœuds Linux à l’aide d’une configuration kubelet personnalisée. Ces paramètres nécessitent le feature flag CustomNodeConfigPreview. Vous pouvez les utiliser que Node Hardening soit activé ou non sur le cluster. AKS gère les valeurs réservées système et l’application des cgroups, et vous ne pouvez pas les personnaliser.

Chaque paramètre remplace une ligne dans les tables Réservations de ressources ou Seuils d’éviction. Les lignes réservées kube correspondent aux kubeReserved paramètres. Les lignes d’éviction stricte correspondent aux paramètres hardEvictionThreshold. Les lignes d’éviction réversible correspondent aux paramètres softEvictionThreshold et softEvictionGracePeriod. La période de grâce maximale de terminaison de pod correspond à evictionMaxPodGracePeriodInSeconds.

Vous pouvez configurer les paramètres suivants :

Setting Overrides Description
kubeReserved.cpuMillicores CPU réservé à Kube CPU réservé aux démons système Kubernetes, en millicores.
kubeReserved.memoryMB Mémoire réservée à Kube Mémoire réservée aux démons système Kubernetes, en MiB.
hardEvictionThreshold.memoryAvailable Éviction forcée : memory.available Seuil d’éviction strict pour la mémoire disponible.
hardEvictionThreshold.nodeFsAvailable Éviction réversible : nodefs.available Seuil d’éviction en dur pour l’espace du système de fichiers de nœud disponible.
hardEvictionThreshold.nodeFsInodesFree Éviction forcée : nodefs.inodesFree Seuil d’éviction stricte pour les inodes libres du système de fichiers du nœud.
softEvictionThreshold.memoryAvailable Éviction réversible : memory.available Seuil d’éviction souple pour la mémoire disponible.
softEvictionThreshold.nodeFsAvailable Éviction réversible : nodefs.available Seuil d’éviction souple pour l’espace du système de fichiers de nœud disponible.
softEvictionThreshold.nodeFsInodesFree Éviction réversible : nodefs.inodesFree Seuil d’éviction réversible pour les inodes libres du système de fichiers du nœud.
softEvictionGracePeriod.memoryAvailable Éviction réversible : période de grâce memory.available Durée pendant laquelle la mémoire disponible doit rester inférieure à son seuil souple avant que le kubelet évince les pods.
softEvictionGracePeriod.nodeFsAvailable Éviction réversible : période de grâce nodefs.available Combien de temps l’espace du système de fichiers de nœud disponible doit rester au-dessous de son seuil souple avant que le kubelet n’évince des pods.
softEvictionGracePeriod.nodeFsInodesFree Éviction réversible : période de grâce nodefs.inodesFree Combien de temps les inodes libres du système de fichiers du nœud doivent rester au-dessous de leur seuil souple avant que le kubelet n’évince les pods.
evictionMaxPodGracePeriodInSeconds Période de grâce maximale de terminaison de pod pendant l’éviction douce Nombre maximal de secondes accordées par le kubelet aux pods pour se terminer pendant une éviction réversible.
  • Pour connaître les valeurs autorisées, les valeurs minimales et les règles de validation pour chaque paramètre, consultez les paramètres de configuration de nœud personnalisés pour AKS.
  • Pour chaque signal d’éviction, définissez à la fois le seuil d’éviction soft et sa période de grâce correspondante, et assurez-vous que chaque seuil d’éviction soft est supérieur au seuil d’éviction hard pour le même signal.

  1. Créez un fichier de configuration kubelet, par exemple nodehardening-kubelet.json, avec les paramètres que vous souhaitez personnaliser. L’exemple suivant définit chaque valeur configurable. Il définit kube-reserved sur 200 millicores de processeur et 1 024 Mio de mémoire. Il définit les seuils d’éviction en dur à 512Mi de la mémoire disponible, 10% de l’espace du système de fichiers disponible et 5% des inodes libres. Il définit des seuils d’éviction souple de 12%, 7% et 1Gi avec des périodes de grâce de 30 secondes, 2 minutes et 2 minutes. Il définit également une période de grâce de terminaison de pod maximale de 60 secondes.

    {
  "kubeReserved": {
    "cpuMillicores": 200,
    "memoryMB": 1024
  },
  "hardEvictionThreshold": {
    "memoryAvailable": "512Mi",
    "nodeFsAvailable": "10%",
    "nodeFsInodesFree": "5%"
  },
  "softEvictionThreshold": {
    "memoryAvailable": "1Gi",
    "nodeFsAvailable": "12%",
    "nodeFsInodesFree": "7%"
  },
  "softEvictionGracePeriod": {
    "memoryAvailable": "30s",
    "nodeFsAvailable": "2m",
    "nodeFsInodesFree": "2m"
  },
  "evictionMaxPodGracePeriodInSeconds": 60
}

  2. Créez un pool de nœuds Linux qui utilise le fichier de configuration à l’aide de la az aks nodepool add commande avec le --kubelet-config paramètre.

    az aks nodepool add \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --kubelet-config ./nodehardening-kubelet.json

    Vous pouvez également utiliser le --kubelet-config paramètre avec la az aks create commande pour appliquer la configuration au pool de nœuds initial du cluster.

Désactiver le renforcement des nœuds

Désactivez le renforcement des nœuds à l’aide de la commande az aks update avec le paramètre --disable-node-hardening.

Cette commande nécessite l’extension aks-preview et l’indicateur de fonctionnalité CustomNodeConfigPreview. Si vous souhaitez en savoir plus, consultez la pageConditions préalables.

az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --disable-node-hardening

La désactivation du renforcement des nœuds désactive le paramètre au niveau du cluster, mais elle ne modifie pas immédiatement les nœuds existants. Les nœuds existants conservent tous les paramètres durcis jusqu’à ce qu’ils soient réinitialisés, par exemple lors d’une mise à niveau de l’image du nœud. Une fois qu’un nœud est réinitialisé à partir d’une image, les modifications suivantes s’appliquent :

  • Rétabli aux valeurs par défaut standard d’AKS : ressources réservées à Kube et au système, seuils d’éviction stricte et mise en œuvre de cgroup. La capacité allouable du nœud augmente en conséquence.
  • Conservé : les seuils d’éviction réversible, les périodes de grâce d’éviction réversible et la période de grâce maximale de terminaison de pod pendant l’éviction réversible.

Vous pouvez définir une configuration kubelet personnalisée uniquement lorsque vous créez un cluster ou un pool de nœuds. Vous ne pouvez donc pas supprimer les paramètres d’éviction logicielle conservés d’un pool de nœuds existant. Pour les supprimer, créez un pool de nœuds qui les supprime explicitement, déplacez vos charges de travail vers le nouveau pool de nœuds, puis supprimez l’ancien pool de nœuds.

  1. Créez un fichier de configuration kubelet, tel que remove-soft-eviction.json. L’exemple suivant attribue une chaîne vide à chaque seuil d’éviction soft et à chaque période de grâce, ce qui désactive l’éviction soft pour ce signal. Il définit également la période de grâce maximale avant la terminaison du pod à 0, qui est la valeur par défaut standard d’AKS.

    {
  "softEvictionThreshold": {
    "memoryAvailable": "",
    "nodeFsAvailable": "",
    "nodeFsInodesFree": ""
  },
  "softEvictionGracePeriod": {
    "memoryAvailable": "",
    "nodeFsAvailable": "",
    "nodeFsInodesFree": ""
  },
  "evictionMaxPodGracePeriodInSeconds": 0
}

  2. Créez un pool de nœuds Linux qui utilise le fichier de configuration à l’aide de la commande az aks nodepool add avec le paramètre --kubelet-config.

    az aks nodepool add \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --kubelet-config ./remove-soft-eviction.json

  3. Déplacez vos charges de travail vers le nouveau pool de nœuds, puis supprimez l’ancien pool de nœuds. Pour plus d’informations, consultez Redimensionner les pools de nœuds dans AKS.

Pour confirmer les paramètres d’un nœud, consultez Vérifier les paramètres de renforcement du nœud. Sur les nœuds du nouveau pool de nœuds, evictionSoft est vide.

Contenu connexe

  • Dernière mise à jour :