Por que não consigo executar comandos kubectl no Amazon EKS?

Breve descrição

Ao tentar executar os comandos kubectl, você pode encontrar os seguintes problemas:

• Não é possível executar kubectl exec, kubectl logs, kubectl attach ou kubectl port-forward.
• kubectl não consegue alcançar o ambiente de gerenciamento.
• Não é possível instalar o kubectl.
• Você encontra erros de autorização.

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.

Não é possível executar kubectl exec, kubectl logs, kubectl attach ou kubectl port-forward

Para executar os comandos kubectl exec, kubectl logs, kubectl attach ou kubectl port-forward, a API do Amazon EKS deve estabelecer uma conexão confiável com o kubelet. Se a autenticação falhar, você receberá um erro semelhante ao exemplo a seguir:

“Error from server: error dialing backend: remote error: tls: internal error”

Verificar se há problemas de conectividade de rede

Certifique-se de que o servidor da API possa se comunicar com o nó de trabalho na porta 1025. O grupo de segurança do nó de processamento deve permitir tráfego de entrada do grupo de segurança do cluster na porta 10250. O grupo de segurança do cluster deve permitir o tráfego de entrada do grupo de segurança do nó de processamento na porta 443. Certifique-se de que seus grupos de segurança cumpram os requisitos do Amazon EKS.

Verifique se há problemas de CSR

Se o painel de controle não aprovar a solicitação de assinatura de certificado (CSR) enviada pelo kubelet, o kubelet não poderá ser executado.

Para identificar a CSR com problemas, execute o seguinte comando:

kubectl get certificatesigningrequest

Para verificar o status da solicitação de CSR, execute o seguinte comando:

kubectl describe certificatesigningrequest csr-name -n namespace

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

Na saída, verifique se há CSRs no estado Pending ou Approved em vez de Approved, Issued.

Você deve ativar os sinalizadores RotateKubeletServerCertificate e ServerTLSBootstrap no kubelet para que o kubelet envie e gire o certificado de serviço por si mesmo. Para verificar se os sinalizadores no arquivo JSON kubelet-config estão definidos como verdadeiros, execute o seguinte comando no nó de processamento:

cat /etc/kubernetes/kubelet/kubelet-config.json

Exemplo de saída:

"serverTLSBootstrap": true
"featureGates": {
    "RotateKubeletServerCertificate": true
    }

Para que o kubelet crie e envie a CSR, você deve anexar o perfil eks:node-bootstrapper aos grupos system:bootstrappers e system:nodes. Para verificar se ClusterRole e ClusterRoleBinding têm o perfil eks:node:boostrapper, execute os seguintes comandos:

kubectl describe clusterrole eks:node-bootstrapper
kubectl describe clusterrolebinding eks:node-bootstrapper

Exemplo de saída:

kubectl describe clusterrole eks:node-bootstrapper
 Name: eks:node-bootstrapper
 Labels: eks.amazonaws.com/component=node
 Annotations: <none>
 PolicyRule:
 Resources Non-Resource URLs Resource Names Verbs
 --------- ----------------- -------------- -----
 certificatesigningrequests.certificates.k8s.io/selfnodeserver [] [] [create]

$ kubectl describe clusterrolebinding eks:node-bootstrapper
 Name: eks:node-bootstrapper
 Labels: eks.amazonaws.com/component=node
 Annotations: <none>
 Role:
 Kind: ClusterRole
 Name: eks:node-bootstrapper
 Subjects:
 Kind Name Namespace
 ---- ---- ---------
 Group system:bootstrappers
 Group system:nodes

Se o perfil eks:node-bootstrapper estiver ausente, crie um arquivo YAML com a seguinte configuração:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-bootstrapper
  labels:
    eks.amazonaws.com/component: node
