Wie beseitige ich den CrashLoopBackOff-Status für CloudWatch-Agent- und EKS-Pod-Identity-Agent-Pods?

Behebung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version von AWS CLI verwendest.

Protokolle überprüfen

Überprüfe zunächst die Protokolle von CloudWatch-Agent und EKS Pod Identity Agent, um Informationen zu dem Problem zu sammeln.

Führe den folgenden Befehl aus, um die CloudWatch-Agent-Protokolle zu überprüfen:

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

Hinweis: Ersetze cloudwatch-agent-pod-name durch den Pod-Namen deines CloudWatch-Agents und namespace durch deinen Namespace-Namen.

Führe den folgenden Befehl aus, um die EKS-Pod-Identity-Agent-Protokolle zu überprüfen:

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

Hinweis: Ersetze pod-identity-agent-pod-name durch deinen EKS-Pod-Identity-Agent-Pod-Namen und namespace durch deinen Namespace-Namen.

Suche in der Befehlsausgabe nach Fehlermeldungen, die angeben, warum der Pod abstürzt, z. B. Berechtigungsprobleme, Netzwerkprobleme oder Konfigurationsprobleme.

Probleme mit den CloudWatch-Agent-Berechtigungen beheben

Fehlermeldung Cannot create provider

Du musst die Service-AWS-Kontorolle von AWS Identity and Access Management (IAM) verwenden, um Amazon-EKS-Worker-Knoten die Berechtigung zu erteilen, Metriken und Protokolle an CloudWatch zu senden. Wenn die IAM-Rolle fehlt oder im erforderlichen amazon-cloudwatch-Namespace falsch konfiguriert ist, erhältst du die folgende Fehlermeldung:

„Error: cannot create provider: failed to retrieve credentials: failed to assume role“

Um dieses Problem zu beheben, erstelle eine Servicekonto-Rolle mit dem Namen des cloudwatch-agent.

Führe den folgenden Befehl aus, um eine benutzerdefinierte Servicekonto-Rolle zu erstellen:

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

Hinweis: Ersetze cluster-name durch deinen Amazon-EKS-Clusternamen und service-account-name durch den Namen des benutzerdefinierten Servicekontos.

Erstelle danach eine ConfigMap für CloudWatch-Agent. Wenn du eine benutzerdefinierte Servicekonto-Rolle verwendest, ersetze cloudwatch-agent durch den Namen der Servicekonto-Rolle.

Fehlermeldungen Not authorized to perform: sts:AssumeRole

Wenn sich die Servicekonto-Rolle, die CloudWatch-Agent verwendet, nicht authentifizieren kann, wird eine der folgenden Fehlermeldungen angezeigt:

„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]“

-oder-

„Error: AccessDenied: Not authorized to perform sts:AssumeRole“

Stelle sicher, dass du die CloudWatchAgentServerPolicy-Richtlinie an die Servicekonto-Rolle angehängt hast. Um Authentifizierungsprobleme zu identifizieren, überprüfe AWS CloudTrail auf PutLogEvents- und DescribeLogStreams-Ereignisse. Vergewissere dich, dass du das Servicekonto cloudwatch-agent verwendest oder den richtigen benutzerdefinierten Servicekonto-Namen in der YAML-Bereitstellungsdatei.

Führe den folgenden Befehl aus, um die Konfiguration des Servicekontos zu überprüfen:

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

Stelle in der Ausgabe sicher, dass die Metadaten von eks.amazonaws.com/role-arn dem folgenden Beispiel ähneln:

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

Für Servicekonten für CloudWatch-Agent müssen die folgenden Regeln gelten:

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"]

Führe den folgenden Befehl aus, um die Regeln im Servicekonto zu überprüfen:

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

EKS-Pod-Identity-Agent-Berechtigungsprobleme beheben

Fehlermeldung „Not authorized to perform: eks-auth:AssumeRoleForPodIdentity“ oder Fehlermeldung „Error fetching credentials“

Wenn EKS Pod Identity Agent die IAM-Rolle des Amazon-EKS-Knotens nicht übernehmen kann, erhältst du eine der folgenden Fehlermeldungen:

„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]“

-oder-

„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"“

