Solucionar problemas com clusters e nós do Amazon EKS

Este capítulo aborda alguns erros comuns que você poderá encontrar ao usar o Amazon EKS e como resolvê-los. Se você precisar solucionar problemas em áreas específicas do Amazon EKS, consulte os tópicos Solução de problemas do IAM, Solução de problemas do Amazon EKS Connector e Solução de problemas do ADOT utilizando complementos do EKS.

Para obter outras informações sobre solução de problemas, consulte o conteúdo do Centro de Conhecimento sobre o Amazon Elastic Kubernetes Service em AWS re:Post.

Insufficient capacity (Capacidade insuficiente)

Se você receber o seguinte erro ao tentar criar um cluster do Amazon EKS, isso significa que uma das zonas de disponibilidade que você especificou não tem capacidade suficiente para oferecer suporte a um cluster.

Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c

Tente criar o cluster com sub-redes na VPC do cluster que são hospedadas nas zonas de disponibilidade retornadas por essa mensagem de erro.

Existem zonas de disponibilidade nas quais um cluster não pode residir. Compare as Zonas de Disponibilidade em que suas sub-redes estão com a lista de Zonas de Disponibilidade em Requisitos e considerações para sub-redesRequisitos e considerações da sub-rede.

Worker nodes fail to join cluster (Falha nos nós ao ingressar no cluster)

Há alguns motivos comuns que impedem que os nós ingressem no cluster:

Você pode usar o runbook AWSSupport-TroubleshootEKSWorkerNode para identificar e solucionar problemas de causas comuns que impedem o ingresso dos nós de processamento em um cluster. Para obter mais informações, consulte AWSSupport-TroubleshootEKSWorkerNode na referência do runbook AWS Systems Manager Automation.

Acesso negado ou não autorizado (kubectl)

Se você receber um dos erros a seguir ao executar os comandos do kubectl, é porque o kubectl não está configurado corretamente para o Amazon EKS ou as credenciais para a entidade principal do IAM (perfil ou usuário) que estão sendo usadas não estão mapeadas para um nome de usuário do Kubernetes com permissões suficientes para objetos do Kubernetes no seu cluster do Amazon EKS.

Isso pode ocorrer devido a um dos seguintes motivos:

Se você instalar e configurar a AWS CLI, poderá configurar as credenciais do IAM que usa. Para obter mais informações, consulte Configurar a AWS CLI, no Guia do usuário da AWS Command Line Interface. Também é possível configurar kubectl para usar um perfil do IAM, se você assumir um perfil do IAM para acessar objetos do Kubernetes no seu cluster. Para ter mais informações, consulte Conecte o kubectl a um cluster EKS criando um arquivo kubeconfig.

hostname doesn’t match

Seu sistema precisa ter a versão 2.7.9 ou superior do Python. Caso contrário, você receberá erros hostname doesn’t match com chamadas AWS CLI para o Amazon EKS. Para obter mais informações, consulte What are "hostname doesn't match" errors? nas Perguntas frequentes sobre solicitações do Python.

getsockopt: no route to host

O Docker é executado no intervalo 172.17.0.0/16 do CIDR em clusters do Amazon EKS. Recomendamos que as sub-redes da VPC do cluster não sobreponham esse intervalo. Caso contrário, você receberá o seguinte erro:

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>:10250: getsockopt: no route to host

Instances failed to join the Kubernetes cluster

Se você receber o erro Instances failed to join the Kubernetes cluster no AWS Management Console, certifique-se de que o acesso ao endpoint privado do cluster esteja habilitado ou que você configurou corretamente os blocos CIDR para acesso ao endpoint público. Para ter mais informações, consulte Controlar o acesso à rede ao endpoint do servidor de API do cluster.

Códigos de erro para o grupo de nós gerenciados

Se o grupo de nós gerenciados encontrar um problema de integridade de hardware, o Amazon EKS retornará um código de erro para ajudar você a diagnosticar o problema. Essas verificações de integridade não detectam problemas de software porque são baseadas em verificações de integridade do Amazon EC2. A lista a seguir descreve os códigos de erro.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl describe clusterrole eks:node-manager

kubectl describe clusterrolebinding eks:node-manager

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl apply -f eks-node-manager-role.yaml

