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.

Meilleures pratiques en matière de fiabilité

Cette section fournit des conseils pour rendre les charges de travail exécutées sur EKS résilientes et hautement disponibles

Comment utiliser ce guide

Ce guide est destiné aux développeurs et aux architectes qui souhaitent développer et exploiter des services hautement disponibles et tolérants aux pannes dans EKS. Le guide est organisé en différents domaines thématiques pour en faciliter la lecture. Chaque rubrique commence par un bref aperçu, suivi d'une liste de recommandations et de bonnes pratiques pour la fiabilité de vos clusters EKS.

Introduction

Les meilleures pratiques en matière de fiabilité pour EKS ont été regroupées sous les rubriques suivantes :

Qu'est-ce qui rend un système fiable ? Si un système peut fonctionner de manière cohérente et répondre aux demandes malgré l'évolution de son environnement au fil du temps, il peut être qualifié de fiable. Pour y parvenir, le système doit détecter les défaillances, se réparer automatiquement et être capable d'évoluer en fonction de la demande.

Les clients peuvent utiliser Kubernetes comme base pour exploiter de manière fiable des applications et des services critiques. Outre l'intégration des principes de conception d'applications basées sur des conteneurs, l'exécution fiable des charges de travail nécessite également une infrastructure fiable. Dans Kubernetes, l'infrastructure comprend le plan de contrôle et le plan de données.

EKS fournit un plan de contrôle Kubernetes de niveau production, conçu pour être hautement disponible et tolérant aux pannes.

Dans EKS, AWS est responsable de la fiabilité du plan de contrôle de Kubernetes. EKS exécute le plan de contrôle Kubernetes dans trois zones de disponibilité d'une région AWS. Il gère automatiquement la disponibilité et l'évolutivité des serveurs API Kubernetes et du cluster etcd.

La responsabilité de la fiabilité du plan de données est partagée entre vous, le client, et AWS. EKS propose quatre options de nœuds de travail pour déployer le plan de données Kubernetes.

Le mode automatique EKS, qui est l'option la plus gérée, gère le provisionnement, la mise à l'échelle et les mises à jour du plan de données, tout en fournissant des fonctionnalités de calcul, de mise en réseau et de stockage gérées. Les AMI en mode automatique sont publiées fréquemment et les clusters sont automatiquement mis à jour avec la dernière AMI afin de déployer les correctifs CVE et les correctifs de sécurité. Vous pouvez contrôler le moment où cela se produit en configurant les commandes d'interruption sur votre mode automatique NodePools.

Fargate gère le provisionnement et la mise à l'échelle du plan de données en exécutant un pod par nœud. La troisième option, les groupes de nœuds gérés, gère le provisionnement et les mises à jour du plan de données. Enfin, les nœuds autogérés constituent l'option la moins gérée pour le plan de données. Plus vous utilisez de plans de AWS-managed données, moins vous avez de responsabilités.

Les groupes de nœuds gérés automatisent le provisionnement et la gestion du cycle de vie des nœuds EC2. Vous pouvez utiliser l'API EKS (à l'aide de la console EKS, de l'API AWS, de l'AWS CLICloudFormation, Terraform oueksctl) pour créer, faire évoluer et mettre à niveau des nœuds gérés. Les nœuds gérés exécutent des instances EKS-optimized Amazon Linux 2 EC2 sur votre compte, et vous pouvez installer des packages logiciels personnalisés en activant l'accès SSH. Lorsque vous provisionnez des nœuds gérés, ils s'exécutent dans le cadre d'un groupe EKS-managed Auto Scaling qui peut couvrir plusieurs zones de disponibilité ; vous contrôlez cela via les sous-réseaux que vous fournissez lors de la création de nœuds gérés. EKS étiquette également automatiquement les nœuds gérés afin qu'ils puissent être utilisés avec Cluster Autoscaler.

Amazon EKS suit le modèle de responsabilité partagée pour les CVE et les correctifs de sécurité sur les groupes de nœuds gérés. Étant donné que les nœuds gérés exécutent les EKS-optimized AMI Amazon, Amazon EKS est chargé de créer des versions corrigées de ces AMI lorsque des bogues sont corrigés. Toutefois, vous êtes responsable du déploiement de ces versions d'AMI corrigées vers vos groupes de nœuds gérés.

EKS gère également la mise à jour des nœuds, bien que vous deviez lancer le processus de mise à jour. Le processus de mise à jour du nœud géré est expliqué dans la documentation EKS.

Si vous exécutez des nœuds autogérés, vous pouvez utiliser l'AMI Amazon EKS-optimized Linux pour créer des nœuds de travail. Vous êtes responsable de l'application des correctifs et de la mise à niveau de l'AMI et des nœuds. Il est recommandé d'utiliser l'eksctlinfrastructure en tant qu'outils de code pour provisionner des nœuds autogérés CloudFormation, car cela vous permettra de mettre facilement à niveau les nœuds autogérés. Envisagez de migrer vers de nouveaux nœuds lors de la mise à jour des nœuds de travail, car le processus de migration altère l'ancien groupe de nœuds NoSchedule et vide les nœuds une fois qu'une nouvelle pile est prête à accepter la charge de travail des pods existante. Cependant, vous pouvez également effectuer une mise à niveau sur place des nœuds autogérés.

Modèle de responsabilité partagée - Fargate

Modèle de responsabilité partagée - MNG

Ce guide inclut un ensemble de recommandations que vous pouvez utiliser pour améliorer la fiabilité de votre plan de données EKS, des composants principaux de Kubernetes et de vos applications.

Commentaires

Ce guide est publié GitHub afin de recueillir des commentaires directs et des suggestions de la part de l'ensemble de la EKS/Kubernetes communauté. Si vous pensez que nous devrions inclure une bonne pratique dans le guide, veuillez signaler un problème ou soumettre un PR dans le GitHub référentiel. Nous avons l'intention de mettre à jour le guide périodiquement à mesure que de nouvelles fonctionnalités sont ajoutées au service ou lorsqu'une nouvelle meilleure pratique évolue.