¿Cómo soluciono los problemas de eksctl con clústeres y grupos de nodos de Amazon EKS?

Descripción corta

Los siguientes son problemas habituales que puede encontrar al utilizar eksctl para crear o administrar un clúster o un grupo de nodos de Amazon EKS:

• No sabe cómo crear un clúster con eksctl. Consulte Getting started with Amazon EKS - eksctl (Introducción a Amazon EKS: eksctl) y la sección eksctl de Creating an Amazon EKS cluster (Creación de un clúster de Amazon EKS).
• No sabe cómo especificar las opciones de arranque de kubelet para los grupos de nodos administrados. Siga los pasos de la sección de resolución Especificar las opciones de arranque de kubelet.
• No sabe cómo cambiar el tipo de instancia de un grupo de nodos existente. Tiene que crear un grupo de nodos nuevo. Consulte Migrating to a new node group (Migración a un nuevo grupo de nodos) y Nodegroup immutability (Inmutabilidad del grupo de nodos) en el sitio web de eskctl.
• Ha alcanzado el número máximo de recursos de AWS. Compruebe sus recursos para ver si puede eliminar los que no utiliza. Si aún necesita más capacidad, consulte Solicitar un aumento de cuota.
• Lanza instancias del plano de control en una zona de disponibilidad con capacidad limitada. Consulte How do I resolve cluster creation errors in Amazon EKS? (¿Cómo soluciono errores al crear clústeres en Amazon EKS?)
• Los nodos no cambian al estado Ready (Listo). Siga los pasos de la sección de resolución Resolver problemas de tiempo de espera de la operación.
• Los valores de exportación no existen para el clúster. Siga los pasos de la sección de resolución Crear el grupo de nodos en subredes privadas.
• Utilizó un tipo de instancia no compatible para crear un clúster o un grupo de nodos. Sigue los pasos de la sección de resolución Comprobar si el tipo de instancia es compatible.

Resolución

Especificar las opciones de arranque de kubelet

De forma predeterminada, eksctl crea un script de arranque y lo agrega a la plantilla de lanzamiento que los nodos de trabajo ejecutan durante el proceso de arranque. Para especificar sus propias opciones de arranque de kubelet, utilice la especificación overrideBootstrapCommand para anular el script de arranque de eksctl. Utilice el comando overrideBootstrapCommand para grupos de nodos administrados y autoadministrados.

Especificación del archivo de configuración:

managedNodeGroups:
  name: custom-ng
  ami: ami-0e124de4755b2734d
  securityGroups:
    attachIDs: ["sg-1234"]
  maxPodsPerNode: 80
  ssh:
    allow: true
  volumeSize: 100
  volumeName: /dev/xvda
  volumeEncrypted: true
  disableIMDSv1: true
  overrideBootstrapCommand: |
  #!/bin/bash
  /etc/eks/bootstrap.sh managed-cluster --kubelet-extra-args '--node-labels=eks.amazonaws.com/nodegroup=custom-ng,eks.amazonaws.com/nodegroup-image=ami-0e124de4755b2734d'

Nota: Puede utilizar overrideBootstrapCommand solo cuando se utiliza una AMI personalizada. Si no especifica un identificador de AMI, se produce un error en la creación del clúster.

No se especificó un identificador de AMI personalizado

Si no especifica un identificador de AMI personalizado al crear grupos de nodos administrados, Amazon EKS utilizará de forma predeterminada una AMI optimizada para Amazon EKS y un script de arranque. Para utilizar una AMI optimizada para Amazon EKS con datos de usuario personalizados para especificar los parámetros de arranque, especifique el identificador de AMI en la configuración del grupo de nodos administrados.

Para obtener el identificador de AMI más reciente para la última AMI optimizada para Amazon EKS, ejecute el siguiente comando:

aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.21/amazon-linux-2/recommended/image_id --region Region --query "Parameter.Value" --output text

Nota: Sustituya Region por su región de AWS.

Resolver problemas de tiempo de espera de la operación

Si recibe el siguiente error al crear un nodo, es posible que su grupo de nodos tenga problemas de tiempo de espera:

waiting for at least 1 node(s) to become ready in "nodegroup"

Cuando crea un grupo de nodos de EKS con eksctl, la CLI de eksctl se conecta al servidor de API para comprobar continuamente el estado del nodo de Kubernetes. La CLI espera a que los nodos cambien al estado Ready (Listo) y, finalmente, agota el tiempo de espera si los nodos no cambian.

Los siguientes son los motivos por los que los nodos no cambian al estado Ready (Listo):

• El kubelet no puede comunicarse ni autenticarse con el punto de conexión del servidor de la API de EKS durante el proceso de arranque.
• Los pods aws-node y kube-proxy no están en estado Running (En ejecución).
• Los datos de usuario del nodo de trabajo de Amazon Elastic Compute Cloud (Amazon EC2) no se ejecutaron correctamente.

El kubelet no puede comunicarse con el punto de conexión del servidor de la API de EKS

Si el kubelet no puede comunicarse con el punto de conexión del servidor de la API de EKS durante el proceso de arranque, obtenga el punto de conexión del servidor de la API de EKS.

Ejecute el siguiente comando en el nodo de trabajo:

curl -k https://123456DC0A12EC12DE0C12BC312FCC1A.yl4.us-east-1.eks.amazonaws.com
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

El comando anterior debe devolver el código de estado HTTP 403. Si el comando agota el tiempo de espera, es posible que tenga un problema de conectividad de red entre el servidor de la API de EKS y los nodos de trabajo.

Para resolver el problema de conectividad, complete uno de los siguientes pasos relacionados con su caso de uso:

• Si los nodos de trabajo están en una subred privada, compruebe que el punto de conexión del servidor de la API de EKS esté en modo de acceso Privado o Público y privado.
• Si el punto de conexión del servidor de la API de EKS se establece en Privado, tiene que aplicar ciertas reglas para que la zona alojada privada dirija el tráfico al servidor de la API. Los atributos enableDNSHostNames y enableDNSSupport de Amazon Virtual Private Cloud (Amazon VPC) deben establecerse en True. Además, el conjunto de opciones de DHCP para Amazon VPC tiene que incluir AmazonProvideDNS en la lista de dominios.
• Si creó el grupo de nodos en subredes públicas, asegúrese de que el atributo de direccionamiento público IPv4 de las subredes esté establecido en True. Si no establece el atributo en True, a los nodos de trabajo no se les asigna una dirección IP pública y no pueden acceder a Internet.
• Compruebe si el grupo de seguridad del clúster de Amazon EKS permite las solicitudes de entrada al puerto 443 del grupo de seguridad del nodo de trabajo.

El kubelet no puede autenticarse con el punto de conexión del servidor de la API de EKS

Si el kubelet no puede autenticarse con el punto de conexión del servidor de la API de EKS durante el proceso de arranque, complete los siguientes pasos.

1.    Ejecute el siguiente comando para comprobar que el nodo de trabajo tiene acceso al punto de conexión de STS:

telnet sts.region.amazonaws.com 443

Nota: Sustituya region por su región de AWS.

2.    Asegúrese de que el rol AWS Identity and Access Management (IAM) del nodo de trabajo se haya agregado al ConfigMap de aws-auth.

Por ejemplo:

apiVersion:v1 kind:ConfigMap metadata:name:aws-auth namespace:kube-system data:mapRoles:|
    - rolearn: ARN of instance role (not instance profile)
      username: system:node:{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Nota: Para los grupos de nodos de Microsoft Windows, debe agregar un grupo RBAC eks:kube-proxy-windows adicional a la sección mapRoles para el rol de IAM del grupo de nodos.

Los pods aws-node y kube-proxy no están en estado Running (En ejecución)

Para comprobar si los pods aws-node y kube-proxy están en estado Running (En ejecución), ejecute el siguiente comando:

kubectl get pods -n kube-system

Si el pod aws-node se encuentra en estado Failing (Fallo), compruebe la conexión entre el nodo de trabajo y el punto de conexión de Amazon EC2:

ec2.region.amazonaws.com

Nota: Sustituya region por su región de AWS.

Compruebe que las políticas administradas de AWS AmazonEKSWorkerNodePolicy y AmazonEC2ContainerRegistryReadOnly estén asociadas al rol de IAM del grupo de nodos.

Si los nodos están en una subred privada, configure los puntos de conexión de VPC de Amazon ECR para permitir la extracción de imágenes de Amazon Elastic Container Registry (Amazon ECR).

Si utiliza IRSA para su CNI de Amazon VPC, adjunte la política administrada de AWS AmazonEKS_CNI_Policy al rol de IAM que utilizan los pods de aws-node. También debe adjuntar la política al rol de IAM del grupo de nodos sin IRSA.

Los datos de usuario del nodo de trabajo de EC2 no se ejecutaron correctamente

Para comprobar si se produjeron errores cuando se ejecutaron los datos del usuario, revise los registros de cloud-init en /var/log/cloud-init.log y /var/log/cloud-init-output.log.

Para obtener más información, ejecute el script EKS Logs Collector en los nodos de trabajo.

Crear el grupo de nodos en subredes privadas

Si recibe el siguiente error al crear un grupo de nodos, cree el grupo de nodos en subredes privadas:

No export named eksctl--cluster::SubnetsPublic found. Rollack requested by user

Si creó el clúster de Amazon EKS con redes PrivateOnly, AWS CloudFormation no puede crear subredes públicas. Esto significa que los valores de exportación no existirán para las subredes públicas. Si no existen valores de exportación para el clúster, se produce un error en la creación del grupo de nodos.

Para resolver este problema, puede incluir el marcador --node-private-networking cuando utilice el comando eksctl en línea. También puede utilizar la especificación privateNetworking: true en la configuración del grupo de nodos para solicitar la creación de grupos de nodos en subredes privadas.

Actualice su versión de eksctl o especifique la región de AWS correcta

Si recibe el siguiente error, compruebe su región de AWS:

no eksctl-managed CloudFormation stacks found for "cluster-name"

Si utiliza una versión de eksctl anterior a la 0.40.0, solo podrá ver o administrar los recursos de Amazon EKS que haya creado con eksctl. Para administrar los recursos que no se crearon con eksctl, actualice eksctl a la versión 0.40.0 o posterior. Para obtener más información acerca de los comandos que puede ejecutar para clústeres que no se crearon con eksctl, consulte Non eksctl-created clusters (Clústeres no creados por eksctl) en el sitio web de eksctl.

Además, las pilas de CloudFormation administradas por eksctl no se encuentran si especifica una región de AWS incorrecta. Para resolver este problema, asegúrese de especificar la región correcta en la que se encuentran sus recursos de Amazon EKS.

Comprobar si el tipo de instancia es compatible

Si utilizó un tipo de instancia no compatible para crear un clúster o un nodo, recibirá el siguiente error:

You must use a valid fully-formed launch template. The requested configuration is currently not supported. Please check the documentation for supported configurations'

Para comprobar si el tipo de instancia u otras configuraciones se admiten en una región de AWS específica, ejecute el siguiente comando:

aws ec2 describe-instance-type-offerings --region Region --query 'InstanceTypeOfferings[*].{InstanceType:InstanceType}'

Nota: Sustituya Region por su región de AWS.

---