Not authorized for images

Uma possível causa de uma mensagem de erro Not authorized for images é usar uma AMI privada do Windows do Amazon EKS para executar grupos de nós gerenciados do Windows. Depois de lançar novas AMIs do Windows, a AWS torna privadas as AMIs com mais de quatro meses, o que as torna inacessíveis. Se o grupo de nós gerenciados estiver usando uma AMI Windows privada, considere a possibilidade de atualizar o grupo de nós gerenciados do Windows em Atualizar um grupo de nós gerenciados para seu cluster. Embora não possamos garantir que poderemos fornecer acesso a AMIs que se tornaram privadas, você pode solicitar acesso ao preencher um tíquete no AWS Support. Para obter mais informações, consulte Patches no Guia do Usuário do Amazon EC2.

O nó está no estado NotReady

Se o seu nó entrar em um status de NotReady, isso provavelmente indica que ele não está íntegro e está indisponível para a programação de novos Pods. Isso pode ocorrer por vários motivos, como a falta de recursos suficientes para a CPU, a memória ou o espaço em disco disponível no nó.

Para AMIs do Windows otimizadas para o Amazon EKS, não há reserva para recursos de computação especificados por padrão na configuração kubelet. Para ajudar a evitar problemas de recursos, você pode reservar recursos de computação para processos do sistema, fornecendo ao kubelet valores de configuração para kube-reserved e/ou system-reserved. Você faz isso ao usar o parâmetro de linha de comando -KubeletExtraArgs no script de inicialização. Para obter mais informações, consulte Reserve Compute Resources for System Daemons na documentação Kubernetes e Parâmetros de configuração do script de bootstrap neste guia do usuário.

Ferramenta de coleta de logs da CNI

O Amazon VPC CNI plugin for Kubernetes para tem seu próprio script de solução de problemas que está disponível em nós em /opt/cni/bin/aws-cni-support.sh. Você pode usar o script para coletar logs de diagnóstico para casos de suporte e solução de problemas gerais.

Use o seguinte comando para executar o script em seu nó:

sudo bash /opt/cni/bin/aws-cni-support.sh

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh

O script coleta as seguintes informações de diagnóstico. A versão da CNI que você implantou pode ser anterior à versão do script.

      This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami

Trying to collect common operating system logs...
Trying to collect kernel logs...
Trying to collect mount points and volume information...
Trying to collect SELinux status...
Trying to collect iptables information...
Trying to collect installed packages...
Trying to collect active system services...
Trying to collect Docker daemon information...
Trying to collect kubelet information...
Trying to collect L-IPAMD information...
Trying to collect sysctls information...
Trying to collect networking information...
Trying to collect CNI configuration information...
Trying to collect running Docker containers and gather container data...
Trying to collect Docker daemon logs...
Trying to archive gathered information...

	Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

As informações de diagnóstico são coletadas e armazenadas em:

/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

A rede de runtime do contêiner não está pronta

Você pode receber um erro Container runtime network not ready e erros de autorização semelhantes a:

4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized
4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized

Isso pode acontecer devido a um dos seguintes motivos:

Tempo limite de handshake TLS

Quando um nó não conseguir estabelecer uma conexão com o endpoint do servidor de API público, talvez você veja um erro semelhante ao erro a seguir.

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post  net/http: TLS handshake timeout\""

O processo kubelet gerará e testará continuamente o endpoint do servidor de API. O erro também pode ocorrer temporariamente durante algum procedimento que realize uma atualização contínua do cluster no ambiente de gerenciamento, como uma alteração de configuração ou atualização de versão.

Para resolver o problema, verifique a tabela de rotas e os grupos de segurança para garantir que o tráfego dos nós possa atingir o endpoint público.

InvalidClientTokenId

Se você estiver usando perfis do IAM para contas de serviço de um Pod ou DaemonSet implantado em um cluster em uma região da China AWS e não tiver definido a variável de ambiente AWS_DEFAULT_REGION na especificação, o Pod ou DaemonSet poderá receber o seguinte erro:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid

