En esta página se enumeran los problemas conocidos 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.
En esta página se enumeran los problemas conocidos de todas las versiones compatibles y de las dos versiones secundarias inmediatamente anteriores a la versión más antigua con asistencia ampliada. Cuando una versión llega al final del periodo de asistencia ampliada, se eliminan todos los problemas de N-2. Por ejemplo, cuando la versión 1.30 llegue al final del periodo de asistencia ampliado, se eliminarán los problemas conocidos específicos de las versiones 1.28 y anteriores.
Si formas parte del Programa para Desarrolladores de Google, guarda esta página para recibir notificaciones cuando se publiquen notas de la versión relacionadas con ella. Para obtener más información, consulta el artículo Páginas guardadas.
Para filtrar los problemas conocidos por versión o categoría de producto, selecciona los filtros en los siguientes menús desplegables.
Selecciona tu versión de GKE:
Selecciona la categoría de tu problema:
También puedes buscar tu problema:
| Categoría | Versión(es) identificada(s) | Versión(es) corregida(s) | Problema y solución alternativa |
|---|---|---|---|
| Operación | Versiones 1.33 anteriores a la 1.33.4-gke.1036000 | 1.33.4-gke.1036000 y versiones posteriores |
Nivel de rendimiento incorrecto para las instancias de Lustre aprovisionadas dinámicamenteAl aprovisionar dinámicamente una instancia de Lustre, se produce un error Solución alternativa: Actualiza el clúster de GKE a la versión 1.33.4-gke.1036000 o a una posterior. Si usas el canal Estable, es posible que aún no haya una versión más reciente disponible. En ese caso, puedes seleccionar manualmente una versión de los canales Habitual o Rápido que incluya la corrección. |
| Operación |
|
1.33.3-gke.1266000 y versiones posteriores |
Error de entrada/salida al cambiar el nombre o mover archivos con el controlador CSI de Cloud Storage FUSESi usas una versión afectada del controlador CSI de Cloud Storage FUSE, es posible que no puedas cambiar el nombre o mover archivos en segmentos de Cloud Storage y que se produzca un error de E/S. Solución alternativa: Añade temporalmente una definición de imagen de sidecar específica al manifiesto de tu pod. En la sección # Add the following block to use the fixed sidecar image - name: gke-gcsfuse-sidecar image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2 Para obtener más información, consulta el manifiesto de Pod en Configurar una imagen privada para el contenedor sidecar. Después de actualizar el clúster a una versión de GKE corregida o posterior, debes eliminar todo el bloque |
| Almacenamiento de registros y monitorización | Todas las versiones | Por determinar |
Condición de carrera en DaemonSets de
|
| Actualizaciones | 1,33 | 1.33.2-gke.1043000 |
Límite de archivos abiertos reducido con containerd 2.0En los grupos de nodos que ejecutan la versión 1.33 de GKE, que usa containerd 2.0, el límite flexible predeterminado de archivos abiertos ( Se trata de un cambio en containerd (consulta la PR #8924 de containerd), donde se ha eliminado Las cargas de trabajo que esperen un límite flexible predeterminado más alto (por ejemplo, las que dependan implícitamente del límite predeterminado anterior) pueden experimentar errores, como errores Solución: Actualiza de una versión anterior del parche 1.33 a la 1.33.2-gke.1043000 o a una posterior. Solución alternativa: Aumenta el límite de archivos abiertos de tus cargas de trabajo con uno de los siguientes métodos:
|
| Actualizaciones | 1.31.5-gke.1169000, 1.32.1-gke.1376000 | 1.31.7-gke.1164000, 1.32.3-gke.1512000 |
El estado CRD.storedVersions no es válido para los CRDs gestionadosAlgunos CRDs gestionados por GKE pueden tener un campo Este problema afecta a los clústeres que cumplen las dos condiciones siguientes:
Solución alternativa: La solución alternativa recomendada es retrasar las actualizaciones del clúster hasta que se resuelva el problema. También puedes añadir estas versiones al campo |
| Operación, registro y monitorización | 1.32.2-gke.1652000, 1.31.6-gke.1221000 y 1.30.10-gke.1227000 |
|
Faltan métricas o el autoescalador de cargas de trabajo no se escalaEs posible que observes lagunas en los datos de las métricas de las versiones afectadas después de que el tamaño del clúster aumente en más de cinco nodos. Este problema también puede afectar a las operaciones de escalado automático. Este problema solo afecta a los clústeres que se hayan actualizado a las versiones afectadas. Los clústeres recién creados deberían funcionar correctamente. Solución alternativa: Si te afecta este problema, puedes cambiar a una versión anterior del parche o actualizar a las versiones corregidas más recientes. |
| Operación |
Límites de tamaño y de archivos adjuntos de Google Cloud HyperdiskNormalmente, un pod que no se puede programar correctamente debido a los límites de adjuntos de volumen de un nodo activa el aprovisionamiento automático de un nuevo nodo. Cuando se programan cargas de trabajo que usan un producto Hyperdisk en un nodo que ejecuta una VM C3, no se produce el aprovisionamiento automático de nodos y el pod se programa en el nodo que ya está lleno. La carga de trabajo se programa en el nodo a pesar de que no haya ningún disco disponible. La carga de trabajo tampoco se inicia debido a un error como el siguiente: AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17] El problema se produce en todos los productos Hyperdisk de las máquinas C3. Los límites de adjuntos de Hyperdisk varían según el número de vCPUs de la VM y el producto Hyperdisk. Para obtener más información, consulta Límites de rendimiento de Hyperdisk. Solución alternativa: Los productos Hyperdisk activan el aprovisionamiento automático en otros tipos de VM. Te recomendamos que elijas una forma que solo admita Hyperdisk. |
||
| Operación | 1.32.3-gke.1927000, 1.32.3-gke.1785000, 1.32.3-gke.1717000, 1.32.3-gke.1440000, 1.32.3-gke.1170000, 1.32.3-gke.1250000, 1.32.3-gke.1671000, 1.32.3-gke.1596000, 1.32.3-gke.1298000 |
gke-metadata-server se cierra por falta de memoria en nodos de TPU o GPUEn los nodos de TPU de GKE (por ejemplo, Solución alternativa: Si observas eventos |
|
| Operación |
|
|
Es posible que los cambios de tamaño de los volúmenes se queden bloqueados debido al estado NodePendingResize de los PVCs.Los clústeres de la versión 1.32 que tengan nodos de la versión 1.31 o anteriores no podrán actualizar el estado de PersistentVolumeClaim durante el cambio de tamaño. Este estado incorrecto impide que se inicien operaciones de cambio de tamaño posteriores, lo que evita que se puedan cambiar de tamaño. Un PVC en este estado tiene un campo Si se creó un PVC mientras tu clúster estaba en una versión afectada, es posible que este problema persista después de que tu clúster se actualice a una versión corregida. En este caso, tu PVC debe parchearse para eliminar el campo Solución alternativa: Las PVCs que se hayan quedado bloqueadas debido a un estado pendiente se pueden parchear para eliminar ese estado. Puedes usar un comando de parche como el siguiente para quitar el estado huérfano: kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}' |
| Operación |
|
|
Es posible que el controlador PDCSI registre demasiada informaciónLos clústeres de GKE en versiones específicas de 1.32 pueden emitir mensajes de registro excesivos del controlador PDCSI. Este exceso de registro consumiría la cuota de la API de escritura de Cloud Logging. Solución alternativa: Puedes reducir este registro excesivo añadiendo un filtro de exclusión. Para evitar que los mensajes de registro se ingieran en Cloud Logging, usa la siguiente consulta:
resource.type="k8s_container"
resource.labels.container_name="gce-pd-driver"
(sourceLocation.file="cache.go" OR "Cannot process volume group")
|
| Operaciones |
|
|
Los pods que intenten montar volúmenes persistentes NFS en nodos de COS que anteriormente tuvieran un montaje de solo lectura (RO) solo se montarán en modo RO.En GKE 1.27 y versiones posteriores, los volúmenes de NFS que usan el controlador CSI interno de Kubernetes solo pueden montar volúmenes persistentes en modo RO después de un montaje RO anterior en el mismo nodo. Solución alternativa: Cambia a una versión anterior de los grupos de nodos a las versiones afectadas |
| Operaciones |
|
|
Los pods que intenten montar volúmenes persistentes de NFS en nodos de Ubuntu no podrán ejecutarse.En GKE 1.32 y versiones posteriores, los volúmenes de NFS que usen el controlador CSI integrado de Kubernetes no podrán montar volúmenes persistentes en nodos de Ubuntu. Cuando esto ocurre, es posible que veas los siguientes mensajes de error: "MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1" Output: Mount failed: mount failed: exit status 127 "Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes" Solución alternativa: Rebaja la versión de los grupos de nodos a la 1.31. |
| Operación | >= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1302000 |
|
Es posible que los pods que usen llamadas al sistema relacionadas con io_uring se queden en estado Terminating
Es posible que los pods que usen llamadas al sistema relacionadas con io_uring entren en el estado D (suspensión de disco), también llamado TASK_UNINTERRUPTIBLE, debido a un error en el kernel de Linux. Los procesos en estado D no se pueden activar mediante señales, incluida
Cuando un pod se ve afectado por este problema conocido, es posible que sus contenedores no se cierren correctamente. En los registros de containerd, es posible que veas mensajes repetidos similares al siguiente:
o
Estos síntomas indican que hay procesos dentro del contenedor que están bloqueados en un estado de suspensión ininterrumpible (estado D), lo que impide que el pod finalice correctamente.
Las cargas de trabajo que usan io_uring directamente o que lo usan indirectamente a través de un tiempo de ejecución de lenguaje como NodeJS pueden verse afectadas por este problema conocido. Las cargas de trabajo afectadas tienen un proceso en el estado D (suspensión de disco) en el archivo Solución alternativa: Actualiza los nodos del clúster a una versión corregida o posterior. |
| Operación | 1.28, 1.29, 1.30, 1.31 |
|
Las cargas de trabajo que usan la transmisión de imágenes fallan con errores de autenticaciónUn error en la función de streaming de imágenes puede provocar que las cargas de trabajo fallen cuando se cumplan una serie de condiciones específicas mientras el contenedor lee archivos. Los mensajes de error relacionados con fallos de autenticación pueden aparecer en el registro de gcfsd.
Para comprobar si te afecta, busca en los registros con esta consulta:
La presencia de estos errores indica que los nodos se ven afectados. Si te afecta este problema, puedes actualizar tus grupos de nodos a una versión de GKE con el parche aplicado. |
| Operación |
|
|
Aumento de las tasas de desalojo de pods en las versiones 1.30 y 1.31 de GKE
Algunas versiones de GKE 1.30 y GKE 1.31 que usan COS 113 y COS 117, respectivamente, tienen kernels que se han compilado con la opción
La opción de configuración Es posible que no siempre veas una tasa de desalojo de pods inusual, ya que este problema depende del patrón de uso de memoria de la carga de trabajo. Existe un mayor riesgo de que kubelet expulse pods de cargas de trabajo que no hayan definido un límite de memoria en el campo de recursos. Esto se debe a que las cargas de trabajo pueden solicitar más memoria de la que kubelet indica que está disponible. Si observas un mayor uso de memoria de una aplicación después de actualizar a las versiones de GKE mencionadas sin hacer ningún otro cambio, es posible que te veas afectado por la opción del kernel.
Para comprobar si hay tasas de desalojo de pods inusuales, analiza las siguientes métricas con el explorador de métricas:
Puedes usar las siguientes consultas de PromQL. Sustituye los valores de
max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))
sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))
Si observas picos inusuales en el uso de la memoria que superan la memoria solicitada, es posible que la carga de trabajo se expulse con más frecuencia. SoluciónSi no puedes actualizar a las versiones corregidas y estás en un entorno de GKE en el que puedes desplegar pods con privilegios, puedes inhabilitar la opción LRU multigeneracional mediante un DaemonSet.
Una vez que el DaemonSet se esté ejecutando en todos los grupos de nodos seleccionados, el cambio se aplicará inmediatamente y el cálculo del uso de memoria de kubelet volverá a la normalidad. |
| Operación | 1.28, 1.29, 1.30, 1.31 |
|
Los pods se quedan en el estado TerminatingUn error en el tiempo de ejecución del contenedor (containerd) puede provocar que los pods y los contenedores se queden bloqueados en el estado Terminating con errores similares a los siguientes: OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
Si te afecta este problema, puedes actualizar tus nodos a una versión de GKE con una versión corregida de containerd. |
| Operación | 1.28 y 1.29 |
|
El streaming de imágenes falla debido a enlaces simbólicosUn error en la función de transmisión de imágenes puede provocar que los contenedores no se inicien. Es posible que no se puedan crear contenedores que se ejecuten en un nodo con la función de streaming de imágenes habilitada en versiones específicas de GKE y que se muestre el siguiente error: "CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links"
Si te afecta este problema, puedes comprobar si hay capas vacías o duplicadas. Si no puedes eliminar capas vacías o duplicadas, inhabilitar la transmisión de imágenes. |
| Operación | 1.27, 1.28 y 1.29 |
|
La transmisión de imágenes falla porque faltan archivosUn error en la función de streaming de imágenes puede provocar que los contenedores fallen porque faltan uno o varios archivos. Es posible que los contenedores que se ejecuten en un nodo con la función de transmisión de imágenes habilitada en las siguientes versiones no se inicien o se ejecuten con errores que indiquen que faltan determinados archivos. A continuación se muestran algunos ejemplos de este tipo de errores:
Si te afecta este problema, puedes inhabilitar la transmisión de imágenes. |
| Redes,actualizaciones y mejoras | 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, no se aprovisionarán los balanceadores de carga. Este problema se solucionará en una próxima versión de parche de GKE 1.28. |
|
| Mejoras y actualizaciones | 1.27 | 1.27.8 o posterior |
Problema con el complemento de dispositivo de GPU
Los clústeres que ejecutan GPUs y se actualizan de la versión 1.26 a una versión de parche 1.27 anterior a la 1.27.8 pueden tener problemas con los complementos de dispositivo de GPU de sus nodos (
|
| Operación | 1.27,1.28 |
|
Se detiene el autoescalado de todas las cargas de trabajo
HorizontalPodAutoscaler (HPA) y VerticalPodAutoscaler (VPA) pueden detener el autoescalado de todas las cargas de trabajo de un clúster si contiene objetos HPA mal configurados. Solución alternativa:
Para corregir los objetos HPA
Para obtener más información sobre cómo configurar objetos |
| Operación | 1.28 y 1.29 |
|
No se puede implementar Container Threat DetectionEs posible que Container Threat Detection no se pueda desplegar en clústeres de Autopilot que ejecuten las siguientes versiones de GKE:
|
| Redes y actualizaciones | 1.27, 1.28, 1.29, 1.30 |
|
Problemas de conectividad de los pods
|
| Redes | 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:
|
| Operación | 1.29, 1.30 y 1.31 |
|
Incompatibilidad entre Ray Operator y el cifrado de la base de datos de Cloud KMSAlgunas versiones de Ray Operator no son compatibles con el cifrado de bases de datos de Cloud KMS. Soluciones alternativas: Actualiza el plano de control del clúster a una versión corregida o posterior. |
| Mejoras y actualizaciones | 1.30 y 1.31 |
|
El pod del controlador de mantenimiento de la GPU está atascado en el estado CrashLoopBackOffCon este problema, los pods de gpu-maintenance-handler se quedan atascados en el estado `CrashLoopBackOff` en sus respectivos nodos. Este estado evita que se aplique la etiqueta `upcoming maintenance` a los nodos de GKE, lo que puede afectar a los procesos de drenaje de nodos y desalojo de pods de las cargas de trabajo.
"Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')"
Si te afecta este problema, puedes solucionarlo actualizando tu plano de control a una versión de GKE que incluya la corrección. |
| Operación | 1.33.1-gke.1522000 y versiones posteriores | 1.33.4-gke.1142000 y versiones posteriores |
Los pods no se inician en nodos con el streaming de imágenes habilitado
En los nodos con la función de streaming de imágenes habilitada, es posible que las cargas de trabajo no se inicien
y se produzca el siguiente error:
Los registros del puerto serie de un nodo afectado también contienen la siguiente firma de error:
La presencia de estas dos firmas de error indica un interbloqueo en uno de los componentes de streaming de imágenes. Este interbloqueo impide que los pods se inicien correctamente. Mitigación: Reinicia el nodo para mitigar el problema rápidamente. Ten en cuenta que es posible que el nodo reiniciado vuelva a encontrarse con el interbloqueo. Para aplicar una medida de mitigación más sólida, inhabilita la transmisión de imágenes en el grupo de nodos ejecutando el siguiente comando: gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming |
Siguientes pasos
Si no encuentras una solución a tu problema en la documentación, consulta la sección Obtener asistencia para obtener más ayuda, incluidos consejos sobre los siguientes temas:
- Abrir un caso de asistencia poniéndose en contacto con el equipo de Atención al Cliente de Cloud.
- Obtener asistencia de la comunidad haciendo preguntas en Stack Overflow
y usando la etiqueta
google-kubernetes-enginepara buscar problemas similares. También puedes unirte al#kubernetes-enginecanal de Slack para obtener más ayuda de la comunidad. - Abrir errores o solicitudes de funciones mediante el seguimiento de problemas público.