Insufficient capacity (Capacidade insuficiente)Worker nodes fail to join cluster (Falha nos nós ao ingressar no cluster)Acesso negado ou não autorizado (kubectl)hostname doesn't match getsockopt: no route to host Instances failed to join the Kubernetes cluster Códigos de erro para o grupo de nós gerenciados Not authorized for images O nó está no estado NotReady Ferramenta de coleta de logs da CNI A rede de runtime do contêiner não está pronta Tempo limite de handshake TLS InvalidClientTokenId Expiração do certificado webhook de admissão da VPC Os grupos de nós devem corresponder à versão do Kubernetes antes da atualização do ambiente de gerenciamento Ao iniciar muitos nós, ocorrem erros Too Many Requests Erros HTTP 401 - Não autorizado Versão antiga da plataforma Perguntas frequentes sobre a integridade do cluster e códigos de erro com caminhos de resolução

Solução de problemas 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 no 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 no Requisitos e considerações para sub-redes.

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:

Se os nós forem nós gerenciados, o Amazon EKS adiciona entradas ao ConfigMap aws-auth quando você cria o grupo de nós. Se a entrada tiver sido removida ou modificada, você precisará adicioná-la novamente. Para obter mais informações, insira eksctl create iamidentitymapping --help no seu terminal. É possível verificar a versão atual das entradas do ConfigMap aws-auth ao substituir my-cluster no comando a seguir pelo nome do seu cluster e, depois, executar o comando modificado: eksctl get iamidentitymapping --cluster my-cluster. O ARN da função que você especifica não pode incluir um caminho diferente de /. Por exemplo, se o nome da sua função for development/apps/my-role, você precisará alterá-lo para my-role ao especificar o ARN da função. Verifique se o ARN do perfil do IAM do nó (não o ARN do perfil de instância) está especificado.

Se os nós forem autogerenciados e você não tiver criado entradas de acesso para o ARN do perfil do IAM do nó, execute os mesmos comandos listados para os nós gerenciados. Se você criou uma entrada de acesso para o ARN do perfil do IAM do nó, talvez ela não esteja configurada corretamente na entrada de acesso. Verifique se o ARN do perfil do IAM do nó (não o ARN do perfil de instância) está especificado como o ARN principal na entrada ConfigMap aws-auth ou na entrada de acesso. Para obter mais informações sobre as entradas de acesso, consulte Permitir que perfis ou usuários do IAM acessem objetos do Kubernetes em seu cluster do Amazon EKS.
O ClusterName no modelo do AWS CloudFormation do seu nó não corresponde exatamente ao nome do cluster no qual você deseja que seus nós ingressem. O fornecimento de um valor incorreto a esse campo resulta em uma configuração incorreta do arquivo /var/lib/kubelet/kubeconfig do nó, e os nós não ingressarão no cluster.

O nó não é marcado como sendo de propriedade do cluster. Os nós devem ter a seguinte etiqueta aplicada a eles, onde my-cluster é substituída pelo nome do cluster.

Chave	Valor
`kubernetes.io/cluster/my-cluster`	`owned`

