Problemas conocidos de GKE

• 1.36.3-gke.1767000 y versiones posteriores

Las cargas de trabajo de la zona de pruebas del agente fallan después de la actualización del clúster

El complemento Agent Sandbox (agentsandbox) ascendió sus definiciones de recursos personalizados y su API de v1alpha1 a v1beta1 a partir de la versión 1.36.3-gke.1767000 de GKE. Si actualizas un clúster que ejecuta Agent Sandbox desde una versión anterior a la 1.36.3-gke.1767000 sin migrar tus recursos personalizados, las cargas de trabajo de v1alpha1 existentes no funcionarán correctamente.

Solución alternativa:

Antes de actualizar el plano de control del clúster a la versión 1.36.3-gke.1767000 o posterior, migra los manifiestos y las cargas de trabajo de Agent Sandbox de v1alpha1 a v1beta1 siguiendo la guía de migración de Agent Sandbox de v1alpha1 a v1beta1.

• 1.35
• 1.36
• 1.37

• 1.35.6-gke.1250001 y versiones posteriores
• 1.36.4-gke.1391002 y versiones posteriores
• 1.37.1-gke.1187000 y versiones posteriores

Las solicitudes HTTP POST de tokens del servidor de metadatos fallan con un error 400 de solicitud incorrecta

Las cargas de trabajo que usan Workload Identity Federation for GKE para autenticarse en las APIs de Cloud de Confiance solicitando tokens de acceso de cuentas de servicio o tokens de identidad del servidor de metadatos de GKE (como /computeMetadata/v1/instance/service-accounts/default/token o /computeMetadata/v1/instance/service-accounts/default/identity) podrían fallar con un error HTTP 400 Bad Request (INVALID_ARGUMENT).

Este problema se produce cuando una aplicación, una biblioteca cliente o una API Gateway envía una solicitud HTTP POST sin una cadena de certificados válida en el cuerpo de la solicitud. En las versiones de GKE afectadas, las solicitudes de POST a estos extremos de token se reservan estrictamente para los tokens de acceso y los tokens de ID vinculados. Como resultado, se rechazan las solicitudes que tienen JSON vacíos, codificados en formularios o no válidos en las cargas útiles.

Para solucionar el problema, actualiza a la versión de parche más reciente dentro de la versión secundaria de cualquier canal de versiones.

Solución alternativa:

Para resolver este problema, configura tu aplicación, biblioteca cliente o API Gateway para que use el método GET en lugar de POST cuando solicites tokens de acceso o tokens de ID al servidor de metadatos, como en el siguiente ejemplo:

curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
    

Si tu carga de trabajo usa un SDK o una puerta de enlace de terceros (como MuleSoft Flex Gateway, IBM App Connect o secuencias de comandos HTTP personalizadas) que envía solicitudes POST a los extremos del servidor de metadatos de forma predeterminada, actualiza la configuración o la biblioteca cliente para enviar solicitudes GET.

• 1.33 y versiones posteriores

Pods no programados y cuota agotada durante las actualizaciones secundarias de dos pasos para el plano de control.

Durante las actualizaciones de versiones secundarias de dos pasos para los planos de control en clústeres de Autopilot que usan Pods de duración extendida, es posible que se aprovisionen grupos de nodos nuevos con la versión anterior del nodo. El escalador automático de clústeres evalúa los nodos recién aprovisionados con la versión actualizada del plano de control, detecta una discrepancia de versión y aplica el taint cloud.google.com/not-target-gke-version:true. El escalador automático de clústeres también bloquea el escalamiento vertical de los grupos de nodos de Pods de duración extendida existentes o recién creados que usan la versión anterior del nodo.

Este comportamiento evita que los Pods se programen y activa un bucle de escalamiento infinito. En lugar de escalar verticalmente un grupo de nodos existente, el aprovisionamiento automático de nodos crea un grupo de nodos único nuevo en cada iteración de escalamiento vertical para alojar las cargas de trabajo pendientes. Este bucle genera cientos de grupos de nodos vacíos independientes que, con el tiempo, pueden agotar las cuotas de los grupos de instancias administrados regionales.

Solución alternativa:

Para resolver el bucle de escalamiento, completa de forma manual la actualización del plano de control ejecutando el siguiente comando:

gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION]

Como alternativa, aplica la siguiente tolerancia a las cargas de trabajo afectadas para que se puedan programar en los nodos de la versión anterior:

tolerations:
- key: "cloud.google.com/not-target-gke-version"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

Los nodos que activan volúmenes de NFS acumulan entradas de activación y dejan de crear contenedores

En los nodos que ejecutan versiones afectadas, la activación de un volumen de NFS deja entradas adicionales en la tabla de activación del nodo. Además, cuando finaliza un Pod que usa un volumen de NFS, los intentos de desmontaje fallan, lo que hace que el kubelet vuelva a intentar el desmontaje de forma reiterada. Cada reintento agrega más entradas a la tabla de activación, lo que hace que esta crezca de forma continua, incluso cuando no se programan cargas de trabajo nuevas.

Cuando la tabla de activación alcanza el límite del kernel, el entorno de ejecución de contenedores ya no puede crear contenedores en ese nodo. El nodo deja de ejecutar Pods nuevos, puede informar un estado NotReady y puede reiniciarse de forma repetida. Los Pods que usan volúmenes de NFS pueden permanecer en el estado Terminating porque no se pueden activar sus volúmenes.

En los eventos de Pod y los registros de kubelet, los nodos en este estado informan errores similares a los siguientes:

MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1

mount: /etc: mount(2) system call failed: No space left on device

Este problema afecta a los grupos de nodos que activan volúmenes de NFS con el controlador de NFS integrado de Kubernetes. Los nodos que no usan el controlador de NFS en el árbol para activar volúmenes de NFS no se ven afectados.

Solución alternativa:

Para recuperar un nodo afectado, reinícialo o vuelve a crearlo. Las entradas de activación adicionales solo existen en el estado de ejecución del nodo, por lo que se borran cuando se reinicia el nodo. Los Pods que se quedan atascados en el estado Terminating después del reinicio se pueden quitar con el siguiente comando:

kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0
    

