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.

Karpenter

Karpenter est un projet open source conçu pour améliorer la gestion du cycle de vie des nœuds au sein des clusters Kubernetes. Il automatise le provisionnement et le déprovisionnement des nœuds en fonction des besoins de planification spécifiques des pods, ce qui permet une mise à l'échelle efficace et une optimisation des coûts. Ses principales fonctions sont les suivantes :

Avec Karpenter, vous pouvez définir NodePools des contraintes sur le provisionnement des nœuds, telles que les teintes, les étiquettes, les exigences (types d'instances, zones, etc.) et les limites du total des ressources provisionnées. Lorsque vous déployez des charges de travail, vous pouvez spécifier diverses contraintes de planification dans les spécifications des pods, telles que les ressources requests/limits, les sélecteurs de nœuds, les node/pod affinités, les tolérations et les contraintes d'étalement de la topologie. Karpenter fournira ensuite des nœuds de la bonne taille en fonction de ces spécifications.

Les raisons d'utiliser Karpenter

Avant le lancement de Karpenter, les utilisateurs de Kubernetes s'appuyaient principalement sur les groupes Amazon EC2 Auto Scaling et le Kubernetes Cluster Autoscaler (CAS) pour ajuster dynamiquement la capacité de calcul de leurs clusters. Avec Karpenter, vous n'avez pas besoin de créer des dizaines de groupes de nœuds pour bénéficier de la flexibilité et de la diversité que vous offre Karpenter. Contrairement à CAS, Karpenter n'est pas aussi étroitement lié aux versions de Kubernetes et ne vous oblige pas à passer d'une API AWS à une API Kubernetes.

Karpenter consolide les responsabilités d'orchestration des instances au sein d'un système unique, plus simple, plus stable et prenant en compte les clusters. Karpenter a été conçu pour surmonter certains des défis posés par Cluster Autoscaler en proposant des moyens simplifiés pour :

Pour obtenir des informations et de la documentation sur l'utilisation de Karpenter, visitez le site karpenter.sh.

Recommandations

Les meilleures pratiques sont divisées en sections sur Karpenter lui-même et sur NodePools la planification des modules.

Les meilleures pratiques de Karpenter

Les bonnes pratiques suivantes couvrent des sujets liés à Karpenter lui-même.

Verrouillez les AMI dans les clusters de production

Nous vous recommandons vivement d'épingler les Amazon Machine Images (AMI) bien connues utilisées par Karpenter pour les clusters de production. L'utilisation amiSelector d'un alias défini sur@latest, ou l'utilisation d'une autre méthode qui entraîne le déploiement d'AMI non testées au fur et à mesure de leur publication, présente le risque de défaillances de la charge de travail et d'indisponibilité de vos clusters de production. Par conséquent, nous vous recommandons vivement d'épingler les versions fonctionnelles testées des AMI pour vos clusters de production pendant que vous testez les nouvelles versions dans des clusters hors production. Par exemple, vous pouvez définir un alias dans votre compte NodeClass comme suit :

amiSelectorTerms
  - alias: al2023@v20240807

Pour plus d'informations sur la gestion et l'identification des AMI dans Karpenter, consultez la section Gestion des AMI dans la documentation de Karpenter.

Utilisez Karpenter pour les charges de travail dont les besoins en capacité évoluent

Karpenter rapproche la gestion du dimensionnement des API natives de Kubernetes plutôt que des groupes de dimensionnement automatique (ASG) et des groupes de nœuds gérés (MNG). Les ASG et les MNG sont des AWS-native abstractions dans lesquelles la mise à l'échelle est déclenchée en fonction de métriques au niveau AWS, telles que la charge du processeur EC2. Cluster Autoscaler relie les abstractions Kubernetes aux abstractions AWS, mais perd une certaine flexibilité à cause de cela, comme la planification pour une zone de disponibilité spécifique.

Karpenter supprime une couche d'abstraction d'AWS pour apporter une partie de la flexibilité directement à Kubernetes. Karpenter est idéal pour les clusters dont les charges de travail sont confrontées à des périodes de forte demande ou qui ont des exigences de calcul diverses. Les MNG et les ASG conviennent aux clusters exécutant des charges de travail qui ont tendance à être plus statiques et cohérentes. Vous pouvez utiliser une combinaison de nœuds gérés dynamiquement et statiquement, en fonction de vos besoins.

Envisagez d'autres projets de mise à l'échelle automatique lorsque...

Vous avez besoin de fonctionnalités qui sont encore en cours de développement dans Karpenter. Karpenter étant un projet relativement récent, envisagez d'autres projets de mise à l'échelle automatique pour le moment si vous avez besoin de fonctionnalités qui ne font pas encore partie de Karpenter.

Exécutez le contrôleur Karpenter sur EKS Fargate ou sur un nœud de travail appartenant à un groupe de nœuds

Karpenter est installé à l'aide d'un graphique https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#4-install-karpenter Helm. Le graphique Helm installe le contrôleur Karpenter et un module Webhook en tant que déploiement qui doit être exécuté avant que le contrôleur puisse être utilisé pour dimensionner votre cluster. Nous recommandons un minimum d'un petit groupe de nœuds avec au moins un nœud de travail. Vous pouvez également exécuter ces pods sur EKS Fargate en créant un profil Fargate pour l'espace de noms. karpenter Cela entraînera l'exécution de tous les pods déployés dans cet espace de noms sur EKS Fargate. N'exécutez pas Karpenter sur un nœud géré par Karpenter.

Aucun support de modèles de lancement personnalisés avec Karpenter

Les modèles de lancement personnalisés ne sont pas pris en charge avec les API v1. Vous pouvez utiliser des données utilisateur personnalisées and/or directement en spécifiant des AMI personnalisées dans le EC2NodeClass. De plus amples informations sur la manière de procéder sont disponibles à l'adresse NodeClasses.

Exclure les types d'instances qui ne correspondent pas à votre charge de travail

Envisagez d'exclure des types d'instances spécifiques à l'aide de la node.kubernetes.io/instance-type clé s'ils ne sont pas requis par les charges de travail exécutées dans votre cluster.

L'exemple suivant montre comment éviter de provisionner de grandes instances de Graviton.

- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
  - m6g.16xlarge
  - m6gd.16xlarge
  - r6g.16xlarge
  - r6gd.16xlarge
  - c6g.16xlarge

Activer la gestion des interruptions lors de l'utilisation de Spot

Karpenter prend en charge la gestion native des interruptions et peut gérer les événements d'interruption involontaires tels que les interruptions d'instances ponctuelles, les événements de maintenance planifiés, les événements d'instance termination/stopping susceptibles de perturber vos charges de travail. Lorsque Karpenter détecte de tels événements pour les nœuds, il souille, vide et arrête automatiquement les nœuds concernés à l'avance afin de lancer un nettoyage en douceur des charges de travail avant toute interruption. Pour les interruptions ponctuelles avec un préavis de 2 minutes, Karpenter démarre rapidement un nouveau nœud afin que les pods puissent être déplacés avant que l'instance ne soit récupérée. Pour activer la gestion des interruptions, vous configurez l'argument --interruption-queue CLI avec le nom de la file d'attente SQS provisionnée à cette fin. Il n'est pas conseillé d'utiliser la gestion des interruptions Karpenter en même temps que Node Termination Handler, comme expliqué ici.

Les pods nécessitant des points de contrôle ou d'autres formes de vidange progressive, nécessitant un délai de 2 minutes avant l'arrêt, devraient permettre à Karpenter de gérer les interruptions dans leurs clusters.

Cluster privé Amazon EKS sans accès Internet sortant

Lorsque vous provisionnez un cluster EKS dans un VPC sans route vers Internet, vous devez vous assurer que vous avez configuré votre environnement conformément aux exigences du cluster privé qui apparaissent dans la documentation EKS. En outre, vous devez vous assurer que vous avez créé un point de terminaison régional STS VPC dans votre VPC. Sinon, vous verrez des erreurs similaires à celles qui apparaissent ci-dessous.

{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts.<region>.amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}

Ces modifications sont nécessaires dans un cluster privé car le contrôleur Karpenter utilise IAM Roles for Service Accounts (IRSA). Les pods configurés avec IRSA obtiennent des informations d'identification en appelant l'API AWS Security Token Service (AWS STS). S'il n'y a pas d'accès Internet sortant, vous devez créer et utiliser un point de terminaison AWS STS VPC dans votre VPC.

Les clusters privés nécessitent également la création d'un point de terminaison VPC pour SSM. Lorsque Karpenter essaie de provisionner un nouveau nœud, il interroge les configurations du modèle de lancement et un paramètre SSM. Si vous n'avez pas de point de terminaison SSM VPC dans votre VPC, cela provoquera l'erreur suivante :

{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm.<region>.amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}

Il n'existe aucun point de terminaison VPC pour l'API https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-pelong.html Price List Query. Par conséquent, les données de tarification deviendront obsolètes au fil du temps. Karpenter contourne ce problème en incluant des données de tarification à la demande dans son binaire, mais ne met à jour ces données que lorsque Karpenter est mis à niveau. Les demandes de données tarifaires échouées entraîneront les messages d'erreur suivants :

{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}

Consultez cette documentation pour utiliser Karpenter dans un cluster EKS totalement privé et pour savoir quels points de terminaison VPC doivent être créés.

Création NodePools

Les bonnes pratiques suivantes couvrent des sujets liés à la création NodePools.

Créez-en plusieurs NodePools lorsque...

Lorsque différentes équipes partagent un cluster et doivent exécuter leurs charges de travail sur différents nœuds de travail, ou ont des exigences différentes en matière de système d'exploitation ou de type d'instance, créez-en plusieurs NodePools. Par exemple, une équipe peut souhaiter utiliser Bottlerocket, tandis qu'une autre peut vouloir utiliser Amazon Linux. De même, une équipe peut avoir accès à du matériel GPU coûteux dont une autre n'aurait pas besoin. L'utilisation de plusieurs éléments NodePools permet de s'assurer que les ressources les plus appropriées sont disponibles pour chaque équipe.

Créez NodePools qui s'excluent mutuellement ou qui sont pondérées

Il est recommandé de créer des éléments NodePools qui s'excluent mutuellement ou qui sont pondérés pour fournir un comportement de planification cohérent. Si ce n'est pas le cas et que plusieurs d'entre elles NodePools sont identiques, Karpenter choisira au hasard celle à utiliser, ce qui provoquera des résultats inattendus. Voici des exemples utiles pour en créer plusieurs NodePools  :

Créer un NodePool avec GPU et autoriser uniquement l'exécution de charges de travail spéciales sur ces nœuds (coûteux) :

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    metadata: {}
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - p3.8xlarge
        - p3.16xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      taints:
      - effect: NoSchedule
        key: nvidia.com/gpu
        value: "true"

Déploiement avec tolérance à la contamination :

# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-gpu
spec:
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"

Pour un déploiement général pour une autre équipe, la NodePool spécification pourrait inclure NodeAffinity. Un déploiement pourrait alors utiliser un nœud SelectorTerms correspondantbilling-team.

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: generalcompute
spec:
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m5.2xlarge
        - c5.large
        - c5.xlarge
        - c5a.large
        - c5a.xlarge
        - r5.large
        - r5.xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand

Déploiement à l'aide de NodeAffinity :

# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
  name: workload-my-team
spec:
  replicas: 200
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "billing-team"
                  operator: "In"
                  values: ["my-team"]

Utilisez des temporisateurs (TTL) pour supprimer automatiquement des nœuds du cluster

Vous pouvez utiliser des minuteries sur les nœuds provisionnés pour définir quand supprimer les nœuds dépourvus de modules de charge de travail ou qui ont atteint un délai d'expiration. L'expiration des nœuds peut être utilisée comme moyen de mise à niveau, de sorte que les nœuds soient retirés et remplacés par des versions mises à jour. Consultez Expiration dans la documentation Karpenter pour plus d'informations sur l'utilisation spec.template.spec pour configurer l'expiration des nœuds.

Évitez de trop restreindre les types d'instances que Karpenter peut provisionner, en particulier lorsque vous utilisez Spot

Lors de l'utilisation de Spot, Karpenter utilise la stratégie d'allocation optimisée pour la capacité des prix pour provisionner des instances EC2. Cette stratégie demande à EC2 de provisionner des instances provenant des pools les plus profonds pour le nombre d'instances que vous lancez et qui présentent le plus faible risque d'interruption. EC2 Fleet demande ensuite des instances Spot auprès des pools les moins chers. Plus vous autorisez Karpenter à utiliser de types d'instances, plus EC2 peut optimiser le temps d'exécution de votre instance spot. Par défaut, Karpenter utilisera tous les types d'instances proposés par EC2 dans la région et les zones de disponibilité dans lesquelles votre cluster est déployé. Karpenter choisit intelligemment parmi tous les types d'instances en fonction des pods en attente afin de s'assurer que vos pods sont planifiés sur des instances de taille et équipées appropriées. Par exemple, si votre pod ne nécessite pas de GPU, Karpenter ne planifiera pas votre pod sur un type d'instance EC2 supportant un GPU. Si vous n'êtes pas sûr des types d'instances à utiliser, vous pouvez exécuter le sélecteur d'instance Amazon ec2 pour générer une liste des types d'instances correspondant à vos besoins de calcul. Par exemple, la CLI prend la mémoire vCPU, l'architecture et la région comme paramètres d'entrée et vous fournit une liste d'instances EC2 qui répondent à ces contraintes.

$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium

Vous ne devez pas imposer trop de contraintes à Karpenter lorsque vous utilisez des instances Spot, car cela peut affecter la disponibilité de vos applications. Supposons, par exemple, que toutes les instances d'un type particulier soient récupérées et qu'aucune alternative appropriée ne soit disponible pour les remplacer. Vos pods resteront en attente jusqu'à ce que la capacité du spot pour les types d'instances configurés soit réapprovisionnée. Vous pouvez réduire le risque d'erreurs de capacité insuffisante en répartissant vos instances dans différentes zones de disponibilité, car les pools de spots sont différents selon les zones de disponibilité. Cela dit, la meilleure pratique générale consiste à autoriser Karpenter à utiliser un ensemble varié de types d'instances lors de l'utilisation de Spot.

Pods de planification

Les meilleures pratiques suivantes concernent le déploiement de pods dans un cluster à l'aide de Karpenter pour le provisionnement des nœuds.

Suivez les meilleures pratiques d'EKS en matière de haute disponibilité

Si vous devez exécuter des applications à haute disponibilité, suivez les recommandations générales d'EKS en matière de bonnes pratiques. Consultez la section Topology Spread dans la documentation Karpenter pour plus de détails sur la façon de répartir les pods entre les nœuds et les zones. Utilisez Disruption Budgets pour définir le minimum de pods disponibles qui doivent être entretenus, au cas où des tentatives d'expulsion ou de suppression de pods seraient tentées.

Utilisez des contraintes en couches pour limiter les fonctionnalités de calcul disponibles auprès de votre fournisseur de cloud

Le modèle de contraintes en couches de Karpenter vous permet de créer un ensemble complexe de contraintes de NodePool déploiement de modules afin d'obtenir les meilleures correspondances possibles pour la planification des modules. Voici des exemples de contraintes qu'une spécification de pod peut demander :

Créez des alarmes de facturation pour surveiller vos dépenses informatiques

Lorsque vous configurez votre cluster pour qu'il évolue automatiquement, vous devez créer des alarmes de facturation pour vous avertir lorsque vos dépenses dépassent un seuil et ajouter des limites de ressources à votre configuration Karpenter. La définition de limites de ressources avec Karpenter est similaire à la définition de la capacité maximale d'un groupe AWS Autoscaling dans la mesure où elle représente la quantité maximale de ressources de calcul qui peuvent être instanciées par un Karpenter. NodePool

L'extrait ci-dessous indique à Karpenter de ne provisionner qu'un maximum de 1 000 cœurs de processeur et 1 000 Go de mémoire. Karpenter cessera d'ajouter de la capacité uniquement lorsque la limite sera atteinte ou dépassée. Lorsqu'une limite est dépassée, le contrôleur Karpenter écrit memory resource usage of 1001 exceeds limit of 1000 un message similaire dans les journaux du contrôleur. Si vous acheminez les journaux de vos conteneurs vers CloudWatch des journaux, vous pouvez créer un filtre de métriques pour rechercher des modèles ou des termes spécifiques dans vos journaux, puis créer une CloudWatch alarme pour vous avertir lorsque le seuil de métriques que vous avez configuré est dépassé.

Pour plus d'informations sur l'utilisation des limites avec Karpenter, consultez la section Définition des limites de ressources dans la documentation de Karpenter.

spec:
  limits:
    cpu: 1000
    memory: 1000Gi

Si vous n'utilisez pas de limites ou ne limitez pas les types d'instances que Karpenter peut provisionner, Karpenter continuera à ajouter de la capacité de calcul à votre cluster selon les besoins. Bien que cette configuration de Karpenter permette à votre cluster d'évoluer librement, cela peut également avoir des implications financières importantes. C'est pour cette raison que nous vous recommandons de configurer les alarmes de facturation. Les alarmes de facturation vous permettent d'être alerté et averti de manière proactive lorsque les frais estimés calculés sur votre ou vos comptes dépassent un seuil défini. Consultez Configuration d'une alarme CloudWatch de facturation Amazon pour surveiller de manière proactive les frais estimés pour plus d'informations.

Vous pouvez également activer la détection des anomalies de coûts, une fonctionnalité de gestion des coûts d'AWS qui utilise l'apprentissage automatique pour surveiller en permanence vos coûts et votre utilisation afin de détecter les dépenses inhabituelles. Vous trouverez de plus amples informations dans le guide de démarrage d'AWS Cost Anomaly Detection Getting Started. Si vous êtes allé jusqu'à créer un budget dans AWS Budgets, vous pouvez également configurer une action pour vous avertir lorsqu'un seuil spécifique est dépassé. Avec les actions budgétaires, vous pouvez envoyer un e-mail, publier un message sur un sujet SNS ou envoyer un message à un chatbot tel que Slack. Pour plus d'informations, consultez la section Configuration des actions AWS Budgets.

Utilise le charpentier. sh/do-annotation non perturbatrice pour empêcher Karpenter de déprovisionner un nœud

Si vous exécutez une application critique sur un Karpenter-provisioned nœud, telle qu'un traitement par lots de longue durée ou une application avec état, et que le TTL du nœud a expiré, l'application sera interrompue lorsque l'instance sera arrêtée. En ajoutant une karpenter.sh/do-not-disrupt annotation au pod, vous demandez à Karpenter de conserver le nœud jusqu'à ce que le pod soit terminé ou que l'karpenter.sh/do-not-disruptannotation soit supprimée. Consultez la documentation relative aux perturbations pour plus d'informations.

S'il ne reste sur un nœud que des pods autres que ceux associés à des tâches, Karpenter est en mesure de cibler et de terminer ces nœuds tant que le statut de la tâche est réussi ou échoué.

Configurer requests=limits pour toutes les ressources autres que le processeur lors de l'utilisation de la consolidation

La consolidation et la planification fonctionnent en général en comparant les demandes de ressources des pods par rapport à la quantité de ressources allouables sur un nœud. Les limites de ressources ne sont pas prises en compte. Par exemple, les pods dont la limite de mémoire est supérieure à la demande de mémoire peuvent dépasser la demande de mémoire. Si plusieurs modules du même nœud éclatent en même temps, cela peut entraîner la fermeture de certains modules en raison d'une insuffisance de mémoire (OOM). La consolidation peut rendre cela plus probable, car elle permet de regrouper les pods sur les nœuds uniquement en tenant compte de leurs demandes.

Permet LimitRanges de configurer les valeurs par défaut pour les demandes et les limites de ressources

Comme Kubernetes ne définit pas de requêtes ni de limites par défaut, la consommation de ressources d'un conteneur provenant de l'hôte, du processeur et de la mémoire sous-jacents n'est pas limitée. Le planificateur Kubernetes examine le nombre total de demandes d'un pod (le plus élevé entre le total des demandes provenant des conteneurs du pod ou le total des ressources provenant des conteneurs Init du pod) afin de déterminer sur quel nœud de travail planifier le pod. De même, Karpenter prend en compte les demandes d'un module pour déterminer le type d'instance qu'il met à disposition. Vous pouvez utiliser une plage limite pour appliquer une valeur par défaut raisonnable à un espace de noms, au cas où les demandes de ressources ne seraient pas spécifiées par certains pods.

Voir Configurer les demandes de mémoire par défaut et les limites pour un espace de noms

Appliquez des demandes de ressources précises à toutes les charges de travail

Karpenter est en mesure de lancer les nœuds les mieux adaptés à vos charges de travail lorsque ses informations sur les exigences en matière de charges de travail sont exactes. Ceci est particulièrement important si vous utilisez la fonction de consolidation de Karpenter.

Voir Configurer et dimensionner les ressources Requests/Limits pour toutes les charges de travail

Recommandations CoreDNS

Mettez à jour la configuration de CoreDNS pour maintenir la fiabilité

Lors du déploiement de pods CoreDNS sur des nœuds gérés par Karpenter, étant donné la nature dynamique de Karpenter qui consiste à terminating/creating créer rapidement des nœuds pour répondre à la demande, il est conseillé de suivre les meilleures pratiques suivantes :

Durée de CoreDNS Lamduck

Sonde de préparation CoreDNS

Cela permettra de s'assurer que les requêtes DNS ne sont pas dirigées vers un pod CoreDNS qui n'est pas encore prêt ou qui a été interrompu.

Plans de Karpenter

Alors que Karpenter adopte une approche axée sur les applications pour fournir de la capacité de calcul au plan de données Kubernetes, il existe des scénarios de charge de travail courants pour lesquels vous vous demandez peut-être comment les configurer correctement. Karpenter Blueprints est un référentiel qui inclut une liste de scénarios de charge de travail courants selon les meilleures pratiques décrites ici. Vous disposerez de toutes les ressources nécessaires pour créer un cluster EKS avec Karpenter configuré et tester chacun des plans inclus dans le référentiel. Vous pouvez combiner différents plans pour finalement créer celui dont vous avez besoin pour vos charges de travail.

Ressources supplémentaires