¿Cómo soluciono los problemas de los complementos CNI de Amazon VPC para Amazon EKS?

Resolución

Amazon EKS requiere una asignación de IP de pod adecuada para que el complemento de interfaz de red de contenedores (CNI) de Amazon Virtual Private Cloud (Amazon VPC) funcione correctamente. Para resolver los problemas del complemento CNI de VPC, comprueba las siguientes configuraciones:

• Permisos de AWS Identity and Access Management (IAM), incluido AmazonEKS_CNI_Policy que se adjunta a los roles de IAM de tu nodo de trabajo. O bien, los permisos de IAM que proporcionas a través de los roles de IAM de la cuenta de servicio.
• Un punto de enlace del servidor de API de Amazon EKS al que se puede acceder desde el nodo de trabajo.
• Acceso de red a los puntos de enlace de API para Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Registry (Amazon ECR) y Amazon Simple Storage Service (Amazon S3).
• Suficientes direcciones IP disponibles en la subred.
• Un kube-proxy que se ejecuta correctamente para que el pod aws-node pase al estado Listo.
• La versión de Kube-proxy y la versión de CNI de VPC que se alinea con la versión de clúster de Amazon EKS.

Completa los siguientes pasos de solución de problemas para resolver los problemas del complemento CNI de VPC.

Verificar que el pod aws-node esté en estado de ejecución

El complemento CNI de VPC se ejecuta como un pod de DaemonSet llamado aws-node en el espacio de nombres kube-system. Se ejecuta un pod aws-node en cada nodo de trabajo del clúster.

1. Para comprobar que el pod aws-node está en ejecución en cada nodo de trabajo, ejecuta el siguiente comando:

   kubectl get pods -n kube-system -l k8s-app=aws-node -o wide

   Nota: Sustituye k8s-app=aws-node por tu selector de etiquetas.

2. Si el resultado del comando muestra que el recuento de REINICIOS es superior a 0, comprueba el estado de los contenedores y los mensajes de error. Ejecuta el siguiente comando describe:

   kubectl describe pod aws-node-pod-name -n kube-system

   Nota: Sustituye aws-node-pod-name por el nombre de tu pod de nodos de AWS.

3. Si el pod aws-node está bloqueado en un estado ContainerCreating y el resultado de describe muestra el siguiente mensaje de error en los eventos:

   "Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"

   A continuación, completa los pasos descritos en ¿Por qué mi pod de Amazon EKS está bloqueado en el estado ContainerCreating y aparece el error "Failed to create pod sandbox"?

4. Para ver los registros del pod aws-node, ejecuta los siguientes comandos de registro:

   kubectl logs daemonset/aws-node -n kube-system

   O bien:

   kubectl logs aws-node-pod-name -n kube-system

   Nota: Sustituye aws-node-pod-name por el nombre de tu pod aws-node.

5. Comprueba los registros del complemento CNI de VPC en el nodo de trabajo. Inicia sesión en el nodo de trabajo y, a continuación, ve al directorio /var/log/aws-routed-eni/. Busca los nombres de archivo plugin.log y ipamd.log y, a continuación, comprueba los registros de estos archivos.

6. Comprueba que los nodos de trabajo puedan llegar al punto de enlace del servidor de API de tu clúster de Amazon EKS. Para iniciar sesión en tu nodo de trabajo, utiliza SSH o el Administrador de sesiones de AWS Systems Manager y, a continuación, ejecuta el siguiente comando:

   curl -ivk https://eks-api-server-endpoint-url

   Nota: Sustituye eks-api-server-endpoint-url por el URL del punto de enlace del servidor de API de Amazon EKS.

Comprobación de la versión de CNI de VPC

Comprueba que la versión del complemento CNI de VPC esté actualizada y sea compatible con la versión del clúster de Amazon EKS.

Para comprobar la versión actual de CNI de VPC, ejecuta el siguiente comando:

kubectl describe daemonset aws-node -n kube-system | grep Image | cut -d "/" -f 2

Compara tu versión actual con la última versión disponible en Amazon VPC CNI plugin releases (Versiones del complemento CNI de Amazon VPC) en el sitio web de GitHub.

Si tu versión está desactualizada, actualiza el complemento CNI de VPC a la versión más reciente. Para obtener más información, consulta Cómo actualizar la CNI de Amazon VPC (complemento de Amazon EKS).

Comprobación de la configuración y los requisitos de la red

Comprueba que las configuraciones de subred y grupos de seguridad del clúster de Amazon EKS estén configuradas correctamente.

Comprobación de las reglas del grupo de seguridad

Los grupos de seguridad deben permitir la conectividad entre el plano de control y el plano de datos.

Si usas un grupo de seguridad personalizado para los nodos de trabajo, comprueba los puertos. Las reglas de grupos de nodos mínimos permiten que el puerto 10250 entre desde el grupo de seguridad del plano de control y el 443 salga hacia el grupo de seguridad del plano de control. Para más información, consulta Seguridad de la red.

Si la característica del grupo de seguridad del pod está activa, comprueba si se han alcanzado los límites de tu grupo de seguridad. Si alcanzas los límites de la interfaz de red elástica de tu grupo de seguridad, la configuración de red del pod puede fallar. Para más información, consulta cuotas de Amazon VPC.

