Como resolver o estado CrashLoopBackOff dos pods do agente do CloudWatch e do agente de Identidade de Pods do EKS?

11 minuto de leitura

Meus pods do agente do Amazon CloudWatch ou do agente de Identidade de Pods do Amazon EKS no cluster do Amazon Elastic Kubernetes Service (Amazon EKS) estão travados no estado CrashLoopBackOff.

Resolução

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solução de problemas da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

Verifique os logs

Primeiro, verifique os logs do agente CloudWatch e do agente de Identidade de Pods do EKS para reunir informações sobre o problema.

Para verificar os logs do agente do CloudWatch, execute o seguinte comando:

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

Observação: substitua cloudwatch-agent-pod-name pelo nome do pod do agente CloudWatch e namespace pelo nome do namespace.

Para verificar os logs do agente de Identidade de Pods do EKS, execute o seguinte comando:

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

Observação: substitua pod-identity-agent-pod-name pelo nome do seu agente de Identidade de Pods do EKS e namespace pelo nome do seu namespace.

Na saída do comando, procure mensagens de erro que mostrem por que o pod falha, como problemas de permissão, problemas de rede ou problemas de configuração.

Solucionar problemas de permissões do agente CloudWatch

Não é possível criar um erro de provedor

Você deve usar o perfil de conta da AWS do serviço AWS Identity and Access Management (AWS IAM) para permitir que os nós de processamento do Amazon EKS enviem métricas e logs para o CloudWatch. Se o perfil do IAM estiver ausente ou configurada incorretamente no namespace amazon-cloudwatch necessário, você receberá o seguinte erro:

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

Para solucionar esse problema, crie um perfil de conta de serviço com o nome cloudwatch-agent.

Para criar um perfil de conta de serviço personalizado, execute o seguinte 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

Observação: substitua cluster-name pelo nome do cluster do Amazon EKS e service-account-name pelo nome da conta de serviço personalizada.

Em seguida, crie um ConfigMap para o agente CloudWatch. Se você usar um perfil de conta de serviço personalizado, substitua cloudwatch-agent pelo nome do perfil da conta de serviço.

Erros Não autorizado a executar: sts:AssumeRole

Se o perfil da conta de serviço usado pelo agente do CloudWatch não puder ser autenticado, você receberá um dos seguintes erros:

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

-ou-

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

Certifique-se de anexar a política CloudWatchAgentServerPolicy ao perfil da conta de serviço. Para identificar problemas de autenticação, verifique o AWS CloudTrail para ver os eventos PutLogEvents e DescribeLogStreams. Certifique-se de usar a conta de serviço cloudwatch-agent ou o nome correto da conta de serviço personalizada no arquivo YAML de implantação.

Para verificar a configuração da conta de serviço, execute o seguinte comando:

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

Na saída, verifique se os metadados eks.amazonaws.com/role-arn são semelhantes ao exemplo a seguir:

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

As contas de serviço do agente CloudWatch devem ter as seguintes regras:

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 verificar as regras na conta de serviço, execute o seguinte comando:

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

Solucionar problemas de permissões do agente de Identidade de Pods do EKS

Não autorizado a executar: EKS-Auth:AssumeRoleForPodIdentity ou Error fetching credentials errors

Se o agente de Identidade de Pods do EKS não conseguir assumir o perfil do IAM do nó do Amazon EKS, você receberá um dos seguintes erros:

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

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

Para solucionar esse problema, certifique-se de que a política do IAM que você anexou ao perfil permita a ação AssumeRoleForPodIdentity. É uma prática recomendada usar a política gerenciada pela AWS da AmazonEKSWorkerNodePolicy. Ou é possível adicionar uma política personalizada semelhante ao exemplo a seguir:

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

Além disso, confirme se as políticas de controle de serviços (SCPs) da sua organização não bloqueiam a ação AssumeRoleForPodIdentity.

Importante: se você criar o pod e a conta de serviço ao mesmo tempo que a associação de identidade de pods, poderá encontrar problemas. Para resolver os problemas, aguarde pelo menos 10 segundos depois de criar o perfil para associá-lo ao pod.

Solucionar problemas de rede do agente CloudWatch

Erros Falha ao enviar logs ou Erro ao executar PutLogEvents

Se o agente do CloudWatch não conseguir acessar o endpoint do CloudWatch Logs, você receberá um dos seguintes erros:

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

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

Esse problema geralmente ocorre devido a restrições de rede ou grupos de segurança mal configurados. Para solucionar problemas, certifique-se de que os nós tenham acesso de saída à Internet por meio de um gateway da Internet. Para sub-redes privadas, confirme se você configurou corretamente o gateway NAT. Configure o endpoint de nuvem privada virtual (VPC) para os serviços do CloudWatch. O endpoint da VPC deve usar a convenção de nomenclatura com.amazonaws.Region.logs, e o grupo de segurança do endpoint deve permitir tráfego de entrada do grupo de segurança do nó.

Para confirmar se os grupos de segurança do nó permitem tráfego HTTPS de saída, verifique a seguinte configuração:

Tipo: HTTPS
Protocolo: TCP
Porta: 443
Destino de intervalo: 0.0.0.0/0

Solucionar problemas de rede do agente de Identidade de Pods do EKS

Erro ao recuperar o token da conta de serviço

Os grupos de segurança do pod devem permitir o tráfego HTTP de saída na porta TCP 80 para o endereço IP do serviço de metadados de instância (169.254.169.254). Se não o fizerem, você receberá o seguinte erro:

"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 esse problema, certifique-se de que os grupos de segurança do pod usem a seguinte configuração:

Tipo: HTTPS
Protocolo: TCP
Porta: 80
Destino de intervalo: 169.254.169.254/32