Para resolver o problema, é necessário adicionar a variável de ambiente AWS_DEFAULT_REGION à especificação do Pod ou DaemonSet, conforme exibido na seguinte especificação do Pod de exemplo:

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: AWS_DEFAULT_REGION
      value: "region-code"

Os grupos de nós devem corresponder à versão do Kubernetes antes da atualização do ambiente de gerenciamento

Antes de atualizar um ambiente de gerenciamento para uma nova versão do Kubernetes, a versão secundária dos nós gerenciados e do Fargate no cluster deve ser a mesma da versão atual do ambiente de gerenciamento. A API update-cluster-version do Amazon EKS rejeita solicitações até que você atualize todos os nós gerenciados do Amazon EKS para a versão atual do cluster. O Amazon EKS fornece APIs para atualizar nós gerenciados. Para obter informações sobre como atualizar a versão do Kubernetes do grupo de nós gerenciado, consulte Atualizar um grupo de nós gerenciados para seu cluster. Para atualizar a versão de um nó do Fargate, exclua o pod representado pelo nó e reimplante o pod depois de atualizar o ambiente de gerenciamento. Para ter mais informações, consulte Atualizar um cluster existente para a nova versão do Kubernetes.

Ao iniciar muitos nós, ocorrem erros Too Many Requests

Se você iniciar muitos nós ao mesmo tempo, poderá ver uma mensagem de erro nos logs de execução de Dados do usuário do Amazon EC2 que indica Too Many Requests. Isso pode ocorrer porque o ambiente de gerenciamento está sendo sobrecarregado por chamadas describeCluster. A sobrecarga resulta em controle de utilização, nós com falha ao executar o script de bootstrap e nós que não são completamente incorporados ao cluster.

Verifique se os argumentos --apiserver-endpoint, --b64-cluster-ca e --dns-cluster-ip estão sendo transmitidos ao script de bootstrap do nó. Ao incluir esses argumentos, não há necessidade de o script bootstrap criar uma chamada describeCluster, o que ajuda a evitar a sobrecarga do ambiente de gerenciamento. Para ter mais informações, consulte Fornecer dados de usuário para passar argumentos para o arquivo bootstrap.sh incluído com uma AMI do Linux/Bottlerocket otimizada para o Amazon EKS.

Resposta de erro HTTP 401 unauthorized (HTTP 401 não autorizado) em solicitações do servidor de API do Kubernetes

Esses erros serão mostrados se um token de conta de serviço de um Pod’s tiver expirado em um cluster.

O servidor de APIs Kubernetes do seu cluster do Amazon EKS rejeita solicitações com tokens com mais de 90 dias. Em versões anteriores do Kubernetes, os tokens não tinham expiração. Isso significa que os clientes que dependem desses tokens precisam atualizá-los em até uma hora. Para evitar que o servidor da API Kubernetes rejeite sua solicitação devido a um token inválido, a versão do SDK do cliente Kubernetes usada por sua workload deve ser a mesma ou posterior às seguintes versões:

É possível identificar todos os Pods existentes no cluster que estão usando tokens obsoletos. Para ter mais informações, consulte Tokens de contas de serviço.

A versão da plataforma Amazon EKS está mais de duas versões atrás da versão atual da plataforma

Isso pode ocorrer quando o Amazon EKS não consegue atualizar automaticamente a versão da plataforma Veja as versões da plataforma Amazon EKS para cada versão do Kubernetesdo seu cluster. Embora existem muitas causas para isso, veja a seguir algumas das causas comuns. Se algum desses problemas se aplicar ao cluster, ele ainda poderá funcionar; apenas a versão da plataforma não será atualizada pelo Amazon EKS.

Problema

O Função do IAM do cluster do Amazon EKSperfil do IAM do cluster foi excluído; essa função foi especificada quando o cluster foi criado. Você pode verificar qual função foi especificada com o comando a seguir. Substitua my-cluster pelo nome do cluster.

aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2

Veja um exemplo de saída abaixo.

eksClusterRole

Solução

Crie um novo Função do IAM do cluster do Amazon EKSperfil do IAM do cluster com o mesmo nome.

Problema

Uma sub-rede especificada durante a criação do cluster foi excluída; as sub-redes a serem usadas com o cluster foram especificadas durante a criação do cluster. Você pode verificar quais sub-redes foram especificadas com o comando a seguir. Substitua my-cluster pelo nome do cluster.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.subnetIds

