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.

Plan de données EKS

Pour exploiter des applications hautement disponibles et résilientes, vous avez besoin d'un plan de données hautement disponible et résilient. Un plan de données élastique permet à Kubernetes de faire évoluer 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 et diminuer en fonction de la charge de travail et se rétablir automatiquement en cas de panne.

Vous avez plusieurs choix pour les nœuds de travail avec EKS : nœuds gérés en mode automatique EKS, instances EC2 et https://docs.aws.amazon.com/eks/latest/userguide/fargate.html Fargate.

Le mode EKS Auto constitue le moyen le plus simple d'accéder à 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 l'infrastructure qui permet le bon fonctionnement de vos charges de travail. Le mode automatique redimensionne automatiquement le plan de données vers le haut ou vers le bas au fur et à mesure que Kubernetes fait évoluer les Pods et veille en permanence à 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 des instances EC2, 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 avec une combinaison de mode automatique, de nœuds de travail gérés et autogérés et de 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 du scaler automatique à pod horizontal.

La méthode préférée pour dimensionner les nœuds de travail EC2 (si vous n'utilisez pas le mode EKS Auto où cela est effectué automatiquement par AWS) est d'utiliser Karpenter, Kubernetes Cluster Autoscaler ou les groupes EC2 Auto Scaling. https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html

Recommandations

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

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 dans plusieurs zones de disponibilité. 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 entre les zones de zone de zone de zone consiste à utiliser les contraintes de répartition de la topologie pour les pods. Auto-scaling des fonctionnalités telles que le mode automatique EKS et Karpenter sont conscientes des contraintes d'étalement de la topologie et lanceront automatiquement les nœuds dans les zones de zone de sécurité appropriées pour permettre de respecter vos contraintes.

Le déploiement ci-dessous répartit les pods entre les zones de disponibilité si possible, en laissant ces pods fonctionner quand même :

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

Sur les anciennes versions de Kubernetes, vous pouvez utiliser les règles d'anti-affinité des pods pour planifier des pods sur plusieurs zones de disponibilité. Le manifeste ci-dessous indique au planificateur Kubernetes de préférer la planification des pods dans des zones de disponibilité distinctes.

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

Garantir la possibilité de lancer des nœuds dans chaque zone de disponibilité 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 la même zone de disponibilité. Un Pod ne peut pas accéder à des volumes EBS-backed persistants situés dans une zone de disponibilité différente. Le planificateur Kubernetes sait dans quelle zone de zone de travail se trouve un nœud de travail à partir des étiquettes qui se trouvent sur le nœud et planifie toujours un pod qui nécessite un volume EBS dans la même zone de disponibilité 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 EKS ou Karpenter, vous devez vous assurer que vous NodeClass sélectionnez des sous-réseaux dans chaque zone de zone de zone de zone de zone. Si vous utilisez des groupes de nœuds gérés, vous devez vous assurer de disposer d'un groupe de nœuds dans chaque zone de disponibilité.

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

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

Le mode automatique EKS rationalise la gestion d'EKS en fournissant des clusters prêts pour la production avec un minimum de frais opérationnels. Le mode automatique est responsable de l'augmentation ou de la diminution du nombre de nœuds en fonction des pods qui s'exécutent dans le cluster. Les nœuds sont automatiquement tenus à jour grâce aux correctifs et correctifs logiciels, 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 les é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 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 sont tous capables de détecter les conditions fatales des nœuds signalées par l'agent de surveillance des nœuds et de réparer ces nœuds automatiquement lorsque ces conditions se produisent.

Mettre en œuvre 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 empêche un conteneur de consommer par inadvertance des ressources système, ce qui a 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 :

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 au moment de l'exécution. Parmi les autres outils qui peuvent être utiles pour déterminer la taille des demandes, citons :

Configurer des 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 une portée 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 qui peuvent être consommées par les ressources de ce projet. Vous pouvez limiter la somme totale des ressources de and/or calcul de stockage (CPU 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 des demandes ou des limites pour chaque conteneur de cet espace de noms.

Pensez à configurer des quotas pour chaque espace de noms. Pensez LimitRanges à 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 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. En outre, appliquez une demande de stockage minimale et maximale par espace PersistentVolumeClaim de noms.

Envisagez LimitRange de l'utiliser conjointement avec ResourceQuota pour appliquer des limites au niveau d'un conteneur ainsi qu'au niveau 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 DNS du cluster en exécutant NodeLocal DNSCache. 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 kube-dns Service. Cette fonction est automatiquement incluse dans le mode automatique EKS.

Configurer CoreDNS avec mise à l'échelle automatique

Une autre méthode pour améliorer les performances du Cluster DNS consiste à activer la mise à l'échelle automatique intégrée des pods CoreDNS.

Cette fonctionnalité surveille en permanence l'état du cluster, y compris le nombre de nœuds et de cœurs de processeur. En fonction de ces informations, le contrôleur ajuste dynamiquement le nombre de réplicas du déploiement CoreDNS dans le cluster EKS.