¿Cómo soluciono el estado CrashLoopBackoff para los pods del agente de CloudWatch y del agente de EKS Pod Identity?

Solución

Nota: Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), consulta Solución de problemas de AWS CLI. Además, asegúrate de utilizar la versión más reciente de AWS CLI.

Comprobación de los registros

En primer lugar, comprueba los registros del agente de CloudWatch y del agente de EKS Pod Identity para recopilar información sobre el problema.

Para comprobar los registros de los agentes de CloudWatch, usa el siguiente comando:

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

Nota: Sustituye cloudwatch-agent-pod-name por el nombre del pod del agente de CloudWatch y namespace por el nombre de tu espacio de nombres.

Para comprobar los registros del agente de EKS Pod Identity, usa el siguiente comando:

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

Nota: Sustituye pod-identity-agent-pod-name por el nombre del pod del agente de EKS Pod Identity y namespace por el nombre de tu espacio de nombres.

En el resultado del comando, busca los mensajes de error que muestren por qué se bloquea el pod, como problemas de permisos, problemas de red o problemas de configuración.

Solución de problemas de permisos de los agentes de CloudWatch

Error Cannot create provider

Debes utilizar el rol de cuenta de AWS del servicio AWS Identity and Access Management (IAM) para permitir que los nodos de trabajo de Amazon EKS envíen métricas y registros a CloudWatch. Si falta el rol de IAM o está mal configurado en el espacio de nombres amazon-cloudwatch requerido, verás el siguiente error:

"Error: cannot create provider: failed to retrieve credentials: failed to assume role"

Para solucionar este problema, crea un rol de cuenta de servicio con el nombre cloudwatch-agent.

Para crear un rol de cuenta de servicio personalizado, usa el siguiente comando:

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

Nota: Sustituye cluster-name por el nombre del clúster de Amazon EKS y service-account-name por el nombre de la cuenta de servicio personalizado.

A continuación, crea un ConfigMap para el agente de CloudWatch. Si usas un rol de cuenta de servicio personalizado, sustituye cloudwatch-agent por el nombre del rol de la cuenta de servicio.

Errores Not authorized to perform: sts:AssumeRole

Si el rol de la cuenta de servicio que usa el agente de CloudWatch no puede autenticarse, verás uno de los siguientes errores:

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

O bien:

"Error: AccessDenied: Not authorized to perform sts:AssumeRole"

Asegúrate de adjuntar la política CloudWatchAgentServerPolicy al rol de la cuenta de servicio. Para identificar problemas de autenticación, consulta AWS CloudTrail para ver los eventos PutLogEvents y DescribeLogStreams. Asegúrate de usar la cuenta de servicio cloudwatch-agent o el nombre de cuenta de servicio personalizado correcto en el archivo YAML de despliegue.

Para comprobar la configuración de la cuenta de servicio, usa el siguiente comando:

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

En el resultado, asegúrate de que los metadatos de eks.amazonaws.com/role-arn sean similares a los del siguiente ejemplo:

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

Las cuentas de servicio del agente de CloudWatch deben tener las siguientes reglas:

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

Para comprobar las reglas de la cuenta de servicio, usa el siguiente comando:

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

Solución de problemas de permisos del agente de EKS Pod Identity

Not authorized to perform: eks-auth:AssumeRoleForPodIdentity or Error fetching credentials errors

Si el agente de EKS Pod Identity no puede asumir el rol de IAM del nodo de Amazon EKS, verás uno de los siguientes errores:

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

O bien:

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

Para solucionar este problema, asegúrate de que la política de IAM que adjuntaste al rol permita la acción AssumeRoleForPodIdentity. Se recomienda utilizar la política administrada de AWS AmazonEKSWorkerNodePolicy. O bien, puedes agregar una política personalizada similar a la del siguiente ejemplo:

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

Confirma también que las políticas de control de servicios (SCP) de tu organización no bloqueen la acción AssumeRoleForPodIdentity.

Importante: Si creas el pod y la cuenta de servicio al mismo tiempo que la asociación de Pod Identity, es posible que surjan problemas. Para resolver los problemas, espera al menos 10 segundos después de crear el rol para asociarlo al pod.

Solución de problemas de red de los agentes de CloudWatch

Errores Failed to send logs o Error occurs in PutLogEvents

Si el agente de CloudWatch no puede llegar al punto de enlace de Registros de CloudWatch, verás uno de los siguientes errores:

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

O bien:

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

Este problema suele producirse debido a restricciones de red o grupos de seguridad mal configurados. Para solucionar problemas, asegúrate de que los nodos tengan acceso saliente a Internet a través de una puerta de enlace a Internet. En el caso de las subredes privadas, confirma que configuraste correctamente la puerta de enlace de NAT. Configura el punto de enlace de la nube virtual privada (VPC) para los servicios de CloudWatch. El punto de enlace de VPC debe utilizar la convención de nomenclatura com.amazonaws.Region.logs y el grupo de seguridad del punto de enlace debe permitir el tráfico entrante del grupo de seguridad del nodo.

