Partager via

Configurer des stratégies d’interruption de nœud pour les nœuds d’approvisionnement automatique de nœuds (NAP) dans Azure Kubernetes Service (AKS)

Cet article explique comment configurer des stratégies d'interruption de nœud pour les nœuds de l'auto-approvisionnement (NAP) dans Azure Kubernetes Service (AKS) et détaille le fonctionnement des interruptions pour optimiser l'utilisation des ressources et l'efficacité des coûts.

NAP optimise votre cluster en :

  • Suppression ou remplacement de nœuds sous-utilisés.
  • Consolidation des charges de travail pour réduire les coûts.
  • Respect des budgets d’interruption et des fenêtres de maintenance.
  • Fournir un contrôle manuel si nécessaire.

Avant de commencer

Comment fonctionne l’interruption de nœud pour les nœuds NAP ?

Karpenter définit un finaliseur Kubernetes sur chaque nœud et chaque demande de nœud qu'il provisionne. Le finaliseur bloque la suppression de l’objet de nœud, tandis que le contrôleur de terminaison teinte et draine le nœud avant de supprimer la revendication de nœud sous-jacente.

Lorsque les charges de travail sur vos nœuds sont réduites, NAP utilise des règles d’interruption sur la spécification du pool de nœuds pour décider quand et comment supprimer ces nœuds et éventuellement replanifier vos charges de travail pour une efficacité.

Méthodes d’interruption de nœud

NAP détecte automatiquement les nœuds éligibles pour une interruption et déploie des remplacements si nécessaire. Vous pouvez déclencher une interruption par le biais de méthodes automatisées telles que Expiration, Consolidation et Drift, des méthodes manuelles ou des systèmes externes.

Expiration

L’expiration vous permet de définir une durée de vie maximale pour vos nœuds NAP. Les nœuds sont marqués comme expirés et interrompus après avoir atteint l’âge que vous spécifiez pour la valeur du pool de nœuds spec.disruption.expireAfter.

Exemple de configuration d’expiration

L’exemple suivant montre comment définir l’heure d’expiration des nœuds NAP sur 24 heures :

spec:
  disruption:
    expireAfter: 24h  # Expire nodes after 24 hours

Consolidation

NAP permet de réduire activement le coût du cluster en identifiant quand les nœuds peuvent être supprimés, car ils sont vides ou sous-utilisés, ou lorsque les nœuds peuvent être remplacés par des variantes moins coûteuses. Ce processus est appelé Consolidation. NAP utilise principalement consolidation pour supprimer ou remplacer des nœuds pour un positionnement optimal des pods.

NAP effectue les types de consolidation suivants afin d’optimiser l’utilisation des ressources :

  • Consolidation des nœuds vides : supprime tous les nœuds vides en parallèle.
  • Consolidation à plusieurs nœuds : supprime plusieurs nœuds, ce qui peut lancer un seul remplacement.
  • Consolidation de nœud unique : supprime un nœud unique et peut éventuellement lancer un remplacement.

Vous pouvez déclencher la consolidation via le spec.disruption.consolidationPolicy champ dans la spécification du pool de nœuds à l’aide de WhenEmpty, ou WhenEmptyOrUnderUtilized paramètres. Vous pouvez également définir le consolidateAfter champ, qui est une condition basée sur le temps qui détermine le temps d’attente NAP après avoir découvert une opportunité de consolidation avant de perturber le nœud.

Exemple de configuration de consolidation

L’exemple suivant montre comment configurer NAP pour consolider les nœuds lorsqu’ils sont vides et attendre 30 secondes après avoir découvert une opportunité de consolidation avant de perturber le nœud :

  disruption:
    # Describes which types of nodes NAP should consider for consolidation
    # `WhenEmptyOrUnderUtilized`: NAP considers all nodes for consolidation and attempts to remove or replace nodes when it discovers that the node is empty or underutilized and could be changed to reduce cost
    # `WhenEmpty`: NAP only considers nodes for consolidation that don't contain any workload pods
    
    consolidationPolicy: WhenEmpty

    # The amount of time NAP should wait after discovering a consolidation decision
    # Currently, you can only set this value when the consolidation policy is `WhenEmpty`
    # You can choose to disable consolidation entirely by setting the string value `Never`
    consolidateAfter: 30s

Dérive

