Aidez à améliorer cette page
Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tous.
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.
Résoudre les problèmes liés aux EKS clusters Amazon locaux sur AWS Outposts
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 EKS clusters Amazon dans le cloud, mais ils sont gérés différemment par AmazonEKS.
Les clusters locaux sont créés via Amazon EKSAPI, mais sont exécutés de manière asynchrone. Cela signifie que les demandes adressées à Amazon sont EKS API renvoyées 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 du Kubernetes API.
Les clusters locaux ne passent pas à l'état FAILED
. Amazon EKS essaie de réconcilier l'état du cluster avec 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 clusters locaux peuvent être découverts à l'aide de la EKS AWS CLI commande describe-cluster
Amazon. Les problèmes liés aux clusters locaux sont signalés par le champ cluster.health
de la réponse de la commande describe-cluster
. Le message contenu dans ce champ inclut un code d'erreur, un message descriptif et une ressource associéeIDs. Ces informations sont disponibles AWS CLI uniquement via Amazon EKSAPI. Dans l'exemple suivant, remplacez my-cluster
avec 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, essayez d'allouer 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 aux mêmesVPC. |
|
|
Tous les sous-réseaux fournis IDs |
Certains sous-réseaux fournis n'appartiennent pas à l'Outpost 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 Elastic pour les instances du plan de contrôle. |
|
|
ID de sous-réseau problématique |
Le type d'instance du plan de contrôle spécifié n'est pas pris en charge sur votre Outpost. |
|
|
Cluster ARN |
Vous avez mis fin à une EC2 instance Amazon du plan de contrôle ou vous avez run-instance réussi, mais l'état observé change deTerminated . Cela peut se produire pendant un certain temps après que votre Outpost se soit reconnecté et que des erreurs EBS internes d'Amazon aient entraîné l'échec d'un flux de travail EC2 interne d'Amazon. |
|
|
Cluster ARN |
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é du Région AWS. |
|
|
Cluster ARN |
Votre compte a dépassé votre quota de groupes de sécurité. |
|
Message d'erreur renvoyé par Amazon EC2 API | VPCID cible |
Votre compte a dépassé votre quota d'interface réseau Elastic. |
|
Message d'erreur renvoyé par Amazon EC2 API | 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 EKS du plan de contrôle Amazon ne sont pas accessibles viaSSM. Vérifiez votre configuration SSM et celle du réseau, et consultez la documentation EKS de dépannage d'Outposts. |
EC2Instance 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 Amazon EC2 API | 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 Amazon EC2 API | 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 Amazon EC2 API | ID d'interface réseau Elastoc problématique |
Le tableau suivant répertorie les erreurs provenant Services AWS d'autres erreurs 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 ne EKS 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 ne EKS pourra plus gérer ni surveiller ces AWS ressources. |
|
|
Cette erreur se produit lorsque l'ID de sous-réseau pour les règles d'entrée d'un groupe de sécurité est introuvable. |
|
|
Cette erreur se produit lorsque les autorisations pour les 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 de l'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 : "You
have requested more vCPU capacity than your current vCPU limit
of 32 allows for the instance bucket that the specified instance
type belongs to. Please visit
http://aws.amazon.com/contact-us/ec2-request to request an
adjustment to this limit." |
|
|
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 EKS des clusters Amazon hébergés dans le cloud. Lorsqu'un cluster ne parvient pas à se créer et produit une InvalidPermissions
erreur, vérifiez que la politique mazonEKSLocal OutpostClusterPolicy gérée A est associée au rôle de cluster que vous utilisez. Tous les autres API appels nécessitent le même ensemble d'autorisations que les EKS clusters Amazon dans le cloud.
Le temps nécessaire à la création d'un cluster local varie en fonction de plusieurs facteurs. Ces facteurs comprennent 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 :
AWS Systems Manager (Systems Manager) rencontre les problèmes suivants :
-
Votre cluster ne peut pas se connecter à l'instance du plan de contrôle à partir de l' Région AWS dans laquelle se trouve Systems Manager. Vous pouvez le vérifier en appelant
aws ssm start-session --target
depuis un hôte bastion de la région. Si cette commande ne fonctionne pas, vérifiez si Systems Manager est exécuté sur l'instance du plan de contrôle. Une autre solution consiste à supprimer le cluster, puis à le recréer.instance-id
-
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 NAT passerelle et VPC une passerelle Internet. Utilisez l'analyseur VPC d'accessibilité pour vérifier que l'instance du plan de contrôle peut atteindre la passerelle Internet. Pour plus d'informations, consultez Getting Started with VPC Reachability Analyzer.
-
Le rôle ARN que vous avez indiqué ne contient pas de politiques. Vérifiez si la politique AWS politique gérée : A mazonEKSLocal OutpostClusterPolicy a été retirée du rôle. Cela peut également se produire si une AWS CloudFormation pile est mal configurée.
Plusieurs sous-réseaux mal configurés et spécifiés lors de la création d'un cluster :
-
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é EKS gérés par Amazon sont appliqués sur l'interface elastic network. Cependant, d'autres éléments de configuration tels que les règles de NACL pare-feu peuvent entrer en conflit avec les règles de l'elastic network interface.
VPCet la DNS configuration du sous-réseau est mal configurée ou manquante
Consultez Créez un VPC et des sous-réseaux pour les EKS clusters Amazon sur AWS Outposts.
Causes courantes :
-
AMIproblèmes :
-
Vous utilisez un appareil non pris en chargeAMI. Vous devez utiliser la version v20220620
ou une version ultérieure Créez des nœuds avec Amazon Linux optimisé AMIs pour Amazon Linux optimisé pour EKS Amazon. -
Si vous avez utilisé un AWS CloudFormation modèle pour créer vos nœuds, assurez-vous qu'il n'utilise pas un modèle non pris en chargeAMI.
-
-
AWS IAMAuthentificateur 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 VPC étapes de liaison privée inattendues, des données CA (
--b64-cluster-ca
) ou un API point de terminaison (--apiserver-endpoint
) erronés sont transmis. -
Mal configuré Pod politique de sécurité :
-
Le CoreDNS and Amazon VPC CNI plugin for Kubernetes Les daemonsets doivent s'exécuter sur les nœuds pour que les nœuds puissent rejoindre le cluster et communiquer avec celui-ci.
-
Le Amazon VPC CNI plugin for 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é du pod par défaut. Pour de plus amples informations, veuillez consulter Comprendre les politiques de sécurité des pods EKS créées par Amazon (PSP).
-
Lorsqu'un avant-poste est déconnecté de Région AWS celui auquel il est associé, le Kubernetes le cluster continuera probablement à fonctionner normalement. Toutefois, si le cluster ne fonctionne pas correctement, suivez les étapes de dépannage dans Préparez les EKS clusters Amazon locaux AWS Outposts pour les déconnexions du réseau. Si vous rencontrez d'autres problèmes, contactez AWS Support. AWS Support peut vous aider à télécharger et à exécuter un outil de collecte de journaux. De cette façon, vous pouvez collecter des journaux à partir de votre Kubernetes regroupez les instances du plan de contrôle et envoyez-les au AWS Support support pour une enquête plus approfondie.
Lorsque les instances du plan de EKS contrôle Amazon ne sont pas accessibles via AWS Systems Manager (Systems Manager), Amazon EKS affiche l'erreur suivante 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 vos sous-réseaux VPC et sous-réseaux répondent aux exigences Créez un VPC et des sous-réseaux pour les EKS clusters Amazon sur AWS Outposts et que vous avez suivi les étapes décrites dans la section Configuration du gestionnaire de session dans le guide de l' AWS Systems Manager utilisateur.