Optimiser Karpenter : efficacité maximale, coûts maîtrisés

Karpenter est l'autoscaler Kubernetes-native conçu pour gérer l'efficacité des ressources k8s. Il provisionne dynamiquement des nœuds en réponse aux workloads en attente, garantissant que les applications disposent des ressources nécessaires précisément au moment voulu. Cette approche vise à améliorer l'efficacité opérationnelle et à réduire les dépenses cloud.

Cependant, concilier efficacité et maîtrise des coûts avec Karpenter n'a rien d'évident. Si Karpenter offre des capacités puissantes, ses paramètres par défaut et certaines bonnes pratiques recommandées peuvent involontairement entraîner des coûts plus élevés, même s'ils améliorent les performances. Il est donc essentiel de ne pas se contenter de suivre les recommandations générales, mais de les adapter aux besoins spécifiques de vos workloads et à vos contraintes budgétaires.

Dans cet article, nous aborderons Karpenter, son architecture, les bonnes pratiques en matière de coûts et d'efficacité, puis nous partagerons notre expérience montrant que les bonnes pratiques doivent être adaptées à votre environnement.

Bonnes pratiques pour optimiser Karpenter

Passons en revue les bonnes pratiques pour optimiser Karpenter :

1. Configurer l'expiration des nœuds : définissez le paramètre expireAfter pour garantir le remplacement périodique des nœuds, en intégrant ainsi les derniers correctifs de sécurité et améliorations de performances. Cette approche proactive réduit le risque de drift à long terme et de vulnérabilités potentielles. Il est essentiel de définir une durée d'expiration adaptée à votre type de workload, afin de concilier sécurité et maîtrise des coûts.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: nodepool
spec:
  template:
    spec:
      expireAfter: 168h # 7 days

2. Définir le délai de grâce avant terminaison : le paramètre terminationGracePeriod définit la durée maximale pendant laquelle Karpenter attend le drain d'un nœud avant de l'arrêter de force. Un délai de grâce bien configuré offre un équilibre entre laisser aux pods le temps de s'arrêter proprement et recycler les nœuds rapidement pour réduire les coûts. Un délai trop court peut entraîner des arrêts brutaux et fragiliser les workloads, tandis qu'un délai excessivement long retarde les économies. Il est recommandé de calculer un délai de grâce adapté à votre environnement.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: nodepool
spec:
  template:
    spec:
      terminationGracePeriod: 30m

3. Utiliser l'annotation karpenter.sh/do-not-disrupt : appliquez cette annotation aux pods critiques pour empêcher leur éviction durant les activités de consolidation. Si elle protège les workloads essentiels, son usage excessif peut bloquer la suppression des nœuds lors des renouvellements planifiés, générant des inefficacités. Réservez cette annotation aux processus réellement critiques et de courte durée ou aux jobs interactifs, et évitez de l'appliquer aux services stateful de longue durée, sauf absolue nécessité.

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

4. Appliquer des Pod Disruption Budgets (PDB) : les PDB garantissent la disponibilité des applications lors d'événements de disruption des nœuds en spécifiant le nombre minimum de pods devant rester disponibles pendant les perturbations. La configuration des PDB implique de choisir entre minAvailable et maxUnavailable selon les SLA (Service Level Agreements) de vos workloads. Intégrez les PDB à Karpenter pour permettre un drain progressif des nœuds et minimiser les interruptions. Pensez également à mettre à jour régulièrement vos PDB pour refléter la dynamique de l'autoscaling et préserver leur efficacité.

5. Configuration des NodePools et contraintes en couches : vous pouvez concevoir des NodePools adaptés aux différents workloads, améliorant ainsi l'utilisation des ressources et la résilience. Par exemple, des NodePools distincts pour les workloads stateful et stateless permettent une sélection optimisée des types d'instances, etc. Vous pouvez aussi utiliser les node selectors, les affinités et les tolerations pour affiner le scheduling, en garantissant que les workloads sont placés sur les nœuds appropriés sans compromettre la résilience.

6. Politiques de consolidation pour optimiser les coûts : la fonctionnalité de consolidation de Karpenter optimise l'utilisation des ressources en identifiant les nœuds sous-utilisés et en regroupant les workloads sur un nombre réduit de nœuds. Ce processus peut générer des économies grâce à un bin-packing efficace et à l'agrégation des ressources. Il est cependant essentiel de mettre en balance les perturbations potentielles de la consolidation avec les bénéfices en matière d'économies et d'efficacité opérationnelle.