Para evitar que el problema vuelva a ocurrir en los clústeres de Standard, cambia a una versión anterior los grupos de nodos que activan volúmenes de NFS a una versión 1.36. Configura una exclusión de mantenimiento para que GKE no actualice automáticamente los grupos de nodos a una versión afectada.

Si un clúster de Autopilot ejecuta una versión afectada, usa una de las siguientes opciones:

• Si tus volúmenes NFS están respaldados por Filestore, móntalos con el controlador de CSI de Filestore en lugar del controlador NFS integrado. El controlador de CSI activa volúmenes desde su propio contenedor y no usa el componente de nodo afectado.
• Si debes seguir usando el controlador NFS en el árbol, permite que la reparación automática de nodos recupere los nodos afectados. Los clústeres de Autopilot reparan los nodos automáticamente, y un nodo que informa un estado NotReady durante unos 10 minutos se vacía y se vuelve a crear, lo que borra su tabla de activación.

Fallas en las cargas de trabajo de GPU A4X Max (GB300)

Crear o actualizar grupos de nodos A4X Max (a4x-maxgpu-4g-metal) de GKE a versiones de parches específicas (consulta la columna Versiones identificadas) provoca fallas en las cargas de trabajo de GPU con los superchips NVIDIA GB300 Grace Blackwell Ultra conectados. Debido a los tiempos de inicio extendidos de la memoria de alto ancho de banda (HBM) en el hardware GB300 con este tipo de máquina de equipos físicos, se agota el tiempo de espera del servicio de inicio nvidia-persistenced. Este tiempo de espera deja las GPU sin inicializar y genera el mensaje de error cudaErrorDeviceUnavailable(46) cuando los Pods intentan reclamar recursos de CUDA.

Solución:

Actualiza cada clúster y grupo de nodos afectado a una versión corregida. GKE impide la creación de grupos de nodos A4X Max con versiones afectadas y no actualizará automáticamente los grupos de nodos a las versiones afectadas. GKE no impide las actualizaciones manuales a las versiones afectadas. Sin embargo, para evitar las fallas, te recomendamos que no actualices a las versiones afectadas.

Solución alternativa:

Si no puedes actualizar, borra todos los grupos de nodos A4X Max que ejecutan versiones afectadas y vuelve a crearlos con una versión anterior que no esté afectada. Ten en cuenta que, como la capacidad de A4X Max se debe obtener a través de una reserva, no perderás capacidad si borras los grupos de nodos.

Nodos de GPU o TPU bloqueados con taints de finalización de nodo inminente después del mantenimiento del host

En los clústeres de GKE con nodos aceleradores (GPU o TPU) que ejecutan versiones afectadas, los nodos pueden quedar bloqueados con los taints cloud.google.com/impending-node-termination o cloud.google.com/maintenance-window-started después de que se completen el mantenimiento o las reparaciones del host de Compute Engine. Cuando se vuelve a iniciar la instancia de VM, el controlador de mantenimiento de GKE puede volver a aplicar estos taints de forma prematura si hay otro evento de mantenimiento futuro programado para el nodo, lo que evita que se programen cargas de trabajo nuevas en nodos en buen estado.

Solución alternativa:

Para resolver el estado de bloqueo, debes quitar de forma manual las etiquetas de mantenimiento activo administradas por GKE y las taints de los nodos afectados. Si solo quitas los taints, el controlador de mantenimiento de GKE los volverá a aplicar de forma automática.

Para borrar las etiquetas y los taints, ejecuta los siguientes comandos:

kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest-
kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination-
kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started-
    

Reemplaza NODE_NAME por el nombre del nodo afectado.

• 1.33
• 1.34

Se produjeron fallas de admisión de Pods para las cargas de trabajo de TPU v7 debido a que se informó un recuento de chips incorrecto.

GKE anuncia de forma incorrecta ocho chips TPU asignables para los aceleradores de TPU v7 (tpu7x) con una topología 2x2x1, que físicamente contiene solo cuatro chips. Esta discrepancia en los informes impide la programación de Pods para las cargas de trabajo de TPU v7.

La arquitectura de chiplet doble de TPU v7 no se controla correctamente en las versiones anteriores, lo que genera fallas de admisión de Pods. Según los recursos TPU solicitados, se producen los siguientes errores:

• Cuando se solicitan cuatro chips TPU (google.com/tpu: 4), el `kubelet` devuelve un UnexpectedAdmissionError: "invalid TPU chip count request, you must request all 4 chips on this node together".
• Cuando se solicitan ocho TPU (google.com/tpu: 8), el webhook de admisión tpu-accelerator-topology-constraints rechaza la solicitud con el siguiente error: "Invalid resource requests for google.com/tpu. Debe ser igual a uno de [4] para el acelerador tpu7x y la topología 2x2x1".

Solución alternativa:

Para resolver este problema, actualiza el clúster de GKE a la versión 1.34.1-gke.1829001 o una posterior.

El cliente de Lustre no usa NIC secundarias en nodos con varias NIC

En los nodos de GKE con varias tarjetas de interfaz de red (NIC), el controlador de CSI de Managed Lustre está habilitado de forma predeterminada para usar todas las NIC disponibles para agregar ancho de banda distribuyendo el tráfico de almacenamiento de TCP entre las interfaces de red. Sin embargo, debido a un problema conocido, es posible que los clientes de Lustre a partir de la versión 2.14.0_p249 no utilicen NIC secundarias. En su lugar, todo el tráfico de almacenamiento de TCP a la instancia de Managed Lustre se enruta exclusivamente a través de la NIC principal, lo que evita la agregación de ancho de banda y limita la capacidad de procesamiento del almacenamiento.

Solución alternativa:

Si tus cargas de trabajo requieren la agregación de ancho de banda de multi-NIC para Managed Lustre, cambia tus grupos de nodos a una versión anterior de GKE, como la 1.35.2-gke.1842000.

Tiempo de espera de conexión agotado o conexión rechazada para los flujos redireccionados al servidor de metadatos de GKE

En la versión 1.35 y posteriores de GKE, las cargas de trabajo que usan Workload Identity para autenticarse en las APIs de Google Cloud podrían experimentar tiempos de espera de conectividad transitorios o conexiones rechazadas al servidor de metadatos de GKE inmediatamente después del inicio del nodo.