Talvez não seja possível que os nós acessem o cluster usando um endereço IP público. Verifique se os nós implantados em sub-redes públicas recebem um endereço IP público. Caso contrário, é possível associar um endereço IP elástico a um nó depois que ele for executado. Para obter mais informações, consulte Associating an Elastic IP address with a running instance or network interface (Associar um endereço IP elástico a uma instância em execução ou interface de rede). Se a sub-rede pública não estiver definida para atribuir automaticamente endereços IP públicos a instâncias implantadas nela, recomendamos ativar essa configuração. Para obter mais informações, consulte Modificar o atributo de endereçamento IPv4 público para a sua sub-rede. Se o nó for implantado em uma sub-rede privada, a sub-rede deverá ter uma rota para um gateway NAT que tenha um endereço IP público atribuído a ele.
O endpoint do AWS STS para a Região da AWS na qual você está implantando os nós não está habilitado para sua conta. Para habilitar a região, consulte Ativação e desativação do AWS STS em uma Região da AWS.
O nó não tem uma entrada DNS privada, resultando no erro node "" not found no log do kubelet. Verifique se a VPC na qual o nó foi criado tem valores definidos para domain-name e domain-name-servers como Options em um DHCP options set. Os valores padrão são domain-name:<region>.compute.internal e domain-name-servers:AmazonProvidedDNS. Para obter mais informações, consulte Conjuntos de opções DHCP no Guia do usuário da Amazon VPC.
Se os nós do grupo de nós gerenciados não se conectarem ao cluster em 15 minutos, um problema de integridade “NoDecreationFailure” será emitido e o status do console será definido como Create failed. Para AMIs do Windows com tempos de lançamento lentos, esse problema pode ser resolvido usando o lançamento rápido.

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 no Referência de runbook do 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.

could not get token: AccessDenied: Access denied
error: You must be logged in to the server (Unauthorized)
error: the server doesn't have a resource type "svc"

Isso pode ocorrer devido a um dos seguintes motivos:

O cluster foi criado com credenciais para uma entidade principal do IAM e o kubectl está configurado para usar credenciais para uma entidade principal do IAM diferente. Para resolver essa situação, atualize seu arquivo kube config para usar as credenciais que criaram o cluster. Para ter mais informações, consulte Criar ou atualizar um arquivo kubeconfig para um cluster do Amazon EKS.
Se o seu cluster atender aos requisitos mínimos de plataforma na seção de pré-requisitos de Permitir que perfis ou usuários do IAM acessem objetos do Kubernetes em seu cluster do Amazon EKS, não existirá uma entrada de acesso com a entidade principal do IAM. Se ela existir, ela não terá os nomes de grupo do Kubernetes necessários definidos para ela ou não terá a política de acesso adequada associada a ela. Para ter mais informações, consulte Permitir que perfis ou usuários do IAM acessem objetos do Kubernetes em seu cluster do Amazon EKS.
Se seu cluster não atender aos requisitos mínimos da plataforma em Permitir que perfis ou usuários do IAM acessem objetos do Kubernetes em seu cluster do Amazon EKS, não existirá uma entrada com a entidade principal do IAM no ConfigMap aws-auth. Se existir, ela não será mapeada para nomes de grupos do Kubernetes vinculados a Role ou ClusterRole do Kubernetes com as permissões necessárias. Para obter mais informações sobre os objetos de autorização baseada em função (RBAC) do Kubernetes, consulte Using RBAC authorization na documentação do Kubernetes. É possível verificar a versão atual das entradas do ConfigMap aws-auth ao substituir my-cluster no comando a seguir pelo nome do seu cluster e, depois, executar o comando modificado: eksctl get iamidentitymapping --cluster my-cluster. Se uma entrada com o ARN da entidade principal do IAM não estiver no ConfigMap, insira eksctl create iamidentitymapping --help no seu terminal para saber como criar uma.

Se você instalar e configurar a AWS CLI, poderá configurar as credenciais do IAM usadas. Para obter mais informações, consulte Configuração da 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 Criar ou atualizar um arquivo kubeconfig para um cluster do Amazon EKS.

`hostname doesn't match`

Seu sistema precisa ter a versão 2.7.9 ou superior do Python. Caso contrário, você receberá erros de hostname doesn't match com chamadas do 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 Controle de acesso ao endpoint do cluster do Amazon EKS.

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.

AccessDenied

O Amazon EKS ou um ou mais nós gerenciados não conseguem autenticar nem autorizar com o servidor de API do cluster do Kubernetes. Para obter mais informações sobre como resolver uma causa comum, consulte Como corrigir uma causa comum de erros AccessDenied para grupos de nós gerenciados. As AMIs privadas do Windows também podem causar esse código de erro juntamente com a mensagem de erro Not authorized for images. Para ter mais informações, consulte Not authorized for images.

AmiIdNotFound

