Comment résoudre l'état CrashLoopBackoff pour les pods de l’agent CloudWatch et de l’agent de l’identité du pod Amazon EKS ?

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'interface.

Vérifier les journaux :

Tout d'abord, consultez les journaux de l'agent CloudWatch et de l'agent de l’identité du pod EKS pour recueillir des informations sur le problème.

Pour consulter les journaux de l'agent CloudWatch, exécutez la commande suivante :

kubectl logs cloudwatch-agent-pod-name -n namespace

Remarque : Remplacez cloudwatch-agent-pod-name par le nom de pod de votre agent CloudWatch et namespace par le nom de votre espace de noms.

Pour vérifier les journaux de l'agent de l’identité du pod EKS, exécutez la commande suivante :

kubectl logs pod-identity-agent-pod-name -n namespace

Remarque : Remplacez pod-identity-agent-pod-name par le nom de pod de votre agent de l’identité du pod EKS, et namespace par le nom de votre espace de noms.

Dans la sortie de commande, recherchez les messages d'erreur indiquant la raison pour laquelle le pod se bloque, tels que des problèmes d'autorisation, de réseau ou de configuration.

Résoudre les problèmes liés aux autorisations de l’agent CloudWatch

Erreur Impossible de créer le fournisseur

Vous devez utiliser le rôle de compte AWS du service AWS Identity and Access Management (IAM) pour permettre aux nœuds de travail Amazon EKS d'envoyer des métriques et des journaux à CloudWatch. Si le rôle IAM est absent ou s'il est configuré de manière incorrecte dans l'espace de noms amazon-cloudwatch requis, l'erreur suivante s'affiche :

« Error: cannot create provider: failed to retriever credentials: failed to assume role » (Erreur : impossible de créer le fournisseur : échec de la récupération des informations d'identification : échec de l'attribution du rôle)

Pour résoudre ce problème, créez un rôle de compte de service avec le nom cloudwatch-agent.

Pour créer un rôle de compte de service personnalisé, exécutez la commande suivante :

eksctl create iamserviceaccount \
--cluster cluster-name \
--namespace amazon-cloudwatch \
--name service-account-name \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--override-existing-serviceaccounts \
--approve

Remarque : Remplacez cluster-name par le nom de votre cluster Amazon EKS et service-account-name par le nom de compte de service personnalisé.

Puis, créez un ConfigMap pour l'agent CloudWatch. Si vous utilisez un rôle de compte de service personnalisé, remplacez cloudwatch-agent par le nom du rôle de compte de service.

Erreurs Non autorisé à exécuter : sts:AssumeRole

Si le rôle de compte de service utilisé par l'agent CloudWatch ne peut pas s'authentifier, l'une des erreurs suivantes s'affiche :

« Error: AccessDenied: User: arn:aws:sts::[Account-ID]:assumed-role/[Role-Name]/[Session-Name] is not authorized to perform: sts:AssumeRole on resource [Role-ARN] » (Erreur : Accès refusé : L’utilisateur arn:aws:sts::[Account-ID]:assumed-role/[Role-Name]/[Session-Name] n’est pas autorisé à exécuter : sts:AssumeRole sur la ressource [Role-ARN]) 

-ou-

« Error: AccessDenied: Not authorized to perform sts:AssumeRole » (Erreur : Accès refusé : Non autorisé à exécuter sts:AssumeRole)

Assurez-vous que vous avez associé la politique CloudWatchAgentServerPolicy au rôle de compte de service. Pour identifier les problèmes d'authentification, consultez AWS CloudTrail pour les événements PutLogEvents et DescribeLogStreams. Assurez-vous d'utiliser le compte de service cloudwatch-agent ou le nom de compte de service personnalisé correct dans le fichier YAML de déploiement.

Pour vérifier la configuration du compte de service, exécutez la commande suivante :

kubectl get serviceaccount cloudwatch-agent -n amazon-cloudwatch -o yaml

