¿Cómo soluciono los problemas comunes relacionados con los errores de actualización de grupos de nodos de Amazon EKS?

Breve descripción

Al iniciar una actualización de un grupo de nodos administrado, Amazon EKS actualiza automáticamente los nodos. Si utiliza una AMI optimizada para Amazon EKS, Amazon EKS aplica automáticamente los parches de seguridad y las actualizaciones del sistema operativo más recientes a sus nodos.

Durante este proceso de actualización, es posible que aparezcan alguno de los siguientes errores. Siga los pasos de solución de problemas correspondientes al error que encuentre. Para obtener más información sobre los errores de actualización, consulte Comportamiento de actualización de nodos administrados.

Solución

Error de actualización a causa de PodEvictionFailure

El siguiente error indica que PodEvictionFailure bloquea la actualización:

«Error message: Reached max retries while trying to evict pods from nodes in node group».

Si los pods no salen del nodo en un plazo de 15 minutos y no hay ningún indicador de que se haya forzado, se produce el error PodEvictionFailure en la actualización.

A continuación se muestran los motivos del error PodEvictionFailure:

PDB (presupuesto de interrupción de pods) agresivo

El PDB agresivo se define en el pod cuando hay varios PDB que apuntan al mismo pod.

El PDB indica la cantidad de interrupciones que se pueden tolerar en un momento determinado para una clase de pod (o un «presupuesto de errores»). Cuando una interrupción voluntaria provoca que los pods de un servicio sean inferiores al presupuesto, la operación se detiene hasta que pueda mantener el presupuesto. El evento de drenaje de nodos se detiene temporalmente hasta que haya más pods disponibles, de modo que no se sobrepase el presupuesto al expulsar los pods. Para obtener más información, consulte Interrupciones en el sitio web de Kubernetes.

Para confirmar que el grupo de nodos administrado se actualiza sin problemas, debe eliminar temporalmente los presupuestos de interrupción de pods o utilizar la opción de forzar para actualizar. Esta opción no respeta los presupuestos de interrupción de pods. En su lugar, esta opción fuerza el reinicio de los nodos para implementar las actualizaciones.

Nota: Si la aplicación está basada en Quorum, la opción de forzar puede hacer que la aplicación no esté disponible temporalmente.

Ejecute el siguiente comando para confirmar que ha configurado los PDB en el clúster:

$ kubectl get pdb --all-namespaces

O bien, si ha activado el registro de auditoría en la consola de Amazon EKS, siga estos pasos:

1. En la pestaña Clústeres, elija el clúster deseado (por ejemplo, rpam-eks-qa2-control-plane) de la lista.

2. En la pestaña Registro, elija Auditoría. Esta acción lo redirige a la consola de Amazon CloudWatch.

3. En la consola de CloudWatch, elija Registros. A continuación, elija Log Insights y ejecute la siguiente consulta:

   fields @timestamp, @message| filter @logStream like "kube-apiserver-audit"
   | filter ispresent(requestURI)
   | filter objectRef.subresource = "eviction"
   | display @logStream, requestURI, responseObject.message
   | stats count(*) as retry by requestURI, responseObject.message

4. Seleccione Personalizado para identificar la fecha de la actualización. Si se produce un error en la actualización del grupo de nodos a causa de un PDB agresivo, resposeObject.message describe el motivo del error de expulsión de los pods.

5. Si la causa del error es el PDB, modifíquelo con el siguiente comando. A continuación, vuelva a actualizar el grupo de nodos:

   $ kubectl edit pdb pdb_name;

Despliegue que tolera todos los taints

Después de expulsar todos los pods, el nodo queda vacío a causa de su propiedad taint en los pasos anteriores. Sin embargo, si el despliegue tolera todos los taints, es más probable que el nodo no esté vacío, lo que provocará un error de expulsión de los pods. Para obtener más información, consulte Taints and tolerations en el sitio web de Kubernetes.

No se pudo actualizar debido a una versión de lanzamiento no válida

Si tiene una versión de lanzamiento que no es válida, es posible que reciba el siguiente error:

«Error message: Requested release version 1.xx is not valid for kubernetes version 1.xx».

Para resolver este problema, vuelva a ejecutar el comando de actualización. Este comando actualiza los grupos de nodos a la misma versión que la versión de Kubernetes del plano de control:

eksctl upgrade nodegroup --name=test --cluster=test --kubernetes-version=1.xx