Veja um exemplo de saída abaixo.

[
"subnet-EXAMPLE1",
"subnet-EXAMPLE2"
]

Solução

Confirme se os IDs de sub-rede existem na conta.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId"

Veja um exemplo de saída abaixo.

[
"subnet-EXAMPLE3",
"subnet-EXAMPLE4"
]

Se os IDs de sub-rede retornados na saída não corresponderem aos IDs de sub-rede especificados quando o cluster foi criado, se você quiser que o Amazon EKS atualize o cluster, será necessário alterar as sub-redes usadas pelo cluster. Isso ocorre porque, se você especificou mais de duas sub-redes ao criar o cluster, o Amazon EKS selecionará aleatoriamente as sub-redes que você especificou para a criação de novas interfaces. Essas interfaces de rede permitem que o ambiente de gerenciamento se comunique com os nós. O Amazon EKS não atualizará o cluster se a sub-rede selecionada não existir. Você não tem controle sobre qual das sub-redes especificadas na criação do cluster o Amazon EKS escolhe para criar uma nova interface de rede.

Quando você inicia uma atualização de versão do Kubernetes para o cluster, a atualização pode falhar pelo mesmo motivo.

Problema

Um grupo de segurança especificado durante a criação do cluster foi excluído. Se você especificou grupo de segurança durante a criação do cluster, poderá ver os IDs com o comando a seguir. Substitua my-cluster pelo nome do cluster.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds

Veja um exemplo de saída abaixo.

[
    "sg-EXAMPLE1"
]

Se [] for retornado, nenhum grupo de segurança foi especificado quando o cluster foi criado e a falta de um grupo de segurança não é o problema. Se grupos de segurança forem retornados, confirme se eles existem na conta.

Solução

Confirme se esses grupos de segurança existem na conta.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId"

Veja um exemplo de saída abaixo.

[
"sg-EXAMPLE2"
]

Se os IDs dos grupos de segurança retornados na saída não corresponderem aos IDs dos grupos de segurança especificados quando o cluster foi criado, se você quiser que o Amazon EKS atualize o cluster, será necessário alterar os grupos de segurança usados pelo cluster. O Amazon EKS não atualizará um cluster se os IDs de grupo de segurança especificados na criação do cluster não existirem.

Quando você inicia uma atualização de versão do Kubernetes para o cluster, a atualização pode falhar pelo mesmo motivo.

Perguntas frequentes sobre a integridade do cluster e códigos de erro com caminhos de resolução

O Amazon EKS detecta problemas com os clusters do EKS e com a infraestrutura do cluster e os armazena na integridade do cluster. Você pode detectar, solucionar problemas e resolver problemas de cluster mais rapidamente com a ajuda das informações de integridade do cluster. Isso permite que você crie ambientes de aplicativos mais seguros e atualizados. Além disso, pode ser impossível atualizar para versões mais recentes do Kubernetes ou instalar atualizações de segurança do Amazon EKS em um cluster degradado como resultado de problemas com a infraestrutura ou a configuração do cluster necessárias. O Amazon EKS pode levar 3 horas para detectar problemas ou detectar que um problema foi resolvido.

A integridade de um cluster do Amazon EKS é uma responsabilidade compartilhada entre o Amazon EKS e seus usuários. Você é responsável pela infraestrutura de pré-requisitos dos perfis do IAM e das sub-redes do Amazon VPC, bem como por outras infraestruturas necessárias, que devem ser fornecidas com antecedência. O Amazon EKS detecta mudanças na configuração dessa infraestrutura e do cluster.

Para acessar a integridade do cluster no console do Amazon EKS, procure uma seção chamada Problemas de integridade na guia Visão geral da página de detalhes do cluster do Amazon EKS. Esses dados também estarão disponíveis chamando a ação DescribeCluster na API do EKS, por exemplo, na interface de linha de comando AWS.

As duas primeiras colunas são o que é necessário para os valores de resposta da API. O terceiro campo do objeto Health ClusterIssue é resourceIds, cujo retorno depende do tipo de problema.