Solución alternativa:

Para obtener recomendaciones y soluciones alternativas, consulta Soluciona errores de tiempo de espera en el inicio del Pod.

La corrección de compatibilidad de gVisor no se limpia y registra el error "runsc: executable file not found in $PATH"

Cada vez que se cierra un Pod de gVisor o se finaliza por falta de memoria, containerd intenta desmantelar la zona de pruebas. Sin embargo, a veces, el proceso de limpieza falla y se registra el error exec: "runsc": executable file not found in $PATH. Este error puede causar problemas como el agotamiento de recursos, la degradación de la red, el pánico de NodeLocalDNS, los tiempos de espera de DNS o la latencia alta cuando se crean Pods.

Solución:

Actualiza los nodos de GKE a la versión 1.35.1 o posterior. En el caso de los clústeres de Standard, actualiza el grupo de nodos con los nodos afectados. En el caso de los clústeres de Autopilot, actualiza manualmente el clúster de Autopilot a la versión 1.35.1 o posterior, y GKE actualizará automáticamente tus nodos para que coincidan con la versión del plano de control lo antes posible.

Solución alternativa:

Si no puedes actualizar el clúster, realiza una de las siguientes acciones:

• Revisa y aumenta las solicitudes y los límites de memoria para los Pods de gVisor.
• Implementa el siguiente DaemonSet con privilegios para copiar el objeto binario runsc de /home/containerd/usr/local/sbin a /home/kubernetes/bin:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: runsc-path
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: runsc-path
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: runsc-path
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor
      volumes:
      - name: host
        hostPath:
          path: /
      initContainers:
      - name: copy-runsc
        image: bash
        command:
        - /usr/local/bin/bash
        - -c
        - |
          set -euo pipefail
          cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin
          chmod a+rx /host/home/kubernetes/bin/runsc
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: 5Mi
            cpu: 5m
        securityContext:
          privileged: true
      containers:
      - image: gcr.io/google-containers/pause:3.2
        name: pause
    

Los volúmenes dinámicos recurren al tipo de disco predeterminado

Es posible que las cargas de trabajo que usan volúmenes dinámicos en la versión 1.35.0-gke.2232000 o posterior de GKE no se programen o adjunten. Este problema también puede provocar que los volúmenes se aprovisionen con el hd-type de resguardo (como hyperdisk-balanced) en lugar del pd-type, incluso en nodos que no admiten Hyperdisk.

Esto ocurre porque el servidor de nodos de PDCSI no puede propagar el objeto CSINode con las topologías de tipo de disco compatibles. Como resultado, el controlador carece de la información de topología necesaria para hacer coincidir los volúmenes con los nodos compatibles.

Solución alternativa:

Actualiza a la versión 1.35.3-gke.1290000 o una posterior.

• Todas las versiones de parches anteriores a la 1.34.3-gke.1208000 para GKE 1.34
• Todas las versiones de parche anteriores a la 1.35.0-gke.2232000 para GKE 1.35

• 1.34.3-gke.1208000 para GKE 1.34
• 1.35.0-gke.2232000 para GKE 1.35

Problemas de inicio de Pods durante las actualizaciones a GKE 1.35 para clústeres de GKE Dataplane V2

Clústeres que actualizan el plano de control a la versión 1.35.0-gke.2232000 y posteriores de GKE desde las versiones

• Anterior a la 1.34.3-gke.1208000 para GKE 1.34
• Anterior a 1.35.0-gke.2232000 para GKE 1.35

Las cargas de trabajo nuevas no se iniciarán durante el lanzamiento de anetd si se programan en un nodo con anetd desactualizado. Durante el lanzamiento, es posible que veas el siguiente mensaje de error:

Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded

Esto ocurre porque GKE usa el identity-management-mode del operador, que requiere que todos los agentes y el operador tengan una vista sincronizada de las etiquetas relevantes para la identidad. A partir de la versión 1.35.0-gke.2232000 de GKE, las etiquetas topology.kubernetes.io se excluyen del conjunto relevante para la identidad para evitar la duplicación de identidades. Este cambio provoca una discrepancia temporal de configuración entre el plano de control actualizado y los agentes de anetd desactualizados durante el lanzamiento. Para obtener más información, consulta la PR de Cilium.

Solución alternativa:

• Para GKE 1.34 anterior a 1.34.3-gke.1208000: actualiza primero a 1.34.3-gke.1208000 o posterior y, luego, a 1.35.0-gke.2232000 o posterior
• Para GKE 1.35 anterior a la versión 1.35.0-gke.2232000: Después de la actualización, espera a que finalice el lanzamiento de anetd. Para acelerar el lanzamiento de forma manual, borra los Pods de anetd desactualizados. Esto garantizará que el operador y los agentes de nodo de anetd tengan vistas sincronizadas de las etiquetas relevantes para la identidad.

• 1.32
• 1.33
• 1.34
• 1.35

• 1.32.11-gke.1153001 y versiones posteriores
• 1.33.5-gke.2326000 y versiones posteriores
• 1.34.3-gke.1214000 y versiones posteriores
• 1.35.0-gke.2180000 y versiones posteriores

Retrasos en la programación de Pods en nodos nuevos con la política de red de Calico habilitada

En los clústeres de GKE con la política de red de Calico habilitada, una regresión en las versiones afectadas puede causar retrasos significativos en la programación de Pods en nodos nuevos o recreados. Estas demoras pueden hacer que los nodos permanezcan en un estado NotReady durante períodos prolongados.

El problema se debe a que la secuencia de comandos de inicio de la CNI de Calico aplica un formato incorrecto a la URL del servidor de la API de Kubernetes para las direcciones IPv4, ya que las encierra entre corchetes ([]). Este enfoque genera un error de análisis de URL cuando se crean nuevos entornos de pruebas de Pods, que se puede ver en los registros de "kubelet":

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443"

Solución alternativa:

La versión del componente de Calico se determina según la versión del plano de control del clúster. Para mitigar este problema, actualiza el plano de control de tu clúster a una de las versiones corregidas. Después de actualizar el plano de control, debes volver a crear los nodos en tus grupos de nodos para asegurarte de que usen el formato de URL correcto del servidor de la API de Kubernetes. Para lograrlo, realiza una actualización in situ del grupo de nodos a la misma versión o a una más reciente, o vuelve a crear los grupos de nodos de forma manual.

• 1.32.8-gke.1134000 y versiones posteriores para GKE 1.32
• 1.33.3-gke.1392000 y versiones posteriores para GKE 1.33
• Todas las versiones de parches para GKE 1.34 y 1.35

• 1.32.11-gke.1075000 y versiones posteriores para GKE 1.32
• 1.33.5-gke.2392000 y versiones posteriores para GKE 1.33
• 1.34.3-gke.1318000 y versiones posteriores para GKE 1.34
• 1.35.0-gke.2398000 y versiones posteriores para GKE 1.35

El rendimiento de las redes de uso general disminuye en los tipos de máquinas con GPU de la serie A y G4

Los clústeres de GKE con nodos de GPU de la serie A y G4 muestran un rendimiento degradado para las redes de uso general en GKE 1.32.8-gke.1134000 y versiones posteriores para GKE 1.32, y en GKE 1.33.3-gke.1392000 y versiones posteriores. La degradación del rendimiento en las redes de uso general afecta a los tipos de máquinas con GPU, incluidas las series de máquinas A3, A4, A4X y G4. Ten en cuenta que GPUDirect-TCPXO en A3 Mega y GPUDirect-RDMA en A3 Ultra, A4 y A4X no se ven afectados.

Esto ocurre porque la secuencia de comandos a nivel de nodo (/usr/bin/google_set_multiqueue) que establece la afinidad de interrupción está configurada de forma incorrecta.

Solución alternativa:

Actualiza cada grupo de nodos afectado a una versión fija.

• 1.32.8-gke.1134000 y versiones posteriores para GKE 1.32
• 1.33.3-gke.1392000 y versiones posteriores para GKE 1.33 y versiones posteriores

• 1.32.11-gke.1075000 y versiones posteriores para GKE 1.32
• 1.33.5-gke.2392000 y versiones posteriores para GKE 1.33

El rendimiento de GPUDirect-TCPX disminuye en A3 High

Los clústeres de GKE con nodos A3 High (a3-highgpu-8g) muestran un rendimiento degradado cuando se usa GPUDirect-TCPX en GKE 1.32.8-gke.1134000 y versiones posteriores para GKE 1.32, y en GKE 1.33.3-gke.1392000 y versiones posteriores.

Esto ocurre porque la secuencia de comandos a nivel de nodo (/usr/bin/google_set_multiqueue) que establece la afinidad de interrupción está configurada de forma incorrecta.

Solución alternativa:

Para los grupos de nodos de GKE 1.32, actualiza las versiones de los grupos de nodos de GKE a la 1.32.11-gke.1075000 o una posterior. Para los grupos de nodos de GKE 1.33 y versiones posteriores, actualiza las versiones de los grupos de nodos de GKE a la 1.33.5-gke.2392000 o una posterior. Para los grupos de nodos de GKE 1.34, consulta GPUDirect-TCPX no está disponible con A3 High para GKE 1.34 y versiones posteriores.

1.35.0-gke.2232000 y versiones posteriores.

Duplicación de identidad de Cilium en clústeres de GKE Dataplane V2

Los clústeres de GKE que ejecutan la versión 1.35 con GKE Dataplane V2 habilitado podrían experimentar un aumento en la cantidad de recursos personalizados ciliumidentities.cilium.io. Este problema se produce porque se agregan etiquetas topology.kubernetes.io a los Pods en Kubernetes 1.35, lo que genera identidades de Cilium adicionales para cada zona en la que se programa un Pod de una carga de trabajo.

En los clústeres regionales y zonales, programar una carga de trabajo nueva puede causar una duplicación temporal de la identidad de Cilium. Esta duplicación se produce porque los Pods obtienen una identidad en el momento de la creación en función de las etiquetas iniciales y otra identidad después de que se agregan las etiquetas de topología cuando el Pod se programa en un nodo. En los clústeres regionales, la cantidad de identidades también puede aumentar en un factor proporcional a la cantidad de zonas que abarca el clúster.

Impacto:

Si la cantidad total de identidades supera las 65,535, es posible que no se puedan programar las cargas de trabajo nuevas.

Solución alternativa:

Para limitar la cantidad total de identidades, evita agregar etiquetas con una gran cantidad de valores únicos a tus Pods.

Para obtener más información, consulta la siguiente documentación de Cilium:

• Seguridad basada en la identidad
• Identidades de seguridad

Las actualizaciones manuales se deben realizar desde las versiones 1.34.3-gke.1208000 y posteriores. Si inicias la actualización desde una versión anterior a la 1.34.3-gke.1208000, es posible que experimentes problemas temporales con la programación de Pods durante el proceso de actualización.

• Versiones de parches 1.34 anteriores a la 1.34.5-gke.1153000
• Versiones de parches 1.35 anteriores a la 1.35.2-gke.1485000

• 1.34.5-gke.1153000 y versiones posteriores
• 1.35.2-gke.1485000 y versiones posteriores
• 1.36 y versiones posteriores

También debes usar la versión 3.1.9 o posterior del instalador de GPUDirect-TCPX y la versión 2.0.12 o posterior del archivo adicional. Las versiones del instalador y del archivo adicional tienen una asignación uno a uno y deben corresponder. Por ejemplo, la versión 3.1.12 del instalador de GPUDirect-TCPX corresponde a la versión 2.0.15 del archivo adicional. Para obtener más información sobre las versiones del instalador y del archivo de complemento, consulta las notas de la versión de GPUDirect-TCPX.

GPUDirect-TCPX no está disponible con A3 High para versiones específicas de GKE

Los clústeres de GKE con nodos A3 High (a3-highgpu-8g) usan GPUDirect-TCPX para maximizar el ancho de banda de red de la GPU. En el caso de los nodos que usan TCPX y A3 High, la actualización a las versiones de GKE afectadas puede generar problemas de funcionamiento o rendimiento con TCPX. Esto se debe a que TCPX no es compatible con el kernel de Linux 6.12 actualizado que usa el hito 125 o posterior de Container-Optimized OS. La versión 1.34 de GKE usa el hito 125.