Se seus pods usarem um proxy, você deverá adicionar 169.254.170.23 para IPv4 e [fd00:ec2::23] para IPv6. Atualize as variáveis de ambiente no_proxy ou NO_PROXY (env) no arquivo YAML de implantação do pod.

Exemplo de arquivo YAML de implantação 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]"

Em seguida, para implementar suas alterações, execute o seguinte comando:

kubectl apply -f deployment.yaml

Para verificar a configuração NO_PROXY, execute o seguinte comando:

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

Observação: substitua pod-name pelo nome do pod e namespace pelo nome do namespace.

Certifique-se de que a saída seja semelhante ao exemplo a seguir:

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

Solucionar problemas de configuração do agente CloudWatch

Para identificar problemas relacionados à configuração ou aos recursos do pod, execute o seguinte comando para verificar o status detalhado do pod:

kubectl describe pod pod-name -n namespace

Em seguida, siga as etapas de solução de problemas a seguir com base no erro recebido.

Amazon/cloud-watch-agent:1 247345.36b249270" já está presente em caso de erro de máquina

Se você configurou incorretamente o cloudwatch-agent, receberá o seguinte erro:

"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 esse problema, confirme se você configurou os arquivos de configuração do cloudwatch-agent com a região, os logs e as métricas corretas da AWS. Além disso, verifique se há campos que não sejam válidos ou que tenham parâmetros ausentes.

Para verificar se você está usando a versão correta da imagem, conclua as seguintes etapas:

Para listar todos os pods que executam o agente CloudWatch, execute o seguinte comando:
```
kubectl get pods -n amazon-cloudwatch
```
Observação: se você usa um namespace personalizado, substitua amazon-cloudwatch pelo nome do namespace.
Para verificar a versão da imagem, execute o seguinte comando:
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
Observação: substitua pod-name pelo nome do seu pod. Se você usa um namespace personalizado, substitua amazon-cloudwatch pelo nome do namespace.

Na saída, verifique o valor da imagem para o número da versão:

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

Para ver a versão mais recente do agente CloudWatch, consulte Lançamentos no site do GitHub.

Se você usar uma versão anterior, execute o seguinte comando para atualizar a versão da imagem:

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

Observação: substitua a latest-version pela versão mais recente da imagem.

Para reiniciar a implantação, execute o seguinte comando:

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

Se você usa o complemento Amazon CloudWatch Observability EKS, atualize o complemento para a versão mais recente.

Erro OOM

Se o contêiner não tiver mais memória disponível, você receberá o seguinte erro:

"Warning OOMKilled kubelet Container was killed due to OOM

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

Para solucionar esse problema, verifique as solicitações de recursos e as cotas (limites) que você definiu no arquivo de implantação do pod.

Exemplo de arquivo de implantação 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 atualizar as solicitações e cotas, execute o seguinte comando:

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

Para implementar as alterações, execute o seguinte comando:

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

Para garantir que seus nós tenham recursos suficientes, execute o seguinte comando:

kubectl top nodes

Se o uso da CPU ou da memória for alto, execute o seguinte comando para escalar o cluster:

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

Observação: substitua nodegroup-name pelo nome do seu grupo de nós e new-size pelo novo tamanho do grupo de nós.

Solucionar problemas de configuração do agente de Identidade de Pods do EKS

Não é possível iniciar o erro do servidor

Se você não configurou corretamente o agente de Identidade de Pods do EKS, poderá receber o seguinte erro:

"{"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 esse problema, certifique-se de cumprir os requisitos do agente de Identidade de Pods do Amazon EKS.

Certifique-se de usar a versão mais recente do complemento para reduzir os problemas de compatibilidade de versões. Para verificar a versão mais recente disponível, execute o seguinte comando describe-addon-versions da AWS CLI:

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

Observação: substitua 1.31 pela sua versão do cluster.

Para atualizar o complemento, execute o seguinte comando update-addon:

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

Observação: substitua my-cluster pelo nome do cluster e version-number pela versão do complemento.

Tópicos: Containers
Tags: Amazon Elastic Kubernetes Service
Idioma: Português

AWS OFICIALAtualizada há um ano

Sem comentários

Conteúdo relevante

Como alocar custos de uso do InvokeAgent no Amazon Bedrock por agente ou aplicação?
Mauricio Schmitz
feita há um ano
Como criar um novo Cluster com a conta Free Tier?
User-7725420
feita há 8 meses
Log de erro no Histórico do CloudWatch, porém funcionado o invoke da Lambda, envio de SNS, alerta de alarme no CloudWatch
Resposta aceita
Jovando
feita há um ano
Erro ao conectar remotamente a Instância EC2 após problemas na licença do Acesso Remoto do Windows Server
PauloS
feita há um ano
Erro "Fail to request credentials" e "Failed to describe Volume vol-0fbd7fb10faaaeddc Fail to request credentials"
rePost-User-6897398
feita há 6 meses
Como posso solucionar problemas de pods do Amazon EKS no AWS Fargate que estão paralisados no estado Pendente?
AWS OFICIALAtualizada há 3 anos
Como soluciono os erros “Unable to fetch credentials” (Não é possível obter credenciais) ao tentar ativar a Identidade de Pods do EKS em meus clusters?
AWS OFICIALAtualizada há um ano
Como soluciono problemas de status do pod no Amazon EKS?
AWS OFICIALAtualizada há 2 anos
Como soluciono problemas de pod do Kubernetes no Amazon EKS?
AWS OFICIALAtualizada há 7 meses
Usando o CloudWatch e o AWS Shield para Monitoramento Eficaz de DDoS: Um Guia Técnico
ESPECIALISTA
Mateus Prado
publicada há 9 meses