¿Cómo soluciono los errores de creación de grupos de nodos administrados por Amazon EKS?

Última actualización: 03-06-2022

Mi grupo de nodos administrados de Amazon Elastic Kubernetes Service (Amazon EKS) no se pudo crear. Los nodos no pueden unirse al clúster y recibí un error similar al siguiente:

“Instances failed to join the kubernetes cluster” (Las instancias no pudieron unirse al clúster de kubernetes).

Descripción corta

Para resolver los errores de creación de grupos de nodos administrados de Amazon EKS, siga estos pasos:

  • Utilice el runbook de automatización de AWS Systems Manager para identificar problemas comunes.
  • Confirme los requisitos de tráfico del grupo de seguridad del nodo de trabajo.
  • Verifique los permisos de Identity and Access Management (IAM) del nodo de trabajo.
  • Confirme que la Amazon Virtual Private Cloud (Amazon VPC) para su clúster admite un nombre de host DNS y una resolución de DNS.
  • Actualice aws-auth ConfigMap con el valor NodeInstanceRole de los nodos de trabajo.
  • Establezca las etiquetas para los nodos de trabajo.
  • Confirme que las subredes de Amazon VPC del nodo de trabajo tengan direcciones IP disponibles.
  • Confirme que los nodos de trabajo pueden alcanzar el punto de conexión del servidor de la API de su clúster.
  • Compruebe que los puntos de conexión de API de Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Registry (Amazon ECR) y Amazon Simple Storage Service (Amazon S3) puedan llegar a su región de AWS.

Resolución

Nota: Si se producen errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), asegúrese de que utiliza la versión más reciente de la AWS CLI.

Utilizar el runbook de automatización de Systems Manager para identificar problemas comunes

Utilice el runbook de AWSSupport-TroubleshootEKSWorkerNode para encontrar problemas comunes que impiden que los nodos de trabajo se unan al clúster.

Importante: Para que la automatización funcione, los nodos de trabajo deben tener permiso para acceder a Systems Manager y que Systems Manager se esté ejecutando. Para conceder el permiso, adjunte la política administrada de AWS AmazonSSMManagedInstanceCore al rol de IAM que corresponda a su perfil de instancia de EC2. Esta es la configuración predeterminada para los grupos de nodos administrados de EKS que se crean mediante eksctl.

  1. Abra el runbook.
  2. Compruebe que la región de AWS en la consola de administración de AWS esté configurada en la misma región que el clúster.
    Nota: Consulte la sección Detalles del documento del runbook para obtener más información sobre el runbook.
  3. En la sección Input parameters (Parámetros de entrada), especifique el nombre de su clúster en el campo ClusterName y el ID de instancia en el campo WorkerID.
  4. (Opcional) En el campo AutomationAssumeRole, especifique el rol de IAM para permitir que Systems Manager realice acciones. Si no se especifica, los permisos de IAM de la entidad de IAM actual se utilizan para realizar las acciones del runbook.
  5. Elija Execute (Ejecutar).
  6. Consulte la sección Outputs (Salidas) para ver por qué el nodo de trabajo no se une al clúster y los pasos que puede tomar para resolverlo.

Confirmar los requisitos de tráfico del grupo de seguridad del nodo de trabajo

Confirme que el grupo de seguridad del plano de control y el grupo de seguridad del nodo de trabajo estén configurados con la configuración recomendada para el tráfico entrante y saliente. De forma predeterminada, Amazon EKS aplica el grupo de seguridad del clúster a las instancias del grupo de nodos para facilitar la comunicación entre los nodos y el plano de control. Si especifica grupos de seguridad personalizados en la plantilla de lanzamiento del grupo de nodos gestionados, Amazon EKS no agrega el grupo de seguridad del clúster.

Verificar los permisos de IAM del nodo de trabajo

Asegúrese de que el rol de instancia de IAM asociado al nodo de trabajo tenga las políticas AmazonEKSWorkerNodePolicy y AmazonEC2ContainerRegistryReadOnly adjuntas.

Nota: Debes adjuntar la política gestionada de Amazon AmazonEKS_CNI_Policy a un rol de IAM. Puede adjuntarlo al rol de instancia del nodo. Sin embargo, se recomienda adjuntar la política a un rol que esté asociado a la cuenta de servicio de Kubernetes de aws-node en el espacio de nombres kube-system. Para obtener más información, consulte Configuración del complemento de CNI de Amazon VPC para utilizar roles de IAM en cuentas de servicio.

