Pools de nœuds à capacité statique en mode automatique EKS

Le mode automatique Amazon EKS prend en charge les pools de nœuds à capacité statique qui maintiennent un nombre fixe de nœuds, quelle que soit la demande de pods. Les pools de nœuds à capacité statique sont utiles pour les charges de travail qui nécessitent une capacité prévisible, des instances réservées ou des exigences de conformité spécifiques lorsque vous devez maintenir une empreinte d'infrastructure cohérente.

Contrairement aux pools de nœuds dynamiques qui évoluent en fonction des demandes de planification des pods, les pools de nœuds à capacité statique maintiennent le nombre de nœuds que vous avez configurés.

Exemple de base

Voici un pool de nœuds simple à capacité statique qui gère 5 nœuds :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: my-static-nodepool
spec:
  replicas: 5  # Maintain exactly 5 nodes

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m", "c"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b"]

  limits:
    nodes: 8

Configuration d'un pool de nœuds à capacité statique

Pour créer un pool de nœuds à capacité statique, définissez le replicas champ dans votre spécification. NodePool Le replicas champ définit le nombre exact de nœuds que le pool de nœuds conservera.

Contraintes liées au pool de nœuds à capacité statique

Les pools de nœuds à capacité statique présentent plusieurs contraintes et comportements importants :

Contraintes de configuration :

• Impossible de changer de mode : une fois que vous avez configuré replicas un pool de nœuds, vous ne pouvez pas le supprimer. Le pool de nœuds ne peut pas passer du mode statique au mode dynamique.

• Limites de ressources limitées : seul le limits.nodes champ est pris en charge dans la section des limites. Les limites de processeur et de mémoire ne sont pas applicables.

• Aucun champ de pondération : le weight champ ne peut pas être défini sur les pools de nœuds à capacité statique car la sélection des nœuds n'est pas basée sur la priorité.

Comportement opérationnel :

• Aucune consolidation : les nœuds des pools à capacité statique ne sont pas pris en compte pour la consolidation en fonction de leur utilisation.

• Opérations de dimensionnement : les opérations de dimensionnement évitent les budgets liés aux interruptions de service des nœuds tout en les respectant PodDisruptionBudgets.

• Remplacement des nœuds : les nœuds sont toujours remplacés pour cause de dérive (comme les mises à jour d'AMI) et d'expiration en fonction de votre configuration.

Dimensionner un pool de nœuds à capacité statique

Vous pouvez modifier le nombre de répliques dans un pool de nœuds à capacité statique à l'aide de la commande suivante : kubectl scale

# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5

Lors de la réduction de la taille, le mode automatique d'EKS met fin aux nœuds de manière harmonieuse, en respectant PodDisruptionBudgets et en autorisant la replanification des pods en cours d'exécution vers les nœuds restants.

Surveillez les pools de nœuds à capacité statique

Utilisez les commandes suivantes pour surveiller vos pools de nœuds à capacité statique :

# View node pool status
kubectl get nodepool static-nodepool

# Get detailed information including current node count
kubectl describe nodepool static-nodepool

# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'

Le status.nodes champ indique le nombre actuel de nœuds gérés par le pool de nœuds, qui devrait correspondre au replicas nombre souhaité dans des conditions normales.

Exemples de configuration

Pool de nœuds à capacité statique de base

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: basic-static
spec:
  replicas: 5

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a"]

  limits:
    nodes: 8  # Allow scaling up to 8 during operations

Capacité statique avec des types d'instances spécifiques

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: reserved-instances
spec:
  replicas: 20

  template:
    metadata:
      labels:
        instance-type: reserved
        cost-center: production
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.2xlarge"]  # Specific instance type
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b", "us-west-2c"]

  limits:
    nodes: 25

  disruption:
    # Conservative disruption for production workloads
    budgets:
      - nodes: 10%

Pool de nœuds à capacité statique multizone

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: multi-zone-static
spec:
  replicas: 12  # Will be distributed across specified zones

  template:
    metadata:
      labels:
        availability: high
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: In
          values: ["8", "16"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b", "us-west-2c"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]

  limits:
    nodes: 15

  disruption:
    budgets:
      - nodes: 25%

Bonnes pratiques

Planification des capacités :

• Définissez limits.nodes une valeur supérieure replicas à pour permettre une mise à l'échelle temporaire lors des opérations de remplacement de nœuds.

• Tenez compte de la capacité maximale requise lors de la dérive des nœuds ou des mises à jour de l'AMI lors de la définition des limites.

Sélection de l'instance :

• Utilisez des types d'instances spécifiques lorsque vous avez des instances réservées ou des exigences matérielles spécifiques.

• Évitez les exigences trop restrictives susceptibles de limiter la disponibilité des instances lors du dimensionnement.

Gestion des perturbations :

• Configurez les budgets d'interruption appropriés pour équilibrer la disponibilité avec les opérations de maintenance.

• Tenez compte de la tolérance de votre application en matière de remplacement de nœuds lors de la définition des pourcentages de budget.

Surveillance :

• Surveillez régulièrement le status.nodes terrain pour vous assurer que la capacité souhaitée est maintenue.

• Configurez des alertes lorsque le nombre réel de nœuds s'écarte des répliques souhaitées.

Répartition des zones :

• Pour une haute disponibilité, répartissez la capacité statique sur plusieurs zones de disponibilité.

• Lorsque vous créez un pool de nœuds à capacité statique qui couvre plusieurs zones de disponibilité, le mode automatique EKS distribue les nœuds dans les zones spécifiées, mais il n'est pas garanti que la distribution soit uniforme.

• Pour une distribution prévisible et uniforme entre les zones de disponibilité, créez des pools de nœuds distincts à capacité statique, chacun étant épinglé à une zone de disponibilité spécifique conformément aux exigences. topology.kubernetes.io/zone

• Si vous avez besoin de 12 nœuds répartis uniformément sur trois zones, créez trois pools de nœuds avec 4 répliques chacun, plutôt qu'un pool de nœuds avec 12 répliques sur trois zones.

Résolution des problèmes

Les nœuds n'atteignent pas les répliques souhaitées :

• Vérifiez si la limits.nodes valeur est suffisante

• Vérifiez que vos exigences ne limitent pas trop la sélection d'instances

• Vérifiez les quotas de AWS service pour les types d'instances et les régions que vous utilisez

Le remplacement du nœud prend trop de temps :

• Ajustez les budgets d'interruption pour permettre un plus grand nombre de remplacements simultanés

• Vérifiez si PodDisruptionBudgets vous empêchez la terminaison du nœud

Arrêt inattendu du nœud :

• Vérifiez les terminationGracePeriod paramètres expireAfter et

• Vérifiez la présence de terminaisons manuelles de nœuds ou AWS d'événements de maintenance