AWSSupport-TroubleshootEKSALBControllerIssues - AWS Systems Manager Référence du manuel d'automatisation

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.

AWSSupport-TroubleshootEKSALBControllerIssues

Description

Le manuel AWSSupport-TroubleshootEKSALBControllerIssues d'automatisation permet de diagnostiquer les problèmes courants qui empêchent le AWS Load Balancer Controller de configurer et de gérer correctement Application Load Balancer (ALB) et Network Load Balancer (NLB) pour les entrées et les services Kubernetes.

Ce manuel effectue la end-to-end validation des composants essentiels, notamment la configuration du fournisseur d'identité OIDC, la configuration IRSA, les prérequis réseau, la configuration et les quotas ingress/service de ressources. Il capture également les journaux des contrôleurs et les configurations de ressources Kubernetes pertinentes pour aider à identifier les erreurs de configuration ou les problèmes opérationnels.

Important

Ce manuel d'automatisation est conçu pour les clusters Amazon EKS utilisant des groupes de nœuds Amazon Elastic Compute Cloud (Amazon EC2) et ne prend actuellement pas en charge les clusters exécutés sur. AWS Fargate

Fonctionnement

Le runbook AWSSupport-TroubleshootEKSALBControllerIssues exécute les étapes de haut niveau suivantes :

  • Valide l'état du cluster Amazon EKS, la configuration des entrées d'accès et la configuration du fournisseur OIDC.

  • Crée un proxy Lambda temporaire pour les communications avec l'API Kubernetes.

  • Vérifie le déploiement du AWS Load Balancer Controller et la configuration du compte de service.

  • Vérifie l'identité du pod, le webhook et l'injection de rôles IAM.

  • Valide la configuration et le balisage des sous-réseaux pour le provisionnement de l'Application Load Balancer et du Network Load Balancer.

  • Vérifie les quotas des comptes Application Load Balancer et Network Load Balancer par rapport à l'utilisation actuelle.

  • Valide les annotations relatives aux entrées et aux ressources de service.

  • Vérifie le balisage des groupes de sécurité des nœuds de travail pour l'intégration de l'équilibreur de charge.

  • Collecte les journaux du module de commande à des fins de diagnostic.

  • Nettoie les ressources d'authentification temporaires.

  • Génère un rapport de diagnostic contenant les résultats et les étapes de correction.

Note
  • Le cluster Amazon EKS doit disposer d'une entrée d'accès configurée pour l'entité IAM exécutant cette automatisation. Le mode d'authentification du cluster doit être défini sur API ouAPI_AND_CONFIG_MAP. Sans une configuration d'entrée d'accès appropriée, l'automatisation s'arrêtera lors de la validation initiale.

  • Le LambdaRoleArn paramètre est obligatoire et doit être AWSLambdaVPCAccessExecutionRole associé aux politiques AWS AWSLambdaBasicExecutionRole gérées pour permettre à la fonction proxy de communiquer avec l'API Kubernetes.

  • Le AWS Load Balancer Controller doit être une version v2.1.1 ou ultérieure.

  • L'automatisation inclut une étape de nettoyage qui supprime les ressources de l'infrastructure d'authentification temporaire. Cette étape de nettoyage s'exécute même en cas d'échec des étapes précédentes, ce qui garantit qu'aucune ressource orpheline ne reste dans votre AWS compte.

Exécuter cette automatisation (console)

Type de document

 Automatisation

Propriétaire

Amazon

Plateformes

/

Autorisations IAM requises

Le AutomationAssumeRole paramètre nécessite les actions suivantes pour utiliser correctement le runbook.

  • cloudformation:CreateStack

  • cloudformation:DeleteStack

  • cloudformation:DescribeStacks

  • cloudformation:UpdateStack

  • ec2:CreateNetworkInterface

  • ec2:DeleteNetworkInterface

  • ec2:DescribeInstances

  • ec2:DescribeNetworkInterfaces

  • ec2:DescribeRouteTables

  • ec2:DescribeSecurityGroups

  • ec2:DescribeSubnets

  • ec2:DescribeVpcs

  • eks:DescribeCluster

  • eks:ListAssociatedAccessPolicies

  • elasticloadbalancing:DescribeAccountLimits

  • elasticloadbalancing:DescribeLoadBalancers

  • iam:GetRole

  • iam:ListOpenIDConnectProviders

  • iam:PassRole

  • lambda:CreateFunction

  • lambda:DeleteFunction

  • lambda:GetFunction

  • lambda:InvokeFunction

  • lambda:ListTags

  • lambda:TagResource

  • lambda:UntagResource

  • lambda:UpdateFunctionCode

  • logs:CreateLogGroup

  • logs:CreateLogStream

  • logs:DescribeLogGroups

  • logs:DescribeLogStreams

  • logs:ListTagsForResource

  • logs:PutLogEvents

  • logs:PutRetentionPolicy

  • logs:TagResource

  • logs:UntagResource

  • ssm:DescribeAutomationExecutions

  • ssm:GetAutomationExecution

  • ssm:StartAutomationExecution

  • tag:GetResources

  • tag:TagResources

