En esta página se enumeran los problemas conocidos de las redes de GKE. Esta página está dirigida a administradores y arquitectos que gestionan 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 (SLOs) o las aplicaciones fallan.
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:
También puedes buscar tu problema:
| Versión(es) identificada(s) | Versión(es) corregida(s) | Problema y solución alternativa |
|---|---|---|
| 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
Fuga de direcciones IP de pods en nodos con GKE Dataplane V2En los clústeres con GKE Dataplane V2 habilitado, puede que se agoten las direcciones IP de los pods en los nodos. Este problema se debe a un error de tiempo de ejecución del contenedor que puede provocar fugas de direcciones IP asignadas cuando los pods sufren errores transitorios de CNI durante la creación. El problema se produce cuando el nodo del clúster de GKE se actualiza o se crea con una de las siguientes versiones de GKE:
Cuando se produce este problema, los nuevos pods programados 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 y 1.33 |
|
Interrupciones de los balanceadores de carga de entrada y de servicio en clústeres con una red antiguaUna incompatibilidad con las redes antiguas provoca que los backends de un balanceador de carga gestionado con GKE desplegado mediante Ingress o Service se desconecten. Como resultado, el balanceador de carga no tiene ningún backend activo, lo que a su vez provoca que se rechacen todas las solicitudes entrantes a esos balanceadores de carga. El problema afecta a los clústeres de GKE que usan una red antigua y tienen la versión 1.31 o una posterior. Para identificar los clústeres de GKE con una red antigua, ejecuta el siguiente comando:
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"
Un clúster con una red antigua obtendrá una salida vacía para este comando. Solución alternativa: Las redes antiguas están obsoletas desde hace algún tiempo, por lo que la solución recomendada es migrar tu red antigua a una red de VPC. Para ello, puedes convertir una red antigua que contenga clústeres de GKE. Si no puedes realizar esta migración en este momento, ponte en contacto con el equipo de Atención al Cliente de Google Cloud. |
| 1.30, 1.31 y 1.32 |
|
Los nodos recién creados no se añaden a los balanceadores de carga internos de capa 4Google Cloud Es posible que los balanceadores de carga que se crean para los servicios 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 haya escalado a cero nodos y, a continuación, se haya vuelto a escalar a uno o más nodos. Soluciones alternativas:
|
| 1.31 y 1.32 |
|
Problemas con la API Gateway debido a que se han eliminado storedVersions del estado de CRD
Kube-Addon-Manager en GKE elimina incorrectamente Tu clúster puede estar en riesgo si cumple todas las condiciones siguientes:
Solución alternativa: La solución alternativa recomendada es retrasar las actualizaciones del clúster hasta que se resuelva el problema.
Si necesitas actualizar la versión del clúster, debes actualizar la versión de almacenamiento de todos los CRDs de la API Gateway afectados a
|
| 1.32 |
|
Los pods nuevos no se inicializan y se quedan en el estado 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 con versiones comprendidas entre la 1.32 y la 1.32.3-gke.1170000 (sin incluir), que se crearon con las versiones 1.31 o 1.32 de GKE. La causa principal es que una estructura de datos en memoria que mantenía una colección de identidades de Cilium asignadas no se sincronizaba 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 medida de mitigació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,1.31 |
El controlador de NEG deja de gestionar los endpoints cuando se elimina el puerto del servicioCuando el controlador de NEG se configura para crear un NEG independiente para un servicio y uno de los puertos configurados se elimina posteriormente del servicio, el controlador de NEG dejará de gestionar los endpoints 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 elimina un puerto de un servicio con una anotación de NEG independiente, también se debe actualizar la anotación para eliminar el puerto en cuestión. |
|
| 1,28 |
Error de configuración de TLS de la pasarelaHemos detectado un problema al configurar TLS para las pasarelas en clústeres que ejecutan la versión 1.28.4-gke.1083000 de GKE. Esto afecta a las configuraciones de TLS que usan un recurso SSLCertificate o un recurso CertificateMap. Si actualizas un clúster con pasarelas, las actualizaciones que se hagan en la pasarela fallarán. En el caso de las nuevas pasarelas, los balanceadores de carga no se aprovisionarán. Este problema se solucionará en una próxima versión de parche de GKE 1.28. |
|
| 1.27, 1.28 y 1.29 |
|
Errores intermitentes al establecer la conexiónLos clústeres de las versiones del plano de control 1.26.6-gke.1900 y posteriores pueden experimentar fallos intermitentes en el establecimiento de la conexión. Las probabilidades de que se produzcan fallos son bajas y no afectan a todos los clústeres. Los fallos deberían desaparecer por completo al cabo de unos días desde la aparición 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 tener problemas de resolución de DNS. |
| 1,28 | 1.28.3-gke.1090000 o posterior |
Network Policy elimina una conexión debido a una búsqueda de seguimiento de conexiones incorrectaEn los clústeres con GKE Dataplane V2 habilitado, cuando un pod cliente se conecta a sí mismo mediante un servicio o la dirección IP virtual de un balanceador de carga de red interno de tipo pasarela, 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 del pod se aplica de forma incorrecta al paquete. El impacto de este problema depende del número de pods configurados para el servicio. Por ejemplo, si el servicio tiene un pod de backend, la conexión siempre falla. Si el servicio tiene dos pods backend, la conexión falla el 50% de las veces. Solución alternativa:
Para mitigar este problema, configure los valores de |
| 1.27,1.28 |
|
Paquetes descartados en flujos de conexión en bucleEn los clústeres con GKE Dataplane V2 habilitado, cuando un pod crea una conexión TCP a sí mismo mediante un servicio, de forma que el pod sea tanto el origen como el destino de la conexión, el seguimiento de conexiones eBPF de GKE Dataplane V2 registra incorrectamente los estados de la conexión, lo que provoca que se filtren entradas de conntrack. Cuando se ha filtrado una tupla de conexión (protocolo, IP de origen o destino y puerto de origen o destino), las nuevas conexiones que usen la misma tupla de conexión pueden provocar que se descarten los paquetes de retorno. Solución alternativa: Usa una de las siguientes soluciones alternativas:
|
| Anterior a 1.31.0-gke.1506000 | 1.31.0-gke.1506000 y versiones posteriores |
La red de tipo dispositivo en GKE con varias redes falla con nombres de red largosNo se puede crear el clúster y se produce el siguiente error:
Solución alternativa: Limita la longitud de los nombres de objetos de red escritos en el dispositivo a 41 caracteres como máximo. Se compone la ruta completa de cada socket de dominio UNIX, incluido el nombre de red correspondiente. Linux tiene una limitación en la longitud de las rutas de sockets (menos de 107 bytes). Teniendo 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 de los pods
|
| 1.31 y 1.32 |
|
Tráfico UDP dañado entre pods que se ejecutan en el mismo nodoLos clústeres con la visibilidad intranodo habilitada pueden experimentar problemas con el tráfico UDP entre los pods que se ejecutan en el mismo nodo. El problema se produce 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. Resolució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 clústeres con menos de 3 nodos en total y una vCPU insuficienteLos pods calico-typha y calico-node no se pueden programar en clústeres que cumplan todas las condiciones siguientes: menos de 3 nodos en total, cada nodo tiene 1 o menos vCPUs asignables y la 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 eventos que provoquen el reinicio del plano de control, como una actualización del clúster. Esto ocurre porque MCG se basa en un mecanismo antiguo para la detección de grupos de puntos finales de red (NEG) que informa incorrectamente de que no hay backends cuando los nodos de un clúster zonal no están disponibles temporalmente durante el reinicio del plano de control. Esto provoca que el balanceador de carga elimine todos los back-ends, lo que conlleva una pérdida de tráfico. Soluciones alternativas:
|