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.
Cluster local EKS sur les Outposts
Lorsque le lien de service Outposts est déconnecté de la région parent, des problèmes peuvent se poser avec des services tels que EKS Extended Cluster, où le plan de contrôle réside dans la région. Parmi les défis figure la perte de communication entre le plan de contrôle EKS et les nœuds de travail et PODs. Bien que les deux nœuds de travail PODs puissent continuer à fonctionner et à gérer les applications résidant sur les Outposts localement, le plan de contrôle Kubernetes peut les considérer comme défaillants et planifier leur remplacement lorsque la connexion au plan de contrôle sera rétablie. Cela peut entraîner des interruptions de service des applications lorsque la connectivité est rétablie.
Pour simplifier les choses, il existe une option permettant d'héberger l'intégralité de votre cluster EKS sur Outposts. Dans cette configuration, le plan de contrôle Kubernetes et vos nœuds de travail s'exécutent localement sur site sur la capacité de calcul de vos Outposts. Ainsi, votre cluster continue de fonctionner même en cas d'interruption temporaire de votre connexion Service Link et après sa restauration.
Cluster local Amazon EKS sur Outposts
Considérations relatives au cluster local EKS sur Outposts
Certaines considérations doivent être prises en compte lors du déploiement d'un cluster local EKS dans Outposts :
-
Lors d'une déconnexion, il n'existe aucune option permettant d'exécuter une modification dans le cluster lui-même nécessitant l'ajout de nouveaux nœuds de travail ou la mise à l'échelle automatique d'un groupe de nœuds, tant que cela dépend EC2 des appels d'API ASG vers la AWS région parent.
-
• Il existe un ensemble de fonctionnalités non prises en charge sur les clusters locaux répertoriées sur le support eksctl AWS Outposts
. .