Um dieses Problem zu beheben, achte darauf, dass die IAM-Richtlinie, die du an die Rolle angehängt hast, die Aktion AssumeRoleForPodIdentity zulässt. Es hat sich bewährt, die von AWS verwaltete Richtlinie AmazonEKSWorkerNodePolicy zu verwenden. Oder du kannst eine benutzerdefinierte Richtlinie hinzufügen, die dem folgenden Beispiel ähnelt:

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

Vergewissere dich außerdem, dass die Service-Kontrollrichtlinien (SCPs) für dein Unternehmen die Aktion AssumeRoleForPodIdentity nicht blockieren.

Wichtig: Wenn du den Pod und das Servicekonto gleichzeitig mit der Pod-Identity-Zuordnung erstellst, treten möglicherweise Probleme auf. Um die Probleme zu beheben, warte nach dem Erstellen der Rolle mindestens 10 Sekunden, um die Rolle dem Pod zuzuordnen.

Netzwerkprobleme von CloudWatch-Agent beheben

Fehlermeldung „Failed to send logs“ oder Fehlermeldung „Error occurs in PutLogEvents“

Wenn CloudWatch-Agent den CloudWatch-Protokollendpunkt nicht erreichen kann, wird eine der folgenden Fehlermeldungen angezeigt:

„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“

-oder-

„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/\"“

Dieses Problem tritt in der Regel aufgrund von Netzwerkeinschränkungen oder falsch konfigurierten Sicherheitsgruppen auf. Stelle zur Problembeseitigung sicher, dass die Knoten über ein Internet-Gateway ausgehenden Internetzugang haben. Vergewissere dich bei privaten Subnetzen, dass das NAT-Gateway ordnungsgemäß konfiguriert ist. Richte den Virtual-Private-Cloud(VPC)-Endpunkt für CloudWatch-Services ein. Der VPC-Endpunkt muss die Benennungskonvention com.amazonaws.Region.logs verwenden und die Sicherheitsgruppe des Endpunkts muss eingehenden Datenverkehr von der Knoten-Sicherheitsgruppe zulassen.

Um zu bestätigen, dass die Knoten-Sicherheitsgruppen ausgehenden HTTPS-Verkehr zulassen, überprüfe die folgende Konfiguration:

• Typ: HTTPS
• Protokoll: TCP
• Port: 443
• Zielbereich: 0.0.0.0/0

Netzwerkprobleme von EKS Pod Identity Agent beheben

Fehlermeldung „Error retrieving service account token“

Die Pod-Sicherheitsgruppen müssen ausgehenden HTTP-Verkehr auf TCP-Port 80 zur IP-Adresse des Instance-Metadatenservices (169.254.169.254) zulassen. Ist dies nicht der Fall, wird die folgende Fehlermeldung angezeigt:

„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“

Um dieses Problem zu beheben, vergewissere dich, dass die Pod-Sicherheitsgruppen die folgende Konfiguration verwenden:

• Typ: HTTPS
• Protokoll: TCP
• Port: 80
• Zielbereich: 169.254.169.254/32

Wenn deine Pods einen Proxy verwenden, musst du für IPv4 169.254.170.23 und für IPv6 [fd00:ec2::23] hinzufügen. Ändere die Umgebungsvariablen (env) no_proxy oder NO_PROXY in der YAML-Datei für die Pod-Bereitstellung.

Beispiel für eine YAML-Datei für die Pod-Bereitstellung:

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]"

Führe danach den folgenden Befehl aus, um deine Änderungen zu übernehmen:

kubectl apply -f deployment.yaml

Führe den folgenden Befehl aus, um die Einstellung NO_PROXY zu überprüfen:

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

Hinweis: Ersetze pod-name durch den Pod-Namen und namespace durch den Namespace-Namen.

Achte darauf, dass die Ausgabe dem folgenden Beispiel ähnelt:

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

Probleme mit der CloudWatch-Agent-Konfiguration beheben

Führe zur Ermittlung von Problemen mit der Konfiguration oder den Ressourcen für den Pod den folgenden Befehl aus, um den detaillierten Status des Pods zu überprüfen:

kubectl describe pod pod-name -n namespace

