¿Cómo soluciono los problemas de los nodos que no pueden unirse a los clústeres de Amazon EKS Anywhere?

Descripción corta

Antes de empezar a solucionar problemas, confirma que la configuración cumple los siguientes requisitos:

• Dispones de una máquina administrativa para ejecutar las operaciones del ciclo de vida del clúster.
• La máquina administrativa, el plano de control y los nodos de trabajo se encuentran en la misma red de capa 2.
• La red admite DHCP.
  Nota: Se recomienda configurar la red para excluir direcciones IP específicas para el plano de control y los nodos de trabajo.
• Has reservado direcciones IP estáticas para el punto de enlace del plano de control y otros nodos del clúster y has excluido las direcciones IP estáticas del rango de DHCP.
• El servidor tiene un mínimo de dos vCPU, 8 GB de RAM y 25 GB de almacenamiento para cada nodo.
• Tu interfaz de red elástica admite un entorno de ejecución previo al arranque (PXE).
• Tienes VMware vSphere 7 u 8 y VMware vCenter Server.
• Tienes la capacidad de desplegar de 6 a 10 máquinas virtuales (VM). Además, estás ejecutando un servicio DHCP en la red de máquinas virtuales principal para tu clúster de carga de trabajo.
• Tu red vSphere permite el acceso a vCenter Server y tú reservaste y excluiste las direcciones IP necesarias del DHCP.

Resolución

Error de registro de nodo

Recibes el siguiente mensaje de error cuando no aplicas el mapa de configuración del autenticador de AWS IAM para Kubernetes (ConfigMap de aws-auth) a un clúster:

«Unable to register node with API server err=Unauthorized».

Nota: El mapa de configuración proporciona los permisos de control de acceso basado en roles (RBAC) system:bootstrappers y system:nodes para que los nodos se registren en el clúster.

Para resolver un error de registro de nodos, agrega tu rol de AWS Identity and Access Management (IAM) al ConfigMap de aws-auth.

Error Unauthorized

Recibes un mensaje de error «unauthorized» cuando eliminas un grupo de nodos administrados y, posteriormente, la entrada del rol de nodo se elimina del ConfigMap de aws-auth. Puedes identificar este error al revisar las solicitudes de la API de kubelet al servidor de API en tus registros de kubelet.

Para resolver un error unauthorized , vuelve a agregar tu rol de IAM al ConfigMap de aws-auth.

Errores de dependencia de Kubelet

Error de archivo de CA

Aparece el siguiente mensaje de error cuando un nodo no puede recuperar el archivo de la autoridad de certificación (CA) de un clúster o cuando se ejecuta el script /etc/eks/bootstrap.sh:

«Failed to construct kubelet dependencies" err="unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory».

Para resolver un error de dependencia de Kubelet, sigue estos pasos:

1. Comprueba la secuencia /var/log/cloud-init-output.log en tus registros de cloud-init para el siguiente mensaje de error:
   «Connect timeout on endpoint URL: https://eks.us-east-1.amazonaws.com/clusters/vg-xx-uat Exited with error on line 291»

2. Ejecuta el siguiente comando curl -vk para comprobar que puedes llegar al punto de enlace de la API de Amazon EKS:

   curl -vk https://eks.us-east-1.amazonaws.com/

3. Elimina el punto de enlace de Amazon EKS.

Si no puedes llegar al punto de enlace, toma las siguientes medidas:

• En el caso de los puntos de enlace privados, coloca el nodo en la misma nube virtual privada (VPC) o red conectada. Los puntos de enlace privados no son de acceso público.
• Configura los grupos de seguridad, las tablas de enrutamiento y la lista de control de acceso de la red (ACL de la red) para los puntos de enlace públicos. Todos los grupos de seguridad, las tablas de enrutamiento y las ACL de la red deben permitir el tráfico HTTPS (TCP 443) saliente al punto de enlace de Amazon EKS. Para obtener más información, consulta Consideraciones sobre la VPC y la subred.
• En el caso de los nodos de subredes privadas, asegúrate de tener una puerta de enlace de NAT o un punto de enlace de VPC para el acceso saliente a Internet.
• Establece enableDnsHostnames y enableDnsSupport en true en tu VPC.
• Asegúrate de que el conjunto de opciones de DHCP incluya AmazonProvidedDNS.

Errores de validación

Recibes el siguiente mensaje de error de validación cuando Kubernetes no puede encontrar el recurso del plano de control «kubeadmcontrolplanes.controlplane.cluster.x-k8s.io» en el clúster de carga de trabajo:

«Validation failed: kubeadmcontrolplanes.controlplane.cluster.x-k8s.io 'eksa-sit' not found; no CAPI cluster objects present on workload cluster 'eksa-sit'...»

Para resolver un error de validación, sigue estos pasos:

1. Accede al nodo del plano de control donde se ejecuta el proceso kubeadm.

2. Ejecuta el siguiente comando journalctl para obtener información sobre la solución de problemas de los registros del servicio de kubelet:

   journalctl -u kubelet -f

3. En la salida del registro, identifica el componente del clúster que está causando el error de validación.

