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.

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 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.

Deux options s'offrent à vous pour les nœuds de travail avec EKS : EC2instances et Fargate. 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 composé à la fois de nœuds de travail gérés et autogérés et de Fargate.

EKS on Fargate offre le chemin le plus simple vers un plan de données résilient. 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 de EC2 travail consiste à utiliser Kubernetes Cluster Autoscaler, des groupes EC2Auto Scaling ou des projets communautaires tels qu'Atlassian Escalator.

Recommandations

Utilisez EC2 Auto Scaling Groups pour créer des nœuds de travail

Il est recommandé de créer des nœuds de travail à l'aide de groupes EC2 Auto Scaling au lieu de créer des EC2 instances individuelles et de les joindre au cluster. Auto Scaling Groups remplacera automatiquement tous les nœuds interrompus ou défaillants afin que le cluster ait toujours la capacité d'exécuter votre charge de travail.

Utiliser Kubernetes Cluster Autoscaler pour dimensionner les nœuds

Cluster Autoscaler ajuste la taille du plan de données lorsque certains pods ne peuvent pas être exécutés parce que le cluster ne dispose pas de ressources suffisantes, et l'ajout d'un autre nœud de travail serait utile. Bien que Cluster Autoscaler soit un processus réactif, il attend que les pods soient en attente en raison d'une capacité insuffisante du cluster. Lorsqu'un tel événement se produit, il ajoute EC2 des instances au cluster. Chaque fois que la capacité du cluster est épuisée, les nouvelles répliques (ou les nouveaux pods) ne seront pas disponibles (à l'état En attente) jusqu'à ce que des nœuds de travail soient ajoutés. Ce délai peut avoir un impact sur la fiabilité de vos applications si le plan de données ne peut pas évoluer suffisamment rapidement pour répondre aux exigences de la charge de travail. Si un nœud de travail est constamment sous-utilisé et que tous ses pods peuvent être planifiés sur d'autres nœuds de travail, Cluster Autoscaler le met fin à celui-ci.

Configurer le surprovisionnement avec Cluster Autoscaler

Cluster Autoscaler déclenche une mise à l'échelle du plan de données lorsque les pods du cluster sont déjà en attente. Par conséquent, il peut y avoir un délai entre le moment où votre application a besoin de plus de répliques et le moment où elle obtient en fait davantage de répliques. Une option pour tenir compte de ce retard éventuel consiste à ajouter plus de répliques que nécessaire, ce qui augmente le nombre de répliques pour l'application.

Un autre modèle recommandé par Cluster Autoscaler utilise les pods de pause et la fonction de préemption prioritaire. Le Pod de pause exécute un conteneur de pause qui, comme son nom l'indique, ne fait que servir d'espace réservé à la capacité de calcul qui peut être utilisée par les autres Pods de votre cluster. Comme il s'exécute avec une très faible priorité attribuée, le Pod en pause est expulsé du nœud lorsqu'un autre Pod doit être créé, et le cluster n'a pas de capacité disponible. Le planificateur Kubernetes remarque l'expulsion du Pod en pause et tente de le reprogrammer. Mais comme le cluster fonctionne à pleine capacité, le Pod de pause reste en attente, auquel le Cluster Autoscaler réagit en ajoutant des nœuds.

Utilisation de Cluster Autoscaler avec plusieurs groupes Auto Scaling

Exécutez le Cluster Autoscaler avec le --node-group-auto-discovery drapeau activé. Cela permettra au Cluster Autoscaler de trouver tous les groupes de mise à l'échelle automatique qui incluent une balise définie particulière et évitera d'avoir à définir et à gérer chaque groupe de mise à l'échelle automatique dans le manifeste.

Utilisation de Cluster Autoscaler avec un stockage local

Par défaut, le Cluster Autoscaler ne réduit pas les nœuds dotés de pods déployés avec un stockage local connecté. Définissez l'--skip-nodes-with-local-storageindicateur sur false pour permettre à Cluster Autoscaler de réduire la taille de ces nœuds.

Répartissez les nœuds de travail et la charge 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 plusieurs AZs nœuds et pods de travail. 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.

Si vous utilisez Kubernetes 1.18+, la méthode recommandée pour répartir les pods AZs est d'utiliser les contraintes de propagation topologique pour les pods.

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

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

Garantir la capacité 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. Au moment de la rédaction du présent rapport, les volumes EBS ne sont disponibles que dans un seul 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 AZ se trouve un nœud de travail. Kubernetes planifiera toujours un pod qui nécessite 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é.

Créez un groupe Auto Scaling pour chaque zone de disponibilité avec une capacité suffisante pour garantir que le cluster dispose toujours de la capacité nécessaire pour planifier les pods dans la même zone que les volumes EBS dont ils ont besoin. En outre, vous devez activer --balance-similar-node-groups cette fonctionnalité dans Cluster Autoscaler.

Si vous exécutez une application qui utilise le volume EBS mais qui n'a aucune exigence de haute disponibilité, vous pouvez limiter le déploiement de l'application à une seule AZ. Dans EKS, les nœuds de travail reçoivent automatiquement une failure-domain.beta.kubernetes.io/zone étiquette qui contient le nom de l'AZ. Vous pouvez voir les étiquettes attachées à vos nœuds en exécutantkubectl get nodes --show-labels. De plus amples informations sur les étiquettes de nœuds intégrées sont disponibles ici. Vous pouvez utiliser les sélecteurs de nœuds pour planifier un pod dans une zone de zone spécifique.

Dans l'exemple ci-dessous, le pod sera uniquement planifié en us-west-2c AZ :

apiVersion: v1
kind: Pod
metadata:
  name: single-az-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - us-west-2c
  containers:
  - name: single-az-container
    image: kubernetes/pause

Les volumes persistants (soutenus par EBS) sont également automatiquement étiquetés avec le nom AZ ; vous pouvez voir à quel AZ appartient votre volume persistant en exécutantkubectl get pv -L topology.ebs.csi.aws.com/zone. Lorsqu'un pod est créé et revendique un volume, Kubernetes planifie le pod sur un nœud situé dans la même zone que le volume.

Imaginons ce scénario ; vous avez un cluster EKS avec un groupe de nœuds. Ce groupe de nœuds comprend trois nœuds de travail répartis sur trois AZs. Vous avez une application qui utilise un volume persistant soutenu par EBS. Lorsque vous créez cette application et le volume correspondant, son Pod est créé dans le premier des trois AZs. Ensuite, le nœud de travail qui exécute ce Pod devient défectueux et ne peut donc pas être utilisé. Cluster Autoscaler remplacera le nœud défectueux par un nouveau nœud de travail ; toutefois, comme le groupe de mise à l'échelle automatique s'étend sur trois AZs, le nouveau nœud de travail peut être lancé dans la deuxième ou la troisième zone, mais pas dans la première zone, comme la situation l'exige. Comme le volume EBS limité en AZ n'existe que dans la première zone de zone, mais qu'aucun nœud de travail n'est disponible dans cette zone, le pod ne peut pas être planifié. Par conséquent, vous devez créer un groupe de nœuds dans chaque zone de disponibilité, afin qu'il y ait toujours suffisamment de capacité disponible pour exécuter des pods qui ne peuvent pas être planifiés dans une autre zone AZs.

L'EFS peut également simplifier le dimensionnement automatique des clusters lors de l'exécution d'applications nécessitant un stockage persistant. Les clients peuvent accéder aux systèmes de fichiers EFS simultanément depuis l'ensemble AZs de la région. Même si un pod utilisant un volume persistant soutenu par EFS est arrêté et programmé dans une zone de zone différente, il sera en mesure de monter le volume.

Détectez les problèmes liés aux nœuds grâce à l'agent de surveillance des nœuds

Les défaillances des nœuds de travail peuvent avoir un impact sur la disponibilité de vos applications. Vous pouvez utiliser l'agent de surveillance des nœuds pour détecter et signaler les problèmes de santé. Vous pouvez également activer la réparation automatique des nœuds pour remplacer automatiquement les nœuds lorsque des problèmes sont détectés.

L'agent de surveillance des nœuds est inclus en tant que fonctionnalité pour tous les clusters en mode automatique Amazon EKS. Pour les autres types de clusters, vous pouvez ajouter l'agent de surveillance en tant que module complémentaire Amazon EKS. Pour plus d'informations, consultez Activer la réparation automatique des nœuds et étudiez les problèmes de santé des nœuds dans le guide de l'utilisateur Amazon EKS.

Réserver des ressources pour le système et les démons Kubernetes

Vous pouvez améliorer la stabilité des nœuds de travail en réservant la capacité de calcul au système d'exploitation et aux démons Kubernetes. Les pods, en particulier ceux qui ne sont pas limits déclarés, peuvent saturer les ressources du système, ce qui place les nœuds dans une situation où les processus du système d'exploitation et les démons Kubernetes (environnement d'exécution des conteneurskubelet, etc.) sont en concurrence avec les pods pour les ressources système. Vous pouvez utiliser kubelet des drapeaux --system-reserved et --kube-reserved réserver des ressources pour les processus système (udev,sshd, etc.) et les démons Kubernetes respectivement.

Si vous utilisez l'AMI Linux optimisée pour EKS, le processeur, la mémoire et le stockage sont réservés par défaut au système et aux daemons Kubernetes. Lorsque les nœuds de travail basés sur cette AMI sont lancés, EC2 les données utilisateur sont configurées pour déclencher le bootstrap.shscript. Ce script calcule les réservations de processeur et de mémoire en fonction du nombre de cœurs de processeur et de la mémoire totale disponible sur l' EC2 instance. Les valeurs calculées sont écrites dans le KubeletConfiguration fichier situé à l'adresse/etc/kubernetes/kubelet/kubelet-config.json.

Vous devrez peut-être augmenter la réservation des ressources système si vous exécutez des démons personnalisés sur le nœud et si la quantité de processeur et de mémoire réservée par défaut est insuffisante.

eksctloffre le moyen le plus simple de personnaliser la réservation des ressources pour le système et les démons Kubernetes.

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 demandes/limites de ressources 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 lors de l'exécution. Les autres outils qui peuvent être utiles pour déterminer la taille des demandes sont les suivants :

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 stockage et/ou de calcul (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 au sein d'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.

CoreDNS

CoreDNS remplit les fonctions de résolution de noms et de découverte de services dans Kubernetes. Il est installé par défaut sur les clusters EKS. Pour des raisons d'interopérabilité, le service Kubernetes pour CoreDNS est toujours appelé kube-dns. Les pods CoreDNS s'exécutent dans le cadre d'un déploiement kube-system dans un espace de noms, et dans EKS, par défaut, ils exécutent deux répliques avec des demandes et des limites déclarées. Les requêtes DNS sont envoyées au kube-dns service qui s'exécute dans l'espace de kube-system noms.

Recommandations

Surveillez les métriques CoreDNS

CoreDNS a intégré le support de Prometheus. Vous devriez notamment envisager de surveiller la latence de CoreDNS coredns_dns_request_duration_seconds_sum (avant la version 1.7.0, la métrique était core_dns_response_rcode_count_total appelée), les erreurs coredns_dns_responses_total (, NXDOMAIN, SERVFAIL, FormErr) et la consommation de mémoire du CoreDNS Pod.

À des fins de résolution des problèmes, vous pouvez utiliser kubectl pour afficher les journaux CoreDNS :

for p in $(kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].metadata.name}'); do kubectl logs $p -n kube-system; done

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.

Configuration cluster-proportional-scaler pour CoreDNS

Une autre méthode pour améliorer les performances du DNS du cluster consiste à dimensionner automatiquement horizontalement le déploiement CoreDNS en fonction du nombre de nœuds et de cœurs de processeur du cluster. Horizontal cluster-proportional-autoscaler est un conteneur qui redimensionne le nombre de répliques d'un déploiement en fonction de la taille du plan de données planifiable.

Les nœuds et l'agrégation des cœurs de processeur dans les nœuds sont les deux indicateurs avec lesquels vous pouvez dimensionner CoreDNS. Vous pouvez utiliser les deux indicateurs simultanément. Si vous utilisez des nœuds plus grands, le dimensionnement CoreDNS est basé sur le nombre de cœurs de processeur. Par contre, si vous utilisez des nœuds plus petits, le nombre de répliques CoreDNS dépend des cœurs de processeur de votre plan de données. La configuration de l'autoscaler proportionnel ressemble à ceci :

linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'

Choix d'une AMI avec un groupe de nœuds

EKS fournit des solutions optimisées EC2 AMIs qui sont utilisées par les clients pour créer des groupes de nœuds autogérés et gérés. Ils AMIs sont publiés dans chaque région pour chaque version de Kubernetes prise en charge. EKS les marque AMIs comme obsolètes lorsqu'un bogue est découvert. CVEs Par conséquent, il est recommandé de ne pas utiliser de produit obsolète AMIs lors du choix d'une AMI pour le groupe de nœuds.

La version obsolète AMIs peut être filtrée à l'aide de l'API Ec2 describe-images à l'aide de la commande ci-dessous :

aws ec2 describe-images --image-id ami-0d551c4f633e7679c --no-include-deprecated

Vous pouvez également reconnaître une AMI obsolète en vérifiant si la sortie describe-image contient un DeprecationTime champ en tant que. Par exemple :

aws ec2 describe-images --image-id ami-xxx --no-include-deprecated
{
    "Images": [
        {
            "Architecture": "x86_64",
            "CreationDate": "2022-07-13T15:54:06.000Z",
            "ImageId": "ami-xxx",
            "ImageLocation": "123456789012/eks_xxx",
            "ImageType": "machine",
            "Public": false,
            "OwnerId": "123456789012",
            "PlatformDetails": "Linux/UNIX",
            "UsageOperation": "RunInstances",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/xvda",
                    "Ebs": {
                        "DeleteOnTermination": true,
                        "SnapshotId": "snap-0993a2fc4bbf4f7f4",
                        "VolumeSize": 20,
                        "VolumeType": "gp2",
                        "Encrypted": false
                    }
                }
            ],
            "Description": "EKS Kubernetes Worker AMI with AmazonLinux2 image, (k8s: 1.19.15, docker: 20.10.13-2.amzn2, containerd: 1.4.13-3.amzn2)",
            "EnaSupport": true,
            "Hypervisor": "xen",
            "Name": "aws_eks_optimized_xxx",
            "RootDeviceName": "/dev/xvda",
            "RootDeviceType": "ebs",
            "SriovNetSupport": "simple",
            "VirtualizationType": "hvm",
            "DeprecationTime": "2023-02-09T19:41:00.000Z"
        }
    ]
}