rules:
  - apiGroups: ["certificates.k8s.io"]
    resources: ["certificatesigningrequests/selfnodeserver"]
    verbs: ["create"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-bootstrapper
  labels:
    eks.amazonaws.com/component: node
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-bootstrapper
subjects:
  - kind: Group
    name: system:bootstrappers
  - kind: Group
    name: system:nodes

Em seguida, execute o seguinte comando para atualizar o cluster Amazon EKS:

 kubectl apply -f file-name command

Observação: substitua o nome do arquivo pelo nome do arquivo YAML.

Se você usar o método de autenticação ConfigMap, também deverá anexar o perfil de instância que você configurou no arquivo aws-auth aos grupos system:bootstrappers e system:nodes. Adicione o perfil de instância ao aws-auth no seguinte formato:

kubectl get cm aws-auth -n kube-system -o yaml
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::12345678912:role/kubectl-cluster-nodegroup-custo-NodeInstanceRole-1KFZHWE6FCBDS
      username: system:node:{{EC2PrivateDNSName}}

Observação: se você configurou a API do Amazon EKS como o modo de autenticação de cluster, verifique sua configuração. Certifique-se de que o perfil do nó de processamento do AWS Identity and Access Management (AWS IAM) seja mapeado para o nome de usuário system:node:{{EC2PrivateDNSName}}. Essa configuração garante que o Amazon EKS reconheça o solicitante de CSR e aprove automaticamente a CSR. O Amazon EKS só aprova automaticamente os CSRs do system:node:{{EC2PrivateDNSName}}.

Para verificar os detalhes do solicitante, execute o seguinte comando:

kubectl describe csr csr-name

Observação: substitua csr-name pelo seu nome CSR.

Exemplo de saída:

Name:               csr-tpb4m
Labels:             <none>
Annotations:        <none>
CreationTimestamp:  Tue, 12 Dec 2023 11:18:30 +0530
Requesting User:    system:node:ip-000-00-00-000.ec2.internal
Signer:             kubernetes.io/kubelet-serving
Status:             Approved,Issued
Subject:
  Common Name:    system:node:ip-172-31-73-240.ec2.internal
  Serial Number:  
  Organization:   system:nodes
Subject Alternative Names:
         DNS Names:     ip-172-31-73-240.ec2.internal
         IP Addresses:  172.31.73.240
Events:  <none>

Certifique-se de que o solicitante de CSR esteja no formato system:node:ip-abc-xx-x-xabc.ec2.internal. Se você usar o mesmo perfil do IAM que criou o cluster para os nós de processamento, o solicitante poderá ser kubernetes-admin em vez de system:node:EC2PrivateDNSName. O Amazon EKS rejeita solicitações que não são de system:node:EC2PrivateDNSName. Se você mapeou o perfil do nó de processamento para um nome de usuário personalizado no aws-auth, certifique-se de mapear corretamente o perfil do nó de processamento para system:node:EC2PrivateDNSName.

Verifique os logs do kubelet

Para verificar o status do kubelet, execute o seguinte comando:

systemctl status kubelet

Se a saída mostrar que o status do kubelet é Stopped, execute o seguinte comando para reiniciar o kubelet:

sudo systemctl restart kubelet

Para verificar a palavra-chave cert nos logs do kubelet, execute o seguinte comando:

 journalctl -u kubelet | grep cert

Exemplo de erro:

kubelet[8070]: I1021 18:49:21.594143 8070 log.go:184] http: TLS handshake error from 192.168.130.116:38710: no serving certificate available for the kubelet

Se você não encontrar erros cet na saída do comando, poderá enviar uma nova CSR. Para logs mais detalhados, use a sinalização --v=4. Para coletar logs do nó de processamento para análise detalhada, use o log-collector-script no site do GitHub.

Verifique os logs do ambiente de gerenciamento

Pré-requisito: Permita que o cluster Amazon EKS envie logs do ambiente de gerenciamento para o Amazon CloudWatch Logs Insights.

Para obter mais informações sobre os problemas de CSR, execute o seguinte comando para usar o CloudWatch Logs Insights para verificar os logs do ambiente de gerenciamento:

fields @timestamp, @message, @logStream, @log
| filter message like 'csr-name'
| sort @timestamp desc
| limit 10000

Observação: substitua csr-name pelo nome da CSR que apresenta problemas.

Kubectl não consegue alcançar o ambiente de gerenciamento