Confirmar que la Amazon VPC para su clúster admite un nombre de host DNS y una resolución de DNS

Después de configurar el acceso privado para el punto de conexión del clúster de EKS, debe activar un nombre de host DNS y una resolución de DNS para su Amazon VPC. Cuando activa el acceso privado del punto de conexión, Amazon EKS crea una zona alojada privada de Amazon Route 53 para usted. A continuación, Amazon EKS la asocia con la Amazon VPC de su clúster. Para obtener más información, consulte Control de acceso de puntos de conexión de clúster de Amazon EKS.

Actualizar aws-auth ConfigMap con el valor NodeInstanceRole de los nodos de trabajo

Compruebe que aws-auth ConfigMap esté configurado correctamente con el rol de IAM de los nodos de trabajo, no con el perfil de instancia.

Establecer las etiquetas para los nodos de trabajo

Para la propiedad Tag (Etiqueta) de los nodos de trabajo, establezca el valor de key (clave) como kubernetes.io/cluster/clusterName y value (valor) como owned (propio).

Confirmar que las subredes de Amazon VPC del nodo de trabajo tengan direcciones IP disponibles

Si la Amazon VPC se está quedando sin direcciones IP, puede asociar un CIDR secundario a su VPC de Amazon existente. Para obtener más información, consulte Aumentar las direcciones IP disponibles para su Amazon VPC.

Confirme que los nodos de trabajo de Amazon EKS pueden alcanzar el punto de conexión del servidor de la API de su clúster

Puede lanzar nodos de trabajo en cualquier subred de la VPC del clúster o subred entre pares si hay una ruta de Internet a través de las siguientes puertas de enlace:

  • NAT
  • Internet
  • Transporte público

Si sus nodos de trabajo se lanzan en una red privada restringida, confirme que los nodos de trabajo pueden alcanzar el punto de conexión del servidor de la API de Amazon EKS. Para obtener más información, consulte los requisitos para ejecutar Amazon EKS en un clúster privado sin acceso a Internet saliente.

Nota: En el caso de aquellos nodos que están en una subred privada respaldada por una puerta de enlace NAT, se recomienda crear la puerta de enlace NAT en una subred pública.

Si no utiliza puntos de conexión de AWS PrivateLink, verifique el acceso a los puntos de conexión de la API a través de un servidor proxy para los siguientes servicios de AWS:

  • Amazon EC2
  • Amazon ECR
  • Amazon S3

Para comprobar que el nodo de trabajo tiene acceso al servidor de la API, conecte su nodo de trabajo mediante SSH y ejecute el siguiente comando netcat:

nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443

Nota: Reemplace 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com por el punto de conexión del servidor de la API.

Compruebe los registros de kubelet mientras sigue conectado a su instancia:

journalctl -f -u kubelet

Si los registros de kubelet no proporcionan información sobre la fuente del problema, compruebe el estado del kubelet en el nodo de trabajo:

sudo systemctl status kubelet

Recopile los registros de Amazon EKS y los registros del sistema operativo para solucionar problemas adicionales.

Comprobar que se pueda acceder a los puntos de conexión de la API de Amazon EC2, Amazon ECR y Simple Storage Service (Amazon S3) desde su región de AWS

Utilice SSH para conectarse a uno de los nodos de trabajo y, a continuación, ejecute los siguientes comandos para cada servicio:

$ nc -vz ec2.region.amazonaws.com 443
$ nc -vz ecr.region.amazonaws.com 443
$ nc -vz s3.region.amazonaws.com 443

Nota: reemplace region por la región de AWS para su nodo de trabajo.

Configurar los datos de usuario para el nodo de trabajo

Para las plantillas de lanzamiento de grupos de nodos administrados con una AMI especificada, debe proporcionar comandos de arranque para que los nodos de trabajo se unan al clúster. Amazon EKS no fusionará los comandos de arranque predeterminados en sus datos de usuario. Para obtener más información, consulte Introducción de la plantilla de lanzamiento y la compatibilidad con AMI personalizadas en los grupos de nodos administrados de Amazon EKS y Especificación de una AMI.

Ejemplo de plantilla de lanzamiento con comandos bootstrap:

#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh ${ClusterName} ${BootstrapArguments}

Nota: Reemplace ${ClusterName} por el nombre de su clúster de Amazon EKS. Reemplace ${BootstrapArguments} por valores de arranque adicionales, si es necesario.