Instructions

Pour configurer et exécuter l'automatisation, procédez comme suit :

Note

Avant d'exécuter l'automatisation, procédez comme suit pour configurer les rôles IAM requis : un pour que Systems Manager Automation exécute le runbook, et un autre pour que Lambda communique avec l'API Kubernetes :

  1. Créez un rôle d'automatisation SSM TroubleshootEKSALBController-SSM-Role dans votre compte. Vérifiez que la relation d'approbation contient la politique suivante.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ssm.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
  2. Joignez la politique IAM suivante pour accorder les autorisations requises :

    { "Version": "2012-10-17", "Statement": [{ "Sid": "TroubleshootEKSALBControllerIssuesActions", "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListAssociatedAccessPolicies", "iam:GetRole", "iam:ListOpenIDConnectProviders", "ssm:StartAutomationExecution", "ssm:GetAutomationExecution", "ssm:DescribeAutomationExecutions", "ec2:DescribeSubnets", "ec2:DescribeRouteTables", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeAccountLimits", "ec2:DescribeInstances", "ec2:DescribeNetworkInterfaces", "ec2:DescribeSecurityGroups" ], "Resource": "*" }, { "Sid": "SetupK8sApiProxyForEKSActions", "Effect": "Allow", "Action": [ "cloudformation:CreateStack", "cloudformation:DeleteStack", "cloudformation:DescribeStacks", "cloudformation:UpdateStack", "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "eks:DescribeCluster", "iam:GetRole", "lambda:CreateFunction", "lambda:DeleteFunction", "lambda:GetFunction", "lambda:InvokeFunction", "lambda:ListTags", "lambda:TagResource", "lambda:UntagResource", "lambda:UpdateFunctionCode", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:ListTagsForResource", "logs:PutLogEvents", "logs:PutRetentionPolicy", "logs:TagResource", "logs:UntagResource", "ssm:DescribeAutomationExecutions", "tag:GetResources", "tag:TagResources" ], "Resource": "*" }, { "Sid": "PassRoleToAutomation", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringLikeIfExists": { "iam:PassedToService": [ "lambda.amazonaws.com", "ssm.amazonaws.com" ] } } }] }
  3. Configurez l'entrée d'accès pour votre cluster Amazon EKS. Il s'agit d'une exigence obligatoire pour l'automatisation. Pour connaître les étapes de configuration du mode d'authentification pour les entrées d'accès, voir Configuration des entrées d'accès.

    Dans la console Amazon EKS, accédez à votre cluster et procédez comme suit :

    • Dans la section Accès, vérifiez que votre configuration d'authentification est définie sur API ouAPI_AND_CONFIG_MAP.

    • Choisissez Créer une entrée d'accès et configurez :

      • Pour l'ARN principal IAM, sélectionnez le rôle IAM que vous avez créé ()TroubleshootEKSALBController-SSM-Role.

      • Pour Type, sélectionnez Standard.

    • Ajoutez une politique d'accès :

      • Dans Nom de la politique, sélectionnezAmazonEKSAdminViewPolicy.

      • Pour Étendue d'accès, sélectionnezCluster.

    • Choisissez Add policy (Ajouter la politique).

    • Vérifiez les informations et choisissez Create.

  4. Créez un rôle IAM pour la fonction Lambda (référencé LambdaRoleArn comme dans les paramètres d'entrée) :

    • Créez un nouveau rôle IAM avec la politique de confiance suivante :

      { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
    • Associez les politiques AWS gérées suivantes à ce rôle :

      • AWSLambdaBasicExecutionRole

      • AWSLambdaVPCAccessExecutionRole

    • Notez l'ARN de ce rôle, car vous en aurez besoin pour le paramètre LambdaRoleArn d'entrée.

  1. Accédez AWSSupport-TroubleshootEKSALBControllerIssuesà la console AWS Systems Manager.

  2. Choisissez Execute automation (Exécuter l’automatisation).

  3. Pour les paramètres d'entrée, entrez ce qui suit :

    • AutomationAssumeRole (Facultatif) :

      Type : AWS::IAM::Role ::Arn

      Description : (Facultatif) Le nom de ressource Amazon (ARN) du rôle Gestion des identités et des accès AWS (IAM) qui permet à Systems Manager Automation d'effectuer des actions en votre nom. Si aucun rôle n'est spécifié, Systems Manager Automation utilise les autorisations de l'utilisateur qui lance ce runbook.

      Modèle autorisé : ^arn :( ? :aws|aws-cn|aws-us-gov) :iam : : \ d {12} :role/ ? [A-za-Z_0-9+=, .@ \ -_/] +$

    • EksClusterName (Obligatoire) :

      Type : Chaîne

      Description : (Obligatoire) Nom du cluster Amazon Elastic Kubernetes Service (Amazon EKS).

      Modèle autorisé : ^ [0-9A-zA-Z] [A-zA-Z0-9-_] {0,99} $

    • ALBControllerDeploymentName (Facultatif) :

      Type : Chaîne

      Description : (Facultatif) Le nom du déploiement du AWS Load Balancer Controller dans votre cluster Amazon EKS. Il s'agit généralement de « aws-load-balancer-controller », sauf si vous l'avez personnalisé lors de l'installation.

      Modèle autorisé : ^ [a-z0-9] ([-.a-z0-9] {0,251} [a-z0-9]) ? $

      Par défaut : aws-load-balancer-controller

    • ALBControllerEspace de noms (facultatif) :

      Type : Chaîne

      Description : (Facultatif) L'espace de noms Kubernetes dans lequel le Load Balancer Controller AWS est déployé. Par défaut, il s'agit de « kube-system », mais cela peut être différent si vous avez installé le contrôleur dans un espace de noms personnalisé.

      Modèle autorisé : ^ [a-z0-9] ([-a-z0-9] {0,61} [a-z0-9]) ? $

      Par défaut : kube-system

    • ServiceAccountName (Facultatif) :

      Type : Chaîne

      Description : (Facultatif) Nom du compte de service Kubernetes associé au Load Balancer AWS Controller. Il s'agit généralement de « aws-load-balancer-controller » à moins que cela ne soit personnalisé lors de l'installation.

      Modèle autorisé : ^ [a-z0-9] ([-.a-z0-9] {0,251} [a-z0-9]) ? $

      Par défaut : aws-load-balancer-controller

    • ServiceAccountNamespace (Facultatif) :

      Type : Chaîne

      Description : (Facultatif) L'espace de noms Kubernetes dans lequel se trouve le compte de service du Load Balancer Controller AWS . Il s'agit généralement d'un « kube-system », mais cela peut être différent si vous avez utilisé un espace de noms personnalisé.

      Modèle autorisé : ^ [a-z0-9] ([-a-z0-9] {0,61} [a-z0-9]) ? $

      Par défaut : kube-system

    • IngressName (Facultatif) :

      Type : Chaîne

      Description : (Facultatif) Nom de la ressource d'entrée à valider (Application Load Balancer). Si elle n'est pas spécifiée, la validation d'entrée sera ignorée.

      Modèle autorisé : ^$|^ [a-z0-9] [a-z0-9.-] {0,251} [a-z0-9] $

      Par défaut : « » (chaîne vide)

    • IngressNamespace (Facultatif) :

      Type : Chaîne

      Description : (Facultatif) Espace de noms de la ressource Ingress. Obligatoire si cela IngressName est spécifié.

      Modèle autorisé : ^$|^ [a-z0-9] [a-z0-9-] {0,61} [a-z0-9] $

      Par défaut : « » (chaîne vide)

    • ServiceName (Facultatif) :

      Type : Chaîne

      Description : (Facultatif) Nom d'une ressource de service spécifique pour valider les annotations du Network Load Balancer (Network Load Balancer). Si elle n'est pas spécifiée, la validation des ressources du service sera ignorée.

      Modèle autorisé : ^$|^ [a-z0-9] [a-z0-9.-] {0,251} [a-z0-9] $

      Par défaut : « » (chaîne vide)

    • ServiceNamespace (Facultatif) :

      Type : Chaîne

      Description : (Facultatif) Espace de noms de la ressource de service. Obligatoire si cela ServiceName est spécifié.

      Modèle autorisé : ^$|^ [a-z0-9] [a-z0-9-] {0,61} [a-z0-9] $

      Par défaut : « » (chaîne vide)

    • LambdaRoleArn (Obligatoire) :

      Type : AWS::IAM::Role ::Arn

      Description : (Obligatoire) L'ARN du rôle IAM qui permet à la fonction AWS Lambda (Lambda) d'accéder aux services et ressources AWS requis. Associez les politiques AWS gérées : AWSLambdaBasicExecutionRole et AWSLambdaVPCAccessExecutionRole à votre rôle IAM d'exécution de fonctions Lambda.

      Modèle autorisé : ^arn :( ? :aws|aws-cn|aws-us-gov) :iam : : \ d {12} :role/ ? [A-za-Z_0-9+=, .@ \ -_/] +$

  4. Sélectionnez Execute (Exécuter).

  5. L'automatisation démarre.

  6. Le document exécute les étapes suivantes :

    1. ValidateAccessEntryAndOIDCProvider:

      Valide la configuration IAM du cluster Amazon EKS en vérifiant les autorisations d'accès et la configuration du fournisseur OIDC.

    2. Configuration K8 sAuthenticationClient :

      Exécutez le document SAW AWSSupport-SetupK 8 sApiProxy Foreks pour configurer une fonction lambda afin d'exécuter des appels d'API Amazon EKS sur le cluster.

    3. Vérifiez ALBController et IRSASetup :

      Vérifie si le compte de service et le contrôleur Application Load Balancer donnés existent dans leurs espaces de noms respectifs. Vérifie également la politique d'annotation et de confiance des rôles de compte de service du contrôleur Application Load Balancer.

    4. VerifyPodIdentityWebhookAndEnv:

      Vérifie s'il pod-identity-webhook est en cours d'exécution. Vérifie également si l'IRSA est injecté dans les variables ENV du pod.

    5. ValidateSubnetRequirements:

      Vérifiez au moins deux sous-réseaux dans deux AZ avec 8 adresses IP disponibles. Un balisage de sous-réseau approprié existe pour public/private les équilibreurs de charge.

    6. CheckLoadBalancerLimitsAndUsage:

      Comparez la limite du compte au nombre d'Application Load Balancer et de Network Load Balancer.

    7. CheckIngressOrServiceAnnotations:

      Vérifie que les annotations et les spécifications sont correctes dans les ressources d'entrée et de service afin de s'assurer qu'elles sont correctement configurées pour l'utilisation de l'Application Load Balancer et du Network Load Balancer.

    8. CheckWorkerNodeSecurityGroupTags:

      Vérifiez qu'un seul groupe de sécurité attaché aux nœuds de travail possède la balise de cluster requise.

    9. ALBControllerJournaux de capture :

      Récupère les derniers journaux de diagnostic des pods AWS Load Balancer Controller exécutés dans le cluster Amazon EKS.

    10. Nettoyage K8 : sAuthenticationClient

      Exécute le document SAW « AWSSupport-SetupK 8 sApiProxy FOREKS » à l'aide de l'opération « Cleanup » pour nettoyer les ressources créées dans le cadre de l'automatisation.

    11. GenerateReport:

      Génère le rapport d'automatisation.

  7. Une fois l'exécution terminée, consultez la section Sorties pour obtenir les résultats détaillés de l'exécution :

    1. Rapport :

      Fournit un résumé complet de toutes les vérifications effectuées, y compris l'état du cluster Amazon EKS, la configuration du contrôleur Application Load Balancer, la configuration IRSA, les exigences du sous-réseau, les limites de l'équilibreur de charge, les ingress/service annotations, les balises du groupe de sécurité des nœuds de travail et les journaux du contrôleur Application Load Balancer. Il inclut également tous les problèmes identifiés et les mesures correctives recommandées.

Références

Systems Manager Automation

Documentation relative au AWS Load Balancer Controller