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

Resolução

Normalmente, os comandos kubectl falham no cluster do Amazon EKS porque o servidor de API não está se comunicando com o kubelet que é executado nos nós de processamento. Os comandos comuns do kubectl incluem kubectl exec, kubectl logs, kubectl attach e kubectl port-forward.

Para solucionar esse problema, certifique-se do seguinte:

• Os pods são executados em um intervalo secundário de encaminhamento entre domínios sem classificação (CIDR).
• Os grupos de segurança usados para o ambiente de gerenciamento e para o nó usam as práticas recomendadas para as regras de entrada e saída.
• Se o ConfigMap aws-auth tem o perfil correto do AWS Identity and Access Management (IAM) com o nome de usuário do Kubernetes que está associado ao nó.
• O requisito de enviar um novo certificado foi atendido.

Os pods estão sendo executados em um intervalo secundário de encaminhamento entre domínios sem classificação (CIDR)

Imediatamente após a criação de um cluster, o Amazon EKS não consegue se comunicar com nós iniciados em sub-redes a partir de blocos CIDR adicionados a uma nuvem privada virtual (VPC). Um intervalo atualizado devido à adição de blocos CIDR a um cluster existente pode demorar até cinco horas para ser reconhecido pelo Amazon EKS. Para obter mais informações, consulte Requisitos e considerações sobre a VPC e a sub-rede do Amazon EKS.

Se os pods estiverem em execução no intervalo secundário de CIDR, faça o seguinte:

• Aguarde até cinco horas para que esses comandos comecem a funcionar.
• Certifique-se de que você tenha pelo menos cinco endereços IP livres em cada sub-rede para concluir a automação com sucesso.

Use o exemplo de política a seguir para visualizar os endereços IP livres para todas as sub-redes em qualquer VPC:

[ec2-user@ip-172-31-51-214 ~]$ aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-078af71a874f2f068" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'
"subnet-0d89886ca3fb30074=8186"
"subnet-0ee46aa228bdc9a74=8187"
"subnet-0a0186a277b8b6a51=8186"
"subnet-0d1fb1de0732b5766=8187"
"subnet-077eff87a4e25316d=8187"
"subnet-0f01c02b04708f638=8186"

Os grupos de segurança usados para o ambiente de gerenciamento e o nó têm as regras de entrada e saída mínimas necessárias

Quando está sendo executado em nós de processamento, um servidor de API deve ter as regras de entrada e saída mínimas necessárias para fazer uma chamada de API para o kublet.. Para verificar se o ambiente de gerenciamento e os grupos de segurança do nó têm as regras de entrada e saída mínimas necessárias, consulte Considerações e requisitos sobre grupos de segurança do Amazon EKS.

O ConfigMap aws-auth tem o perfil correto do IAM com o nome de usuário do Kubernetes que está associado ao nó

Você deve aplicar o perfil correto do IAM ao ConfigMap aws-auth. Certifique-se de que o perfil do IAM tenha o nome de usuário do Kubernetes que está associado ao nó. Para aplicar o ConfigMap aws-auth ao cluster, consulte Adicionar usuários ou perfis do IAM ao cluster Amazon EKS.

O requisito de enviar um novo certificado foi atendido

Os clusters do Amazon EKS exigem que o kubelet do nó envie e alterne o certificado de serviço para ele próprio. Quando um certificado de serviço não está disponível, ocorre um erro de certificado.

1.    Execute o comando a seguir para validar o certificado do servidor do kubelet:

cd /var/lib/kubelet/pki/# use openssl command to validate kubelet server cert 
sudo openssl x509 -text -noout -in kubelet-server-current.pem

