Soluciona problemas de grupos de nodos de Windows Server

Cuando ejecutas grupos de nodos de Windows Server en Google Kubernetes Engine (GKE), es posible que encuentres problemas, como que los Pods no se inicien, errores al extraer imágenes de contenedores de Windows, problemas de conectividad de red o nodos que no se inician.

Usa este documento para diagnosticar y resolver estos problemas comunes, y mantener tus aplicaciones basadas en Windows en funcionamiento de manera confiable.

Esta información es importante para los operadores y administradores de plataformas que administran clústeres de GKE con grupos de nodos de Windows, y para los desarrolladores de aplicaciones que implementan y ejecutan aplicaciones basadas en Windows en GKE. Para obtener más información sobre las funciones comunes y las tareas de ejemplo a las que hacemos referencia en el Google Cloud contenido, consulta Funciones y tareas comunes de los usuarios de GKE.

Para obtener orientación más general, consulta la documentación de Kubernetes sobre la depuración de Pods y servicios.

Problemas de nodos de containerd

Para obtener información sobre cómo resolver problemas si usas una imagen de nodo de containerd, consulta Problemas en grupos de nodos de Windows Server.

Los pods de Windows no se inician

Las incompatibilidades entre la imagen base y las versiones del SO host de Windows Server pueden impedir que se inicien los Pods.

Síntomas

  • Los pods de Windows no se inician.
  • El nodo informa el estado NotReady.

Causa

La imagen de contenedor se compiló en una imagen base de Windows anterior que no es compatible con la versión de Windows Server del nodo host.

Solución

Compila tus imágenes de contenedor con imágenes base de Windows que incluyan actualizaciones de Windows de marzo de 2020 o versiones posteriores. Para obtener más información sobre la compatibilidad de contenedores de Microsoft, consulta la documentación de Microsoft sobre el problema de incompatibilidad de contenedores de Windows Server de febrero de 2020.

Errores de extracción de imágenes

Las imágenes de contenedor de Windows Server suelen ser mucho más grandes que las imágenes de Linux, lo que puede provocar tiempos de espera.

Síntomas

  • Mensajes de error como Failed to pull image o context cancelled.
  • Los Pods muestran el estado ErrImagePull.

Causa

Las imágenes de contenedor de Windows Server y las capas individuales que las componen pueden ser grandes. Su tamaño puede hacer que el agente kubelet agote el tiempo de espera y falle cuando se descarguen y extraigan las capas del contenedor.

Solución

Para resolver estas fallas de extracción de imágenes, prueba las siguientes soluciones:

  • Aumenta la CPU del nodo: La extracción de contenedores se ejecuta en paralelo en todos los núcleos, por lo que los tipos de máquinas con más núcleos reducen el tiempo de extracción general.
  • Optimiza las capas de imágenes: Para mejorar el almacenamiento en caché de las capas de Docker y hacer que cuando se vuelva a intentar la extracción de imágenes haya más probabilidades de que se realice sin problemas, divide las capas de aplicación en capas más pequeñas. Para obtener más información, consulta Imágenes y capas en la documentación del controlador de almacenamiento de Docker.
  • Usa extracciones manuales: Conéctate a los nodos de Windows Server y ejecuta el comando docker pull de forma manual en las imágenes de contenedor antes de crear los Pods.

Para obtener asesoramiento más general, consulta Soluciona problemas de extracciones de imágenes.

Familia de imágenes que alcanzó el final del ciclo de vida

GKE quita periódicamente las familias de imágenes de Windows Server más antiguas cuando finaliza la asistencia del proveedor. Esta baja impide la creación de grupos de nodos con esas imágenes.

Síntomas

Cuando creas un grupo de nodos con una imagen de Windows, recibes un error similar al siguiente:

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer
versions are still available.

Causa

La familia de imágenes de Windows Server seleccionada ya no es compatible con GKE.

Solución

Elige una imagen de Windows que esté disponible y sea compatible. Puedes encontrar la fecha de finalización de la asistencia para las imágenes de nodo de Windows en GKE mediante el comando gcloud container get-server-config, como se describe en Asigna versiones de GKE y Windows.

Tiempo de espera durante la creación del grupo de nodos

Inicializar una gran cantidad de nodos de Windows Server de forma simultánea puede causar tiempos de espera.

Síntomas

Las operaciones de creación de grupos de nodos agotan el tiempo de espera antes de completarse.

Causa

La creación del grupo de nodos puede agotar el tiempo de espera si creas una gran cantidad de nodos (por ejemplo, 500) y es el primer grupo de nodos del clúster que usa una imagen de Windows Server.