Não foi possível encontrar o ID da AMI associada ao seu modelo de inicialização. Certifique-se de que a AMI existe e é compartilhada com sua conta.

AutoScalingGroupNotFound

Não foi possível encontrar o grupo do Auto Scaling associado ao grupo de nós gerenciados. Você pode recriar um grupo do Auto Scaling com as mesmas configurações para fazer a recuperação.

ClusterUnreachable

O Amazon EKS ou um ou mais nós gerenciados não conseguem se comunicar com o servidor de API do cluster do Kubernetes. Isso pode acontecer se houver interrupções na rede ou se os servidores de API estiverem expandindo solicitações de processamento.

Ec2SecurityGroupNotFound

Não foi possível localizar o grupo de segurança do cluster. Você deve recriar seu cluster.

Ec2SecurityGroupDeletionFailure

Não foi possível excluir o grupo de segurança de acesso remoto para o grupo de nós gerenciados. Remova quaisquer dependências do grupo de segurança.

Ec2LaunchTemplateNotFound

Não foi possível encontrar o modelo de inicialização do Amazon EC2 para o grupo de nós gerenciados. Você deve recriar seu grupo de nós para a recuperação.

Ec2LaunchTemplateVersionMismatch

A versão do modelo de inicialização do Amazon EC2 para o grupo de nós gerenciados não corresponde à versão que o Amazon EKS criou. Você pode reverter para a versão criada pelo Amazon EKS para fazer a recuperação.

IamInstanceProfileNotFound

Não foi possível encontrar o perfil de instância do IAM para o grupo de nós gerenciados. Você pode recriar um perfil de instância com as mesmas configurações para fazer a recuperação.

IamNodeRoleNotFound

Não foi possível encontrar o perfil do IAM para o grupo de nós gerenciados. Você pode recriar uma função do IAM com as mesmas configurações para fazer a recuperação.

AsgInstanceLaunchFailures

O grupo do Auto Scaling está sofrendo falhas ao tentar iniciar instâncias.

NodeCreationFailure

As instâncias iniciadas não conseguem se registrar no cluster do Amazon EKS. Causas comuns dessa falha são permissões insuficientes da função do IAM do nó ou a falta de acesso à Internet na saída para os nós. Seus nós devem atender a qualquer um dos seguintes requisitos:

Capacidade de acessar a Internet utilizando um endereço IP público. O grupo de segurança associado à sub-rede em que o nó se encontra deve permitir a comunicação. Para obter mais informações, consulte Requisitos e considerações para sub-redes e Considerações e requisitos sobre grupos de segurança do Amazon EKS.
Os nós e a VPC devem atender aos requisitos em Requisitos de clusters privados.

InstanceLimitExceeded

Sua conta da AWS não pode iniciar mais nenhuma instância do tipo especificado. Você pode solicitar um aumento do limite de instâncias do Amazon EC2 para fazer a recuperação.

InsufficientFreeAddresses

Uma ou mais sub-redes associadas ao grupo de nós gerenciados não têm endereços IP disponíveis suficientes para novos nós.

InternalFailure

Esses erros geralmente são causados por um problema no servidor do Amazon EKS.

A causa mais comum de erros AccessDenied ao executar operações em grupos de nós gerenciados, é a ausência de eks:node-manager, ClusterRole ou ClusterRoleBinding. O Amazon EKS configura esses recursos no cluster como parte da integração com grupos de nós gerenciados, e eles são necessários para gerenciar os grupos de nós.

O ClusterRole pode mudar ao longo do tempo, mas deve ser semelhante ao seguinte exemplo:


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

O ClusterRoleBinding pode mudar ao longo do tempo, mas deve ser semelhante ao seguinte exemplo:


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

Verifique se o eks:node-manager ClusterRole existe.


kubectl describe clusterrole eks:node-manager

Se estiver presente, compare a saída com ao exemplo de ClusterRole anterior.

Verifique se o eks:node-manager ClusterRoleBinding existe.