A saída é semelhante a esta:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1e:f1:84:62:a3:39:32:c7:30:04:b5:cf:b0:91:6e:c7:bd:5d:69:fb
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Oct 11 19:03:00 2021 GMT
            Not After : Oct 11 19:03:00 2022 GMT
        Subject: O=system:nodes, CN=system:node:ip-192-168-65-123.us-east-2.compute.internal
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:7f:44:c6:95:7e:0f:1e:f8:f8:bf:2e:f8:a9:40:
                    6a:4f:83:0a:e8:89:7b:87:cb:d6:b8:47:4e:8d:51:
                    00:f4:ac:9d:ef:10:e4:97:4a:1b:69:6f:2f:86:df:
                    e0:81:24:c6:62:d2:00:b8:c7:60:da:97:db:da:b7:
                    c3:08:20:6e:70
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A8:EA:CD:1A:5D:AB:DC:47:A0:93:31:59:ED:05:E8:7E:40:6D:ED:8C
            X509v3 Authority Key Identifier:
                keyid:2A:F2:F7:E8:F6:1F:55:D1:74:7D:59:94:B1:45:23:FD:A1:8C:97:9B

            X509v3 Subject Alternative Name:
                DNS:ec2-3-18-214-69.us-east-2.compute.amazonaws.com, DNS:ip-192-168-65-123.us-east-2.compute.internal, IP Address:192.168.65.123, IP Address:3.18.214.69

2.    Revise os logs do kubelet para verificar se há erros de certificado. Se você não encontrar nenhum erro, será porque a exigência de enviar novos certificados foi atendida.

Exemplo de um erro de certificado no log do kubelet:

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

Observação: para obter logs mais detalhados, ative os logs detalhados do kubelet com o sinalizador --v=4 e, em seguida, reinicie o kubelet no nó de processamento. O log detalhado do kubelet será semelhante a este:

#kubelet verbosity can be increased by updating this file ...max verbosisty level --v=4
sudo vi /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
# Normal kubelet verbosisty is 2 by default
cat /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
[Service]
Environment='KUBELET_ARGS=--node-ip=192.168.65.123 --pod-infra-container-image=XXXXXXXXXX.dkr.ecr.us-east-2.amazonaws.com/eks/pause:3.1-eksbuild.1 --v=2
#to restart the demon and kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet
#make sure kubelet in running state
sudo systemctl status kubelet
# to stream logs for kubelet
journalctl -u kubelet -f

3.    Se você encontrar um erro, verifique o arquivo config do kubelet: /etc/kubernetes/kubelet/kubelet-config.json no nó de processamento e confirme se os sinalizadores RotateKubeletServerCertificate e serverTLSBootstrap estão listados como true:

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

4.    Execute o comando eks:node-bootstrapper a seguir para confirmar que o kubelet tem as permissões do sistema de controle de acesso baseado em perfil (RBAC) necessárias para enviar a solicitação de assinatura de certificado (CSR):

$ kubectl get clusterrole eks:node-bootstrapper -o yaml
apiVersion: rbac.authorization.k8s.io/v1

A saída é semelhante a esta:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"node"},"name":"eks:node-bootstrapper"},"rules":[{"apiGroups":["certificates.k8s.io"],"resources":["certificatesigningrequests/selfnodeserver"],"verbs":["create"]}]}
  creationTimestamp: "2021-11-09T10:07:42Z"
  labels:
    eks.amazonaws.com/component: node
  name: eks:node-bootstrapper
  resourceVersion: "199"
  uid: da268bf3-31a3-420a-9a71-414229437b7e
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/selfnodeserver
  verbs:
  - create

As permissões necessárias do RBAC incluem os seguintes atributos:

- apiGroups: ["certificates.k8s.io"]
resources: ["certificatesigningrequests/selfnodeserver"]
verbs: ["create"]

5.    Execute o comando a seguir para verificar se a função do cluster eks:node-bootstrapper está vinculada a system:bootstrappers e system:nodes. Isso permite que o kubelet envie e faça o rodízio de certificado de serviço para si mesmo.

$ kubectl get clusterrolebinding eks:node-bootstrapper -o yaml
apiVersion: rbac.authorization.k8s.io/v1

A saída é semelhante a esta:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"node"},"name":"eks:node-bootstrapper"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"eks:node-bootstrapper"},"subjects":[{"apiGroup":"rbac.authorization.k8s.io","kind":"Group","name":"system:bootstrappers"},{"apiGroup":"rbac.authorization.k8s.io","kind":"Group","name":"system:nodes"}]}
  creationTimestamp: "2021-11-09T10:07:42Z"
  labels:
    eks.amazonaws.com/component: node
  name: eks:node-bootstrapper
  resourceVersion: "198"
  uid: f6214fe0-8258-4571-a7b9-ff3455add7b9
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-bootstrapper
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:bootstrappers
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:nodes

---