Otros tipos de máquinas de GPU A3 High (a3-highgpu-1g, a3-highgpu-2g, a3-highgpu-4g) y otras series de máquinas de GPU no se ven afectadas porque no admiten GPUDirect-TCPX.

Solución:

Actualiza a los parches de la versión de GKE corregida para resolver este problema. Para obtener detalles sobre cómo configurar y actualizar grupos de nodos con GPUDirect-TCPX, consulta Maximiza el ancho de banda de red de la GPU en clústeres de Standard o Maximiza el ancho de banda de red de la GPU en clústeres de Autopilot.

Cuando ejecutes pruebas de NCCL en versiones fijas, es posible que veas las siguientes advertencias que no afectan el rendimiento ni la funcionalidad:

• Registros de NCCL WARN para Rx Ctrl Timeouts: Este mensaje puede aparecer si la carga de trabajo publica una operación de comunicación Recv en el destino mucho antes de que publique una operación de comunicación Send en el iniciador. No se espera que esto afecte el rendimiento.
• Registros de NCCL WARN para No free space for recv task: Este mensaje advierte sobre una cantidad total baja de tareas de red para procesar operaciones, lo que hace que todas las tareas se ocupen de forma temporal. No se espera que se vea afectado el rendimiento.

Se actualizó la capacidad mínima de instancias

La capacidad mínima de las instancias de Managed Lustre se actualizó a 9,000 GiB. Los clústeres que ejecutan versiones anteriores a la 1.34.0-gke.2285000 no pueden crear instancias con esta capacidad mínima a través del controlador de CSI de Managed Lustre.

Solución alternativa:

Actualiza la versión de tu clúster a la 1.34.0-gke.2285000 o una posterior para habilitar la creación de instancias de Managed Lustre con la capacidad mínima de 9,000 GiB.

La IU de la consola deCloud de Confiance no se puede editar durante la reparación automática de nodos

Cuando un nodo de GKE se está reparando automáticamente, el grupo de nodos no se puede editar a través de la consola de Cloud de Confiance debido a una operación en curso.

Solución alternativa:

Aún puedes editar la configuración del grupo de nodos con los comandos de gcloud CLI.

Nivel de rendimiento incorrecto para las instancias de Lustre aprovisionadas de forma dinámica

Cuando se aprovisiona de forma dinámica una instancia de Lustre, la creación de la instancia falla con un error InvalidArgument para PerUnitStorageThroughput, independientemente del valor de perUnitStorageThroughput especificado en la solicitud a la API.

Solución alternativa:

Actualiza el clúster de GKE a la versión 1.33.4-gke.1036000 o una posterior. Si usas el canal estable, es posible que aún no haya una versión más reciente disponible. En este caso, puedes seleccionar de forma manual una versión de los canales Regular o Rápido que incluya la corrección.

• 1.32.3-gke.1099000 y versiones posteriores
• 1.33

Error de entrada/salida cuando se cambia el nombre de los archivos o se mueven con el controlador de CSI de Cloud Storage FUSE

Cuando se usa una versión afectada del controlador CSI de Cloud Storage FUSE, es posible que no se puedan cambiar de nombre o mover los archivos en los buckets de Cloud Storage debido a un error de E/S.

Solución alternativa:

Agrega de forma temporal una definición de imagen de sidecar específica al manifiesto del Pod. En la sección spec.containers del manifiesto de tu Pod, agrega la siguiente definición de contenedor con la imagen: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2.

    # 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 sidecar.

Después de actualizar el clúster a una versión de GKE fija o posterior, debes quitar todo el bloque gke-gcsfuse-sidecar del manifiesto. Después de quitar este bloque, GKE reanudará la inserción y administración automáticas de la imagen de archivo adicional correcta para la versión actualizada del clúster.

Condición de carrera en DaemonSets de gke-metrics-agent

Cuando agregas la etiqueta cloud.google.com/gke-metrics-agent-scaling-level a un grupo de nodos para aumentar de forma manual la asignación de memoria del DaemonSet gke-metrics-agent, se produce una condición de carrera en el DaemonSet durante la creación de un nodo nuevo. Esta condición de carrera genera reinicios intermitentes y puede provocar la pérdida de métricas.

Este problema se produce porque hay una demora antes de que se agregue la etiqueta a un nodo nuevo en el grupo de nodos. Durante esta demora, el DaemonSet crea un Pod con la asignación de memoria original en ese nodo. Después de que se aplica la etiqueta, el DaemonSet crea un Pod que tiene la nueva asignación de memoria. El Pod existente no se borra por completo cuando se inicia el Pod actualizado. Ambos Pods intentan vincularse al mismo número de puerto.

Solución alternativa:

Después de agregar la etiqueta cloud.google.com/gke-metrics-agent-scaling-level a un grupo de nodos, reinicia el DaemonSet gke-metrics-agent:

kubectl -n kube-system rollout restart daemonset gke-metrics-agent

Se redujo el límite de archivos abiertos con containerd 2.0

En el caso de 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 (ulimit -n) de los contenedores se reduce a 1024.

Este es un cambio en containerd (consulta la PR de containerd n° 8924) en el que se quitó LimitNOFILE de containerd.service como práctica recomendada, lo que hace que se aplique el límite flexible predeterminado del sistema.

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 más alto anterior) podrían experimentar fallas, como errores Too many open files.

Solución:

Actualiza desde una versión de parche 1.33 anterior a la 1.33.2-gke.1043000 o una posterior.

Solución alternativa:

Aumenta el límite de archivos abiertos para tus cargas de trabajo con uno de los siguientes métodos:

• Ajuste a nivel de la aplicación: Modifica el código o la configuración de la aplicación para establecer de forma explícita el ulimit -n o el prlimit --nofile=524288.
• Complemento de ajuste de ulimit de NRI de Containerd Usa el complemento containerd/nri ulimit-adjuster para ajustar el ulimit.
• Cambia a una versión anterior del grupo de nodos (solo para Standard): En el caso de los clústeres de GKE Standard, puedes cambiar temporalmente tu grupo de nodos a una versión anterior, la 1.32, para evitar este problema hasta que haya una solución permanente disponible.