kubectl describe clusterrolebinding eks:node-manager

Se estiver presente, compare a saída com ao exemplo de ClusterRoleBinding anterior.

Se você identificou a ausência de ClusterRole ou ClusterRoleBinding como a causa de um erro AcessDenied ao solicitar operações de grupo de nó gerenciado, você pode restaurá-los. Salve o conteúdo a seguir em um arquivo denominado eks-node-manager-role.yaml.


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

Aplique o arquivo.


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

Tente novamente a operação do grupo de nós para ver se isso resolveu o problema.

`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 seu grupo de nós gerenciados estiver usando uma AMI do Windows privada, considere atualizar o grupo de nós gerenciados do Windows. 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, atualizações de segurança e IDs de AMI no Guia do usuário do Amazon EC2 para instâncias do Windows.

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, é possível reservar recursos de computação para processos do sistema, fornecendo ao kubelet valores de configuração para kube-reserved 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 do Kubernetes e Bootstrap script configuration parameters neste guia do usuário.

Ferramenta de coleta de logs da CNI

O Amazon VPC CNI plugin for para Kubernetes 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

nota

Se o script não está presente no local, ocorreu uma falha na execução do contêiner do CNI. Você pode baixar e executar o script manualmente com o seguinte comando:


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:

Ou você não tem um ConfigMap aws-auth em seu cluster ou ele não inclui entradas para o perfil do IAM com o qual você configurou seus nós.

A entrada ConfigMap será necessária se os nós atenderem a um dos seguintes critérios:
- Nós gerenciados em um cluster com qualquer versão do Kubernetes ou da plataforma.
- Nós autogerenciados em um cluster anterior a uma das versões da plataforma listadas na seção de pré-requisitos do tópico Permitir que perfis ou usuários do IAM acessem objetos do Kubernetes em seu cluster do Amazon EKS.
Para resolver o problema, verifique as entradas existentes no ConfigMap ao substituir my-cluster no comando a seguir pelo nome do cluster e execute o comando modificado: eksctl get iamidentitymapping --cluster my-cluster. Se você receber uma mensagem de erro do comando, talvez seja porque seu cluster não tem um ConfigMap aws-auth. O comando a seguir adiciona uma entrada ao ConfigMap. Se o ConfigMap não existir, ele também será criado pelo comando. Substitua 111122223333 pelo ID da Conta da AWS do perfil do IAM e myAmazonEKSNodeRole pelo nome da função do seu nó.
```
eksctl create iamidentitymapping --cluster my-cluster \
    --arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --group system:bootstrappers,system:nodes \
    --username system:node:{{EC2PrivateDNSName}}
```
O ARN da função que você especifica não pode incluir um caminho diferente de /. Por exemplo, se o nome da sua função for development/apps/my-role, você precisará alterá-lo para my-role ao especificar o ARN da função. Verifique se o ARN do perfil do IAM do nó (não o ARN do perfil de instância) está especificado.
Seus nós autogerenciados estão em um cluster com uma versão da plataforma na versão mínima listada nos pré-requisitos do tópico Permitir que perfis ou usuários do IAM acessem objetos do Kubernetes em seu cluster do Amazon EKS, mas uma entrada não está listada no ConfigMap aws-auth (consulte o item anterior) para o perfil do IAM do nó ou não existe uma entrada de acesso para a função. Para resolver o problema, visualize as entradas de acesso existentes ao substituir my-cluster no comando a seguir pelo nome do cluster e execute o comando modificado: aws eks list-access-entries --cluster-name my-cluster. O comando a seguir adiciona uma entrada de acesso para o perfil do IAM do nó. Substitua 111122223333 pelo ID da Conta da AWS do perfil do IAM e myAmazonEKSNodeRole pelo nome da função do seu nó. Se você tiver um nó do Windows, substitua EC2_Linux por EC2_Windows. Verifique se o ARN do perfil do IAM do nó (não o ARN do perfil de instância) está especificado.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --type EC2_Linux
```

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 plano de controle, 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 estiver usando perfis do IAM para contas de serviço para um Pod ou DaemonSet implantado em um cluster em uma Região da AWS da China e ainda 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"

