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 del producto, selecciona tus filtros en los siguientes menús desplegables.
Selecciona tu versión de GKE:
También puedes buscar tu problema:
| Versiones identificadas | Versiones corregidas | Problema y solución alternativa |
|---|---|---|
| 1.36 | Corrección en curso |
Fallas de conectividad y Pods del sistema con bucles de fallas en nodos de Windows que usan balanceadores de cargas de capa 4Los clústeres de GKE con grupos de nodos de Windows Server que ejecutan la versión 1.36 pueden experimentar cualquiera de los siguientes problemas:
Este problema se produce cuando los clústeres usan balanceadores de cargas internos de capa 4 sin la subdivisión de GKE o un balanceador de cargas de red de transferencia externo que usa grupos de instancias o de destino más antiguos. En GKE 1.36, el agente invitado de Compute Engine habilita Solución alternativa: Para mitigar este problema, usa uno de los siguientes métodos:
|
| Gráfico de Helm de InferencePool v1.1.0 |
Se ignoró la marca targetPortNumber de InferencePoolEn la versión Solución alternativa: Verifica el puerto después de la instalación: kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \ --context=CLUSTER_CONTEXT Si el puerto es incorrecto, aplica un parche al recurso personalizado kubectl patch inferencepool POOL_NAME --type=merge \ -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \ --context=CLUSTER_CONTEXT |
|
| 1.33, 1.34, 1.35 |
|
Fallas intermitentes de conectividad de Pods o de DNS debido a la eliminación de
|
| 1.29, 1.30, 1.31, 1.32, 1.33 | 1.34 |
El contenedor
|
| 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 un agotamiento de las direcciones IP de Pods en los nodos. Este problema se debe a un error del entorno de ejecución de contenedores que puede filtrar direcciones IP asignadas cuando los Pods encuentran errores transitorios de CNI durante la creación. El problema se activa cuando el nodo del clúster de GKE se actualiza a una de las siguientes versiones de GKE o se crea con una de ellas:
Cuando se produce este problema, los Pods nuevos que se programan en el nodo afectado no se inician y devuelven 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, 1.33 |
|
Interrupciones de los balanceadores de cargas de Ingress y Service 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 que se implementó 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 tienen 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: Como 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 |
|
Los nodos recién creados no se agregan a los balanceadores de cargas internos de capa 4Google Cloud Los balanceadores de cargas que se crean para los objetos Service LoadBalancer internos podrían omitir 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 escalar a uno o más nodos. Soluciones alternativas:
|
| 1.31 y 1.32 |
|
Problemas con la API de Gateway debido a que se quitaron las storedVersions del estado de la 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 condiciones que se indican a continuación:
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 atascados 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 las versiones entre la 1.32 y anteriores 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 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 mitigación temporal es reiniciar el plano de control. Para ello, actualiza el plano de control a la misma versión que ya se está ejecutando: gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 1.27,1.28,1.29,1.30,1.31 |
El controlador de NEG deja de administrar los extremos cuando se quita el puerto del ServiceCuando el controlador de NEG se configura para crear un NEG independiente para un Service y uno de los puertos configurados se quita más adelante del Service, 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 la puerta de enlace de GKE, MCI y la puerta de enlace de varios clústeres de GKE. Solución alternativa: Cuando se quita un puerto de un Service 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 puertas de enlace existentes, las actualizaciones realizadas en la puerta de enlace fallarán. Para las puertas de enlace nuevas, no se aprovisionarán los balanceadores de cargas. Este problema se corregirá en una próxima versión del parche de GKE 1.28. |
|
| 1.27,1.28,1.29 |
|
Fallas intermitentes en el establecimiento de la conexiónLos clústeres en las versiones del plano de control 1.26.6-gke.1900 y posteriores pueden encontrar fallas intermitentes en el establecimiento de la conexión. Las probabilidades de que se produzcan fallas son bajas y no afectan a todos los clústeres. Las fallas deberían detenerse por completo unos días después de la aparición de los síntomas. |
| 1.27,1.28,1.29 |
|
Problemas de resolución de DNS con Container-Optimized OSLas cargas de trabajo que se ejecutan en clústeres de GKE con nodos basados en Container-Optimized OS pueden experimentar 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,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 con un Service, de modo que el Pod sea el origen 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 1.31.0-gke.1506000 | 1.31.0-gke.1506000 y versiones posteriores |
La red de tipo de 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 con tipo de 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 las rutas de acceso de los sockets
(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, 1.30 |
|
Problemas de conectividad para los Pods de
|
| 1.31, 1.32 |
|
Tráfico UDP interrumpido entre Pods que se ejecutan en el mismo nodoLos clústeres con la visibilidad dentro de los nodos habilitada pueden experimentar un tráfico de 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 a una de las siguientes versiones de GKE o se crea con una de ellas:
La ruta afectada es el tráfico de 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, 1.31 |
Los Pods de Calico no están en buen estado en los clústeres con menos de 3 nodos en total y CPU virtuales insuficientesLos Pods calico-typha y calico-node no se pueden programar en clústeres que cumplan con todas las condiciones siguientes: menos de 3 nodos en total, cada nodo con 1 o menos CPU virtuales asignables y la política de red habilitada. Esto se debe a que los recursos de CPU son insuficientes. Soluciones alternativas:
|
|
Interrupciones de la puerta de enlace de varios clústeres (MCG) en clústeres zonales durante las actualizaciones del plano de controlLas implementaciones que usan la puerta de enlace de varios clústeres (MCG) en clústeres zonales de GKE pueden experimentar interrupciones con errores "503" durante eventos que causan 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 cero 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 genera una pérdida de tráfico. Soluciones alternativas:
|
||
Condición de carrera de la puerta de enlace de preparación de NEGEn ciertas condiciones, las puertas de preparación pueden devolver un estado de preparación de "falso positivo" antes de que la verificación de estado de Ingress informe un estado correcto, lo que genera eventos de error como el siguiente en el objeto Ingress:
Este problema hace que el balanceador de cargas informe un error Tener una cantidad relativamente pequeña de Pods (por ejemplo, 2) en comparación con la cantidad de NEG aumentará el riesgo de esta condición de carrera. Se crean NEG para cada región, con un NEG por zona, lo que suele dar como resultado tres NEG. Si hay una cantidad relativamente mayor de Pods, de modo que cada NEG siempre tenga varios Pods antes de que comience la actualización progresiva, es muy poco probable que se active esta condición de carrera. Solución alternativa: La mejor manera de evitar esta condición de carrera es tener más backends en el grupo de extremos de red. Asegúrate de que la estrategia de actualización progresiva esté configurada para garantizar que siempre se esté ejecutando al menos 1 Pod. Por ejemplo, si solo 2 Pods se ejecutan con normalidad, un ejemplo de configuración podría verse de la siguiente manera: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 El ejemplo anterior es una sugerencia. Debes actualizar la estrategia en función de varios factores, como la cantidad de réplicas. |
||
Recolección incompleta de elementos no usados de los balanceadores de cargas nativos del contenedorGKE recolecta elementos no utilizados de los balanceadores de cargas nativos de contenedores cada dos minutos. Si se borra un clúster antes de que los balanceadores de cargas se quiten por completo, tienes que borrar los NEG del balanceador de cargas de forma manual. Solución alternativa: Para revisar los NEG en tu proyecto, ejecuta el comando siguiente: gcloud compute network-endpoint-groups list En el resultado del comando, busca los NEG relevantes. Para borrar un NEG, ejecuta el siguiente comando y reemplaza gcloud compute network-endpoint-groups delete <var>NEG_NAME</var> |
||
Alinea los lanzamientos de carga de trabajo con la propagación de extremosEste problema no se produce en los clústeres que usan los comentarios de preparación de Pods para administrar los lanzamientos de cargas de trabajo. Cuando implementas una carga de trabajo en tu clúster o actualizas una carga de trabajo existente, el balanceador de cargas nativo del contenedor puede demorar más en propagar extremos nuevos que lo que demora en terminar el lanzamiento de la carga de trabajo. Solución alternativa: Configura los valores de las cargas de trabajo
|
||
No se respeta initialDelaySeconds en el readinessProbe del PodQuizás esperes que el balanceador de cargas nativo del contenedor respete la configuración de |