En esta página, se enumeran los problemas conocidos 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.
En esta página, se enumeran los problemas conocidos para todas las versiones compatibles y para las dos versiones secundarias que preceden inmediatamente a la versión más antigua en el soporte extendido. Después de que una versión alcanza el final de la asistencia extendida, se quitan todos los problemas de N-2. Por ejemplo, cuando la versión 1.30 llega al final de la asistencia extendida, se quitan 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 publique una nota de la versión relacionada con ella. Para obtener más información, consulta Páginas guardadas.
Para filtrar los problemas conocidos por versión o categoría del producto, selecciona los filtros en los siguientes menús desplegables.
Selecciona tu versión de GKE:
Selecciona la categoría de tu problema:
O bien, busca tu problema:
| Categoría | Versiones identificadas | Versiones corregidas | Problema y solución |
|---|---|---|---|
| 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 de forma dinámicaCuando se aprovisiona de forma dinámica una instancia de Lustre, falla la creación de la instancia con un error Solución alternativa: Actualiza el clúster de GKE a la versión 1.33.4-gke.1036000 o posterior. Si usas el canal estable, es posible que aún no esté disponible una versión más reciente. En este caso, puedes seleccionar manualmente una versión de los canales Regular o Rapid 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 de CSI de Cloud Storage FUSECuando se usa una versión afectada del controlador de CSI de Cloud Storage FUSE, es posible que se produzca un error de E/S al cambiar el nombre o mover archivos en buckets de Cloud Storage. Solución alternativa: Agrega temporalmente una definición de imagen de sidecar específica a tu manifiesto del 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 del Pod en Configura una imagen privada para el contenedor del archivo adicional. Después de actualizar el clúster a una versión fija de GKE o posterior, debes quitar todo el bloque |
| Registro y supervisión | Todas las versiones | Por definir |
Condición de carrera en DaemonSets de
|
| Actualizaciones | 1.33 | 1.33.2-gke.1043000 |
Se redujo el límite de archivos abiertos con containerd 2.0Para los grupos de nodos que ejecutan la versión 1.33 de GKE, que usa containerd 2.0, el límite flexible predeterminado para los archivos abiertos ( Este es un cambio en containerd (consulta la PR #8924 de containerd) en el que se quitó Las cargas de trabajo que esperan un límite flexible predeterminado más alto (por ejemplo, las que dependen de forma implícita del límite predeterminado anterior más alto) pueden experimentar fallas, como errores de Solution: Actualiza desde una versión de parche anterior de 1.33 a 1.33.2-gke.1043000 o una versión posterior. Solución alternativa: Aumenta el límite de archivos abiertos para tus cargas de trabajo con uno de los siguientes métodos:
|
| Actualizaciones | 1.31.5-gke.1169000 y 1.32.1-gke.1376000 | 1.31.7-gke.1164000 y 1.32.3-gke.1512000 |
El campo status.storedVersions de la CRD no es válido para las CRD administradasEs posible que algunos CRD administrados por GKE tengan un campo Este problema afecta a los clústeres que cumplen con 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 sabes que tu clúster contiene versiones no compatibles de objetos CRD, puedes agregar estas versiones al campo |
| Operación, registro y supervisión | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
Faltan métricas o el escalador automático de cargas de trabajo no ajusta la escalaEs posible que observes vacíos en los datos de las métricas en 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 las operaciones de ajuste de escala automático. Este problema solo afecta a los clústeres que se actualizaron a las versiones afectadas. Los clústeres creados recientemente deberían funcionar según lo previsto. Solución alternativa: Si te ves afectado, 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 conexión de Google Cloud HyperdiskPor lo general, un Pod que no se puede programar correctamente debido a los límites de adjuntos de volúmenes de un nodo activa el aprovisionamiento automático de un nodo nuevo. Cuando se programan cargas de trabajo que usan un producto de hiperdisco para 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á completo. La carga de trabajo se programa en el nodo a pesar de la falta de una conexión de 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 está presente en todos los productos de Hyperdisk en máquinas C3. Los límites de conexión de Hyperdisk varían según la cantidad de CPU virtuales de la VM y el producto de Hyperdisk. Para obtener más información, consulta Límites de rendimiento de Hyperdisk. Solución alternativa: Los productos de Hyperdisk activan el aprovisionamiento automático en otras formas de VM. Recomendamos 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 los nodos de TPU o GPUEn los nodos de TPU de GKE (por ejemplo, Solución alternativa: Si observas eventos de |
|
| Operación |
|
|
Es posible que los cambios de tamaño de volúmenes se bloqueen debido al estado NodePendingResize pendiente en los PVC.Los clústeres de la versión 1.32 que tienen nodos en las versiones 1.31 o anteriores no podrán actualizar el estado de PersistentVolumeClaim durante el cambio de tamaño. Este estado incorrecto impide que comiencen las operaciones de cambio de tamaño posteriores, lo que evita que se realicen más cambios de tamaño. Un PVC en este estado tiene un campo Si se creó un PVC mientras el clúster estaba en una versión afectada, es posible que este problema persista después de que el clúster se actualice a una versión corregida conocida. En esta situación, tu PVC debe parchearse para quitar el campo Solución alternativa: Las PVC atascadas debido a un estado pendiente se pueden parchear para quitar ese estado. Puedes usar un comando de parche como el siguiente para quitar el estado pendiente: 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 de PDCSI registre datos en excesoLos clústeres de GKE en versiones específicas de 1.32 pueden emitir mensajes de registro excesivos desde el controlador de PDCSI. Este exceso de registros consumiría la cuota de la API de Cloud Logging Write. Solución alternativa: Puedes reducir este registro excesivo agregando un filtro de exclusión. Para excluir los mensajes de registro de la transferencia a 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 activar volúmenes persistentes de NFS en nodos de COS que anteriormente tenían una activación de solo lectura (RO) solo se activarán en modo RO.En la versión 1.27 y posteriores de GKE, los volúmenes de NFS que usan el controlador de CSI integrado en Kubernetes solo pueden activar volúmenes persistentes en modo RO después de una activación RO anterior en el mismo nodo. Solución alternativa: Cambia a una versión inferior de los grupos de nodos a una versión anterior a las versiones afectadas. |
| Operaciones |
|
|
Los Pods que intenten activar volúmenes persistentes de NFS en nodos de Ubuntu no podrán ejecutarse.En la versión 1.32 y posteriores de GKE, los volúmenes de NFS que usen el controlador de CSI integrado de Kubernetes no podrán activar volúmenes persistentes en nodos de Ubuntu. Cuando esto sucede, 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: Cambia a una versión inferior de los grupos de nodos a la versión 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 usan llamadas al sistema relacionadas con io_uring se queden atascados en el estado Terminating.
Los Pods que usan llamadas al sistema relacionadas con io_uring pueden ingresar al 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 con señales, incluida
Cuando un Pod se ve afectado por este problema conocido, es posible que sus contenedores no finalicen correctamente. En los registros de containerd, es posible que observes mensajes repetidos similares al siguiente:
o
Estos síntomas apuntan a procesos dentro del contenedor que están atascados en un estado de suspensión ininterrumpible (estado D), lo que impide la finalización adecuada del Pod.
Las cargas de trabajo que usan io_uring directamente o que lo usan de forma indirecta a través de un tiempo de ejecución de lenguaje como NodeJS podrían 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 y 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 transmisión de imágenes puede provocar que las cargas de trabajo fallen cuando se cumple un conjunto de condiciones específicas mientras el contenedor lee archivos. Es posible que los mensajes de error relacionados con las fallas de autenticación se muestren en el registro de gcfsd.
Para verificar si te afecta, busca en los registros con esta consulta de búsqueda:
La presencia de estos errores indica que los nodos se ven afectados. Si este problema te afecta, puedes actualizar tus grupos de nodos a una versión de GKE con parche. |
| Operación |
|
|
Aumento de las tasas de expulsión 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 compilaron 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 para cargas de trabajo que no hayan establecido 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 informa como disponible. Si observas un mayor uso de memoria de una aplicación después de actualizar a las versiones de GKE mencionadas sin ningún otro cambio, es posible que te afecte la opción del kernel.
Para verificar 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. Reemplaza 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 ves picos inusuales en el uso de memoria que superan la memoria solicitada, es posible que la carga de trabajo se expulse con mayor frecuencia. Solución alternativaSi no puedes actualizar a las versiones corregidas y ejecutas en un entorno de GKE en el que puedes implementar Pods con privilegios, puedes inhabilitar la opción LRU multigeneracional con un DaemonSet.
Después de que el DaemonSet se ejecute en todos los grupos de nodos seleccionados, el cambio entrará en vigencia de inmediato y el cálculo del uso de memoria de kubelet volverá a la normalidad. |
| Operación | 1.28, 1.29, 1.30 y 1.31 |
|
Los pods están atascados en el estado de finalizaciónUn error en el entorno de ejecución del contenedor (containerd) podría hacer que los Pods y los contenedores se queden atascados 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 |
|
La transmisión de imágenes falla debido a vínculos 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 transmisión de imágenes habilitada en versiones específicas de GKE con 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 este problema te afecta, puedes comprobar si hay capas vacías o duplicadas. Si no puedes quitar las capas vacías o duplicadas, inhabilita 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 transmisión de imágenes puede provocar que los contenedores fallen debido a la falta de uno o más archivos. Es posible que los contenedores que se ejecutan en un nodo con la transmisión de imágenes habilitada en las versiones siguientes no se inicien o se ejecuten con errores que informan que no existen ciertos archivos. A continuación, se muestran ejemplos de estos errores:
Si te afecta este problema, puedes inhabilitar la transmisión de imágenes. |
| Herramientas de redes,actualizaciones y revisiones | 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. |
|
| Revisiones y actualizaciones | 1.27 | 1.27.8 o una versión posterior |
Problema con el complemento del dispositivo GPU
Es posible que los clústeres que ejecutan GPUs y se actualizaron de la versión 1.26 a una versión de parche 1.27 anterior a la 1.27.8 experimenten problemas con los complementos de dispositivos de GPU (
|
| Operación | 1.27 y 1.28 |
|
Se detiene el ajuste de escala automático para todas las cargas de trabajo
HorizontalPodAutoscaler (HPA) y VerticalPodAutoscaler (VPA) podrían detener el ajuste de escala automático de todas las cargas de trabajo en un clúster si contiene objetos Solución alternativa:
Corrige los objetos
Para obtener más detalles sobre cómo configurar objetos |
| Operación | 1.28 y 1.29 |
|
No se puede implementar la detección de amenazas de contenedoresEs posible que Container Threat Detection no se pueda implementar en clústeres de Autopilot que ejecuten las siguientes versiones de GKE:
|
| Redes, actualizaciones | 1.27, 1.28, 1.29 y 1.30 |
|
Problemas de conectividad para los Pods
|
| Redes | 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:
|
| Operación | 1.29, 1.30 y 1.31 |
|
Incompatibilidad entre el operador de Ray y la encriptación de la base de datos de Cloud KMSAlgunas versiones del operador de Ray son incompatibles con la encriptación de la base de datos de Cloud KMS. Soluciones alternativas: Actualiza el plano de control del clúster a una versión corregida o posterior. |
| Revisiones 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 quedan atascados en un estado "CrashLoopBackOff" en sus respectivos nodos. Este estado evita que se aplique la etiqueta "mantenimiento próximo" a los nodos de GKE, lo que puede afectar los procesos de vaciado de nodos y desalojo de Pods para 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 este problema te afecta, puedes resolverlo 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 los nodos con la transmisión de imágenes habilitada
En los nodos con la transmisión de imágenes habilitada, es posible que las cargas de trabajo no se inicien
con la siguiente firma de 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 bloqueo en uno de los componentes de transmisión de imágenes. Este bloqueo 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 experimentar el bloqueo. Para una 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 |
¿Qué sigue?
Si no encuentras una solución a tu problema en la documentación, consulta Obtener asistencia para obtener más ayuda, como asesoramiento en los siguientes temas:
- Comunicarse con Atención al cliente de Cloud para abrir un caso de asistencia.
- Hacer preguntas en StackOverflow para obtener asistencia de
la comunidad y usar la etiqueta
google-kubernetes-enginepara buscar problemas similares. También puedes unirte al canal de Slack#kubernetes-enginepara obtener más Asistencia de la comunidad. - Abrir errores o solicitudes de funciones con la herramienta de seguimiento de errores pública.