Estado de CRD no válido.storedVersions para CRD administradas

Es posible que algunas CRD administradas por GKE tengan un campo status.storedVersions no válido, lo que genera un riesgo de que se interrumpa el acceso a los objetos de CRD después de una actualización.

Este problema afecta a los clústeres que cumplen con las siguientes condiciones:

• Clústeres que usaron una versión de GKE afectada en algún momento.
• Clústeres que tenían versiones no compatibles (served=false) de objetos de CRD almacenados en etcd.

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 status.storedVersions con el comando kubectl patch.

• 1.32.2-gke.1652003 o posterior
• 1.31.6-gke.1221001 o posterior
• 1.30.10-gke.1227001 o superior

Faltan métricas o el escalador automático de cargas de trabajo no escala

Es 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 podría afectar las operaciones de ajuste de escala automático.

Este problema solo afecta a los clústeres actualizados a las versiones afectadas. Los clústeres recién creados deberían funcionar según lo previsto.

Solución alternativa:

Si te ves afectado, puedes cambiar a una versión de parche anterior o actualizar a las versiones corregidas más recientes.

Límites de tamaño y conexión de Google Cloud Hyperdisk

Por lo general, un Pod que no se puede programar correctamente debido a los límites de conexión de volúmenes de un nodo activa el aprovisionamiento automático de un nodo nuevo. Cuando las cargas de trabajo en ejecución que usan un producto de Hyperdisk se programan 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 la falta de un disco conectado 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 presenta en todos los productos de Hyperdisk en las 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 Google Cloud Hyperdisk activan el aprovisionamiento automático en otras formas de VM. Recomendamos una forma que solo admita Google Cloud Hyperdisk.

gke-metadata-server se cierra por falta de memoria en los nodos de TPU/GPU

En los nodos TPU de GKE (por ejemplo, ct4p-hightpu-4t) y los nodos GPU (por ejemplo, a3-highgpu-8g), el kernel podría finalizar el gke-metadata-server con un OOMKilled cuando el uso de memoria del servidor supere los 100 MB.

Solución alternativa:

Si observas eventos OOMKilled para gke-metadata-server en nodos de TPU o GPU, comunícate con el equipo de guardia de GKE Identity (ID del componente: 395450) para obtener opciones de mitigación.

• De 1.32.0-gke.1358000 a 1.32.4-gke.1106006, 1.32.4-gke.1236007, 1.32.4-gke.1353001, 1.32.4-gke.1415001 y 1.32.4-gke.1533000
• De 1.33.0-gke.0 a 1.33.0-gke.1552000

• 1.32.4-gke.1353003 y versiones posteriores
• 1.33.0-gke.1552000 y versiones posteriores

Es posible que los cambios de tamaño de los volúmenes se detengan debido al estado NodePendingResize pendiente en las PVC.

Los clústeres de la versión 1.32 que tengan nodos de la versión 1.31 o anterior no podrán actualizar el estado de PersistentVolumeClaim durante el cambio de tamaño. Este estado incorrecto impide que se inicien las operaciones de cambio de tamaño posteriores, lo que evita que se realicen más cambios de tamaño.

Una PVC en este estado tiene un campo status.allocatedResourceStatuses que contiene NodePendingResize o el campo status.allocatedResources y status.conditions.type: FileSystemResizePending.

Si se creó una 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, se debe aplicar un parche a tu PVC para quitar el campo status.allocatedResources con una solución alternativa única.

Solución alternativa:

Las PVC bloqueadas debido al estado pendiente se pueden parchar 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}}'

• 1.32.4-gke.1236007, 1.32.4-gke.1353001

• 1.32.4-gke.1353003 y versiones posteriores

El controlador de PDCSI podría registrar de forma excesiva

Los clústeres de GKE en versiones específicas de la 1.32 podrían emitir mensajes de registro excesivos del controlador de PDCSI. Este exceso de registros consumiría la cuota de la API de Write de Cloud Logging.

Solución alternativa:

Para reducir este registro excesivo, agrega 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")
    

• 1.27.16-gke.2440000 y versiones posteriores
• 1.28.15-gke.1673000 y versiones posteriores
• 1.29.13-gke.1038000 y versiones posteriores
• 1.30.9 y posteriores
• 1.31.7 y posteriores
• 1.32.1-gke.1357001 y versiones posteriores

• 1.27.16-gke.2691000 y versiones posteriores
• 1.28.15-gke.2152000 y versiones posteriores
• 1.29.15-gke.1218000 y versiones posteriores
• 1.30.11-gke.1190000 y versiones posteriores
• 1.31.7-gke.1363000 y versiones posteriores
• 1.32.4-gke.1106000 y versiones posteriores
• 1.33.0-gke.1552000 y versiones posteriores

Los Pods que intenten activar volúmenes persistentes de NFS en nodos de COS que antes 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 de Kubernetes solo pueden activar volúmenes persistentes en modo RO después de una activación de 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.

• Versiones 1.32 desde la 1.32.1-gke.1357001 hasta la 1.32.4-gke.1106000, sin incluirla
• Todas las versiones 1.33 anteriores a la 1.33.0-gke.1552000

• Versión 1.32: 1.32.4-gke.1106000 y posteriores
• Versión 1.33: 1.33.0-gke.1552000 y posteriores

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"

Además de ver estos mensajes de error, los Pods que usen estos volúmenes no podrán iniciarse.

Solución alternativa:

Cambia a una versión inferior de los grupos de nodos a la versión 1.31.

• 1.28.15-gke.1668000 o posterior
• 1.29.13-gke.1028000 o superior
• 1.30.8-gke.1287000 o posterior
• 1.31.6-gke.1020000 o superior
• 1.32.1-gke.1369000 o posterior

Los Pods que usan llamadas al sistema relacionadas con io_uring podrían quedar atascados en el estado Terminating

