Architecture EKS Recommandations Surveiller les métriques du plan de contrôle Authentification du cluster Webhooks d'admission Gestion des mises à niveau des clusters Connectivité des terminaux de cluster Exécution de grands clusters Ressources supplémentaires :

Plan de contrôle EKS

Astuce

Découvrez les meilleures pratiques grâce aux ateliers Amazon EKS.

Amazon Elastic Kubernetes Service (EKS) est un service Kubernetes géré qui vous permet d'exécuter facilement Kubernetes sur AWS sans avoir à installer, exploiter et gérer votre propre plan de contrôle Kubernetes ou vos propres nœuds de travail. Il exécute Kubernetes en amont et est certifié conforme à Kubernetes. Cette conformité garantit qu'EKS prend en charge les API Kubernetes, tout comme la version communautaire open source que vous pouvez installer sur EC2 ou sur site. Les applications existantes exécutées sur Kubernetes en amont sont compatibles avec Amazon EKS.

EKS gère automatiquement la disponibilité et l'évolutivité des nœuds du plan de contrôle de Kubernetes et remplace automatiquement les nœuds du plan de contrôle défectueux.

Architecture EKS

L'architecture EKS est conçue pour éliminer tout point de défaillance unique susceptible de compromettre la disponibilité et la durabilité du plan de contrôle Kubernetes.

Le plan de contrôle Kubernetes géré par EKS s'exécute dans un VPC géré par EKS. Le plan de contrôle EKS comprend les nœuds du serveur d'API Kubernetes, etc., le cluster. Nœuds de serveur d'API Kubernetes qui exécutent des composants tels que le serveur d'API, le planificateur et kube-controller-manager s'exécutent dans un groupe de mise à l'échelle automatique. EKS gère au moins deux nœuds de serveur d'API dans des zones de disponibilité (AZ) distinctes au sein d'une région AWS. De même, pour des raisons de durabilité, les nœuds du serveur etcd s'exécutent également dans un groupe de mise à l'échelle automatique qui s'étend sur trois AZ. EKS exécute une passerelle NAT dans chaque zone de disponibilité, et les serveurs API et les serveurs etcd s'exécutent dans un sous-réseau privé. Cette architecture garantit qu'un événement dans une seule zone de disponibilité n'affecte pas la disponibilité du cluster EKS.

Lorsque vous créez un nouveau cluster, Amazon EKS crée un point de terminaison hautement disponible pour le serveur d'API Kubernetes géré que vous utilisez pour communiquer avec votre cluster (à l'aide d'outils tels que). kubectl Le terminal géré utilise NLB pour équilibrer la charge des serveurs API Kubernetes. EKS fournit également deux ENI dans différents AZ pour faciliter la communication avec vos nœuds de travail.

Connectivité réseau EKS Data Plane