Expiração do certificado webhook de admissão da VPC

Se o certificado usado para assinar o webhook de admissão da VPC expirar, o status das novas implantações do Pod do Windows permanecerá em ContainerCreating.

Para resolver o problema, se você tiver suporte ao Windows herdado em plano de dados, consulte Renovar o certificado webhook de admissão da VPC. Se a versão do cluster e da plataforma forem posteriores às versões listadas em Pré-requisitos de suporte do Windows, recomendamos remover o suporte ao Windows herdado do plano de dados e habilitá-lo no ambiente de gerenciamento. Ao fazer isso, você não precisará gerenciar o certificado webhook. Para ter mais informações, consulte Habilitar o suporte ao Windows para o cluster do Amazon EKS.

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 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 uma versão do Kubernetes do cluster do Amazon EKS.

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 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 de API do Kubernetes rejeite a solicitação devido a um token inválido, a versão do SDK de cliente do Kubernetes utilizada pela workload deve ser igual ou posterior às seguintes:

Versão do Go 0.15.7 e posteriores
Versão do Python 12.0.0 e posteriores
Versão Java 9.0.0 e posterior
Versão JavaScript 0.10.3 e posterior
Ramificação Ruby master
Versão do Haskell 0.3.0.0
Versão do C# 7.0.5 ou posterior.

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

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

Isso pode acontecer quando o Amazon EKS não consegue atualizar automaticamente versão da plataforma do 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 perfil 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 perfil 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.

Outros motivos pelos quais o Amazon EKS não atualiza a versão da plataforma do cluster

Você não tem pelo menos seis (embora recomendemos 16) endereços IP disponíveis em cada uma das sub-redes especificadas ao criar o cluster. Se não tiver endereços IP disponíveis suficientes na sub-rede, você precisará liberar endereços IP na sub-rede ou alterar as sub-redes usadas pelo cluster para usar sub-redes com endereços IP disponíveis suficientes.
Você habilitou a criptografia de segredos quando você criou o cluster e a chave do AWS KMSque você especificou foi excluída. Se você quiser que o Amazon EKS atualize o cluster, precisará criar um novo cluster

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 ao chamar a ação DescribeCluster na API do EKS, por exemplo, de dentro do AWS Command Line Interface.

Por que devo usar esse recurso?: Você terá maior visibilidade da integridade do cluster do Amazon EKS, diagnosticará e corrigirá rapidamente quaisquer problemas, sem precisar perder tempo depurando ou abrindo casos de suporte da AWS. Por exemplo: você excluiu acidentalmente uma sub-rede do cluster do Amazon EKS; o Amazon EKS não poderá criar interfaces de rede entre contas e os comandos da AWS CLI do Kubernetes, como exec do kubectl ou logs dokubectl. Eles falharão com o erro: Error from server: error dialing backend: remote error: tls: internal error. Agora você verá um problema de integridade do Amazon EKS que diz: subnet-da60e280 was deleted: could not create network interface.
Como este recurso se relaciona ou funciona com outros serviços da AWS?: Os perfis do IAM e as sub-redes do Amazon VPC são dois exemplos de infraestrutura de pré-requisito com a qual a integridade do cluster detecta problemas. O recurso retornará informações detalhadas se esses recursos não estiverem configurados corretamente.
Um cluster com problemas de integridade gera custos?: Sim, cada cluster do Amazon EKS é cobrado de acordo com o preço padrão do Amazon EKS. O recurso de integridade do cluster está disponível sem custo adicional.
Esse recurso funciona com clusters do Amazon EKS no AWS Outposts?: Sim, problemas de cluster são detectados em clusters do EKS na Nuvem AWS, incluindo clusters estendidos no AWS Outposts e clusters locais no AWS Outposts. A integridade do cluster não detecta problemas com o Amazon EKS Anywhere ou o Amazon EKS Distro (EKS-D).
Posso ser notificado quando novos problemas forem detectados?: Não, você precisa verificar o console do Amazon EKS ou chamar a API DescribeCluster do EKS.
O console me avisa sobre problemas de integridade?: Sim, qualquer cluster com problemas de integridade incluirá um banner na parte superior do console.

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.

