Aidez à améliorer cette page
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.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.
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.
Cette rubrique traite de certaines erreurs courantes que vous pourriez rencontrer lorsque vous utilisez des clusters locaux, ainsi que des solutions. Les clusters locaux sont similaires aux clusters Amazon EKS dans le cloud, mais ils sont gérés différemment par Amazon EKS.
Important
Ne mettez jamais fin à une instance de Kubernetes plan de contrôle du cluster local EKS gérée exécutée sur Outpost, sauf indication explicite du Support. AWS La mise hors service de ces instances représente un risque pour la disponibilité du service de cluster local, notamment la perte du cluster local en cas de résiliation simultanée de plusieurs instances. Les instances du Kubernetes plan de contrôle du cluster local EKS sont identifiées par la balise eks-local:controlplane-name sur la console d' EC2 instance.
Les clusters locaux sont créés via l'API Amazon EKS, mais sont exécutés de manière asynchrone. Cela signifie que les demandes adressées à l'API Amazon EKS aboutissent immédiatement pour les clusters locaux. Toutefois, ces demandes peuvent aboutir, effectuer une interruption immédiate en raison d'erreurs de validation d'entrée, ou échouer et comporter des erreurs de validation descriptives. Ce comportement est similaire à celui de l'API Kubernetes.
Les clusters locaux ne passent pas à un FAILED statut. Amazon EKS tente de rapprocher l'état du cluster de l'état souhaité demandé par l'utilisateur de manière continue. Par conséquent, un cluster local peut rester dans l'état CREATING pendant une longue période, jusqu'à ce que le problème sous-jacent soit résolu.
Les problèmes de cluster locaux peuvent être découverts à l'aide de la commande describe-cluster Amazon EKS AWS CLI. Les problèmes de clusters locaux sont mis en évidence par le cluster.health champ de réponse de la describe-cluster commande. Le message contenu dans ce champ inclut un code d'erreur, un message descriptif et une ressource associée IDs. Ces informations sont uniquement disponibles via l'API et la AWS CLI Amazon EKS. Dans l'exemple suivant, remplacez my-cluster par le nom de votre cluster local.
aws eks describe-cluster --name my-cluster --query 'cluster.health'L'exemple qui suit illustre un résultat.
{
"issues": [
{
"code": "ConfigurationConflict",
"message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.",
"resourceIds": [
"my-cluster-arn"
]
}
]
}Si le problème est irréparable, vous devrez peut-être supprimer le cluster local et en créer un nouveau. Par exemple, vous essayez de provisionner un cluster avec un type d'instance qui n'est pas disponible sur votre Outpost. Le tableau suivant répertorie les erreurs courantes liées à l'état.
| Scénario d'erreur | Code | Message | ResourceIds |
|---|---|---|---|
|
Les sous-réseaux fournis sont introuvables. |
|
|
Tous les sous-réseaux fournis IDs |
|
Les sous-réseaux fournis n'appartiennent pas au même VPC. |
|
|
Tous les sous-réseaux fournis IDs |
|
Certains sous-réseaux fournis n'appartiennent pas à l'avant-poste spécifié. |
|
|
ID de sous-réseau problématique |
|
Certains sous-réseaux fournis n'appartiennent à aucun Outpost. |
|
|
ID de sous-réseau problématique |
|
Certains sous-réseaux fournis ne disposent pas de suffisamment d'adresses libres pour créer des interfaces réseau élastiques pour les instances du plan de contrôle. |
|
|
ID de sous-réseau problématique |
|
Le type d'instance de plan de contrôle spécifié n'est pas pris en charge sur votre Outpost. |
|
|
ARN de cluster |
|
Vous avez mis fin à une EC2 instance Amazon du plan de contrôle ou vous avez |
|
|
ARN de cluster |
|
Vous avez une capacité insuffisante sur votre Outpost. Cela peut également se produire lors de la création d'un cluster si un avant-poste est déconnecté de la AWS région. |
|
|
ARN de cluster |
|
Votre compte a dépassé votre quota de groupes de sécurité. |
|
Message d'erreur renvoyé par l' EC2 API Amazon |
ID du VPC cible |
|
Votre compte a dépassé votre quota d'interface réseau Elastic. |
|
Message d'erreur renvoyé par l' EC2 API Amazon |
l'ID du sous-réseau cible |
|
Les instances du plan de contrôle n'étaient pas accessibles via AWS Systems Manager. Pour la résolution, consultez Les instances du plan de contrôle ne sont pas accessibles via AWS Systems Manager. |
|
Les instances du plan de contrôle Amazon EKS ne sont pas accessibles via SSM. Vérifiez votre SSM et votre configuration réseau, et consultez la documentation de résolution des problèmes EKS sur les Outposts. |
EC2 Instance Amazon IDs |
|
Une erreur s'est produite lors de l'obtention de détails pour un groupe de sécurité géré ou une interface réseau Elastic. |
Basé sur le code d'erreur du EC2 client Amazon. |
Message d'erreur renvoyé par l' EC2 API Amazon |
Tous les groupes de sécurité sont gérés IDs |
|
Une erreur s'est produite lors de l'autorisation ou de la révocation des règles d'entrée du groupe de sécurité. Cela s'applique à la fois aux groupes de sécurité du cluster et du plan de contrôle. |
Basé sur le code d'erreur du EC2 client Amazon. |
Message d'erreur renvoyé par l' EC2 API Amazon |
ID de groupe de sécurité problématique |
|
Une erreur s'est produite lors de la suppression d'une interface réseau Elastic d'une instance du plan de contrôle. |
Basé sur le code d'erreur du EC2 client Amazon. |
Message d'erreur renvoyé par l' EC2 API Amazon |
ID d'interface réseau Elastoc problématique |
Le tableau suivant répertorie les erreurs provenant d'autres AWS services présentées dans le champ de santé de la describe-cluster réponse.
| Code EC2 d'erreur Amazon | Code de problème de santé du cluster | Description |
|---|---|---|
|
|
|
Cette erreur peut se produire pour différentes raisons. La raison la plus courante est que vous avez accidentellement supprimé une balise que le service utilise pour réduire la portée de la politique de rôle lié à un service du plan de contrôle. Dans ce cas, Amazon EKS ne pourra plus gérer ni surveiller ces AWS ressources. |
|
|
|
Cette erreur peut se produire pour différentes raisons. La raison la plus courante est que vous avez accidentellement supprimé une balise que le service utilise pour réduire la portée de la politique de rôle lié à un service du plan de contrôle. Dans ce cas, Amazon EKS ne pourra plus gérer ni surveiller ces AWS ressources. |
|
|
|
Cette erreur se produit lorsque l'ID de sous-réseau correspondant aux règles d'entrée d'un groupe de sécurité est introuvable. |
|
|
|
Cette erreur se produit lorsque les autorisations relatives aux règles d'entrée d'un groupe de sécurité ne sont pas correctes. |
|
|
|
Cette erreur se produit lorsque le groupe des règles d'entrée d'un groupe de sécurité est introuvable. |
|
|
|
Cette erreur se produit lorsque l'ID d'interface réseau pour les règles d'entrée d'un groupe de sécurité est introuvable. |
|
|
|
Cette erreur se produit lorsque le quota de ressources du sous-réseau est dépassé. |
|
|
|
Cette erreur se produit lorsque le quota de capacité de l'avant-poste est dépassé. |
|
|
|
Cette erreur se produit lorsque le quota de l'interface réseau Elastic est dépassé. |
|
|
|
Cette erreur se produit lorsque le quota du groupe de sécurité est dépassé. |
|
|
|
Cela est observé lors de la création d'une EC2 instance Amazon dans un nouveau compte. L'erreur peut être similaire à ce qui suit : " |
|
|
|
Amazon EC2 renvoie ce code d'erreur si le type d'instance spécifié n'est pas pris en charge sur l'Outpost. |
|
Toutes les autres erreurs |
|
Aucune |
Les clusters locaux nécessitent des autorisations et des politiques différentes de celles des clusters Amazon EKS qui sont hébergés dans le cloud. Lorsqu'un cluster ne parvient pas à se créer et génère une InvalidPermissions erreur, vérifiez que le rôle de cluster que vous utilisez est associé à la politique EKSLocal OutpostClusterPolicy gérée par Amazon. Tous les autres appels d'API nécessitent le même ensemble d'autorisations que les clusters Amazon EKS dans le cloud.
Le temps nécessaire à la création d'un cluster local varie en fonction de plusieurs facteurs. Ces facteurs incluent la configuration de votre réseau, la configuration d'Outpost et la configuration du cluster. En général, un cluster local est créé et passe à l'état ACTIVE dans les 15 à 20 minutes. Si un cluster local reste dans l'état CREATING, vous pouvez appeler describe-cluster pour obtenir des informations sur la cause dans le champ de sortie cluster.health.
Les problèmes les plus courants sont les suivants :
-
Votre cluster ne peut pas se connecter à l'instance du plan de contrôle depuis la AWS région dans laquelle se trouve Systems Manager. Vous pouvez le vérifier en appelant
aws ssm start-session --targetdepuis un hôte bastion de la région. Si cette commande ne fonctionne pas, vérifiez si Systems Manager est en cours d'exécution sur l'instance du plan de contrôle. Une autre solution consiste à supprimer le cluster, puis à le recréer.instance-id -
Les instances du plan de contrôle ne sont pas créées en raison des autorisations clés KMS pour les volumes EBS. Avec les clés KMS gérées par l'utilisateur pour les volumes EBS chiffrés, les instances du plan de contrôle s'arrêteront si la clé n'est pas accessible. Si les instances sont mises hors service, passez à une clé KMS AWS gérée ou assurez-vous que votre politique de clé gérée par l'utilisateur accorde les autorisations nécessaires au rôle de cluster.
-
Il se peut que les instances du plan de contrôle de Systems Manager n'aient pas accès à Internet. Vérifiez si le sous-réseau que vous avez fourni lors de la création du cluster possède une passerelle NAT et un VPC avec une passerelle Internet. Utilisez l'analyseur d'accessibilité VPC pour vérifier si l'instance du plan de contrôle peut atteindre la passerelle Internet. Pour plus d'informations, consultez Getting started with VPC Reachability Analyzer (langue française non garantie).
-
Le rôle ARN que vous avez fourni ne contient pas de politiques. Vérifiez si la politique AWS gérée : Amazon EKSLocal OutpostClusterPolicy a été supprimée du rôle. Cela peut également se produire si une AWS CloudFormation pile est mal configurée.
-
Tous les sous-réseaux fournis doivent être associés au même Outpost et pouvoir communiquer entre eux. Lorsque plusieurs sous-réseaux sont spécifiés lors de la création d'un cluster, Amazon EKS tente de répartir les instances du plan de contrôle sur plusieurs sous-réseaux.
-
Les groupes de sécurité gérés par Amazon EKS sont appliqués sur l'interface réseau Elastic. Cependant, d'autres éléments de configuration tels que les règles de pare-feu NACL peuvent entrer en conflit avec les règles de l'interface réseau Elastic.
La configuration du VPC et du DNS du sous-réseau est mal configurée ou manquante
Consultez l'article Créer un VPC et des sous-réseaux pour les clusters Amazon EKS sur Outposts. AWS
Amazon EKS met automatiquement à jour tous les clusters locaux existants vers les dernières versions de plate-forme pour la version mineure de Kubernetes correspondante. Pour plus d'informations sur les versions de la plateforme, reportez-vous àDécouvrez les versions des plateformes Kubernetes et Amazon EKS pour Outposts AWS.
Lors du déploiement automatique d'une version de plate-forme, le statut du cluster passe à. UPDATING Le processus de mise à jour consiste à remplacer toutes les instances du plan de contrôle Kubernetes par de nouvelles instances contenant les derniers correctifs de sécurité et corrections de bogues publiés pour la version mineure correspondante de Kubernetes. En général, le processus de mise à jour d'une plate-forme de cluster locale se termine en moins de 30 minutes et le cluster revient à ACTIVE son état. Si un cluster local reste dans UPDATING cet état pendant une période prolongée, vous pouvez appeler describe-cluster pour vérifier les informations sur la cause dans le champ cluster.health de sortie.
Amazon EKS garantit qu'au moins 2 instances du plan de contrôle Kubernetes sur 3 sont des nœuds de cluster sains et opérationnels afin de maintenir la disponibilité du cluster local et d'éviter les interruptions de service. Si un cluster local est bloqué, c'est généralement parce qu'un problème d'infrastructure ou de configuration empêche de garantir la disponibilité minimale de deux instances au cas où le processus se poursuivrait. UPDATING Le processus de mise à jour cesse donc de progresser pour protéger l'interruption de service du cluster local.
Il est important de dépanner un cluster local bloqué et de remédier à UPDATING la cause première afin que le processus de mise à jour puisse se terminer et rétablir le cluster local ACTIVE avec la haute disponibilité de 3 instances du plan de contrôle Kubernetes.
Ne mettez fin à aucune Kubernetes instance de cluster local EKS gérée sur Outposts, sauf indication explicite du Support AWS . Cela est particulièrement important pour les clusters locaux bloqués, car il UPDATING est fort probable qu'un autre nœud du plan de contrôle ne soit pas complètement sain et que l'arrêt de la mauvaise instance puisse entraîner une interruption du service et une perte de données du cluster local.
Les problèmes les plus courants sont les suivants :
-
Une ou plusieurs instances du plan de contrôle ne peuvent pas se connecter à System Manager en raison d'un changement de configuration réseau depuis la création du cluster local. Vous pouvez le vérifier en appelant
aws ssm start-session --targetdepuis un hôte bastion de la région. Si cette commande ne fonctionne pas, vérifiez si Systems Manager est en cours d'exécution sur l'instance du plan de contrôle.instance-id -
Les nouvelles instances du plan de contrôle ne peuvent pas être créées en raison des autorisations clés KMS pour les volumes EBS. Avec les clés KMS gérées par l'utilisateur pour les volumes EBS chiffrés, les instances du plan de contrôle s'arrêteront si la clé n'est pas accessible. Si les instances sont mises hors service, passez à une clé KMS AWS gérée ou assurez-vous que votre politique de clé gérée par l'utilisateur accorde les autorisations nécessaires au rôle de cluster.
-
Les instances du plan de contrôle de Systems Manager ont peut-être perdu l'accès à Internet. Vérifiez si le sous-réseau fourni lors de la création du cluster possède une passerelle NAT et un VPC avec une passerelle Internet. Utilisez l'analyseur d'accessibilité VPC pour vérifier si l'instance du plan de contrôle peut atteindre la passerelle Internet. Pour plus d'informations, consultez Getting started with VPC Reachability Analyzer (langue française non garantie). Si vos réseaux privés ne disposent pas de connexion Internet sortante, assurez-vous que tous les points de terminaison VPC et de passerelle requis sont toujours présents dans le sous-réseau régional de votre cluster (voir). Accès aux services par sous-réseau AWS
-
Le rôle ARN que vous avez fourni ne contient pas de politiques. Vérifiez si la politique AWS gérée : Amazon n'EKSLocalOutpostClusterPolicya pas été supprimée du rôle.
-
L'une des nouvelles instances du plan de contrôle Kubernetes a peut-être connu un échec de démarrage inattendu. Veuillez déposer un ticket auprès du AWS Support Center
pour obtenir des conseils supplémentaires sur le dépannage et la collecte des journaux dans ce cas exceptionnel.
-
Problèmes AMI :
-
Vous utilisez une AMI non prise en charge. Vous devez utiliser la version v20220620
ou une version ultérieure pour créer des nœuds avec Amazon Linux optimisé Amazon EKS optimisé pour AMIs Amazon Linux. -
Si vous avez utilisé un AWS CloudFormation modèle pour créer vos nœuds, assurez-vous qu'il n'utilise pas une AMI non prise en charge.
-
-
L'authentificateur AWS IAM est manquant
ConfigMap: s'il est absent, vous devez le créer. Pour plus d'informations, consultez Appliquer la ConfigMap aws-auth à votre cluster. -
Le mauvais groupe de sécurité est utilisé – Assurez-vous d'utiliser
eks-cluster-sg-pour le groupe de sécurité de vos composants master. Le groupe de sécurité sélectionné est modifié AWS CloudFormation pour autoriser un nouveau groupe de sécurité chaque fois que la pile est utilisée.cluster-name-uniqueid -
Suite à des étapes inattendues liées à un VPC de lien privé – Des données CA incorrectes (
--b64-cluster-ca) ou le mauvais point de terminaison de l'API (--apiserver-endpoint) sont transmis. -
Politique de sécurité du Pod mal configurée :
-
Le plug-in CoreDNS et Amazon VPC CNI pour Kubernetes Daemonsets doit s'exécuter sur les nœuds pour que les nœuds puissent rejoindre le cluster et communiquer avec celui-ci.
-
Le plug-in Amazon VPC CNI pour Kubernetes nécessite certaines fonctionnalités réseau privilégiées pour fonctionner correctement. Vous pouvez afficher les fonctions réseau privilégiées à l'aide de la commande suivante :
kubectl describe psp eks.privileged.
Nous ne recommandons pas de modifier la politique de sécurité par défaut du pod. Pour de plus amples informations, veuillez consulter Comprendre les politiques de sécurité des Pod (PSP) créées par Amazon EKS.
-
Lorsqu'un avant-poste est déconnecté de la AWS région à laquelle il est associé, le cluster Kubernetes continuera probablement à fonctionner normalement. Toutefois, si le cluster ne fonctionne pas correctement, suivez les étapes de résolution des problèmes décrites dans Préparer les clusters Amazon EKS locaux sur AWS Outposts pour les déconnexions réseau. Si vous rencontrez d'autres problèmes, contactez le AWS Support. AWS Support peut vous aider à télécharger et à exécuter un outil de collecte de journaux. Ainsi, vous pouvez collecter des journaux à partir de vos instances de plan de contrôle du cluster Kubernetes et les envoyer au AWS support technique pour une enquête plus approfondie.
Lorsque les instances du plan de contrôle Amazon EKS ne sont pas accessibles via AWS Systems Manager (Systems Manager), Amazon EKS affiche le message d'erreur suivant pour votre cluster.
Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation.
Pour résoudre ce problème, assurez-vous que votre VPC et vos sous-réseaux répondent aux exigences de la section Créer un VPC et des sous-réseaux pour les clusters Amazon EKS sur AWS Outposts et que vous avez suivi les étapes décrites dans Configuration du gestionnaire de session dans le guide de l'utilisateur de Systems Manager. AWS