Los Pods que usan llamadas al sistema relacionadas con io_uring pueden ingresar al estado D (suspensión del disco), que también se llama TASK_UNINTERRUPTIBLE, debido a un error en el kernel de Linux. Los procesos en estado D no se pueden activar con indicadores, incluido SIGKILL.

Cuando un Pod se ve afectado por este problema conocido, es posible que sus contenedores no finalicen con normalidad. En los registros de containerd, es posible que observes mensajes repetidos similares a los siguientes: Kill container [container-id], que indican que el sistema intenta detener un contenedor de forma reiterada.
Al mismo tiempo, los registros de kubelet muestran mensajes de error, como los siguientes:

"Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded"

o

"Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid"

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 usan io_uring de forma indirecta a través de un entorno 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 del disco) en el archivo /proc/<pid>/state y muestran la cadena io_uring como parte del contenido de /proc/<pid>/stack. Es posible que las cargas de trabajo de NodeJS puedan inhabilitar el uso de io_uring a través de UV_USE_IO_URING=0.

Solución alternativa:

Actualiza los nodos del clúster a una versión fija o posterior.

• 1.30.8-gke.1261000 y versiones posteriores
• 1.31.4-gke.1183000 y versiones posteriores
• 1.32.0-gke.1448000 y versiones posteriores

Las cargas de trabajo que usan la transmisión de imágenes fallan con errores de autenticación

Un 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 fallas de autenticación se vean en el registro de gcfsd.

Para verificar si te afecta, busca en los registros con esta consulta de búsqueda: resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential."

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 parches.

• De 1.30.0 a 1.30.5-gke.1443001
• De 1.31.0 a 1.31.1-gke.1678000

• 1.30.5-gke.1628000 y versiones posteriores
• 1.31.1-gke.1846000 y versiones posteriores

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 CONFIG_LRU_GEN_ENABLED=y. Esta opción habilita la función del kernel LRU de varias generaciones, que hace que el kubelet calcule de forma incorrecta el uso de memoria y puede provocar que el kubelet expulse Pods.

La opción de configuración CONFIG_LRU_GEN_ENABLED está inhabilitada en cos-113-18244-151-96 y cos-117-18613-0-76.

Es posible que no siempre veas una tasa de expulsión 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 el kubelet expulse Pods para las cargas de trabajo que no establecieron 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 el kubelet informa como disponible.

Si ves 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 expulsión de Pods inusuales, analiza las siguientes métricas con el Explorador de métricas: kubernetes.io/container_memory_used_bytes y kubernetes.io/container_memory_request_bytes

Puedes usar las siguientes consultas de PromQL. Reemplaza los valores de cluster_name, namespace_name, metadata_system_top_level_controller_type y metadata_system_top_level_controller_name por el nombre y el tipo de carga de trabajo que deseas analizar:

Si ves aumentos repentinos inusuales en el uso de memoria que superan la memoria solicitada, es posible que la carga de trabajo se expulse con más frecuencia.

Solución alternativa

Si 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 de LRU multigeneracional con un DaemonSet.

1. Actualiza los grupos de nodos de GKE desde los que deseas ejecutar el DaemonSet con una anotación para inhabilitar la opción de LRU multigeneracional. Por ejemplo, disable-mglru: "true".
2. Actualiza el parámetro nodeSelector en el manifiesto del DaemonSet con la misma anotación que usaste en el paso anterior. Por ejemplo, consulta el archivo disable-mglru.yaml en el repositorio GoogleCloudPlatform/k8s-node-tools.
3. Implementa el DaemonSet en tu clúster.

Después de que el DaemonSet se ejecute en todos los grupos de nodos seleccionados, el cambio se aplicará de inmediato y el cálculo del uso de memoria de kubelet volverá a la normalidad.

• 1.28.14-gke.1175000 y versiones posteriores
• 1.29.9-gke.1341000 y versiones posteriores
• 1.30.5-gke.1355000 y versiones posteriores
• 1.31.1-gke.1621000 y versiones posteriores

Pods atascados en el estado Terminating

Un error en el entorno de ejecución del contenedor (containerd) puede hacer que los Pods y los contenedores se queden bloqueados en el estado Terminating con errores similares a los siguientes:

Si este problema te afecta, puedes actualizar tus nodos a una versión de GKE con una versión corregida de containerd.

• 1.34 y anteriores
• Versiones 1.35 anteriores a la 1.35.6-gke.1005000
• Versiones 1.36 anteriores a la 1.36.0-gke.2459000

• 1.35.6-gke.1005000 y versiones posteriores
• 1.36.0-gke.2459000 y versiones posteriores

La transmisión de imágenes falla debido a los vínculos simbólicos

Un error en la función de transmisión de imágenes puede provocar que los contenedores no se inicien.

Es posible que los contenedores que se ejecutan en un nodo con la transmisión de imágenes habilitada en versiones específicas de GKE no se creen con el siguiente error:

Solución alternativa:

Para resolver este problema, actualiza tus grupos de nodos a una versión fija (1.35.6-gke.1005000 o posterior, o 1.36.0-gke.2459000 o posterior).

Si no puedes actualizar, 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.

• 1.28.9-gke.1103000 y versiones posteriores
• 1.29.4-gke.1202000 y versiones posteriores
• 1.30: Todas las versiones

La transmisión de imágenes falla debido a que faltan archivos

Un error en la función de transmisión de imágenes puede hacer que los contenedores fallen debido a que faltan 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 siguientes versiones no se inicien o se ejecuten con errores que informen que ciertos archivos no existen. A continuación, se muestran ejemplos de estos errores:

• No such file or directory
• Executable file not found in $PATH

Si este problema te afecta, puedes inhabilitar la transmisión de imágenes.

Error de configuración de TLS de la puerta de enlace

Identificamos 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.

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 podrían experimentar problemas con los complementos de dispositivos de GPU de sus nodos (nvidia-gpu-device-plugin). Sigue estos pasos según el estado de tu clúster:

• Si tu clúster ejecuta la versión 1.26 y tiene GPU, no lo actualices de forma manual hasta que la versión 1.27.8 esté disponible en el canal de versiones del clúster.
• Si tu clúster ejecuta una versión de parche 1.27 anterior y los nodos se ven afectados, reinícialos o borra de forma manual el Pod nvidia-gpu-device-plugin en los nodos (el administrador de complementos creará un complemento de trabajo nuevo).
• Si tu clúster usa actualizaciones automáticas, esto no te afecta, ya que las actualizaciones automáticas solo moverán los clústeres a versiones de parches con la corrección.