Solución

Reduce el recuento inicial de nodos cuando crees el grupo de nodos. Después de crear el grupo de nodos, puedes aumentar la cantidad de nodos.

Los nodos de Windows se vuelven NotReady con el error: PLEG is not healthy

Programar rápidamente varios contenedores de Windows en un solo nodo puede sobrecargar el generador de eventos de ciclo de vida de Pod (PLEG).

Síntomas

  • Los nodos de Windows ingresan al estado NotReady.
  • Los eventos o registros muestran un mensaje de error PLEG is not healthy.

Causa

Se produce un problema conocido de Kubernetes cuando se inician varios Pods con rapidez en un solo nodo de Windows.

Solución

Para recuperarte de las fallas de PLEG y evitar que vuelvan a ocurrir, haz lo siguiente:

  • Reinicia el nodo de Windows Server afectado.
  • Limita la creación de Pods de Windows a no más de un Pod cada 30 segundos.

TerminationGracePeriod incoherente

Las diferencias entre los temporizadores de apagado de contenedores de Windows y la configuración del período de gracia de Kubernetes pueden provocar que los contenedores finalicen de forma inesperada.

Síntomas

Windows finaliza los contenedores de forma forzosa antes de que venza la duración configurada en el campo TerminationGracePeriodSeconds.

Causa

El tiempo de espera interno del sistema de Windows para el contenedor difiere del período de gracia especificado en el manifiesto de Pod de Kubernetes.

Solución

Modifica el tiempo de espera del contenedor de Windows si editas las claves de registro locales del contenedor en el tiempo de compilación de la imagen. Alinea el campo TerminationGracePeriodSeconds en tu manifiesto de Pod según corresponda.

Problemas de conexión de red

Las discrepancias en el tamaño de la unidad de transmisión máxima (MTU) entre las redes de contenedores de Windows Server y las Google Cloud redes pueden provocar la pérdida de paquetes.

Síntomas

Las aplicaciones que se ejecutan dentro de los contenedores de Windows Server experimentan fallas de conectividad de red o pérdida de paquetes.

Causa

Las redes de contenedores de Windows Server suelen suponer una MTU de red de 1500, que no es compatible con Google Cloud's MTU de 1460.

Solución

Configura la MTU de la interfaz de red del contenedor y el valor de MTU de la interfaz de red del nodo de Windows Server en 1460 o menos. Para obtener más información, consulta Problemas conocidos de los contenedores de Windows en la documentación de Compute Engine.

Problemas con el inicio de nodos

Es posible que las instancias nuevas de Windows Server no puedan completar las secuencias de comandos de inicialización o registrarse en el plano de control.

Síntomas

Los nodos de Windows Server no se inicializan o no se unen al clúster.

Causa

Los errores durante la inicialización del nodo impiden que el nodo se inicie o se una al clúster.

Solución

Para identificar qué errores de inicio podrían estar causando el problema, revisa el resultado del puerto en serie del nodo: serial port output:

gcloud compute instances get-serial-port-output NODE_NAME \
    --zone=COMPUTE_ZONE

Reemplaza lo siguiente:

Servicios intermitentes y inaccesibles en nodos de Windows con un clúster que ejecuta la versión 1.24 o anterior

En los clústeres que ejecutan la versión 1.24 o anteriores, reiniciar el componente kube-proxy crea retrasos temporales en el enrutamiento de la red mientras se vuelven a procesar las reglas del balanceador de cargas del servicio de red del host (HNS).

Síntomas

Los servicios son inaccesibles de forma intermitente desde los Pods que se ejecutan en nodos de Windows.

Causa

Para los clústeres de GKE que ejecutan la versión 1.24 o anteriores, si un evento reinicia el componente kube-proxy en un nodo de Windows (por ejemplo, el inicio del nodo, la actualización del nodo o el reinicio manual), el componente debe sincronizar y volver a crear todas las reglas del balanceador de cargas de HNS. Si el clúster tiene una gran cantidad de estas reglas, puede haber un retraso significativo en el procesamiento, que dura alrededor de 30 segundos por regla. Durante este retraso de sincronización, los servicios son inaccesibles de forma intermitente desde los Pods que se ejecutan en ese nodo. Para obtener más información, consulta el problema original en GitHub.

Solución

Actualiza tu plano de control del clúster a la versión 1.25 o posterior. Este comportamiento mejora considerablemente en las versiones más recientes, como se detalla en la solicitud de extracción en GitHub.

¿Qué sigue?