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.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 Pod 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 dejaron de estar disponibles hace algún 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 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 quitaron storedVersions del estado de la CRD
Kube-Addon-Manager en GKE quita de forma incorrecta 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 Service y, luego, se quita uno de los puertos configurados del Service, el controlador de NEG dejará de administrar los extremos del NEG. En adición a 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 Gateways 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 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 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 del 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 problemas con el tráfico UDP 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 de 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:
|
||
Condición de carrera de la puerta de enlace de preparación del NEGEn ciertas condiciones, es posible que las puertas de preparación muestren un estado de preparación de "falso positivo" antes de que la verificación de estado de entrada informe un estado en buen estado, lo que genera eventos de error como los siguientes 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 generar 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 ejecute 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 del pod 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
|
||
No se respeta initialDelaySeconds en el readinessProbe del PodQuizás esperes que el balanceador de cargas nativo del contenedor respete la configuración de |