Nota: Sustituya la versión 1.xx por la versión compatible con el plano de control de Amazon EKS.

Error de actualización a causa de problemas de estado del grupo de nodos

Si su grupo de nodos tiene problemas de estado, un error de actualización devuelve el siguiente error:

«Error message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]».

Esto indica que el grupo de escalamiento automático del grupo de nodos no puede encontrar la versión esperada de su plantilla de lanzamiento de Amazon Elastic Compute Cloud (Amazon EC2). Este error se produce si ha modificado o eliminado manualmente la versión de la plantilla asociada al grupo de nodos. Esta plantilla de lanzamiento hace que EKS muestre el grupo de nodos como degradado.

Si aún no ha eliminado la plantilla de lanzamiento, vuelva a cambiar manualmente la versión de la plantilla de lanzamiento del grupo de escalamiento automático a la versión adecuada. Esta acción devuelve el grupo de nodos a un estado correcto y activo. Ahora puede volver a iniciar el proceso de actualización.

La actualización ha fallado porque los nuevos nodos no se unen al grupo de nodos

Este problema se produce si los nuevos nodos del grupo de nodos no pueden unirse al clúster. Como resultado, el grupo de nodos vuelve a su versión anterior. En este caso, es posible que aparezca el siguiente error:

«NodeCreationFailure
Couldn't proceed with upgrade process as new nodes are not joining node group ng-backend».

Existen varios motivos por los que los nodos actualizados no pueden unirse al clúster:

Ha modificado una regla de grupo de seguridad que usa el grupo de nodos existente

Compruebe que las reglas de salida del grupo de seguridad del nodo permiten el acceso del puerto 443 al grupo de seguridad del clúster.

El grupo de seguridad del clúster no permite el tráfico desde el grupo de seguridad del nodo

Compruebe que las reglas de entrada del grupo de seguridad del clúster permiten el acceso al puerto 443 desde el grupo de seguridad del nodo. Para obtener más información, consulte Requisitos y consideraciones sobre grupos de seguridad de Amazon EKS.

Ha creado un grupo de nodos con una plantilla de lanzamiento personalizada

Si va a actualizar una plantilla de lanzamiento personalizada, la nueva versión de la plantilla debe tener los datos de usuario correctos. Además, si usa una AMI personalizada, asegúrese de haber configurado correctamente la AMI para unirse al clúster.

Para solucionar problemas con las plantillas de lanzamiento, cree un nuevo grupo de nodos con la misma plantilla de lanzamiento. Asegúrese de que la plantilla utilice la versión más reciente de la AMI personalizada. A continuación, compruebe si el nodo se une correctamente al clúster. Si el nodo no se une al clúster, conéctese a la instancia del nodo con SSH y compruebe los registros de kubelet.

Faltan permisos de IAM

Compruebe si el rol de AWS Identity and Access Management (IAM) del grupo de nodos tiene los permisos necesarios.

Las ACL deniegan el tráfico

La lista de control de acceso (ACL) de la subred del nodo puede denegar el tráfico saliente del puerto 443 o el tráfico entrante de un puerto efímero. Asegúrese de permitir estas reglas para la subred del nodo.

Del mismo modo, la ACL de la subred del clúster podría denegar el tráfico entrante del puerto 443. Asegúrese de permitir este tráfico en las subredes del clúster.

Los nuevos nodos no pueden agregar un complemento

Es posible que un complemento CNI o kube-proxy de Amazon Virtual Private Cloud (Amazon VPC) no aparezca en los nodos nuevos. Para obtener más información, consulte How do I resolve kubelet or CNI plugin issues for Amazon EKS?

Una subred tiene problemas de conectividad

Es posible que la subred en la que Amazon EKS crea los nodos no tenga conectividad con los puntos de conexión necesarios. Estos puntos de conexión pueden incluir Amazon Elastic Container Registry (Amazon ECR), Amazon Simple Storage Service (Amazon S3) o Amazon EC2. La conectividad puede fallar a través de Internet o de los puntos de conexión de VPC. En el caso de los puntos de conexión de VPC, compruebe los grupos de seguridad de los nodos y los puntos de conexión para asegurarse de que permiten el tráfico necesario. Si usa una puerta de enlace de NAT o una puerta de enlace de Internet, compruebe que la regla de enrutamiento sea correcta en la tabla de enrutamiento de la subred. Además, compruebe que existe la puerta de enlace de NAT o la puerta de enlace de Internet correspondiente.