¿Por qué no puedo ejecutar comandos kubectl en Amazon EKS?

Resolución

Normalmente, los comandos kubectl fallan en el clúster de Amazon EKS porque el servidor de la API no se comunica con el kubelet que se ejecuta en los nodos de trabajo. Los comandos más comunes de kubectl incluyen kubectl exec, kubectl logs, kubectl attach o kubectl port-forward.

Para solucionar este problema, verifique lo siguiente:

• Los pods se ejecutan en el rango secundario de enrutamiento entre dominios sin clases (CIDR).
• Los grupos de seguridad que se utilizan para el plano de control y el nodo utilizan las prácticas recomendadas para las reglas de entrada y salida.
• El ConfigMap aws-auth tiene el rol correcto de AWS Identity and Access Management (IAM) con el nombre de usuario de Kubernetes asociado al nodo.
• Se cumple el requisito de enviar un nuevo certificado.

Los pods se ejecutan en el rango secundario de enrutamiento entre dominios sin clases (CIDR)

Inmediatamente después de crear un clúster, Amazon EKS no se puede comunicar con nodos lanzados en subredes de bloques de CIDR agregados a una nube privada virtual (VPC). Un rango actualizado causado por la adición de bloques de CIDR a un clúster existente puede tardar hasta cinco horas en ser reconocido por Amazon EKS. Para obtener más información, consulte los requisitos y consideraciones sobre la VPC y las subredes de Amazon EKS.

Si los pods se ejecutan en el rango CIDR secundario, realice las siguientes acciones:

• Espere hasta cinco horas para que estos comandos empiecen a funcionar.
• Asegúrese de tener al menos cinco direcciones IP libres en cada subred para completar correctamente la automatización.

Utilice la siguiente política de ejemplo para ver las direcciones IP libres de todas las subredes de cualquier 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"

Los grupos de seguridad que se utilizan para el plano de control y el nodo tienen las reglas mínimas requeridas de entrada y salida

Cuando se ejecuta en nodos de trabajo, un servidor de la API debe tener las reglas mínimas requeridas de entrada y salida para hacer una llamada a la API de kubelet. Para verificar que el plano de control y los grupos de seguridad de nodos tienen las reglas mínimas requeridas de entrada y salida, consulte Requisitos y consideraciones sobre grupos de seguridad de Amazon EKS.

El ConfigMap aws-auth tiene el rol de IAM correcto con el nombre de usuario de Kubernetes asociado al nodo

Debe aplicar el rol de IAM correcto al ConfigMap aws-auth. Asegúrese de que el rol de IAM tenga el nombre de usuario de Kubernetes asociado a su nodo. Para aplicar el ConfigMap aws-auth a su clúster, consulte Agregar roles o usuarios de IAM a su clúster de Amazon EKS.

Se cumple el requisito de enviar un nuevo certificado

Los clústeres de Amazon EKS requieren que el kubelet del nodo envíe y rote el certificado de servicio por sí mismo. Se produce un error de certificado cuando un certificado de servicio no está disponible.

1.    Ejecute el siguiente comando para validar el certificado del servidor kubelet:

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

El resultado es similar al siguiente:

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 los registros de kubelet en busca de errores de certificación. Si no se muestra ningún error, significa que se ha cumplido el requisito de enviar nuevos certificados.

Ejemplo de un error de certificación del registro 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

Nota: Para obtener registros más detallados, active los registros detallados de kubelet con la marca --v=4 y luego reinicie el kubelet en el nodo de trabajo. El registro detallado de kubelet tiene un aspecto similar al siguiente:

#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.    Si aparece un error, verifique el archivo de configuración de kubelet /etc/kubernetes/kubelet/kubelet-config.json en el nodo de trabajo, y luego confirme que las marcas RotateKubeletServerCertificate y serverTLSBootstrap aparecen como verdaderas:

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

4.    Ejecute el siguiente comando eks:node-bootstrapper para confirmar que el kubelet tiene los permisos del sistema de control de acceso basado en roles (RBAC) necesarios para enviar la solicitud de firma de certificado (CSR):

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

El resultado es similar al siguiente:

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

Los permisos de control de acceso basado en roles (RBAC) requeridos incluyen los siguientes atributos:

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

5.    Ejecute el siguiente comando para verificar si el rol de clúster eks:node-bootstrapper está vinculado a system:bootstrappers y system:nodes. Esto permite al kubelet enviar y rotar el certificado de servicio por sí mismo.

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

El resultado es similar al siguiente:

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

---