Vous pouvez configurer si le serveur d'API de votre cluster Kubernetes est accessible depuis l'Internet public (via le point de terminaison public) ou via votre VPC (via l' EKS-managed ENiS) ou les deux.

Que les utilisateurs et les nœuds de travail se connectent au serveur API via le point de terminaison public ou l' EKS-managed ENI, il existe des chemins de connexion redondants.

Recommandations

Passez en revue les recommandations suivantes.

Surveiller les métriques du plan de contrôle

La surveillance des métriques de l'API Kubernetes peut vous donner des informations sur les performances du plan de contrôle et identifier les problèmes. Un plan de contrôle défectueux peut compromettre la disponibilité des charges de travail exécutées au sein du cluster. Par exemple, des contrôleurs mal écrits peuvent surcharger les serveurs d'API, affectant ainsi la disponibilité de votre application.

Kubernetes expose les métriques du plan de contrôle au point de terminaison. /metrics

Vous pouvez consulter les métriques exposées en utilisant kubectl :


kubectl get --raw /metrics

Ces métriques sont représentées dans un format texte Prometheus.

Vous pouvez utiliser Prometheus pour collecter et stocker ces statistiques. En mai 2020, la prise en charge de la surveillance des métriques Prometheus CloudWatch a été ajoutée dans CloudWatch Container Insights. Vous pouvez donc également utiliser Amazon CloudWatch pour surveiller le plan de contrôle EKS. Vous pouvez utiliser Tutorial for Adding a New Prometheus Scrape Target : Prometheus KPI Server Metrics pour collecter des métriques et créer un tableau de CloudWatch bord pour surveiller le plan de contrôle de votre cluster.

Vous trouverez les statistiques du serveur d'API Kubernetes ici. https://github.com/kubernetes/apiserver/blob/master/pkg/endpoints/metrics/metrics.go Par exemple, apiserver_request_duration_seconds peut indiquer la durée d'exécution des requêtes d'API.

Envisagez de surveiller ces métriques du plan de contrôle :

Serveur d'API

Métrique	Description
`apiserver_request_total`	Compteur de requêtes apiserver ventilées pour chaque verbe, valeur d'exécution à sec, groupe, version, ressource, portée, composant et code de réponse HTTP.
`apiserver_request_duration_seconds*`	Histogramme de latence de réponse en secondes pour chaque verbe, valeur d'exécution à vide, groupe, version, ressource, sous-ressource, portée et composant.
`apiserver_admission_controller_admission_duration_seconds*`	Histogramme de latence du contrôleur d'admission en secondes, identifié par son nom et ventilé pour chaque opération, ressource et type d'API (validation ou admission).
`apiserver_admission_webhook_rejection_count`	Nombre de refus de webhooks d'admission. Identifié par nom, opération, rejection_code, type (validation ou admission), error_type (calling_webhook_error, apiserver_internal_error, no_error)
`rest_client_request_duration_seconds*`	Demandez un histogramme de latence en secondes. Réparti par verbe et par URL.
`rest_client_requests_total`	Nombre de requêtes HTTP, partitionnées par code d'état, méthode et hôte.

Les mesures de l'histogramme incluent les suffixes _bucket, _sum et _count.

etcd

Métrique	Description
`etcd_request_duration_seconds*`	Histogramme de latence des requêtes Etcd en secondes pour chaque opération et type d'objet.
`apiserver_storage_db_total_size_in_bytes`ou `apiserver_storage_size_bytes` (à partir de EKS v1.28)	Taille de la base de données Etcd.

Les mesures de l'histogramme incluent les suffixes _bucket, _sum et _count.

Envisagez d'utiliser le tableau de bord de présentation de la surveillance de Kubernetes pour visualiser et surveiller les requêtes du serveur d'API Kubernetes ainsi que les mesures de latence et de latence etcd.

Important

Lorsque la limite de taille de la base de données est dépassée, etcd émet une alarme d'absence d'espace et arrête de prendre d'autres demandes d'écriture. En d'autres termes, le cluster passe en lecture seule et toutes les demandes de mutation d'objets, telles que la création de nouveaux pods, la mise à l'échelle des déploiements, etc., seront rejetées par le serveur d'API du cluster.

Authentification du cluster

EKS prend actuellement en charge deux types d'authentification : les jetons de bearer/service compte et l'authentification IAM qui utilise l'authentification par jeton Webhook. Lorsque les utilisateurs appellent l'API Kubernetes, un webhook transmet un jeton d'authentification inclus dans la demande à IAM. Le jeton, une URL signée en base 64, est généré par l'interface de ligne de commande AWS (AWS CLI).

L'utilisateur ou le rôle IAM qui crée le cluster EKS obtient automatiquement un accès complet au cluster. Vous pouvez gérer l'accès au cluster EKS en modifiant la carte de configuration aws-auth.

Si vous ne configurez pas correctement le aws-auth configmap et que vous perdez l'accès au cluster, vous pouvez toujours utiliser l'utilisateur ou le rôle du créateur du cluster pour accéder à votre cluster EKS.

Dans le cas peu probable où vous ne pourriez pas utiliser le service IAM dans la région AWS, vous pouvez également utiliser le jeton porteur du compte de service Kubernetes pour gérer le cluster.

Créez un super-admin compte autorisé à effectuer toutes les actions du cluster :


kubectl -n kube-system create serviceaccount super-admin

Créez une liaison de rôle qui donne le rôle superadmin cluster-admin :


kubectl create clusterrolebinding super-admin-rb --clusterrole=cluster-admin --serviceaccount=kube-system:super-admin

Obtenez le secret du compte de service :


SECRET_NAME=`kubectl -n kube-system get serviceaccount/super-admin -o jsonpath='{.secrets[0].name}'`

Obtenez le jeton associé au secret :


TOKEN=`kubectl -n kube-system get secret $SECRET_NAME -o jsonpath='{.data.token}'| base64 --decode`

Ajoutez un compte de service et un jeton à kubeconfig :


kubectl config set-credentials super-admin --token=$TOKEN

Définissez le contexte actuel kubeconfig pour utiliser le compte super-admin :


kubectl config set-context --current --user=super-admin

La finale kubeconfig devrait ressembler à ceci :


apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:<REDACTED>
    server: https://<CLUSTER>.gr7.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
contexts:
- context:
    cluster: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
    user: super-admin
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
current-context: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
kind: Config
preferences: {}
users:
#- name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
#  user:
#    exec:
#      apiVersion: client.authentication.k8s.io/v1beta1
#      args:
#      - --region
#      - us-west-2
#      - eks
#      - get-token
#      - --cluster-name
#      - <<cluster name>>
#      command: aws
#      env: null
- name: super-admin
  user:
    token: <<super-admin sa's secret>>

Webhooks d'admission

Kubernetes possède deux types de webhooks d'admission : les webhooks d'admission de validation et les webhooks d'admission mutants. Ils permettent à un utilisateur d'étendre l'API kubernetes et de valider ou de muter des objets avant qu'ils ne soient acceptés par l'API. De mauvaises configurations de ces webhooks peuvent déstabiliser le plan de contrôle EKS en bloquant les opérations critiques du cluster.

Afin d'éviter d'affecter les opérations critiques du cluster, évitez de configurer des webhooks « fourre-tout » comme suit :


- name: "pod-policy.example.com"
  rules:
  - apiGroups:   ["*"]
    apiVersions: ["*"]
    operations:  ["*"]
    resources:   ["*"]
    scope: "*"

Ou assurez-vous que le webhook dispose d'une politique d'échec d'ouverture avec un délai d'attente inférieur à 30 secondes pour vous assurer que si votre webhook n'est pas disponible, cela n'affectera pas les charges de travail critiques du cluster.

Bloquer les pods dont les `systèmes ne sont pas sécurisés`

Sysctlest un utilitaire Linux qui permet aux utilisateurs de modifier les paramètres du noyau pendant l'exécution. Ces paramètres du noyau contrôlent divers aspects du comportement du système d'exploitation, tels que le réseau, le système de fichiers, la mémoire virtuelle et la gestion des processus.

Kubernetes permet d'attribuer sysctl des profils aux Pods. Kubernetes les classe systcls comme étant sûrs et dangereux. sysctlsLes Safe sont placés dans un espace de noms dans le conteneur ou le pod, et leur configuration n'a aucun impact sur les autres pods du nœud ou sur le nœud lui-même. En revanche, les fichiers sysctls non sécurisés sont désactivés par défaut car ils peuvent potentiellement perturber d'autres Pods ou rendre le nœud instable.

Comme sysctls les fichiers non sécurisés sont désactivés par défaut, le kubelet ne créera pas de Pod avec un profil non sécurisésysctl. Si vous créez un tel Pod, le planificateur attribuera à plusieurs reprises ces Pods aux nœuds, mais le nœud ne le lancera pas. Cette boucle infinie met finalement à rude épreuve le plan de contrôle du cluster, ce qui le rend instable.

Envisagez d'utiliser OPA Gatekeeper ou Kyverno pour rejeter les Pods présentant un danger. sysctls

Gestion des mises à niveau des clusters

Depuis avril 2021, le cycle de publication de Kubernetes est passé de quatre versions par an (une fois par trimestre) à trois versions par an. Une nouvelle version mineure (comme 1. 21 ou 1. 22) est publié toutes les quinze semaines environ. À partir de Kubernetes 1.19, chaque version mineure est prise en charge pendant environ douze mois après sa première publication. Avec l'avènement de Kubernetes v1.28, le biais de compatibilité entre le plan de contrôle et les nœuds de travail est passé de n-2 à n-3 versions mineures. Pour en savoir plus, consultez la section Meilleures pratiques pour les mises à niveau des clusters.

Connectivité des terminaux de cluster

Lorsque vous travaillez avec Amazon EKS (Elastic Kubernetes Service), vous pouvez rencontrer des délais de connexion ou des erreurs lors d'événements tels que la mise à l'échelle du plan de contrôle de Kubernetes ou l'application de correctifs. Ces événements peuvent entraîner le remplacement des instances de kube-apiserver, ce qui peut entraîner le renvoi d'adresses IP différentes lors de la résolution du FQDN. Ce document décrit les meilleures pratiques pour les utilisateurs d'API Kubernetes afin de maintenir une connectivité fiable.

Note

La mise en œuvre de ces meilleures pratiques peut nécessiter des mises à jour des configurations des clients ou des scripts pour gérer efficacement les nouvelles stratégies de rerésolution et de nouvelle tentative du DNS.

Le principal problème provient de la mise en cache côté client du DNS et de la possibilité d'adresses IP périmées du point de terminaison EKS, à savoir le NLB public pour le point de terminaison public ou le point de terminaison privé. X-ENI Lorsque les instances de kube-apiserver sont remplacées, le nom de domaine complet (FQDN) peut être résolu en nouvelles adresses IP. Toutefois, en raison des paramètres DNS Time to Live (TTL), qui sont définis sur 60 secondes dans la zone Route 53 gérée par AWS, les clients peuvent continuer à utiliser des adresses IP obsolètes pendant une courte période.

Pour atténuer ces problèmes, les utilisateurs de l'API Kubernetes (tels que kubectl, CI/CD pipelines et applications personnalisées) doivent mettre en œuvre les meilleures pratiques suivantes :

Mettre en œuvre la re-résolution du DNS
Implémentez Retries avec Backoff et Jitter. Par exemple, consultez cet article intitulé Failures Happen
Implémentez les délais d'expiration des clients. Définissez des délais d'attente appropriés pour éviter que les demandes de longue durée ne bloquent votre application. Sachez que certaines bibliothèques clientes Kubernetes, en particulier celles générées par les générateurs OpenAPI, peuvent ne pas permettre de définir facilement des délais d'expiration personnalisés.
- Exemple 1 avec kubectl :
```
  kubectl get pods --request-timeout 10s # default: no timeout
```
- Exemple 2 avec Python : le client Kubernetes fournit un paramètre _request_timeout

En mettant en œuvre ces bonnes pratiques, vous pouvez améliorer de manière significative la fiabilité et la résilience de vos applications lors de l'interaction avec l'API Kubernetes. N'oubliez pas de tester ces implémentations de manière approfondie, en particulier dans des conditions de défaillance simulées, pour vous assurer qu'elles se comportent comme prévu lors d'événements de dimensionnement ou d'application de correctifs réels.

Exécution de grands clusters

EKS surveille activement la charge sur les instances du plan de contrôle et les dimensionne automatiquement pour garantir des performances élevées. Cependant, vous devez tenir compte des problèmes de performances et des limites potentiels au sein de Kubernetes et des quotas dans les services AWS lorsque vous exécutez de grands clusters.

Selon les tests effectués par l' ProjectCalico équipe, les clusters contenant plus de 1 000 services peuvent présenter une latence réseau kube-proxy en cas d'utilisation en iptables mode actif. La solution consiste à passer kube-proxy en ipvs mode fonctionnement.
Vous pouvez également rencontrer une limitation des demandes d'API EC2 si le CNI doit demander des adresses IP pour les Pods ou si vous devez créer fréquemment de nouvelles instances EC2. Vous pouvez réduire les appels à l'API EC2 en configurant le CNI pour mettre en cache les adresses IP. Vous pouvez utiliser des types d'instances EC2 plus importants pour réduire les événements de dimensionnement EC2.

Ressources supplémentaires :

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Applications

Plan de données