Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Optimisation des coûts en mode automatique EKS

Le mode automatique d'EKS optimise en permanence les coûts de calcul de votre cluster grâce à la consolidation, au regroupement et au dimensionnement correct. Toutefois, certaines configurations de charge de travail peuvent empêcher ces optimisations. Cette rubrique explique comment fonctionne l'optimisation des coûts, ce qui peut la bloquer et comment configurer votre cluster pour maintenir la rentabilité.

Comment le mode automatique d'EKS optimise les coûts

Le mode automatique EKS réduit les coûts de calcul grâce aux mécanismes suivants :

Ces optimisations s'exécutent en continu sans intervention manuelle. Cependant, certaines annotations et NodePool configurations des pods peuvent empêcher la consolidation de prendre effet.

Built-in pools de nœuds et garde-fous en matière de coûts

Les pools intégrés general-purpose et de system nœuds appliquent déjà plusieurs paramètres par défaut de protection des coûts :

Si vous utilisez uniquement les pools de nœuds intégrés, vous bénéficiez déjà de ces garde-fous. Les conseils de cette rubrique sur l'exclusion des familles d'instances et la limitation de la taille des instances sont particulièrement pertinents lorsque vous créez des éléments personnalisés NodePools, qui n'héritent pas de ces restrictions.

Toutefois, même avec les pools de nœuds intégrés, les sections suivantes s'appliquent toujours à vous :

Quels sont les obstacles à la consolidation

La consolidation est bloquée lorsque le mode automatique d'EKS détermine que la perturbation d'un nœud violerait les exigences de disponibilité d'une charge de travail. Les configurations suivantes empêchent la consolidation :

L'annotation « ne pas perturber »

L'karpenter.sh/do-not-disruptannotation indique au mode automatique EKS de conserver un nœud tant que le module annoté est exécuté dessus. Cela empêche le nœud d'être consolidé, remplacé ou résilié, même s'il est sous-utilisé.

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

Solutions de rechange à envisager :

Budgets relatifs aux perturbations des pods (PDB)

Les PDB dont le nombre de répliques est défini maxUnavailable: 0 ou minAvailable égal au nombre actuel de répliques bloquent efficacement toute consolidation pour les pods concernés. Passez en revue vos PDB pour vous assurer qu'ils permettent d'interrompre au moins un module à la fois.

Utiliser NodePool les limites comme plafond de coûts

NodePool limitsfixer un plafond strict pour le total des ressources de calcul qu'un NodePool fournisseur peut fournir. Lorsque la limite est atteinte, le mode automatique EKS arrête de lancer de nouveaux nœuds pour cela NodePool. Cela se produit même si les pods sont en attente.

À utiliser limits comme mesure de réduction des coûts, en particulier pour les NodePools charges de travail hors production, de test ou surchargées pour lesquelles une mise à l'échelle illimitée n'est pas appropriée.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
  limits:
    cpu: "500"
    memory: 1000Gi

Dans cet exemple, il ci-runners NodePool ne peut pas dépasser 500 vCPU ou 1 000 GiB de mémoire au total sur tous les nœuds qu'il provisionne. Les pods qui dépassent cette limite restent en Pending état jusqu'à ce que leur capacité soit libérée.

Exclure les familles d'instances pour contrôler les coûts

Par défaut, le mode automatique d'EKS sélectionne parmi un large éventail de types d'instances afin d'optimiser la flexibilité de planification. Pour les charges de travail qui ne nécessitent pas de matériel spécialisé, limitez les familles d'instances afin d'éviter le lancement de types d'instances coûteux.

Exclure les instances accélérées

Si vos charges de travail ne demandent pas de ressources de GPU ou d'accélérateur, excluez les familles d'instances accélérées de votre NodePool. Cela permet d'éviter les scénarios dans lesquels des instances accélérées sont sélectionnées en cas de contraintes de capacité.

spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]

En spécifiant uniquement des catégories optimisées pour le calcul, pour usage général et pour la mémoire, vous excluez de la sélection les familles d'instances accélérées (P, G, Inf, Trn) et les autres familles d'instances spécialisées.

Comment la sélection d'instances interagit avec les contraintes de capacité

Le mode automatique d'EKS ne donne plus la priorité aux types d'instances accélérés et exotiques lors de la sélection normale des instances. Toutefois, en cas d'échec prolongé du lancement, le mode automatique d'EKS se lance à partir de n'importe quel type d'instance encore disponible afin de prioriser la disponibilité de la charge de travail. Cela se produit par exemple lorsque les quotas de service EC2 sont temporairement épuisés pour tous les types d'instances préférés.

Pour éviter ce comportement de repli, limitez explicitement vos NodePool exigences aux seules catégories d'instances dont votre charge de travail a besoin. Lorsque les types préférés ne sont pas disponibles et qu'aucun autre type n'est autorisé par votre NodePool configuration, les pods restent en Pending état au lieu d'être programmés sur des instances coûteuses.

Limiter la taille des instances

Outre la restriction des familles d'instances, vous pouvez limiter la taille maximale des instances au sein de votre NodePool. La limitation de la taille des instances limite l'exposition aux coûts liés à tout nœud qui ne peut pas être consolidé. Par exemple, un nœud bloqué par une do-not-disrupt annotation ne peut pas être réduit même si sa charge de travail est faible.

Utilisez l'eks.amazonaws.com/instance-cpuétiquette pour limiter la taille maximale des instances selon vos NodePool besoins :

requirements:
  - key: "eks.amazonaws.com/instance-cpu"
    operator: Lte
    values: ["32"]

Cette configuration empêche le mode automatique d'EKS de lancer des instances de plus de 32 vCPU dans ce mode. NodePool

Pour identifier les opportunités d'optimisation dans un cluster existant, passez en revue vos plus grandes instances en cours d'exécution. Si la consolidation des nœuds de grande taille est systématiquement bloquée, le coût par nœud de cette capacité inutilisée est proportionnellement plus élevé.

Modèles recommandés pour les charges de travail excessives

CI/CD les pipelines, les tâches par lots et les circuits de distribution éphémères créent des cycles d'inactivité qui nécessitent une configuration spécifique pour maintenir la rentabilité.

Valeurs par défaut recommandées pour les charges de travail surchargées

Exemple : CI Runner NodePool

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    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: Lte
          values: ["32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: "500"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Cette configuration :

Cycle de vie et coût des nœuds

Le mode automatique EKS remplace les nœuds par interruption progressive lorsqu'ils s'écartent de leurs spécifications souhaitées (par exemple, après la publication d'une nouvelle AMI en mode automatique) ou lorsque la durée de vie du nœud approche de l'expiration. Lors d'un remplacement gracieux :

Pour les clusters comportant de grands ou de nombreux nœuds, ce chevauchement peut entraîner des augmentations de coûts périodiques. Pour minimiser l'impact :

Pour plus d'informations sur le cycle de vie des nœuds, consultez En savoir plus sur les instances gérées en mode automatique Amazon EKS.