Führe danach ausgehend von der Fehlermeldung, die du erhältst, die folgenden Schritte zur Fehlerbehebung durch.

Fehlermeldung Amazon/cloud-watch-agent:1 247345.36b249270" already present on machine

Wenn du cloudwatch-agent falsch konfiguriert hast, wird die folgende Fehlermeldung angezeigt:

„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)“

Um dieses Problem zu beheben, stelle sicher, dass du die cloudwatch-agent-Konfigurationsdateien mit der richtigen AWS-Region sowie den richtigen Protokollen und Metriken konfiguriert hast. Suche auch nach Feldern, die nicht gültig sind oder in denen Parameter fehlen.

Gehe wie folgt vor, um zu überprüfen, ob du die richtige Image-Version verwendest:

1. Führe den folgenden Befehl aus, um alle Pods aufzulisten, auf denen CloudWatch-Agent ausgeführt wird:

   kubectl get pods -n amazon-cloudwatch

   Hinweis: Wenn du einen benutzerdefinierten Namespace verwendest, ersetze amazon-cloudwatch durch den Namespace-Namen.

2. Führe den folgenden Befehl aus, um die Image-Version zu überprüfen:

   kubectl describe pod pod-name -n amazon-cloudwatch

   Hinweis: Ersetze pod_name durch den Namen deines Pods. Wenn du einen benutzerdefinierten Namespace verwendest, ersetze amazon-cloudwatch durch den Namespace-Namen.

3. Überprüfe in der Ausgabe die Versionsnummer des Images:

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

   Die neueste Version des CloudWatch-Agents findest du unter Releases auf der GitHub-Website.

4. Wenn du eine frühere Version verwendest, führe den folgenden Befehl aus, um die Image-Version auf den neuesten Stand zu bringen:

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

   Hinweis: Ersetze latest-version durch die neueste Image-Version.

5. Führe den folgenden Befehl aus, um die Bereitstellung neu zu starten:

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

Wenn du das Amazon-CloudWatch-Observability-EKS-Add-on verwendest, aktualisiere das Add-on auf die neueste Version.

OOM-Fehler

Wenn für deinen Container kein Speicher mehr verfügbar ist, wird die folgende Fehlermeldung angezeigt:

„Warning OOMKilled kubelet Container was killed due to OOM

Warning Failed kubelet Container failed to start: Back-off restarting failed container“

Um dieses Problem zu beheben, überprüfe die Ressourcenanforderungen und Kontingente (Limits), die du in der Pod-Bereitstellungsdatei definiert hast.

Beispiel für eine Pod-Bereitstellungsdatei:

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

Führe den folgenden Befehl aus, um die Anforderungen und Kontingente zu aktualisieren:

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

Führe den folgenden Befehl aus, um die Änderungen zu übernehmen:

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

Führe den folgenden Befehl aus, um sicherzustellen, dass deine Knoten über ausreichend Ressourcen verfügen:

kubectl top nodes

Wenn die CPU- oder Speicherauslastung hoch ist, führe den folgenden Befehl aus, um den Cluster zu skalieren:

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

Hinweis: Ersetze nodegroup-name durch den Namen deiner Knotengruppe und new-size durch die neue Knotengruppengröße.

Konfigurationsproblemen mit EKS Pod Identity Agent beheben

Fehlermeldung Unable to start server

Wenn du EKS Pod Identity Agent nicht richtig konfiguriert hast, wird möglicherweise die folgende Fehlermeldung angezeigt:

„{"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“

Um dieses Problem zu beheben, vergewissere dich, dass du die Anforderungen von Amazon EKS Pod Identity Agent erfüllst.

Stelle sicher, dass du die neueste Add-on-Version verwendest, um Probleme mit der Versionskompatibilität zu reduzieren. Führe den folgenden AWS-CLI-Befehl describe-addon-versions aus, um die neueste verfügbare Version herauszufinden:

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

Hinweis: Ersetze 1.31 durch deine Cluster-Version.

Führe den folgenden Befehl update-addon aus, um das Add-on zu aktualisieren:

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

Hinweis: Ersetze my-cluster durch deinen Cluster-Namen und version-number durch die Add-on-Version.