Para obtener más información sobre las reglas de grupos de seguridad requeridas, consulta Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres.

Comprobación de la configuración de subred

Para enumerar las direcciones IP disponibles en cada subred del ID de Amazon VPC, ejecuta el siguiente comando:

aws ec2 describe-subnets —filters "Name=vpc-id,Values= VPCID" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'

Comprueba que las reglas de la lista de control de acceso a la red de tu nodo de trabajo para tus subredes permitan la comunicación con el servidor de API de Amazon EKS. Para obtener más información sobre cómo configurar las ACL de la red, consulta Control del tráfico de la subred con listas de control de acceso a la red.

Verifica que las subredes del plano de control tengan suficientes direcciones IP libres disponibles. Cada subred del plano de control debe tener al menos seis direcciones IP que Amazon EKS pueda usar. Sin embargo, AWS recomienda que cada subred tenga al menos 16 direcciones IP. El valor de AvailableIpAddressCount debe ser mayor que 0 para la subred en la que se inician los pods. Para obtener más información, consulta Requisitos y consideraciones de la subred.

Comprobar que el pod kube-proxy esté en estado de ejecución

El pod kube-proxy debe estar en ejecución para que la conectividad de red sea adecuada.

Para comprobar que kube-proxy está en ejecución, ejecuta el siguiente comando:

kubectl get pods -n kube-system -l k8s-app=kube-proxy

Confirma que todos los pods kube-proxy estén en estado de ejecución. Si kube-proxy no se está en ejecución, comprueba si hay errores en los registros del pod:

kubectl logs -n kube-system POD-NAME

Nota: Sustituye POD-NAME por el nombre del pod kube-proxy.

Comprobación del valor de WARM_PREFIX_TARGET

Si la delegación de prefijos está activada, comprueba si hay el siguiente mensaje de error en el archivo de registro:

"Error: Setting WARM_PREFIX_TARGET = 0 is not supported while WARM_IP_TARGET/MINIMUM_IP_TARGET is not set. Please configure either one of the WARM_{PREFIX/IP}_TARGET or MINIMUM_IP_TARGET env variable"

Para resolver el error, WARM_PREFIX_TARGET se debe establecer en un valor mayor o igual que 1. Si la delegación de prefijos está activada y WARM_PREFIX_TARGET está establecido en 0, actualiza el valor a al menos 1:

kubectl set env daemonset aws-node -n kube-system WARM_PREFIX_TARGET=1

Comprobación del espacio reservado en la subred

Cuando la delegación de prefijos esté activada, comprueba que las subredes tengan suficientes bloques de CIDR de IP /28 disponibles. Las 16 direcciones IP deben ser contiguas. Si la delegación de prefijos está activada, comprueba si hay el siguiente mensaje de error en el archivo de registro:

"InsufficientCidrBlocks"

Para resolver el error, crea una nueva subred y, a continuación, inicia los pods desde la nueva subred. Utiliza una reserva de CIDR de subred de Amazon EC2 para reservar espacio en una subred con un prefijo asignado. Para obtener más información, consulta Reservas de CIDR de subred.

Comprobación de la configuración de red personalizada

Para determinar si las redes personalizadas están activas para tu clúster de Amazon EKS, ejecuta el siguiente comando:

kubectl describe pod -n kube-system $(kubectl get pods -n kube-system -l k8s-app=aws-node -o jsonpath='{.items[0].metadata.name}')

Si esta variable se establece en True, la red personalizada está activa.

Si la red personalizada está activa, los CRD de ENIConfig deben configurarse correctamente para que coincidan con los requisitos de red del clúster. Ejecuta el siguiente comando para recuperar una lista e inspeccionar todos los CRD de ENIConfig:

kubectl get ENIConfig -A -o yaml

Para describir un ENIConfig específico, ejecuta el siguiente comando:

kubectl describe ENIConfig eni-config-name

Nota: Sustituye Eni-config-name por el nombre de tu ENIConfig.

Comprueba que cada ENIConfig tenga la configuración correcta de subred y grupo de seguridad para cada zona de disponibilidad.

Confirma que la subred especificada en la ENIConfig coincide con la zona de disponibilidad de tus nodos de trabajo.

Para obtener más información sobre las redes personalizadas, consulta Despliegue de pods en subredes alternativas con redes personalizadas.

Configuración de la resolución de conflictos para evitar restauraciones

Cuando utilices AWS Cloud Development Kit (AWS CDK), AWS CloudFormation o eksctl con complementos administrados, define un método de resolución de conflictos para evitar restauraciones.

Los métodos correctos son NONE, OVERWRITE o PRESERVE.

• Si no se define ningún método, el valor predeterminado es NONE. Cuando el sistema detecta conflictos, la actualización de la pila de CloudFormation se restaura y no se realiza ningún cambio.
• Para establecer la configuración predeterminada de los complementos, utiliza el método de sobrescritura. Debes usar OVERWRITE cuando pases de complementos autoadministrados a complementos administrados por Amazon EKS.
• Utiliza el método PRESERVE cuando utilices configuraciones definidas personalizadas, como WARM_IP_TARGET o redes personalizadas.

Para obtener más información sobre la configuración de los métodos de resolución de conflictos, consulta Actualización de un complemento de Amazon EKS.