Problemas conocidos de las herramientas de redes de GKE

Autopilot Estándar

---

En esta página, se enumeran los problemas conocidos de las redes de GKE. Esta página está destinada a administradores y arquitectos que administran el ciclo de vida de la infraestructura tecnológica subyacente y responden a alertas y páginas cuando no se cumplen los objetivos de nivel de servicio (SLO) o fallan las aplicaciones.

Para filtrar los problemas conocidos por versión del producto, selecciona los filtros en los siguientes menús desplegables.

Selecciona tu versión de GKE:

1.32 1.31 1.30 1.29 1.28 1.27

O bien, busca tu problema:

Versiones identificadas	Versiones corregidas	Problema y solución
1.31, 1.32 y 1.33	1.33.1-gke.1107000 y versiones posteriores	Interrupciones de los balanceadores de cargas de entrada y de servicio en clústeres con una red heredada Una incompatibilidad con las redes heredadas hace que se desconecten los backends de un balanceador de cargas administrado por GKE implementado con Ingress o Service. Esto hace que el balanceador de cargas no tenga backends activos, lo que, a su vez, provoca que se descarten todas las solicitudes entrantes a esos balanceadores de cargas. El problema afecta a los clústeres de GKE que usan una red heredada y que ejecutan la versión 1.31 o una posterior. Para identificar los clústeres de GKE con una red heredada, ejecuta el siguiente comando: gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)" Un clúster con una red heredada obtendrá un resultado vacío para este comando. Solución alternativa: Dado que las redes heredadas dejaron de estar disponibles hace un tiempo, la solución preferida es migrar tu red heredada a una red de VPC. Para ello, convierte una red heredada que contenga clústeres de GKE. Si no puedes realizar esta migración en este momento, comunícate con Atención al cliente de Cloud.
1.30, 1.31 y 1.32	1.30.10-gke.1070000 y versiones posteriores 1.31.5-gke.1068000 y versiones posteriores 1.32.1-gke.1002000 y versiones posteriores	Los nodos recién creados no se agregan a los balanceadores de cargas internos de capa 4 Es posible que los balanceadores de cargas Google Cloud que se crean para los objetos Service LoadBalancer internos no incluyan los nodos recién creados en el grupo de instancias de backend. El problema será más visible en un clúster que se redujo a cero nodos y, luego, se volvió a aumentar a uno o más nodos. Soluciones alternativas: Activa la subdivisión de GKE y vuelve a crear el servicio. Nota: La subdivisión de GKE no se puede desactivar una vez que se activa. Crea otro servicio de balanceo de cargas interno. Cuando se sincronice, el grupo de instancias también se corregirá para el servicio afectado. El nuevo servicio se puede quitar después de la sincronización. Agrega y, luego, quita la etiqueta node.kubernetes.io/exclude-from-external-load-balancers de uno de los nodos. Agrega un nodo al clúster. Puedes quitar el nodo después de que el servicio comience a funcionar.
1.27, 1.28, 1.29, 1.30 y 1.31		El controlador de NEG deja de administrar los extremos cuando se quita el puerto del servicio Cuando el controlador de NEG está configurado para crear un NEG independiente para un servicio y, luego, se quita uno de los puertos configurados del servicio, el controlador de NEG dejará de administrar los extremos del NEG. Además de los Services en los que el usuario crea una anotación de NEG independiente, esto también afecta a los Services a los que hacen referencia GKE Gateway, MCI y GKE Multi Cluster Gateway. Solución alternativa: Cuando se quita un puerto de un servicio con una anotación de NEG independiente, también se debe actualizar la anotación para quitar el puerto en cuestión.
1.28		Error de configuración de TLS de la puerta de enlace Identificamos un problema con la configuración de TLS para las puertas de enlace en clústeres que ejecutan la versión 1.28.4-gke.1083000 de GKE. Esto afecta las configuraciones de TLS que usan un SSLCertificate o un CertificateMap. Si actualizas un clúster con Gateways existentes, fallarán las actualizaciones realizadas en el Gateway. En el caso de las puertas de enlace nuevas, no se aprovisionarán los balanceadores de cargas. Este problema se solucionará en una próxima versión de parche de GKE 1.28.
1.27, 1.28 y 1.29	1.26.13-gke.1052000 y versiones posteriores 1.27.10-gke.1055000 y versiones posteriores 1.28.6-gke.1095000 y versiones posteriores 1.29.1-gke.1016000 y versiones posteriores	Fallas intermitentes en el establecimiento de la conexión Es posible que los clústeres en versiones del plano de control 1.26.6-gke.1900 y posteriores experimenten fallas intermitentes en el establecimiento de la conexión. Las probabilidades de fallas son bajas y no afectan a todos los clústeres. Las fallas deberían detenerse por completo después de unos días desde el inicio del síntoma.
1.27, 1.28 y 1.29	1.27.11-gke.1118000 o versiones posteriores 1.28.7-gke.1100000 o versiones posteriores 1.29.2-gke.1217000 o versiones posteriores	Problemas de resolución de DNS con Container-Optimized OS Es posible que las cargas de trabajo que se ejecutan en clústeres de GKE con nodos basados en Container-Optimized OS experimenten problemas de resolución de DNS.
1.28	1.28.3-gke.1090000 o superior	La política de red descarta una conexión debido a una búsqueda de seguimiento de conexión incorrecta En los clústeres con GKE Dataplane V2 habilitado, cuando un Pod de cliente se conecta consigo mismo a través de un Service o la dirección IP virtual de un balanceador de cargas de red de transferencia interno, el paquete de respuesta no se identifica como parte de una conexión existente debido a una búsqueda de conntrack incorrecta en el plano de datos. Esto significa que una política de red que restringe el tráfico de entrada para el Pod se aplica de forma incorrecta en el paquete. El impacto de este problema depende de la cantidad de Pods configurados para el Service. Por ejemplo, si el Service tiene 1 Pod de backend, la conexión siempre falla. Si el Service tiene 2 Pods de backend, la conexión falla el 50% del tiempo. Solución alternativa: Puedes mitigar este problema si configuras port y containerPort en el manifiesto del servicio para que tengan el mismo valor.
1.27 y 1.28	1.28.3-gke.1090000 o superior 1.27.11-gke.1097000 o superior	Pérdida de paquetes para los flujos de conexión en horquilla En los clústeres con GKE Dataplane V2 habilitado, cuando un Pod crea una conexión TCP a sí mismo usando un Service, de modo que el Pod sea la fuente y el destino de la conexión, el seguimiento de conexión de eBPF de GKE Dataplane V2 realiza un seguimiento incorrecto de los estados de conexión, lo que genera entradas de conntrack filtradas. Cuando se filtra una tupla de conexión (protocolo, IP de origen/destino y puerto de origen/destino), las conexiones nuevas que usan la misma tupla de conexión pueden provocar que se pierdan paquetes de retorno. Solución alternativa: Aplica una de las siguientes soluciones: Habilita la reutilización de TCP (keep-alive) para una aplicación que se ejecuta en un Pod que puede comunicarse consigo misma a través de un Service. Esto evita que se emita la marca TCP FIN y se evite que se filtre la entrada de conntrack. Cuando uses conexiones de corta duración, expón el Pod con un balanceador de cargas de proxy, como Gateway, para exponer el Service. Esto hace que el destino de la solicitud de conexión se establezca en la dirección IP del balanceador de cargas, lo que evita que GKE Dataplane V2 realice SNAT a la dirección IP de bucle invertido.
Anterior a 1.31.0-gke.1506000	1.31.0-gke.1506000 y versiones posteriores	La red escrita por el dispositivo en la red múltiple de GKE falla con nombres de red largos La creación del clúster falla con el siguiente error: error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument Solución alternativa: Limita la longitud de los nombres de objetos de red escritos en el dispositivo a 41 caracteres o menos. Se compone la ruta de acceso completa de cada socket de dominio de UNIX, incluido el nombre de red correspondiente. Linux tiene una limitación en la longitud de las rutas de socket (menos de 107 bytes). Después de tener en cuenta el directorio, el prefijo del nombre de archivo y la extensión .sock, el nombre de la red se limita a un máximo de 41 caracteres.
1.27, 1.28, 1.29 y 1.30	1.30.4-gke.1282000 o versiones posteriores 1.29.8-gke.1157000 o versiones posteriores 1.28.13-gke.1078000 o versiones posteriores 1.27.16-gke.1342000 o versiones posteriores	Problemas de conectividad para los Pods hostPort después de la actualización del plano de control Los clústeres con la política de red habilitada pueden experimentar problemas de conectividad con los Pods de hostPort. Además, los Pods recién creados pueden tardar entre 30 y 60 segundos adicionales en estar listos. El problema se activa cuando el plano de control de GKE de un clúster se actualiza a una de las siguientes versiones de GKE 1.30 a 1.30.4-gke.1281999 1.29.1-gke.1545000 a 1.29.8-gke.1156999 1.28.7-gke.1042000 a 1.28.13-gke.1077999 1.27.12-gke.1107000 a 1.27.16-gke.1341999 Solución alternativa: Actualiza o vuelve a crear los nodos inmediatamente después de la actualización del plano de control de GKE.
1.31 y 1.32	1.32.1-gke.1729000 o versiones posteriores 1.31.6-gke.1020000 o versiones posteriores	Tráfico UDP interrumpido entre Pods que se ejecutan en el mismo nodo Es posible que los clústeres con la visibilidad dentro de los nodos habilitada experimenten tráfico UDP interrumpido entre los Pods que se ejecutan en el mismo nodo. El problema se activa cuando el nodo del clúster de GKE se actualiza o se crea con una de las siguientes versiones de GKE: 1.32.1-gke.1729000 o versiones posteriores 1.31.6-gke.1020000 o versiones posteriores La ruta afectada es el tráfico UDP de Pod a Pod en el mismo nodo a través de Hostport o Service. Solución Actualiza el clúster a una de las siguientes versiones corregidas: 1.32.3-gke.1927000 o versiones posteriores 1.31.7-gke.1390000 o versiones posteriores
1.28, 1.29, 1.30 y 1.31		Los Pods de Calico no están en buen estado en clústeres con menos de 3 nodos en total y una cantidad insuficiente de CPUs virtuales Los Pods calico-typha y calico-node no se pueden programar en clústeres que cumplan con todas las siguientes condiciones: menos de 3 nodos en total, cada nodo con 1 o menos CPU virtuales asignables y política de red habilitada. Esto se debe a que no hay suficientes recursos de CPU. Soluciones alternativas: Ajusta la escala a un mínimo de 3 grupos de nodos con 1 nodo que use 1 CPU virtual asignable. Cambia el tamaño de un solo grupo de nodos a un mínimo de 3 nodos con 1 CPU virtual asignable. Usa un tipo de máquina con al menos 2 CPU virtuales asignables en un grupo de nodos con un solo nodo.