Problemas conocidos de las herramientas de redes de GKE

Autopilot Estándar

---

En esta página, se enumeran los problemas conocidos de las herramientas de 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 una versión de producto, selecciona los filtros de los siguientes menús desplegables.

Selecciona tu versión de GKE:

1.30 1.29 1.28 1.27

También puedes buscar tu problema:

Versiones identificadas	Versiones corregidas	Problema y solución
1.30, 1.31 y 1.32		Los nodos recién creados no se agregan a los balanceadores de cargas internos de la capa 4. Es posible que los balanceadores de cargas de Google Cloud que se crean para servicios de LoadBalancer internos no detecten los nodos creados recientemente en el grupo de instancias de backend. El problema será más visible en un clúster que se ajustó a cero nodos y luego se volvió a ajustar 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 después de activarla. Crea otro servicio de balanceador de cargas interno. Cuando se sincronice, el grupo de instancias también se corregirá para el servicio afectado. El servicio nuevo 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 se configura para crear un NEG independiente para un servicio y, más adelante, se quita uno de los puertos configurados del servicio, el controlador de NEG eventualmente dejará de administrar los extremos del NEG. Además de los servicios en los que el usuario crea una anotación de NEG independiente, esto también afecta a los servicios 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 los clústeres que ejecutan la versión 1.28.4-gke.1083000 de GKE. Esto afecta a las configuraciones de TLS que usan un SSLCertificate o un CertificateMap. Si actualizas un clúster con puertas de enlace existentes, fallarán las actualizaciones que se realicen en la puerta de enlace. En el caso de las nuevas puertas de enlace, no se aprovisionarán los balanceadores de cargas. Este problema se solucionará en una próxima versión del parche 1.28 de GKE.
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 con las versiones del plano de control 1.26.6-gke.1900 y versiones 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 de los síntomas.
1.27, 1.28 y 1.29	1.27.11-gke.1118000 o superior 1.28.7-gke.1100000 o superior 1.29.2-gke.1217000 o superior	Problemas con la resolución de DNS en 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 el caso de los clústeres con GKE Dataplane V2 habilitado, cuando un Pod de cliente se conecta a sí 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 Service 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 el caso de 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 con sí 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 por 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 las longitudes de ruta 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 superior 1.29.8-gke.1157000 o superior 1.28.13-gke.1078000 o superior 1.27.16-gke.1342000 o superior	Problemas de conectividad para Pods hostPort después de la actualización del plano de control Es posible que los clústeres con la política de red habilitada experimenten problemas de conectividad con los Pods 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: De 1.30 a 1.30.4-gke.1281999 De 1.29.1-gke.1545000 a 1.29.8-gke.1156999 De 1.28.7-gke.1042000 a 1.28.13-gke.1077999 De 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.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 CPU virtual insuficiente. 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 uno con 1 o menos CPU virtuales asignables y política de red habilitada. Esto se debe a que no hay recursos de CPU suficientes. Soluciones alternativas: Ajusta la escala a un mínimo de 3 grupos de nodos con 1 nodo que use 1 CPU virtual asignable. Modifica el tamaño de un grupo de nodos único 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.