Para confirmar que los grupos de seguridad de los nodos permiten el tráfico HTTPS saliente, comprueba la siguiente configuración:

• Tipo: HTTPS
• Protocolo: TCP
• Puerto: 443
• Destino de rango: 0.0.0.0/0

Solución de problemas de red del agente de EKS Pod Identity

Error "Error retrieving service account token"

Los grupos de seguridad del pod deben permitir el tráfico HTTP saliente en el puerto TCP 80 a la dirección IP del servicio de metadatos de la instancia (169.254.169.254). Si no lo hacen, verás el siguiente error:

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

Para solucionar este problema, asegúrate de que los grupos de seguridad del pod utilicen la siguiente configuración:

• Tipo: HTTPS
• Protocolo: TCP
• Puerto: 80
• Destino de rango: 169.254.169.254/32

Si tus pods usan un proxy, debes agregar 169.254.170.23 para IPv4 y [fd00:ec2::23] para IPv6. Actualiza las variables de entorno no_proxy o NO_PROXY (env) en el archivo YAML de despliegue del pod.

Ejemplo de archivo YAML de despliegue del 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]"

A continuación, para implementar los cambios, usa el siguiente comando:

kubectl apply -f deployment.yaml

Para comprobar la configuración NO_PROXY, usa el siguiente comando:

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

Nota: Sustituye pod-name por el nombre del pod y namespace por el nombre del espacio de nombres.

Asegúrate de que el resultado sea similar al siguiente ejemplo:

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

Solución de problemas de configuración de los agentes de CloudWatch

Para identificar los problemas relacionados con la configuración o los recursos del pod, usa el siguiente comando para comprobar el estado detallado del pod:

kubectl describe pod pod-name -n namespace

Luego, sigue los siguientes pasos de solución de problemas según el error que recibas.

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

Si configuraste cloudwatch-agent de forma incorrecta, verás el siguiente error:

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

Para solucionar este problema, confirma que has configurado los archivos de configuración de cloudwatch-agent con la región, los registros y las métricas de AWS correctos. Revisa también si hay campos que no sean válidos o a los que les falten parámetros.

Para comprobar si estás usando la versión de imagen correcta, sigue estos pasos:

1. Para enumerar todos los pods que usan el agente de CloudWatch, usa el siguiente comando:

   kubectl get pods -n amazon-cloudwatch

   Nota: Si usas un espacio de nombres personalizado, sustituye amazon-cloudwatch por el nombre del espacio de nombres.

2. Para comprobar la versión de la imagen, usa el siguiente comando:

   kubectl describe pod pod-name -n amazon-cloudwatch

   Nota: Sustituye pod-name por el nombre de tu pod. Si usas un espacio de nombres personalizado, sustituye amazon-cloudwatch por el nombre del espacio de nombres.

3. En el resultado, comprueba el número de versión de Imagen:

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

   Para ver la versión más reciente del agente de CloudWatch, consulta Releases (Versiones) en el sitio web de GitHub.

4. Si usas una versión anterior, usa el siguiente comando para actualizar la versión de la imagen:

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

   Nota: Sustituye latest-version por la última versión de la imagen.

5. Para iniciar el despliegue, usa el siguiente comando:

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

Si usas el complemento de observabilidad para EKS de Amazon CloudWatch, actualízalo a su versión más reciente.

Error de OOM

Si el contenedor no tiene más memoria disponible, verás el siguiente error:

"Warning OOMKilled kubelet Container was killed due to OOM

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

Para solucionar este problema, comprueba las solicitudes de recursos y las cuotas (límites) que definiste en el archivo de despliegue del pod.

Ejemplo de archivo de despliegue 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

Para actualizar las solicitudes y las cuotas, usa el siguiente comando:

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

Usa el siguiente comando para implementar los cambios:

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

Para asegurarte de que los nodos tengan suficientes recursos, usa el siguiente comando:

kubectl top nodes

Si el uso de CPU o memoria es alto, usa el siguiente comando para escalar el clúster:

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

Nota: Sustituye nodegroup-name por el nombre de tu grupo de nodos y new-size por el nuevo tamaño del grupo de nodos.

Solución de problemas de configuración del agente de EKS Pod Identity

Error Unable to start server

Si no configuraste correctamente el agente de EKS Pod Identity, es posible que veas el siguiente error:

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

Para solucionar este problema, asegúrate de cumplir los requisitos del agente de Amazon EKS Pod Identity.

Asegúrate de usar la última versión del complemento para reducir los problemas de compatibilidad de versiones. Para comprobar la última versión disponible, usa el comando describe-addon-versions de AWS CLI:

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

Nota: Sustituye 1.31 por la versión de clúster.

Para actualizar el complemento, usa el comando update-addon:

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

Nota: Sustituye my-cluster por el nombre de tu clúster y version-number por la versión del complemento.