• 1.27.5-gke.1300 y versiones posteriores
• 1.28.1-gke.1400 y versiones posteriores

Se detiene el ajuste de escala automático para todas las cargas de trabajo

HorizontalPodAutoscaler (HPA) y VerticalPodAutoscaler (VPA) podrían dejar de escalar automáticamente todas las cargas de trabajo de un clúster si contiene objetos de HPA de autoscaling/v2 mal configurados. El problema afecta a los clústeres que ejecutan versiones de parches anteriores de GKE 1.27 y 1.28 (por ejemplo, 1.27.3-gke.100).

Solución alternativa:

Corrige los objetos HPA autoscaling/v2 mal configurados asegurándote de que los campos de spec.metrics.resource.target coincidan, por ejemplo:

• Cuando spec.metrics.resource.target.type es Utilization, el destino debe ser averageUtilization
• Cuando spec.metrics.resource.target.type es AverageValue, el destino debe ser averageValue

Para obtener más detalles sobre cómo configurar objetos HPA de autoscaling/v2, consulta la documentación de Kubernetes sobre HorizontalPodAutoscaler.

• 1.28.7-gke.1026000
• 1.29.2-gke.1060000

No se puede implementar Container Threat Detection

Es posible que Container Threat Detection no se implemente en los clústeres de Autopilot que ejecutan las siguientes versiones de GKE:

• De 1.28.6-gke.1095000 a 1.28.7-gke.1025000
• De 1.29.1-gke.1016000 a 1.29.1-gke.1781000

• 1.30.4-gke.1282000 o posterior
• 1.29.8-gke.1157000 o superior
• 1.28.13-gke.1078000 o superior
• 1.27.16-gke.1342000 o posterior

Problemas de conectividad para los Pods de hostPort después de la actualización del plano de control

Los clústeres con la política de red habilitada pueden experimentar problemas de conectividad con los Pods hostPort. Además, los Pods recién creados pueden tardar entre 30 y 60 segundos adicionales en estar listos.

El problema se activa cuando el plano de control de GKE de un clúster se actualiza a una de las siguientes versiones de GKE

• 1.30 a 1.30.4-gke.1281999
• De 1.29.1-gke.1545000 a 1.29.8-gke.1156999
• De 1.28.7-gke.1042000 a 1.28.13-gke.1077999
• De 1.27.12-gke.1107000 a 1.27.16-gke.1341999

Solución alternativa:

Actualiza o vuelve a crear los nodos inmediatamente después de la actualización del plano de control de GKE.

• 1.32.1-gke.1729000 o superior
• 1.31.6-gke.1020000 o superior

Tráfico UDP interrumpido entre Pods que se ejecutan en el mismo nodo

Los clústeres con la visibilidad dentro de los nodos habilitada pueden experimentar un tráfico 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:

• 1.32.1-gke.1729000 o superior
• 1.31.6-gke.1020000 o superior

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.32.3-gke.1927000 o posterior
• 1.31.7-gke.1390000 o superior

• 1.29.10-gke.1071000 o superior
• 1.30.5-gke.1723000 o posterior
• 1.31.2-gke.1115000 o posterior

Incompatibilidad entre Ray Operator y la encriptación de la base de datos de Cloud KMS

Algunas versiones de Ray Operator no son compatibles 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 fija o posterior.

• 1.30.8-gke.1051000 o posterior
• 1.31.1-gke.2008000 y versiones posteriores

El Pod del controlador de mantenimiento de GPU se queda atascado en el estado CrashLoopBackOff

Con este problema, los Pods de gpu-maintenance-handler se quedan atascados en el estado "CrashLoopBackOff" en sus nodos respectivos. Este estado evita que se aplique la etiqueta "mantenimiento próximo" a los nodos de GKE, lo que puede afectar los procesos de desvío de nodos y expulsión de Pods para las cargas de trabajo.

Si este problema te afecta, puedes resolverlo actualizando tu plano de control a una versión de GKE que incluya la corrección.

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: Failed to create pod sandbox ... context deadline exceeded

Los registros del puerto en serie de un nodo afectado también contienen la siguiente firma de error: task gcfsd ... blocked for more than X seconds

La presencia de estas dos firmas de error indica un interbloqueo en uno de los componentes de transmisión de imágenes. Este interbloqueo impide que los Pods se inicien correctamente.

Mitigación:

Reinicia el nodo para una mitigación rápida. Ten en cuenta que el nodo reiniciado podría volver a encontrar el interbloqueo. Para una mitigación más sólida, inhabilita la transmisión de imágenes en el grupo de nodos ejecutando lo siguiente:

gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming

• 1.32.4-gke.1198000 y versiones posteriores
• Versiones 1.33 anteriores a la 1.33.5-gke.1862000
• Versiones 1.34 anteriores a la 1.34.1-gke.2541000

• 1.33.5-gke.1862000 y versiones posteriores
• 1.34.1-gke.2541000 y versiones posteriores

ComputeClasses personalizadas con ImageType que no usan grupos de nodos de GKE existentes.

Cuando se usa una ComputeClass personalizada que define un campo ImageType, el escalador automático de clústeres crea y escala verticalmente de forma repetida grupos de nodos nuevos en lugar de escalar verticalmente los grupos de nodos existentes. El estado de ComputeClass no es correcto.

Solución alternativa:

Actualiza el clúster a una de las siguientes versiones corregidas:

• 1.33.5-gke.1862000 o posterior
• 1.34.1-gke.2541000 o superior

Como alternativa, puedes mitigar este problema si no defines ciertos campos en la ComputeClass personalizada.

• Si no usas una ComputeClass personalizada de Autopilot, no definas el campo ImageType. En este caso, el valor que se usa es el parámetro de configuración predeterminado a nivel del clúster, que es cos_containerd.
• Si usas una ComputeClass personalizada de Autopilot, no definas el campo nodePoolConfig, que es un nivel ImageType.