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

Descripción corta

Al intentar ejecutar los comandos de kubectl, es posible que surjan los siguientes problemas:

• No puedes ejecutar kubectl exec, kubectl logs, kubectl attach ni kubectl port-forward.
• kubectl no puede acceder al plano de control.
• No puedes instalar kubectl.
• Se producen errores de autorización.

Resolución

Nota: Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), consulta Solución de problemas de AWS CLI. Además, asegúrate de utilizar la versión más reciente de la AWS CLI.

No puedes ejecutar kubectl exec, kubectl logs, kubectl attach ni kubectl port-forward

Para ejecutar los comandos kubectl exec, kubectl logs, kubectl attach o kubectl port-forward, la API de Amazon EKS debe establecer una conexión de confianza con el kubelet. Si la autenticación falla, aparecerá un error similar al siguiente ejemplo:

«Error from server: error dialing backend: remote error: tls: internal error»

Comprobar si hay problemas de conectividad de red

Asegúrate de que el servidor de la API pueda comunicarse con el nodo de trabajo en el puerto 1025. El grupo de seguridad del nodo de trabajo debe permitir el tráfico entrante desde el grupo de seguridad del clúster en el puerto 10250. El grupo de seguridad del clúster debe permitir el tráfico entrante desde el grupo de seguridad del nodo de trabajo en el puerto 443. Asegúrate de que tus grupos de seguridad cumplan los requisitos de Amazon EKS.

Comprobar si hay problemas de CSR

Si el panel de control no aprueba la solicitud de firma de certificado (CSR) que envió el kubelet, el kubelet no se puede ejecutar.

Para identificar la CSR con problemas, ejecuta el siguiente comando:

kubectl get certificatesigningrequest

Para comprobar el estado de la solicitud de CSR, ejecuta el siguiente comando:

kubectl describe certificatesigningrequest csr-name -n namespace

Nota: Sustituye csr-name por el nombre de CSR y namespace por el nombre del espacio de nombres.

En el resultado, comprueba si las CSR están en el estado Pendiente o Aprobado en lugar del estado Aprobado y emitido.

Debes activar los indicadores RotateKubeletServerCertificate y ServerTLSBootstrap en el kubelet para que el kubelet envíe y rote el certificado de entrega por sí mismo. Para comprobar si los indicadores del archivo JSON kubelet-config están configurados en true, ejecuta el siguiente comando desde el nodo de trabajo:

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

Resultado de ejemplo:

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

Para que el kubelet cree y envíe la CSR, debes adjuntar el rol eks:node-bootstrapper a los grupos system:bootstrappers y system:nodes. Para comprobar si ClusterRole y ClusterRoleBinding tienen el rol eks:node:boostrapper, ejecuta los siguientes comandos:

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

Resultado de ejemplo:

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

Si falta el rol eks:node-bootstrapper, crea un archivo YAML con la siguiente configuración:

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

A continuación, ejecuta el siguiente comando para actualizar el clúster de Amazon EKS:

 kubectl apply -f file-name command

Nota: Sustituye file-name por tu nombre de archivo YAML.

Si usas el método de autenticación ConfigMap, también debes adjuntar el instance-role que has configurado en el archivo aws-auth a los grupos system:bootstrappers y system:nodes. Agrega instance-role a aws-auth en el siguiente 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}}

Nota: Si has configurado la API de Amazon EKS como modo de autenticación de clústeres, comprueba la configuración. Asegúrate de que el rol de AWS Identity and Access Management (IAM) del nodo de trabajo se asigne al nombre de usuario system:node:{{EC2PrivateDNSName}}. Esta configuración garantiza que Amazon EKS reconozca al solicitante de la CSR y apruebe automáticamente la CSR. Amazon EKS solo aprueba automáticamente las CSR del system:node:{{EC2PrivateDNSName}}.

Para comprobar los detalles del solicitante, ejecuta el siguiente comando:

kubectl describe csr csr-name

Nota: Sustituye csr-name por tu nombre de CSR.

Resultado de ejemplo:

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>

Asegúrate de que el solicitante de CSR esté en el formato system:node:ip-abc-xx-x-xabc.ec2.internal. Si usas el mismo rol de IAM que creó el clúster para los nodos de trabajo, el solicitante podría ser kubernetes-admin en lugar de system:node:EC2PrivateDNSName. Amazon EKS rechaza las solicitudes que no provienen de system:node:EC2PrivateDNSName. Si has asignado el rol de nodo de trabajo a un nombre de usuario personalizado en aws-auth, asegúrate de haber asignado correctamente el rol de nodo de trabajo a system:node:EC2PrivateDNSName.

Comprobar los registros de kubelet

Para comprobar el estado del kubelet, ejecuta el siguiente comando:

systemctl status kubelet

Si el resultado muestra que el estado del kubelet es Detenido, ejecuta el siguiente comando para reiniciar el kubelet:

sudo systemctl restart kubelet

Para comprobar la palabra clave cert en los registros de kubelet, ejecuta el siguiente comando:

 journalctl -u kubelet | grep cert

Ejemplo del error:

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

Si no ves errores cert en el resultado del comando, puedes enviar una nueva CSR. Para registros más detallados, usa el indicador --v=4. Para recopilar los registros de los nodos de trabajo para un análisis detallado, usa el script log-collector-script en el sitio web de GitHub.

Comprobar los registros del plano de control

Requisito previo: Permite que el clúster de Amazon EKS envíe registros del plano de control a Información de registros de Amazon CloudWatch.

Para obtener más información sobre los problemas de CSR, ejecuta el siguiente comando para usar Información de registros de CloudWatch y comprobar los registros del plano de control:

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

Nota: Sustituye csr-name por el nombre de la CSR que tiene problemas.

Kubectl no puede acceder al plano de control

Comprobar el acceso al punto de enlace de Amazon EKS

Si has activado el acceso privado para el punto de enlace del servidor de la API de Kubernetes de tu clúster, solo podrás acceder al servidor de la API desde los siguientes orígenes:

• Tu red privada virtual (VPN)
• Una red conectada

Si ejecutas kubectl desde un cliente que no forma parte de la VPC ni está en una red conectada, no podrás acceder al servidor de la API del clúster. Aparece un error similar al siguiente:

«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 este problema, cambia el acceso de los puntos de enlace del clúster a Acceso público. Si debes tener un clúster privado, crea un host bastión de Amazon Elastic Compute Cloud (Amazon EC2) en la VPC del clúster. A continuación, utiliza el host bastión para acceder al clúster. Debes agregar el grupo de seguridad del host bastión al grupo de seguridad del clúster.

Comprobar la configuración del host y del puerto

Si aparece el mensaje de error The connection to the server localhost:8080 was refused, compruebe la configuración del host y del puerto. El error suele producirse cuando kubectl no puede encontrar la información correcta sobre el puerto y el host del punto de enlace del servidor de la API de Amazon EKS en el archivo kubeconfig.

Para resolver este problema, sigue estos pasos:

1. Para actualizar el archivo kubeconfig, ejecuta el siguiente comando update-kubeconfig de la AWS CLI:

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

   Nota: Sustituye region-code por tu región de AWS y my-cluster por el nombre de tu clúster.

2. Para ver el contexto actual, ejecuta el siguiente comando:

   kubectl config current-context

3. Para comprobar el usuario o el rol de IAM que has configurado en tu entorno, ejecuta el siguiente comando get-caller-identity:

   aws sts get-caller-identity

Para solucionar problemas de IAM, consulta ¿Cómo proporciono acceso al clúster a otros usuarios y roles de IAM después de crear un clúster en Amazon EKS?

Comprobar las reglas del grupo de seguridad del plano de control y del nodo de trabajo

Si las reglas del plano de control y del grupo de seguridad de nodos bloquean el acceso al servidor de la API, aparecerá el siguiente error:

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

Para resolver este problema, asegúrate de que el plano de control y los grupos de seguridad de nodos tengan las reglas de entrada y salida necesarias. El grupo de seguridad del servidor de la API debe permitir el acceso entrante desde el cliente del servidor de la API en el puerto 443.

No puedes instalar kubectl

Debes usar una versión de kubectl que esté dentro de una diferencia de versión menor con respecto a tu clúster. Por ejemplo, un cliente v1.31 puede comunicarse con las versiones v1.30, v1.31 y v1.32 del plano de control. Para evitar problemas, instala la última versión compatible de kubectl.

Al instalar kubectl, es posible que aparezca uno de los siguientes errores:

«error: exec plugin: invalid apiVersion client.authentication.k8s.io/v1alpha1»

Alternativa:

«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"»

Los errores anteriores suelen producirse cuando utilizas una versión anterior de la AWS CLI para ejecutar el comando update-kubeconfig. Para resolver este problema, sigue actualizando la AWS CLI. Para obtener más información, consulta Cómo dejar en desuso la versión v1alpha1 de la API de cliente de Kubernetes en el sitio web de GitHub.

Se producen errores de autorización al ejecutar los comandos de kubectl

Es posible que aparezca el siguiente error al ejecutar los comandos de kubectl:

«error: You must be logged in to the server (Unauthorized)»

Para resolver este problema, consulta ¿Cómo puedo solucionar el error «You must be logged in to the server (Unauthorized)» cuando me conecto al servidor API de Amazon EKS?