La dérive gère les modifications apportées aux ressources NodePool/AKSNodeClass. Les valeurs du fichier NodeClaimTemplateSpec/AKSNodeClassSpec sont reflétées de la même façon qu’elles sont définies. Un NodeClaim est détecté comme dérivé si les valeurs dans les NodePool/AKSNodeClass associés ne correspondent pas aux valeurs dans le NodeClaim. À l’instar de la relation en amont deployment.spec.template avec les pods, Karpenter annote l'objet associé àNodePool/AKSNodeClass avec un hachage du NodeClaimTemplateSpec pour vérifier les dérives. Karpenter supprime la condition d’état Drifted dans les scénarios suivants :

  • Le garde-fou de fonctionnalité Drift n'est pas activé, mais le NodeClaim est décalé.
  • Le NodeClaim n’est pas décalé, mais a un statut conditionné.

Karpenter ou l’interface du fournisseur cloud peut découvrir des cas spéciaux déclenchés par NodeClaim/Instance/NodePool/AKSNodeClassdes modifications.

Cas spéciaux sur la dérive

Dans des cas spéciaux, la dérive peut correspondre à plusieurs valeurs et doit être gérée différemment. La dérive sur les champs résolus peut créer des cas où la dérive se produit sans modification des définitions de ressources personnalisées (CRD) ou où les modifications CRD ne entraînent pas de dérive.

Par exemple, si un NodeClaim élément a node.kubernetes.io/instance-type: Standard_D2s_v3et que les exigences sont passées node.kubernetes.io/instance-type In [Standard_D2s_v3] à node.kubernetes.io/instance-type In [Standard_D2s_v3, Standard_D4s_v3], l’élément NodeClaim n’est pas dérivé, car sa valeur est toujours compatible avec les nouvelles exigences. À l'inverse, si un NodeClaim utilise un NodeClaimimageFamily, mais que le champ spec.imageFamily change, Karpenter détecte le NodeClaim comme étant en dérive et remplace le nœud pour se conformer à cette spécification.

Important

Karpenter surveille les modifications de configuration des sous-réseaux et détecte un écart lorsqu’un vnetSubnetID dans un AKSNodeClass est modifié. Comprendre ce comportement est essentiel lors de la gestion des configurations réseau personnalisées. Pour plus d’informations, consultez le comportement de dérive de sous-réseau.

Pour plus d’informations, consultez Drift Design.

Période de grâce pour résiliation

Vous pouvez définir une période de grâce d’arrêt pour les nœuds NAP à l’aide du spec.template.spec.terminationGracePeriod champ dans la spécification du pool de nœuds. Ce paramètre vous permet de configurer la durée pendant laquelle Karpenter attend que les pods se terminent en douceur. Ce paramètre est prioritaire sur les pods terminationGracePeriodSeconds et contourne PodDisruptionBudgets et l’annotation karpenter.sh/do-not-disrupt.

Exemple de configuration de la période de grâce de terminaison

L’exemple suivant montre comment définir une période de grâce d’arrêt de 30 secondes pour les nœuds NAP :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      terminationGracePeriod: 30s

Budgets de disruption

Vous pouvez limiter la perturbation de Karpenter en modifiant le spec.disruption.budgets champ dans la spécification du pool de nœuds. Si vous laissez ce paramètre indéfini, Karpenter utilise par défaut un seul budget avec nodes: 10%. Les budgets tiennent compte des nœuds qui sont supprimés quelle que soit la raison, et ils bloquent uniquement Karpenter contre les interruptions volontaires liées à l’expiration, la dérive, l'inactivité et la consolidation.

Lors du calcul de la possibilité qu'un budget bloque les nœuds face à des interruptions, Karpenter compte le nombre total de nœuds appartenant à un pool de nœuds, puis soustrait les nœuds qui sont supprimés ainsi que ceux qui sont NotReady. Si le budget est configuré avec une valeur de pourcentage, par 20%exemple, Karpenter calcule le nombre d’interruptions autorisées en tant que allowed_disruptions = roundup(total * percentage) - total_deleting - total_notready. Pour plusieurs budgets dans un pool de nœuds, Karpenter prend la valeur minimale (la plus restrictive) de chacun des budgets.

Champs de planification et de durée

