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

Actualización más reciente: 24 de noviembre de 2021

No puedo ejecutar correctamente los comandos kubectl, como kubectl exec, kubectl logs, kubectl attach o kubectl port-forward, en Amazon Elastic Kubernetes Service (Amazon EKS).

Resolución

La razón más común por la que no es posible ejecutar correctamente comandos, como kubectl exec, kubectl logs, kubectl attach o kubectl port-forward en el clúster de Amazon EKS, es porque el servidor de la API no se comunica correctamente con el kubelet que se ejecuta en los nodos de trabajo.

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 utilizados 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)

Amazon EKS no se puede comunicar con nodos lanzados en subredes de bloques de CIDR adicionales agregados a una nube privada virtual (VPC) inmediatamente después de la creación de un clúster. 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 Consideraciones sobre la VPC del clúster.

Si los pods se ejecutan en el rango CIDR secundario, haga lo siguiente:

  • 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 utilizados para el plano de control y el nodo tienen las reglas mínimas requeridas de entrada y salida

Para que un servidor de la API pueda hacer una llamada a la API de kubelet mientras se ejecuta en los nodos de trabajo, debe tener las reglas mínimas requeridas de entrada y salida. Para verificar que los grupos de seguridad utilizados para el plano de control y el nodo tienen las reglas de entrada y salida mínimas requeridas, consulte Consideraciones sobre los 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

Es necesario tener el rol de IAM correcto, con el nombre de usuario de Kubernetes asociado al nodo, aplicado al ConfigMap aws-auth. Para aplicar el ConfigMap aws-auth al clúster, consulte Administrar usuarios o roles de IAM para el clúster.

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

La salida es similar a la 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

La salida es similar a la siguiente:

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: "2019-11-17T05:01:38Z"
 labels:
 eks.amazonaws.com/component: node
 name: eks:node-bootstrapper
 resourceVersion: "168"
 selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/eks%3Anode-bootstrapper
 uid: 564b6a3a-08f7-11ea-9d07-06e275d1e5e0
rules:
- apiGroups:
 - certificates.k8s.io
resources:
- certificatesigningrequests/selfnodeserver
verbs:
- create

Los permisos de control de acceso basado en roles (RBAC) requeridos incluyen lo siguiente:

- 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

La salida es similar a la siguiente:

kind: ClusterRoleBinding
metadata:
 labels:
 eks.amazonaws.com/component: node
 name: eks:node-bootstrapper
 resourceVersion: "167"
 selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/eks%3Anode-bootstrapper
 uid: 564a00de-08f7-11ea-9d07-06e275d1e5e0
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

¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?