7. Équilibrer instances Spot et On-Demand : combiner instances Spot et On-Demand vous permet de profiter des avantages tarifaires tout en garantissant la stabilité des composants critiques. Configurez vos NodePools avec des pondérations et des limites d'instances appropriées, en cohérence avec vos commitments Savings Plans. Cette stratégie vous permet d'optimiser les coûts sans compromettre la fiabilité des workloads essentiels.

Notre expérience : quand les bonnes pratiques se retournent contre vous

                                                                                                                                                                                                                                                                                                                                                                         - Rédigé par [Olexandr Veleten](https://www.linkedin.com/in/aleksandr-veleten/)

Dans notre cas, nous avons suivi les bonnes pratiques recommandées pour Karpenter. Nous avons configuré les nœuds avec le paramètre expireAfter pour garantir une rotation régulière.

Pour nos workloads critiques, nous avons appliqué l'annotation karpenter.sh/do-not-disrupt afin d'éviter toute perturbation durant les activités de consolidation. Sur le papier, cette approche semblait sans faille.

Lorsque les nœuds ont atteint leur expiration, Karpenter a lancé le provisionnement de nouveaux nœuds comme prévu. Mais une complication est apparue : les nœuds existants ne pouvaient pas être arrêtés, car l'annotation do-not-disrupt empêchait l'éviction des pods critiques qu'ils hébergeaient. Résultat : un scénario temporaire où anciens et nouveaux nœuds tournaient simultanément, doublant de fait notre capacité et, par conséquent, nos coûts.

Pour y remédier, nous avons défini le paramètre terminationGracePeriod, qui fixe la durée maximale de drain d'un nœud avant arrêt forcé. Si ce paramètre garantit que les nœuds finissent par être décommissionnés, il apporte son lot de défis. Si plusieurs nœuds stateful sont arrêtés simultanément sans Pod Disruption Budgets (PDB) correctement configurés, la stabilité du cluster peut être compromise.

Face à ces complexités, nous avons décidé de désactiver le paramètre expireAfter pour nos workloads stateful. Nous avons opté à la place pour des mises à jour manuelles de ces nœuds lors de fenêtres de maintenance planifiées ou à l'occasion des mises à niveau Kubernetes, environ tous les six mois. Cette approche nous a permis de garder le contrôle sur les événements du cycle de vie des nœuds, en assurant à la fois maîtrise des coûts et stabilité du cluster.

Cette expérience nous a appris une leçon essentielle : si les bonnes pratiques constituent des repères précieux, elles ne sont pas des solutions universelles. Il est impératif d'évaluer et d'adapter les configurations aux exigences propres à vos workloads et à votre environnement opérationnel. Vous pourrez ainsi exploiter tout le potentiel d'outils comme Karpenter sans mauvaises surprises.

Karpenter vs Cluster Autoscaler

Karpenter incarne une approche plus moderne et flexible du scaling des clusters Kubernetes, avec des temps de provisionnement plus rapides et une utilisation plus efficace des ressources. Il est particulièrement adapté aux environnements dynamiques dont les besoins varient. Cluster Autoscaler, de son côté, est une solution plus établie qui fonctionne bien avec des groupes de nœuds prédéfinis et offre une prise en charge plus large des fournisseurs cloud. C'est un choix fiable pour des environnements plus statiques ou lorsque vous travaillez avec plusieurs fournisseurs cloud.

>> Découvrez ici comment tirer le meilleur de Karpenter grâce au right-sizing intelligent des pods.

Tirez le meilleur de Karpenter avec PerfectScale

Intégrer Karpenter à PerfectScale peut considérablement améliorer l'efficacité de votre cluster Kubernetes. Si Karpenter offre un provisionnement intelligent des nœuds en flux tendu, il peut manquer d'une vision approfondie de l'historique d'utilisation des ressources et des besoins de fiabilité de vos workloads. PerfectScale comble cette lacune en analysant les patterns des workloads et en fournissant des recommandations d'optimisation. Cette synergie a permis à des clients d'obtenir 30 à 50 % de réduction de coûts supplémentaire, au-delà de ce que Karpenter offre à lui seul. Par exemple, PerfectScale peut identifier les scénarios où Karpenter risque de surprovisionner des ressources et suggérer des configurations pour éviter des coûts inutiles et des impacts potentiels sur la fiabilité. Essayez PerfectScale pour voir comment renforcer votre cluster géré par Karpenter. Inscrivez-vous ou réservez une démo pour en savoir plus.