Lorsque vous utilisez des budgets, vous pouvez éventuellement définir les champs schedule et duration pour créer des budgets basés sur le temps. Ces champs vous permettent de définir des fenêtres de maintenance ou des délais spécifiques lorsque les limites d’interruption sont plus strictes.

  • Schedule utilise la syntaxe de cron job avec des macros spéciales telles que @yearly, @monthly, @weekly, @daily, @hourly.
  • La durée autorise les durées composées telles que 10h5m, 30mou 160h. La durée et la planification doivent être définies ensemble.

Exemples de planification et de durée

Budget pour la période de maintenance

Empêcher les interruptions pendant les heures d’ouverture :

budgets:
- nodes: "0"
  schedule: "0 9 * * 1-5"  # 9 AM Monday-Friday
  duration: 8h             # For 8 hours
Interruptions de fin de semaine uniquement

Autorisez uniquement les perturbations le week-end :

budgets:
- nodes: "50%"
  schedule: "0 0 * * 6"    # Saturday midnight
  duration: 48h            # All weekend
- nodes: "0"               # Block all other times
Budget de déploiement progressif

Autoriser l’augmentation des taux d’interruption :

budgets:
- nodes: "1"
  schedule: "0 2 * * *"    # 2 AM daily
  duration: 2h
- nodes: "3"
  schedule: "0 4 * * *"    # 4 AM daily
  duration: 4h

Exemples de configuration budgétaire

La spécification suivante NodePool comporte trois budgets configurés :

  • Le premier budget permet à 20% de nœuds appartenant au pool de nœuds d’être interrompus à la fois.
  • Le deuxième budget agit comme un plafond, ce qui permet seulement cinq interruptions lorsqu’il y a plus de 25 nœuds.
  • Le dernier budget bloque les perturbations au cours des 10 premières minutes de chaque jour.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    expireAfter: 720h # 30 * 24h = 720h
    budgets:
    - nodes: "20%"      # Allow 20% of nodes to be disrupted
    - nodes: "5"        # Cap at maximum 5 nodes
    - nodes: "0"        # Block all disruptions during maintenance window
      schedule: "@daily" # Scheduled daily
      duration: 10m # Duration of 10 minutes

Interruption manuelle des nœuds

Vous pouvez perturber manuellement les nœuds NAP à l’aide kubectl ou en supprimant des NodePool ressources.

Supprimer des nœuds avec kubectl

Vous pouvez supprimer manuellement des nœuds à l’aide de la kubectl delete node commande. Vous pouvez supprimer des nœuds spécifiques, tous les nœuds gérés par NAP ou des nœuds d’un pool de nœuds spécifique à l’aide d’étiquettes, par exemple :

# Delete a specific node
kubectl delete node $NODE_NAME

# Delete all NAP-managed nodes
kubectl delete nodes -l karpenter.sh/nodepool

# Delete nodes from a specific nodepool
kubectl delete nodes -l karpenter.sh/nodepool=$NODEPOOL_NAME

Supprimer des NodePool ressources

NodePool possède NodeClaims par le biais d'une référence de propriétaire. NAP met fin en douceur aux nœuds via une suppression en cascade lorsque vous supprimez l'objet correspondant NodePool.

Contrôler l’interruption à l’aide d’annotations

Vous pouvez bloquer ou désactiver les perturbations pour les pods, les nœuds ou les pools de nœuds entiers à l’aide d’annotations.

Contrôles de pod

Empêcher nap de perturber certains pods en définissant l’annotation karpenter.sh/do-not-disrupt: "true" :

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:
      annotations:
        karpenter.sh/do-not-disrupt: "true"

Cette annotation empêche l’interruption volontaire de l’expiration, de la consolidation et de la dérive. Toutefois, elle n’empêche pas les interruptions des systèmes externes ou des interruptions manuelles par le biais de la suppression kubectl ou NodePool.

Contrôles de nœud

Empêcher NAP de perturber les nœuds spécifiques :

apiVersion: v1
kind: Node
metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

Contrôles du pool de nœuds

Désactiver l’interruption pour tous les nœuds d’un NodePool:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    metadata:
      annotations:
        karpenter.sh/do-not-disrupt: "true"

Étapes suivantes

Pour plus d’informations sur le provisionnement automatique de nœuds dans AKS, consultez les articles suivants :

  • Last updated on