Plan de données EKS

Pour exploiter des applications résilientes et à haute disponibilité, vous avez besoin d'un plan de données hautement disponible et résilient. Un plan de données élastique permet à Kubernetes de dimensionner et de réparer automatiquement vos applications. Un plan de données résilient se compose de deux nœuds de travail ou plus, peut augmenter ou diminuer en fonction de la charge de travail et se rétablir automatiquement en cas de panne.

Plusieurs options s'offrent à vous pour les nœuds de travail dotés d'EKS : nœuds gérés en mode automatique EKS, EC2 instances et Fargate.

Le mode automatique EKS offre le chemin le plus simple vers un plan de données résilient. Le mode automatique étend la gestion des clusters Kubernetes par AWS au-delà du cluster lui-même, afin de permettre à AWS de configurer et de gérer également l'infrastructure qui permet le bon fonctionnement de vos charges de travail. Le mode automatique redimensionne automatiquement le plan de données à la hausse ou à la baisse au fur et à mesure que Kubernetes adapte les pods et veille à ce que les nœuds de votre cluster soient dimensionnés de manière appropriée et rentable pour les charges de travail en cours d'exécution.

Si vous choisissez EC2 des instances, vous pouvez gérer vous-même les nœuds de travail ou utiliser des groupes de nœuds gérés par EKS. Vous pouvez avoir un cluster combinant le mode automatique, des nœuds de travail gérés et autogérés et Fargate.

Fargate exécute chaque Pod dans un environnement informatique isolé. Chaque Pod exécuté sur Fargate possède son propre nœud de travail. Fargate redimensionne automatiquement le plan de données au fur et à mesure que Kubernetes redimensionne les pods. Vous pouvez redimensionner à la fois le plan de données et votre charge de travail à l'aide de l'autoscaler horizontal.

