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

Descripción breve

Las versiones más recientes de Amazon EKS también incluyen nuevas versiones de las AMI de Amazon para actualizaciones de grupos de nodos. Los clientes con una carga de trabajo implementada en varios grupos de nodos se enfrentan al desafío de actualizar sus nodos para mantenerse al día con su ciclo de versiones.

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 como parte de la versión de lanzamiento más reciente de la AMI. Para implementar la actualización, AWS Auto Scaling lanza los nodos en todas las zonas de disponibilidad en las que los nodos estén presentes en el grupo de nodos. Este servicio también reequilibra la zona de disponibilidad. Como los nodos existentes solo se agotan una vez, el paso de lanzamiento se lleva a cabo correctamente. La fase de reducción vertical reduce en uno el tamaño máximo y el tamaño deseado del grupo de escalado automático para volver a los valores anteriores a la actualización. Consulte “Fase de reducción vertical” en Comportamiento de actualización de nodos administrados para obtener más información.

Resolución

Durante este proceso de actualización, es posible que aparezcan algunos de los siguientes errores que requieren sus propios pasos de mitigación. Conocer estos problemas con antelación le permite minimizar el tiempo de inactividad. Consulte Comportamiento de actualización de nodos administrados para obtener más información sobre los errores de actualización.

Error de actualización a causa de PodEvictionFailure

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

Este error indica que PodEvictionFailure bloquea la actualización. 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 PodEvictionFailure en la actualización.

A continuación se muestran los motivos del error PodEvictionFailure en la fase de actualización:

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 (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 fuga 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 Clusters (Clústeres), elija el clúster deseado (por ejemplo, rpam-eks-qa2-control-plane) de entre los de la lista.

2.    En la pestaña Logging (Registro), elija Audit (Auditoría). Esto lo redirige a la Consola de Amazon CloudWatch.

3.    En la Consola de CloudWatch, seleccione Logs (Registros). A continuación, elija Log Insights (Información de registro) 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 Custom (Personalizado) en la parte superior derecha 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;

Implementación que tolera todos los taints

Después de expulsar cada pod, el nodo queda vacío a causa de su propiedad taint en los pasos anteriores. Sin embargo, si la implementación 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. Consulte Taints and tolerations (Taints y tolerancias) en el sitio web de Kubernetes para obtener más información.

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

Error Message: Requested release version 1.xx is not valid for kubernetes version 1.xx.

Para resolver este problema, vuelva a ejecutar el comando upgrade (actualizar). 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

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

Este error se produce si ha modificado manualmente el grupo de escalado automático del grupo de nodos para usar una versión diferente de su plantilla de lanzamiento de Amazon Elastic Compute Cloud (Amazon EC2). O bien, puede que haya eliminado la versión de la plantilla asociada al grupo de nodos. El grupo de nodos de EKS utiliza una plantilla de lanzamiento predeterminada que entra en conflicto con la plantilla de lanzamiento del grupo de escalado automático. 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 escalado 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.

---