Sélectionnez les types d'instances et leur emplacement pour les clusters locaux Amazon EKS sur AWS Outposts configurés avec le magasin d'instances EC2

Cette rubrique fournit des conseils pour sélectionner les types d'instances du plan de contrôle Kubernetes et configurer le placement afin de répondre aux exigences de haute disponibilité de votre cluster Amazon EKS local sur un AWS Outpost configuré avec un magasin d'instances EC2.

Note

Si votre Outpost est configuré avec Amazon EBS au lieu du magasin d'instances EC2, l'architecture décrite dans cette rubrique n'est pas disponible pour votre Outpost. Les Outposts configurés avec EBS continueront à utiliser l'implémentation des clusters locaux existants. Pour de plus amples informations, veuillez consulter Sélectionnez les types d'instances et les groupes de placement pour les clusters Amazon EKS sur AWS Outposts basés sur des considérations de capacité.

Si vous souhaitez créer un cluster local sur un EBS-backed Outpost à l'aide de l'architecture de clusters locaux mise à jour, contactez l'équipe chargée de votre AWS compte.

Architecture du plan de contrôle

Le plan de contrôle Kubernetes du cluster local s'exécute sur 6 instances EC2 sur votre Outpost :

• 3 instances de plan de contrôle : hébergent les composants du plan de contrôle Kubernetes, notamment le serveur d'API Kubernetes, le planificateur et le gestionnaire de contrôleurs.

• 3 etcd instances : stockez l'état du cluster Kubernetes dans une topologie etcd externe.

Ces instances s'exécutent dans un compte de service AWS géré sur votre Outpost. Elles n'apparaissent pas en tant qu'instances EC2 dans votre AWS compte ou dans la console Amazon EC2. La capacité consommée par le plan de contrôle est visible dans la console AWS Outposts.

Le plan de contrôle ne s'ajuste pas horizontalement sous la charge. Si vous avez besoin d'une taille d'instance de plan de contrôle différente, vous devez créer un nouveau cluster.

Sélection du type d'instance

Grâce à l'architecture mise à jour pour les clusters locaux Amazon EKS sur AWS Outposts, le plan de contrôle Kubernetes utilise une etcd topologie dédiée : le serveur d'API et s'exécute sur des instances distinctes. etcd Lorsque vous créez un cluster, vous spécifiez deux types d'instance : controlPlaneInstanceType pour le serveur d'API et etcdInstanceType pouretcd.

Les types d'instances que vous choisissez doivent être disponibles sur votre Outpost. Les familles d'instances disponibles dépendent de la génération et du SKU de votre Outpost, et les différentes familles d'instances peuvent avoir différentes configurations de vCPU et de mémoire pour la même taille d'instance.

Serveur d'APIcontrolPlaneInstanceType ()

Nœuds de travail attendus	vCPUs	Mémoire
1-20	2	8 GiO
21–100	4	16 GiO
101–250	8	32 GiO
251–500	16	64 Go

etcd (etcdInstanceType)

Nœuds de travail attendus	vCPUs	Mémoire
1 à 50	2	8 GiO
51—250	4	16 GiO
251–500	8	32 GiO

Important

Assurez-vous que votre avant-poste peut accueillir 3 instances controlPlaneInstanceType et 3 instances pendant toute la durée de etcdInstanceType vie de votre cluster local.

Utilisez ces tableaux à titre indicatif plutôt que comme exigence stricte. Nous vous recommandons de sélectionner une famille d'instances et une taille adaptées à votre croissance prévue, car elles controlPlaneInstanceType ne etcdInstanceType peuvent pas être modifiées après la création du cluster. Pour modifier l'un ou l'autre, vous devez créer un nouveau cluster.

Plan de contrôle et placement, etc.

Pour une haute disponibilité, nous vous recommandons de répartir votre plan de contrôle et vos etcd instances sur plusieurs domaines de défaillance matérielle. Vous pouvez contrôler cet écart à l'aide de la spreadLevel propriété « on » controlPlanePlacement et « etcdPlacement in outpostConfig ». Lorsque vous définissezspreadLevel, Amazon EKS crée un groupe de placement EC2 avec la stratégie Spread. Il n'est pas nécessaire de créer un groupe de placement au préalable.

Note

Le groupName paramètre in n'controlPlanePlacementest pas utilisé avec les Outposts qui exécutent des instances EC2 basées sur le magasin d'instances. Si vous utilisiez auparavant un groupe de placement avec un cluster local, vous l'utilisez désormais à la spreadLevel place.

Niveaux de propagation

La spreadLevel propriété accepte deux valeurs :

• host— Répartit les instances du plan de contrôle sur différents hôtes physiques. Nécessite au moins 3 hôtes configurés avec le type d'instance choisi.

• rack— Répartit les instances du plan de contrôle sur différents racks physiques d'Outpost. Nécessite au moins 3 racks avec des hôtes configurés avec le type d'instance choisi.

Planification de la capacité

Lorsque vous planifiez la capacité d'un avant-poste pour les clusters locaux, tenez compte des éléments suivants :

• Plan de contrôle et etcd instances : 6 instances par cluster (3 controlPlaneInstanceType et 3etcdInstanceType).

• Nœuds de travail : instances EC2 pour vos groupes de nœuds autogérés.

• Hôtes virtualisés : le plan de contrôle doit s'exécuter sur des hôtes virtualisés. Votre Outpost doit disposer d'hôtes virtualisés dotés d'une capacité suffisante.

Résolution des problèmes de placement

Si votre cluster reste dans l'UPDATINGétat CREATING ou pendant une période prolongée après avoir spécifié un niveau de spread, vérifiez que votre Outpost dispose de suffisamment d'hôtes ou de racks avec le type d'instance choisi pour satisfaire à la topologie de spread.

Pour plus d'informations sur le dépannage des clusters locaux, consultezRésoudre les problèmes liés aux clusters Amazon EKS locaux sur AWS Outposts configurés avec le magasin d'instances EC2.