Verifique o acesso ao endpoint do Amazon EKS

Se você ativou o acesso privado para o endpoint do servidor da API Kubernetes do seu cluster, só poderá acessar o servidor de API das seguintes fontes:

• Sua rede privada virtual (VPC)
• Uma rede conectada

Se você executar o kubectl a partir de um cliente que não faz parte da VPC ou em uma rede conectada, não conseguirá acessar o servidor de API do cluster. Você recebe um erro semelhante ao seguinte:

“E1009 12:33:44.852680 106 memcache.go:265] couldn't get current server API group list: Get “APISERVERENDPOINT”: dial tcp 11.11.111.111:443: i/o timeout”

Para resolver esse problema, altere o acesso ao endpoint do cluster para Acesso público. Se você precisar ter um cluster privado, crie um bastion host do Amazon Elastic Compute Cloud (Amazon EC2) na VPC do cluster. Em seguida, use o bastion host para acessar o cluster. Você deve adicionar o grupo de segurança do bastion host ao grupo de segurança do cluster.

Verifique as configurações do seu host e da porta

Se você receber a mensagem de erro The connection to the server localhost:8080 was refused, verifique as configurações do host e da porta. O erro normalmente ocorre quando o kubectl não consegue encontrar as informações corretas de porta e host do endpoint do servidor da API do Amazon EKS no arquivo kubeconfig.

Para solucionar esse problema, conclua as etapas a seguir:

1. Para atualizar o arquivo kubeconfig, execute o seguinte comando update-kubeconfig da AWS CLI:

   aws eks update-kubeconfig --region region-code --name my-cluster

   Observação: substitua o código da região pela sua região da AWS e my-cluster pelo nome do seu cluster.

2. Para visualizar seu contexto atual, execute o seguinte comando:

   kubectl config current-context

3. Para verificar o usuário ou perfil do IAM que você configurou em seu ambiente, execute o comando get-caller-identity:

   aws sts get-caller-identity

Para solucionar problemas do IAM, consulte Como conceder acesso ao cluster a outros usuários e perfis do IAM após a criação de um cluster no Amazon EKS?

Verifique as regras do grupo de segurança do ambiente de gerenciamento e do nó de processamento

Se as regras do ambiente de gerenciamento e do grupo de segurança do nó bloquearem o acesso ao servidor da API, você receberá o seguinte erro:

“The connection to the server APISERVERENDPOINT was refused - did you specify the right host or port?“

Para resolver esse problema, certifique-se de que o ambiente de gerenciamento e os grupos de segurança do nó tenham as regras de entrada e saída necessárias. O grupo de segurança do servidor de API deve permitir acesso de entrada do cliente do servidor de API na porta 443.

Não é possível instalar o kubectl

Você deve usar uma versão do kubectl que possua uma versão secundária diferente do seu cluster. Por exemplo, um cliente v1.31 pode se comunicar com as versões v1.30, v1.31 e v1.32 do ambiente de gerenciamento. Para evitar problemas, instale a versão compatível mais recente do kubectl.

Ao instalar o kubectl, você pode receber um dos seguintes erros:

“error: exec plugin: invalid apiVersion “client.authentication.k8s.io/v1alpha1”

-ou-

“Unable to connect to the server: getting credentials: decoding stdout: no kind "ExecCredential" is registered for version "client.authentication.k8s.io/v1alpha1" in scheme "pkg/client/auth/exec/exec.go:62””

Os erros anteriores normalmente ocorrem quando você usa uma versão anterior do AWS CLI para executar o comando update-kubeconfig. Para resolver esse problema, atualize a AWS CLI. Para obter mais informações, consulte Descontinuar a versão v1alpha1 da API do cliente Kubernetes no site do GitHub.

Você encontra erros de autorização ao executar comandos kubectl

Você pode encontrar o seguinte erro ao executar os comandos kubectl:

“error: You must be logged in to the server (Unauthorized)”

Para resolver esse problema, consulte Como resolver o erro “You must be logged in to the server (Unauthorized)” quando me conecto ao servidor de APIs do Amazon EKS?