Error en el token de arranque

Se produce un error de token de arranque debido a un error en la versión 1.0.2 de los clústeres de Amazon EKS Anywhere. Para obtener más información, consulta bootstrap tokens can expire before they can be used if the bootstrap cluster's time is sufficiently behind the workload cluster (Los tokens de arranque pueden vencer antes de poder usarse si el tiempo del clúster de arranque es lo suficientemente atrasado con respecto al clúster de carga de trabajo) en el sitio web de GitHub.

Para resolver este error, consulta la sección Fix to enable bootstrap secret rotation if the secret itself missing (Corrección para activar la rotación de secretos de arranque si falta el secreto) en el sitio web de GitHub.

Error de secreto del token de arranque que falta

Puedes recibir un mensaje de error al ejecutar el comando eksctl anywhere upgrade cluster -f cluster.yaml. El error se produce porque falta un secreto del token de arranque debido a un error en el flujo de trabajo. El error bloquea los nuevos nodos que intentan unirse a tu clúster.

Para resolver este error, sigue estos pasos:

1. Elimina manualmente la nueva máquina aprovisionada para actualizar el token de arranque.
2. Cuando el clúster esté en buen estado, haz una copia de seguridad de la API de clúster de Kubernetes (CAPI) y mueve los componentes de CAPI al clúster de administración. Para obtener instrucciones, consulta Cluster upgrade fails with management components on bootstrap cluster (La actualización del clúster falla con los componentes de administración en el clúster de arranque).

Errores internos

Recibes el siguiente mensaje de error interno cuando el servicio de validación de webhooks tiene problemas de conectividad:

«Error from server (InternalError): Internal error occurred: failed calling webhook...»

Para resolver un error interno, sigue estos pasos:

1. Ejecuta el siguiente comando kubectl get pods para encontrar tu pod eks-controller-manager:

   kubectl get pods -n kube-system | grep eks-controller-manager

2. Ejecuta el siguiente comando kubectl logs para ver los registros del pod:

   kubectl logs eksa-controller-manager-pod-name -n kube-system

   Nota: Sustituye eksa-controller-manager-pod-name por el nombre de tu pod eksa-controller-manager.

3. Utiliza la información de la salida del registro para solucionar el problema.

Recibes el siguiente mensaje de error interno cuando se agota el tiempo de espera del proceso de elección de líderes en el plano de control de Kubernetes:

«Failed to update lock: etcdserver: request timed out failed to renew lease eksa-system/f64ae69e.eks.amazonaws.com: timed out waiting for the condition Error setup problem running manager {'error': 'leader election lost'}...»

También puedes recibir este mensaje de error cuando el proceso de elección del líder no puede renovar su arrendamiento debido a un bloqueo de recursos en etcd.

Las causas principales del error incluyen retrasos en la red, falta de disponibilidad etcd o problemas de contención de recursos.

Para resolver este error interno, elimina el pod eksa-controller-manager. Se inicia un pod de reemplazo y pasa al estado En ejecución.

Nota: Pueden producirse errores internos en las versiones 1.21 o anteriores de los clústeres de Amazon EKS Anywhere. Para evitar este error, se recomienda actualizar el clúster a la versión más reciente de Kubernetes.

Error de PLEG

Aparece el siguiente mensaje de error cuando el generador de eventos del ciclo de vida del pod (PLEG) tiene un problema:

«PLEG is not healthy: pleg was last seen active».

Para resolverlo, haz lo siguiente:

• Comprueba y resuelve la latencia o los tiempos de espera de la versión ejecutable de los contenedores, como la degradación del rendimiento, el interbloqueo o los errores, que se producen durante las solicitudes remotas.
• Evita demasiados pods en ejecución para los recursos del host o demasiados pods en ejecución en hosts de altas especificaciones.
• Soluciona los problemas de recursos en el nodo.

Para obtener más información sobre PLEG, consulta Pod Lifecycle Event Generator: Understanding the "PLEG is not healthy" issue in Kubernetes (Generador de eventos del ciclo de vida: descripción del problema «PLEG is not healthy» en Kubernetes) en el sitio web de Red Hat Developer.

Error NotReady,SchedulingDisabled

Se produce un error cuando uno de los nodos del clúster de Amazon EKS Anywhere se encuentra en el estado NotReady,SchedulingDisabled. Esto se debe a que la máquina física en la que se ejecutaba la máquina virtual vSphere ya no existe. El clúster se queda bloqueado en la fase de escalamiento y los nuevos nodos no pueden ponerse en marcha.

Para resolver un error de estado NotReady,SchedulingDisabled, sigue estos pasos:

1. Elimina el finalizador de la máquina.
2. Ejecuta el siguiente comando kubectl delete node para eliminar el nodo pendiente de Amazon EKS y dejar que se active un nodo nuevo:

   kubectl delete node your_node_name

   Nota: Sustituye your_node_name por el nombre del nodo que deseas eliminar.

Información relacionada

What is EKS Anywhere? (¿Qué es EKS Anywhere?)

La red de versión ejecutable del contenedor no está lista