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 sur la manière de rendre les charges de travail 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 consommation. Chaque rubrique commence par un bref aperçu, suivi d'une liste de recommandations et de bonnes pratiques pour la fiabilité de vos EKS clusters.

Introduction

Les meilleures pratiques 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é les changements survenus dans son environnement au fil du temps, il peut être qualifié de fiable. Pour ce faire, 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. Mais outre l'intégration des principes de conception d'applications basés 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.

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

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

La responsabilité de la fiabilité du plan de données est partagée entre vous, le client etAWS. EKSpropose trois options de nœuds de travail pour déployer le plan de données Kubernetes. Fargate, qui est l'option la plus gérée, gère le provisionnement et le dimensionnement du plan de données. La deuxiè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 un plan de données AWS géré, moins vous êtes responsable.

Les groupes de nœuds gérés automatisent le provisionnement et la gestion du cycle de vie des EC2 nœuds. Vous pouvez utiliser le EKS API (à l'aide de EKS la console AWSAPI, AWSCLI,CloudFormation,, Terraform oueksctl) pour créer, dimensionner et mettre à niveau des nœuds gérés. Les nœuds gérés exécutent des EC2 instances Amazon Linux 2 EKS optimisées sur votre compte, et vous pouvez installer des packages logiciels personnalisés en activant SSH l'accès. Lorsque vous provisionnez des nœuds gérés, ils s'exécutent dans le cadre d'un groupe Auto Scaling EKS géré pouvant 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. EKSbalise é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 CVEs et les correctifs de sécurité sur les groupes de nœuds gérés. Comme les nœuds gérés exécutent le système EKS optimisé pour AmazonAMIs, Amazon EKS est chargé de créer des versions corrigées de ceux-ci AMIs lors de la correction de bogues. Toutefois, vous êtes responsable du déploiement de ces AMI versions corrigées sur vos groupes de nœuds gérés.

EKSgè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 EKS documentation.

Si vous exécutez des nœuds autogérés, vous pouvez utiliser Linux EKS optimisé pour Amazon pour créer des nœuds AMI de travail. Vous êtes responsable de l'application des correctifs et de la AMI mise à niveau des nœuds. Il est recommandé d'utiliser ou d'utiliser l'eksctlinfrastructure en tant qu'outils de code pour provisionner des nœuds autogérés, car cela vous permettra de mettre à niveau facilement les nœuds autogérés. CloudFormation Envisagez de migrer vers de nouveaux nœuds lorsque vous mettez à jour des nœuds de travail, car le processus de migration altère l'ancien groupe de nœuds NoSchedule et épuise les nœuds une fois qu'une nouvelle pile est prête à accepter la charge de travail du pod existant. Toutefois, 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 EKS données, des composants principaux de Kubernetes et de vos applications.

Commentaires

Ce guide est publié GitHub pour recueillir les commentaires directs et les suggestions de l'ensemble de la communauté EKS /Kubernetes. Si vous avez une bonne pratique que vous pensez que nous devrions inclure 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 régulièrement à mesure que de nouvelles fonctionnalités sont ajoutées au service ou lorsqu'une nouvelle bonne pratique évolue.

📝 Modifiez cette page sur GitHub