Código	Message	ResourceIds	Cluster recuperável?
SUBNET_NOT_FOUND	Não foi possível encontrar uma ou mais sub-redes que estão atualmente associadas ao seu cluster. Chame a API update-cluster-config do Amazon EKS para atualizar sub-redes.	IDs de sub-rede	Sim
SECURITY_GROUP_NOT_FOUND	Não foi possível encontrar um ou mais grupos de segurança que estão atualmente associados ao seu cluster. Chame a API update-cluster-config do Amazon EKS para atualizar grupos de segurança	IDs de grupos de segurança	Sim
IP_NOT_AVAILABLE	Uma ou mais sub-redes associadas ao seu cluster não têm endereços IP disponíveis suficientes para o Amazon EKS realizar operações de gerenciamento de cluster. Libere endereços na(s) sub-rede(s) ou associe diferentes sub-redes ao seu cluster usando a API update-cluster-config do Amazon EKS.	IDs de sub-rede	Sim
VPC_NOT_FOUND	Não foi possível encontrar a VPC associada ao seu cluster. Você deve excluir e recriar seu cluster.	ID da VPC	Não
ASSUME_ROLE_ACCESS_DENIED	Seu cluster não está usando a função vinculada ao serviço do Amazon EKS. Não foi possível assumir a função associada ao seu cluster para realizar as operações de gerenciamento necessárias do Amazon EKS. Verifique se a função existe e tem a política de confiança necessária.	O perfil do IAM do cluster	Sim
PERMISSION_ACCESS_DENIED	Seu cluster não está usando a função vinculada ao serviço do Amazon EKS. A função associada ao seu cluster não concede permissões suficientes para que o Amazon EKS execute as operações de gerenciamento necessárias. Verifique as políticas anexadas à função de cluster e se alguma política de negação separada foi aplicada.	O perfil do IAM do cluster	Sim
ASSUME_ROLE_ACCESS_DENIED_USING_SLR	Não foi possível assumir a função vinculada ao serviço de gerenciamento de clusters do Amazon EKS. Verifique se a função existe e tem a política de confiança necessária.	A função vinculada ao serviço do Amazon EKS	Sim
PERMISSION_ACCESS_DENIED_USING_SLR	A função vinculada ao serviço de gerenciamento de clusters do Amazon EKS não concede permissões suficientes para que o Amazon EKS execute as operações de gerenciamento necessárias. Verifique as políticas anexadas à função de cluster e se alguma política de negação separada foi aplicada.	A função vinculada ao serviço do Amazon EKS	Sim
OPT_IN_REQUIRED	Sua conta não tem uma assinatura de serviço do Amazon EC2. Atualize as assinaturas da sua conta na página de configurações da conta.	N/D	Sim
STS_REGIONAL_ENDPOINT_DISABLED	O endpoint regional do STS está desativado. Habilite o endpoint do Amazon EKS para realizar as operações de gerenciamento de cluster necessárias.	N/D	Sim
KMS_KEY_DISABLED	A chave do AWS KMS associada ao seu cluster está desativada. Habilite novamente a chave para recuperar o cluster.	A KMS Key Arn	Sim
KMS_KEY_NOT_FOUND	Não foi possível encontrar a chave do AWS KMS associada ao seu cluster. Você precisa excluir e recriar o cluster.	A KMS Key ARN	Não
KMS_GRANT_REVOKED	As concessões para a chave do AWS KMS associada ao seu cluster foram revogadas. Você precisa excluir e recriar o cluster.	A KMS Key Arn	Não

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Amazon Detective

Amazon EKS Connector