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:
O bien, busca tu problema:
| Versiones identificadas | Versiones corregidas | Problema y solución |
|---|---|---|
| 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
Filtración de direcciones IP de Pods en nodos con GKE Dataplane V2Los clústeres con GKE Dataplane V2 habilitado pueden experimentar el agotamiento de las direcciones IP de Pods en los nodos. Este problema se debe a un error del entorno de ejecución del contenedor que puede filtrar direcciones IP asignadas cuando los Pods experimentan errores transitorios de CNI durante la creación. 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:
Cuando ocurre este problema, los Pods nuevos que se programan en el nodo afectado no se inician y muestran un mensaje de error similar al siguiente: Solución alternativa: Para mitigar este problema, puedes aplicar el DaemonSet de mitigación al clúster para limpiar los recursos de IP filtrados: apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 seccompProfile: type: RuntimeDefault automountServiceAccountToken: false containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerd |
|
| 1.31, 1.32 y 1.33 |
|
Interrupciones de los balanceadores de cargas de entrada y de servicio en clústeres con una red heredadaUna 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 están obsoletas desde 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 |
|
Los nodos recién creados no se agregan a los balanceadores de cargas internos de capa 4Es posible que los balanceadores de cargas de Google Cloud que se crean para los objetos Service LoadBalancer internos no incluyan los nodos creados recientemente 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:
|
| 1.31 y 1.32 |
|
Problemas de la API de Gateway debido a que se quitó storedVersions del estado de CRD
Kube-Addon-Manager en GKE quita de forma incorrecta el Es posible que tu clúster esté en riesgo si cumple con todas las siguientes condiciones:
Solución alternativa: La solución alternativa recomendada es retrasar las actualizaciones del clúster hasta que se resuelva el problema.
Como alternativa, si necesitas actualizar la versión del clúster, debes actualizar la versión de almacenamiento de todas las CRD de la API de Gateway afectadas a
|
| 1.32 |
|
Los Pods nuevos no se inicializan y se quedan atascados en ContainerCreating
No se pueden crear Pods nuevos y se quedan en el estado Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded El problema afecta a los clústeres de GKE en versiones entre la 1.32 y la anterior a la 1.32.3-gke.1170000, que se crearon en las versiones 1.31 o 1.32 de GKE. La causa raíz es que una estructura de datos en la memoria que mantenía una colección de identidades de Cilium asignadas no se sincronizó correctamente con el estado del servidor de la API de Kubernetes.
Para confirmar la versión de GKE que se usó para crear el clúster, puedes consultar el recurso gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
Si el clúster de GKE tiene habilitado el registro, el contenedor resource.type="k8s_container" resource.labels.container_name="cilium-agent" Solución alternativa: Una solución temporal es reiniciar el plano de control. Para ello, actualiza el plano de control a la misma versión que ya está ejecutando: gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 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 servicioCuando 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 enlaceIdentificamos 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 |
|
Fallas intermitentes en el establecimiento de la conexiónEs 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. Los errores deberían detenerse por completo después de unos días desde el inicio del síntoma. |
| 1.27, 1.28 y 1.29 |
|
Problemas de resolución de DNS con Container-Optimized OSEs 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 incorrectaEn 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 |
| 1.27 y 1.28 |
|
Pérdida de paquetes para los flujos de conexión en horquillaEn 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:
|
| Anterior a la versión 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 largosLa creación del clúster falla con el siguiente error:
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 |
| 1.27, 1.28, 1.29 y 1.30 |
|
Problemas de conectividad para los Pods
|
| 1.31 y 1.32 |
|
Tráfico UDP interrumpido entre Pods que se ejecutan en el mismo nodoEs 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:
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.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 virtualesLos 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:
|
|
Interrupciones de Multi-Cluster Gateway (MCG) en clústeres zonales durante las actualizaciones del plano de controlLas implementaciones que usan Multi-Cluster Gateway (MCG) en clústeres zonales de GKE pueden experimentar interrupciones con errores "503" durante los eventos que provocan un reinicio del plano de control, como una actualización del clúster. Esto ocurre porque MCG se basa en un mecanismo heredado para el descubrimiento de grupos de extremos de red (NEG) que informa de forma incorrecta que no hay backends cuando los nodos de un clúster zonal dejan de estar disponibles temporalmente durante el reinicio del plano de control. Esto hace que el balanceador de cargas quite todos los backends, lo que provoca la pérdida de tráfico. Soluciones alternativas:
|