La méthode préférée pour dimensionner les nœuds EC2 de travail (si vous n'utilisez pas le mode automatique EKS où cela est effectué automatiquement par AWS) consiste à utiliser les groupes Karpenter, Kubernetes Cluster Autoscaler ou Auto Scaling. EC2

Recommandations

Répartissez les nœuds de travail et les charges de travail sur plusieurs AZs

Vous pouvez protéger vos charges de travail contre les défaillances dans une zone de disponibilité individuelle en exécutant des nœuds de travail et des pods en plusieurs AZs. Vous pouvez contrôler l'AZ dans laquelle les nœuds de travail sont créés à l'aide des sous-réseaux dans lesquels vous créez les nœuds.

La méthode recommandée pour répartir les pods AZs est d'utiliser les contraintes de propagation topologique pour les pods. Les fonctionnalités de mise à l'échelle automatique telles que le mode automatique d'EKS et Karpenter sont conscientes des contraintes de dispersion topologique et lancent automatiquement les nœuds correctement AZs pour permettre de respecter vos contraintes.

Le déploiement ci-dessous répartit les pods AZs si possible, en les laissant fonctionner de toute façon sinon :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1

Note

kube-schedulerne connaît les domaines topologiques que via les nœuds qui existent avec ces étiquettes. Si le déploiement ci-dessus est déployé sur un cluster avec des nœuds dans une seule zone, tous les pods seront planifiés sur ces kube-scheduler nœuds, sans connaître les autres zones. Pour que cette répartition topologique fonctionne comme prévu avec le planificateur, des nœuds doivent déjà exister dans toutes les zones. La minDomains propriété des contraintes de dispersion topologique est utilisée pour informer le planificateur du nombre de domaines éligibles, même si un nœud y est exécuté pour éviter ce problème.

Avertissement

Si DoNotSchedule vous définissez whenUnsatisfiable cette valeur sur, les pods ne seront pas planifiables si la contrainte de propagation de la topologie ne peut pas être respectée. Il ne doit être défini que s'il est préférable que les pods ne s'exécutent pas au lieu de violer la contrainte de propagation de la topologie.

Sur les anciennes versions de Kubernetes, vous pouvez utiliser les règles anti-affinité des pods pour planifier des pods sur plusieurs. AZs Le manifeste ci-dessous indique au planificateur Kubernetes de préférer planifier les pods de manière distincte. AZs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx

Avertissement

N'exigez pas que les pods soient planifiés de AZs manière distincte, sinon le nombre de pods dans un déploiement ne dépassera jamais le nombre de AZs.

Garantir la capacité de lancer des nœuds dans chaque AZ lors de l'utilisation de volumes EBS

Si vous utilisez Amazon EBS pour fournir des volumes persistants, vous devez vous assurer que les pods et le volume EBS associé se trouvent dans le même AZ. Un pod ne peut pas accéder aux volumes persistants sauvegardés par EBS situés dans une autre zone de disponibilité. Le planificateur Kubernetes sait dans quelle zone se trouve un nœud de travail à partir des étiquettes figurant sur le nœud et planifie toujours un pod nécessitant un volume EBS dans la même zone que le volume. Toutefois, si aucun nœud de travail n'est disponible dans l'AZ où se trouve le volume, le Pod ne peut pas être planifié.

Si vous utilisez le mode automatique d'EKS ou Karpenter, vous devez vous assurer que vous avez NodeClass sélectionné des sous-réseaux dans chaque AZ. Si vous utilisez des groupes de nœuds gérés, vous devez vous assurer que vous disposez d'un groupe de nœuds dans chaque zone de disponibilité.

Une capacité de stockage EBS est intégrée au mode automatique d'EKS, mais si vous utilisez Karpenter ou Managed Node Groups, l'EBS CSI devra également être installé.

Utiliser le mode automatique EKS pour gérer les nœuds de travail

Le mode automatique d'EKS rationalise la gestion d'EKS en fournissant des clusters prêts pour la production avec une charge opérationnelle minimale. Le mode automatique est chargé de redimensionner le nombre de nœuds à la hausse ou à la baisse en fonction des pods exécutés dans le cluster. Les nœuds sont automatiquement mis à jour avec les correctifs logiciels et les mises à jour, les mises à jour étant effectuées conformément aux paramètres d'NodePoolinterruption configurés et aux budgets d'interruption des modules.

Exécutez l'agent de surveillance des nœuds

L'agent de surveillance des nœuds surveille les problèmes de santé des nœuds et y réagit en publiant des événements Kubernetes et en mettant à jour l'état des nœuds. L'agent de surveillance des nœuds est inclus dans les nœuds en mode automatique d'EKS et peut être installé en tant qu'extension EKS pour les nœuds qui ne sont pas gérés par le mode automatique.

Le mode automatique EKS, les groupes de nœuds gérés et Karpenter ont tous la capacité de détecter les conditions fatales signalées par l'agent de surveillance des nœuds et de réparer ces nœuds automatiquement lorsque ces conditions se produisent.

Implémenter la QoS

Pour les applications critiques, pensez à définir requests = limits pour le conteneur du Pod. Cela garantira que le conteneur ne sera pas détruit si un autre pod demande des ressources.

Il est recommandé d'implémenter des limites de processeur et de mémoire pour tous les conteneurs, car cela évite qu'un conteneur ne consomme par inadvertance des ressources système et n'ait un impact sur la disponibilité d'autres processus colocalisés.

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

Certaines directives générales peuvent être appliquées au dimensionnement des demandes de ressources et aux limites des charges de travail :

• Ne spécifiez pas de limites de ressources sur le processeur. En l'absence de limites, la demande agit comme un poids sur le temps processeur relatif dont disposent les conteneurs. Cela permet à vos charges de travail d'utiliser l'intégralité du processeur sans limite artificielle ni privation.

• Pour les ressources autres que le processeur, la configuration requests = limits fournit le comportement le plus prévisible. Si requests ! =limits, la qualité de service du conteneur est également réduite, passant de garantie à burstable, ce qui le rend plus susceptible d'être expulsé en cas de pression sur les nœuds.

• Pour les ressources autres que le processeur, ne spécifiez pas de limite beaucoup plus grande que la demande. Plus le nombre de nœuds limits configurés est élevé par rapport àrequests, plus il est probable que les nœuds soient surengagés, ce qui augmente les risques d'interruption de la charge de travail.

• Les requêtes correctement dimensionnées sont particulièrement importantes lors de l'utilisation d'une solution d'auto-scaling des nœuds telle que Karpenter ou Cluster. AutoScaler Ces outils examinent vos demandes de charge de travail afin de déterminer le nombre et la taille des nœuds à provisionner. Si vos demandes sont trop petites et que les limites sont plus élevées, vous risquez de voir vos charges de travail expulsées ou d'éliminer OOM si elles ont été regroupées sur un nœud.

Il peut être difficile de déterminer les demandes de ressources, mais des outils tels que le Vertical Pod Autoscaler peuvent vous aider à « dimensionner correctement » les demandes en observant l'utilisation des ressources du conteneur lors de l'exécution. Les autres outils qui peuvent être utiles pour déterminer la taille des demandes sont les suivants :

• Boucles d'or

• Parca

• Profileur

• rsg

Configurer les quotas de ressources pour les espaces de noms

Les espaces de noms sont destinés à être utilisés dans des environnements avec de nombreux utilisateurs répartis sur plusieurs équipes ou projets. Ils fournissent un champ d'application pour les noms et permettent de répartir les ressources du cluster entre plusieurs équipes, projets et charges de travail. Vous pouvez limiter la consommation globale de ressources dans un espace de noms. L'ResourceQuotaobjet peut limiter la quantité d'objets pouvant être créés dans un espace de noms par type, ainsi que la quantité totale de ressources de calcul pouvant être consommées par les ressources de ce projet. Vous pouvez limiter la somme totale des ressources de and/or calcul de stockage (processeur et mémoire) qui peuvent être demandées dans un espace de noms donné.

Si le quota de ressources est activé pour un espace de noms pour les ressources de calcul telles que le processeur et la mémoire, les utilisateurs doivent spécifier les demandes ou les limites pour chaque conteneur de cet espace de noms.

Envisagez de configurer des quotas pour chaque espace de noms. Envisagez LimitRanges de l'utiliser pour appliquer automatiquement des limites préconfigurées aux conteneurs au sein d'un espace de noms.

Limiter l'utilisation des ressources du conteneur dans un espace de noms

Les quotas de ressources permettent de limiter la quantité de ressources qu'un espace de noms peut utiliser. L'LimitRangeobjet peut vous aider à implémenter les ressources minimales et maximales qu'un conteneur peut demander. LimitRangeVous pouvez ainsi définir une demande par défaut et des limites pour les conteneurs, ce qui est utile si la définition de limites de ressources de calcul n'est pas une pratique courante dans votre organisation. Comme son nom l'indique, LimitRange peut imposer une utilisation minimale et maximale des ressources de calcul par pod ou conteneur dans un espace de noms. De plus, appliquez le minimum et le maximum de demandes de stockage par PersistentVolumeClaim espace de noms.

Envisagez LimitRange de l'utiliser conjointement avec ResourceQuota pour appliquer des limites au niveau du conteneur et de l'espace de noms. La définition de ces limites garantit qu'un conteneur ou un espace de noms n'empiète pas sur les ressources utilisées par les autres locataires du cluster.

Utiliser NodeLocal DNSCache

Vous pouvez améliorer les performances du DNS du cluster en exécutant NodeLocalDNSCache. Cette fonctionnalité exécute un agent de mise en cache DNS sur les nœuds du cluster en tant DaemonSet que. Tous les pods utilisent l'agent de mise en cache DNS exécuté sur le nœud pour la résolution des noms au lieu d'utiliser le kube-dns service. Cette fonctionnalité est automatiquement incluse dans le mode automatique d'EKS.

Configurer l'auto-scaling CoreDNS

Une autre méthode pour améliorer les performances du DNS du cluster consiste à activer l'auto-scaling intégré des pods CoreDNS.

Cette fonctionnalité surveille en permanence l'état du cluster, notamment le nombre de nœuds et de cœurs de processeur. Sur la base de ces informations, le contrôleur adaptera dynamiquement le nombre de répliques du déploiement CoreDNS dans un cluster EKS.