Dans la sortie, assurez-vous que les métadonnées eks.amazonaws.com/role-arn sont similaires à celles de l'exemple suivant :

metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/role-name

Les comptes de service de l'agent CloudWatch doivent respecter les règles suivantes :

rules:
  - apiGroups: [""]
    resources: ["pods", "nodes", "endpoints"]
    verbs: ["list", "watch"]
  - apiGroups: [ "" ]
    resources: [ "services" ]
    verbs: [ "list", "watch" ]
  - apiGroups: ["apps"]
    resources: ["replicasets", "daemonsets", "deployments", "statefulsets"]
    verbs: ["list", "watch"]
  - apiGroups: ["batch"]
    resources: ["jobs"]
    verbs: ["list", "watch"]
  - apiGroups: [""]
    resources: ["nodes/proxy"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["nodes/stats", "configmaps", "events"]
    verbs: ["create", "get"]
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["cwagent-clusterleader"]
    verbs: ["get","update"]
  - nonResourceURLs: ["/metrics"]
    verbs: ["get", "list", "watch"]

Pour vérifier les règles du compte de service, exécutez la commande suivante :

kubectl auth can-i --list --as=system:serviceaccount:amazon-cloudwatch:cloudwatch-agent

Résoudre les problèmes liés aux autorisations de l'agent de l’identité du pod EKS

Erreurs Non autorisé à exécuter : eks-auth:AssumeRoleForPodIdentity ou erreur de récupération des informations d’identification

Si l'agent de l’identité du pod EKS ne peut pas endosser le rôle IAM du nœud Amazon EKS, l'une des erreurs suivantes s'affiche :

« Error: AccessDenied: User: arn:aws:sts::[Account-ID]:assumed-role/[Role-Name]/[Session-Name] is not authorized to perform: eks-auth:AssumeRoleForPodIdentity on resource [Cluster] » (Erreur : Accès refusé : L’utilisateur : arn:aws:sts::[Account-ID]:assumed-role/[Role-Name]/[Session-Name] n’est pas autorisé à exécuter : eks-auth:AssumeRoleForPodIdentity sur la ressource [Cluster])

-ou-

« Error: "error","msg":"Error fetching credentials: error getting credentials to cache: unable to fetch credentials from EKS Auth: operation error EKS Auth: AssumeRoleForPodIdentity, https response error StatusCode: 403, RequestID: fc66d1ec-33f1-43b0-a617-df1a52adcb63, AccessDeniedException: ","operation":"AssumeRoleForPodIdentity","request-id":"fc66d1ec-33f1-43b0-a617-df1a52adcb63","service":"EKS Auth" » ((Erreur : "error","msg" : "Erreur lors de la récupération des informations d'identification : erreur lors de la mise en cache des informations d'identification : impossible de récupérer les informations d'identification depuis EKS Auth : erreur de fonctionnement d’EKS Auth : AssumeRoleForPodIdentity, erreur de réponse https Code de statut : 403, ID de requête : fc66d1ec-33f1-43b0-a617-df1a52adcb63, Exception accès refusé : ","operation":"AssumeRoleForPodIdentity","request-id":"fc66d1ec-33f1-43b0-a617-df1a52adcb63","service":"EKS Auth")

Pour résoudre ce problème, assurez-vous que la politique IAM que vous avez associée au rôle autorise l'action AssumeRoleForPodIdentity. Il est recommandé d'utiliser la politique gérée par AWS AmazonEKSWorkerNodePolicy. Vous pouvez également ajouter une politique personnalisée similaire à l'exemple suivant :

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}

Vérifiez également que les politiques de contrôle des services (SCP) de votre organisation ne bloquent pas l'action AssumeRoleForPodIdentity.

Important : Si vous créez le pod et le compte de service en même temps que l'association d'identité du pod, vous pouvez rencontrer des problèmes. Pour résoudre les problèmes, attendez au moins 10 secondes après avoir créé le rôle pour associer le rôle au pod.

Résoudre les problèmes liés au réseau de l’agent CloudWatch

Erreurs d’échec d’envoi des journaux ou Une erreur s'est produite dans PutLogEvents

Si l'agent CloudWatch ne parvient pas à atteindre le point de terminaison CloudWatch Logs, l'une des erreurs suivantes s'affiche :

« 2023-03-18T12:00:00Z E! [outputs.cloudwatchlogs] Failed to send logs: RequestError: send request failed caused by: Post "https://logs.us-west-2.amazonaws.com/": dial tcp 52.94.76.32:443: i/o timeout » (2023-03-18T12:00:00Z E! [outputs.cloudwatchlogs] Échec d’envoi des journaux : RequestError: échec de l’envoi de la requête causé par :

-ou-

« 2024-11-22T17:00:48Z E! {"caller":"cwlogs@v0.103.0/cwlog_client.go:135","msg":"cwlog_client: Error occurs in PutLogEvents","kind":"exporter","data_type":"metrics","name":"awsemf/containerinsights","error":"RequestError: send request failed\ncaused by: Post \"https://logs.us-east-1.amazonaws.com/\" » (2024-11-22T17:00:48Z E! {"caller":"cwlogs@v0.103.0/cwlog_client.go:135","msg":"cwlog_client : Une erreur s’est produite dans PutLogEvents","kind":"exporter","data_type":"metrics","name":"awsemf/containerinsights","error":"RequestError : échec d’envoi de la requête\ncausé par : Publiez \"https://logs.us-east-1.amazonaws.com/\")

Ce problème se produit généralement en raison de restrictions réseau ou d’une configuration incorrecte des groupes de sécurité. Pour résoudre les problèmes, assurez-vous que les nœuds disposent d'un accès Internet sortant via une passerelle Internet. Pour les sous-réseaux privés, vérifiez que vous avez correctement configuré la passerelle NAT. Configurez le point de terminaison du cloud privé virtuel (VPC) pour les services CloudWatch. Le point de terminaison de VPC doit utiliser la convention de dénomination com.amazonaws.Region.logs, et le groupe de sécurité du point de terminaison doit autoriser le trafic entrant en provenance du groupe de sécurité du nœud.

Pour vérifier que les groupes de sécurité des nœuds autorisent le trafic HTTPS sortant, vérifiez la configuration suivante :

• Type : HTTPS
• Protocole : TCP
• Port : 443
• Destination de la plage : 0.0.0.0/0

Résoudre les problèmes liés au réseau de l'agent de l’identité du pod EKS

Erreur lors de la récupération du jeton de compte de service

Les groupes de sécurité du pod doivent autoriser le trafic HTTP sortant sur le port TCP 80 vers l'adresse IP du service de métadonnées de l'instance (169.254.169.254). Si tel n'est pas le cas, le message d'erreur suivant s'affiche :

« Error retrieving service account token: Get "http://169.254.169.254/latest/meta-data/iam/security-credentials/": dial tcp 169.254.169.254:80: connect: connection timed out » (Erreur lors de la récupération du jeton de compte de service : Accédez à « http://169.254.169.254/latest/meta-data/iam/security-credentials/ » : appelez tcp 169.254.169.254:80 : connexion : expiration de la connexion)

Pour résoudre ce problème, assurez-vous que les groupes de sécurité du pod utilisent la configuration suivante :

• Type : HTTPS
• Protocole : TCP
• Port : 80
• Destination de la plage : 169.254.169.254/32

Si vos pods utilisent un proxy, vous devez ajouter 169.254.170.23 pour IPv4 et [fd00:ec2::23] pour IPv6. Mettez à jour les variables d'environnement no_proxy ou NO_PROXY (env) dans le fichier YAML de déploiement du pod.

Exemple de fichier YAML de déploiement de pod :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-namespace
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: my-app-image
          env:
            - name: HTTP_PROXY
              value: "http://proxy.example.com:3128"
            - name: HTTPS_PROXY
              value: "http://proxy.example.com:3128"
            - name: NO_PROXY
              value: "localhost,127.0.0.1,169.254.170.23,[fd00:ec2::23]"

Puis, pour implémenter vos modifications, exécutez la commande suivante :

kubectl apply -f deployment.yaml

Pour vérifier le paramètre NO_PROXY, exécutez la commande suivante :

kubectl exec -it pod-name -n namespace -- env | grep -i no_proxy

Remarque : Remplacez pod-name par le nom du pod et namespace par le nom de l'espace de noms.

Assurez-vous que la sortie ressemble à l’exemple suivant :

NO_PROXY=localhost,127.0.0.1,169.254.170.23,[fd00:ec2::23]

Résoudre les problèmes de configuration de l'agent CloudWatch

Pour identifier les problèmes liés à la configuration ou aux ressources du pod, exécutez la commande suivante pour vérifier le statut détaillé du pod :

kubectl describe pod pod-name -n namespace

Puis, suivez les étapes de dépannage suivantes en fonction de l'erreur que vous recevez.

Erreur Amazon/cloud-watch-agent:1 247345.36b249270 déjà présent sur la machine

Si vous n'avez pas correctement configuré cloudwatch-agent, le message d'erreur suivant s'affiche :

« Normal Pulled 14m (x307 over 26h) kubelet Container image "amazon/cloudwatch-agent:1.247345.36b249270" already present on machine Warning BackOff 4m10s (x7130 over 26h) kubelet Back-off restarting failed container aws-cloudwatch-metrics in pod aws-cloudwatch-metrics-4jz88_kube-system(ad6f68f0-7df0-435f-b101-2be05df84eb2) » (Kubelet normal extrait 14 m (x307 sur 26h) Image de conteneur "amazon/cloudwatch-agent:1.247345.36b249270" déjà présente sur la machine Avertissement Interruption kubelet 4 m 10 s (x7130 sur 26h) Interruption du redémarrage du conteneur défectueux aws-cloudwatch-metrics dans le pod aws-cloudwatch-metrics-4jz88_kube-system(ad6f68f0-7df0-435f-b101-2be05df84eb2)

Pour résoudre ce problème, vérifiez que vous avez configuré les fichiers de configuration cloudwatch-agent avec la région, les journaux et les métriques AWS appropriés. Vérifiez également les champs qui ne sont pas valides ou dont les paramètres sont manquants.

Pour vérifier si vous utilisez la bonne version de l'image, procédez comme suit :

1. Pour répertorier tous les pods qui exécutent l'agent CloudWatch, exécutez la commande suivante :

   kubectl get pods -n amazon-cloudwatch

   Remarque : Si vous utilisez un espace de noms personnalisé, remplacez amazon-cloudwatch par le nom de l'espace de noms.

2. Pour connaître la version de l’image, exécutez la commande suivante :

   kubectl describe pod pod-name -n amazon-cloudwatch

   Remarque : Remplacez pod-name par le nom de votre pod. Si vous utilisez un espace de noms personnalisé, remplacez amazon-cloudwatch par le nom de l'espace de noms.

3. Dans la sortie, vérifiez la valeur de l’Image pour le numéro de version :

   Containers:
     cloudwatch-agent:
       Image: public.ecr.aws/cloudwatch-agent/cloudwatch-agent:1.300017.0b337

   Pour voir la dernière version de l'agent CloudWatch, consultez la section Versions sur le site Web de GitHub.

4. Si vous utilisez une version antérieure, exécutez la commande suivante pour mettre à jour la version de l'image :

   kubectl set image daemonset/aws-cloudwatch-agent \
    -n amazon-cloudwatch \
    cloudwatch-agent=public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest-version

   Remarque : Remplacez latest-version par la dernière version de l'image.

5. Pour redémarrer le déploiement, exécutez la commande suivante :

   kubectl rollout restart daemonset aws-cloudwatch-agent -n amazon-cloudwatch

Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS, mettez-le à jour vers la dernière version.

Erreur OOM

Si votre conteneur ne dispose plus de mémoire disponible, le message d'erreur suivant s'affiche :

« Warning OOMKilled kubelet Container was killed due to OOM

Warning Failed kubelet Container failed to start: Back-off restarting failed container » (Avertissement Kubelet OOMKilled Le conteneur a été désactivé en raison d’une mémoire insuffisante Avertissement Kubelet défectueux Le conteneur n’a pas pu démarrer : Interruption du redémarrage du conteneur défectueux)

Pour résoudre ce problème, vérifiez les requêtes et les quotas (limites) que vous avez définis dans le fichier de déploiement du pod.

Exemple de fichier de déploiement de pod :

kubectl get pod cloudwatch-agent-xyz123 -n amazon-cloudwatch -o yaml | grep -A10 'resources:'
If limits are too low, update them in the DaemonSet:
resources:
  requests:
    cpu: 100m
    memory: 200Mi
  limits:
    cpu: 200m
    memory: 400Mi
Apply the changes:
kubectl apply -f cloudwatch-agent-daemonset.yaml

Pour mettre à jour les requêtes et les quotas, exécutez la commande suivante :

kubectl edit daemonset aws-cloudwatch-agent -n amazon-cloudwatch
resources:
  requests:
    cpu: 100m
    memory: 200Mi
  limits:
    cpu: 200m
    memory: 400Mi

Pour appliquer les modifications, exécutez la commande suivante :

kubectl rollout restart daemonset aws-cloudwatch-agent -n amazon-cloudwatch

Pour vous assurer que vos nœuds disposent de ressources suffisantes, exécutez la commande suivante :

kubectl top nodes

Si l'utilisation du processeur ou de la mémoire est élevée, exécutez la commande suivante pour mettre à l’échelle le cluster :

kubectl scale nodegroup --name nodegroup-name --replicas=new-size

Remarque : Remplacez nodegroup-name par le nom de votre groupe de nœuds et new-size par la nouvelle taille de groupe de nœuds.

Résoudre les problèmes de configuration de l'agent de l’identité du pod EKS

Erreur Démarrage du serveur impossible

Si vous n'avez pas configuré correctement l'agent de l'identité du pod EKS, le message d'erreur suivant peut s'afficher :

« {"bind-addr":"[fd00:ec2::23]:80","level":"info","msg":"Starting server...","time":"2024-02-05T17:52:40Z"}{"bind-addr":"[fd00:ec2::23]:80","level":"fatal","msg":"Unable to start server: listen tcp [fd00:ec2::23]:80: socket: address family not supported by protocol","time":"2024-02-05T17:52:40Z"}2024/02/05 17:52:40 running command: exit status 1 » ({"bind-addr":"[fd00:ec2::23]:80","level":"info","msg":"Starting server...","time":"2024-02-05T17:52:40Z"}{"bind-addr":"[fd00:ec2::23]:80","level":"fatal","msg":"Impossible de démarrer le serveur : écoutez tcp [fd00:ec2::23]:80: socket : famille d’adresses non prise en charge par le protocole","time" : "2024-02-05T17:52:40Z"}2024/02/05 17:52:40 exécution de la commande : statut de sortie 1)

Pour résoudre ce problème, assurez-vous de respecter les exigences relatives à l'agent de l'identité du pod Amazon EKS.

Assurez-vous d'utiliser la dernière version du module complémentaire afin de réduire les problèmes de compatibilité des versions. Pour vérifier la dernière version disponible, exécutez la commande de l'interface de ligne de commande AWS describe-addon-versions suivante :

aws eks describe-addon-versions --kubernetes-version 1.31 --addon-name eks-pod-identity-agent

Remarque : Remplacez 1.31 par la version de votre cluster.

Pour mettre à jour le module complémentaire, exécutez la commande update-addon suivante :

aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version version-number --resolve-conflicts PRESERVE

Remarque : Remplacez my-cluster par le nom de votre cluster et version-number par la version du module complémentaire.