Acerca de las ComputeClasses personalizadas

Puedes crear tus propias ComputeClasses para controlar las propiedades de los nodos que Google Kubernetes Engine (GKE) aprovisiona cuando se ajusta automáticamente la escala de tu clúster. Este documento está dirigido a los administradores de plataformas que desean definir de forma declarativa perfiles de ajuste de escala automático para los nodos, de modo que las cargas de trabajo específicas se ejecuten en hardware que cumpla con sus requisitos. Para obtener más información sobre qué son las ComputeClasses, consulta Acerca de las ComputeClasses de GKE.

Descripción general de ComputeClasses

En GKE, una ComputeClass es un perfil que consta de un conjunto de atributos de nodos que GKE usa para aprovisionar los nodos que ejecutan tus cargas de trabajo durante los eventos de escalamiento automático. Las ComputeClasses pueden segmentar optimizaciones específicas, como el aprovisionamiento de nodos de alto rendimiento o la priorización de configuraciones optimizadas para el costo y, así, reducir los costos de ejecución. Las ComputeClasses personalizadas te permiten definir perfiles que GKE usa para ajustar automáticamente la escala de los nodos y satisfacer de cerca los requisitos de cargas de trabajo específicas.

Las ComputeClasses personalizadas están disponibles para usarse en el modo Autopilot de GKE y en el modo estándar de GKE en la versión 1.30.3-gke.1451000 y posteriores, y ofrecen un enfoque declarativo para definir los atributos de los nodos y las prioridades del ajuste de escala automático. Las ComputeClasses personalizadas están disponibles para configurarse y usarse en todos los clústeres de GKE aptos de forma predeterminada.

Beneficios de las ComputeClasses personalizadas

Las ComputeClasses personalizadas ofrecen los siguientes beneficios:

  • Prioridades de procesamiento de respaldo: Define una jerarquía de configuraciones de nodos en cada ComputeClass para que GKE las priorice. Si la configuración más preferida no está disponible, GKE elige automáticamente la siguiente configuración en la jerarquía. Este modelo de respaldo garantiza que, incluso cuando los recursos de procesamiento no estén disponibles, tus cargas de trabajo se sigan ejecutando en hardware optimizado con demoras de programación mínimas.
  • Control granular del ajuste de escala automático: Define configuraciones de nodos que se adapten mejor a cargas de trabajo específicas. GKE prioriza esas configuraciones cuando crea nodos durante el ajuste de escala.
  • Configuración declarativa de la infraestructura: Adopta un enfoque declarativo para la administración de la infraestructura, de modo que GKE cree automáticamente nodos que coincidan con los requisitos específicos de tu carga de trabajo.
  • Migración activa: Si los recursos de procesamiento para una configuración de máquina más preferida están disponibles en tu ubicación, GKE migra automáticamente tus cargas de trabajo a nodos nuevos que usan la configuración preferida.
  • Optimización de costos: Prioriza los tipos de nodos rentables, como las VMs Spot, para reducir los gastos del clúster.
  • ComputeClasses personalizadas predeterminadas: Establece una ComputeClass personalizada como la predeterminada para todo un clúster o para espacios de nombres de Kubernetes específicos, de modo que las cargas de trabajo se ejecuten en hardware optimizado incluso si no solicitan una ComputeClass específica.
  • Umbrales de consolidación de nodos personalizados: Define umbrales de uso de recursos personalizados para los nodos. Si el uso de recursos de un nodo específico cae por debajo del umbral, GKE intenta consolidar las cargas de trabajo en un nodo similar disponible y reduce la escala del nodo subutilizado.

Casos de uso de ComputeClasses personalizadas

Considera usar ComputeClasses personalizadas en situaciones como las siguientes:

  • Deseas ejecutar tus cargas de trabajo de IA/AA en configuraciones específicas de GPU o TPU.
  • Deseas establecer parámetros de configuración de hardware predeterminados para las cargas de trabajo que ejecutan equipos específicos, lo que quita la sobrecarga de los operadores de aplicaciones.
  • Ejecutas cargas de trabajo que tienen un rendimiento óptimo en series de máquinas o configuraciones de hardware específicas de Compute Engine.
  • Quieres declarar configuraciones de hardware que cumplan con requisitos comerciales específicos, como alto rendimiento, optimización de costos o alta disponibilidad.
  • Deseas que GKE recurra jerárquicamente al uso de configuraciones de hardware específicas durante la falta de disponibilidad de recursos de procesamiento, de modo que tus cargas de trabajo siempre se ejecuten en máquinas que se adapten a sus requisitos.
  • Deseas decidir de forma centralizada las configuraciones óptimas en toda la flota de tu empresa para que tus costos sean más predecibles y tus cargas de trabajo se ejecuten de manera más confiable.
  • Quieres especificar de forma centralizada cuáles de tus reservas de capacidad de Compute Engine debe usar GKE para aprovisionar nodos nuevos para cargas de trabajo específicas.
  • Deseas especificar una política de posición compacta para usar con GKE Autopilot. Para obtener más información, consulta posición compacta.

Cómo funcionan las ComputeClasses personalizadas

Las ComputeClasses personalizadas son recursos personalizados de Kubernetes que aprovisionan infraestructura deGoogle Cloud . Defines un objeto ComputeClass en el clúster y, luego, solicitas ese objeto ComputeClass en las cargas de trabajo o lo estableces como el valor predeterminado para un espacio de nombres de Kubernetes. Cuando una carga de trabajo coincidente exige infraestructura nueva, GKE aprovisiona nodos nuevos en función de las prioridades que estableces en la definición de ComputeClass.

Los atributos que configuras en tus ComputeClasses definen cómo GKE configura los nodos nuevos para ejecutar cargas de trabajo. Cuando modificas un ComputeClass existente, todos los nodos futuros que GKE cree para ese ComputeClass usarán la configuración modificada. GKE no cambia de forma retroactiva la configuración de los nodos existentes para que coincidan con tus modificaciones.

Las ComputeClasses personalizadas influyen en las decisiones de ajuste de escala automático, pero kube-scheduler no las tiene en cuenta. Durante la programación de Pods, es posible que el programador no priorice los nodos con prioridades de ComputeClass personalizadas más altas, incluso cuando haya nodos disponibles en varias prioridades.

Para asegurarte de que tus ComputeClasses personalizadas estén optimizadas para tu flota, ten en cuenta los siguientes lineamientos:

  • Comprende los requisitos de procesamiento de tu flota, incluidos los requisitos de hardware específicos de la aplicación.
  • Decide un tema que guíe el diseño de cada ComputeClass. Por ejemplo, una ComputeClass optimizada para el rendimiento podría tener una estrategia de resguardo que solo use tipos de máquinas con alta capacidad de CPU.
  • Decide qué familia y serie de máquinas de Compute Engine se ajustan mejor a tus cargas de trabajo. Para obtener más detalles, consulta la guía de comparación y recursos de familias de máquinas.
  • Planifica una estrategia de resguardo dentro de cada ComputeClass para que las cargas de trabajo siempre se ejecuten en nodos que usen configuraciones de máquinas similares. Por ejemplo, si la serie de máquinas N4 no está disponible, puedes recurrir a las máquinas C3.

Visualiza la definición de recurso personalizado completa

Para ver la definición de recurso personalizado (CRD) más reciente del recurso personalizado ComputeClass, incluidos todos los campos y sus relaciones, consulta la documentación de referencia de ComputeClass.

También puedes ver la CRD en tu clúster ejecutando el siguiente comando:

kubectl describe crd computeclasses.cloud.google.com

Planifica una ComputeClass personalizada

Para planificar, implementar y usar de manera eficaz una ComputeClass personalizada en tu clúster, sigue estos pasos:

  1. Elige tus prioridades de procesamiento de resguardo: Define una serie de reglas que rigen las propiedades de los nodos que GKE crea para la ComputeClass.
  2. Configura los grupos de nodos y las ComputeClasses de GKE Standard: Para los clústeres del modo Standard, realiza los pasos de configuración necesarios para usar la ComputeClass con tus grupos de nodos.
  3. Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad: De manera opcional, indícale a GKE qué debe hacer si no se pueden aprovisionar los nodos que cumplen con tus reglas de prioridad.
  4. Configura parámetros de ajuste de escala automático para la consolidación de nodos: Indica a GKE cuándo consolidar cargas de trabajo y quitar nodos subutilizados.
  5. Configura la migración activa a nodos de prioridad más alta: Opcionalmente, puedes indicarle a GKE que traslade las cargas de trabajo a nodos más preferidos a medida que el hardware esté disponible.
  6. Consume reservas de Compute Engine: De forma opcional, indícale a GKE que consuma las reservas zonales existentes de Compute Engine cuando cree nodos nuevos.

Elige tus prioridades de procesamiento de resguardo

La principal ventaja de usar una ComputeClass personalizada es tener control sobre la estrategia de resguardo cuando los nodos preferidos no están disponibles debido a factores como el agotamiento de recursos y las limitaciones de cuota.

Para crear una estrategia de resguardo, debes definir una lista de reglas de prioridad en tu ComputeClass personalizada. Cuando un clúster necesita escalar, GKE prioriza la creación de nodos que coincidan con la regla de primera prioridad. Si GKE no puede crear esos nodos, recurre a la siguiente regla de prioridad y repite este proceso hasta que GKE escale verticalmente el clúster correctamente o agote todas las reglas. Si se agotan todas las reglas, GKE crea nodos según el comportamiento predeterminado o especificado que se describe en Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad.

Las diferentes series de máquinas de Compute Engine admiten diferentes tecnologías y funciones. Es posible que las generaciones anteriores de una serie de máquinas no admitan los mismos tipos de almacenamiento que las generaciones más recientes. Si ejecutas cargas de trabajo con estado que dependen de datos persistentes, evita usar una ComputeClass que abarque varias generaciones de una serie de máquinas. Es posible que las cargas de trabajo no puedan acceder a los datos persistentes si GKE las coloca en un tipo de máquina que no admite ese tipo de almacenamiento. Para obtener más detalles, filtra la tabla comparativa de series de máquinas para ver tipos de almacenamiento específicos.

Reglas de prioridad

Puedes definir reglas de prioridad en el campo spec.priorities del recurso personalizado ComputeClass. Cada regla del campo priorities describe las propiedades de los nodos que se aprovisionarán. GKE procesa el campo priorities en orden, lo que significa que el primer elemento del campo tiene la prioridad más alta para el aprovisionamiento de nodos.

Existen dos tipos de reglas de prioridad:

  • Tipos de reglas declarativas: Usa las características del nodo para describir los nodos que deseas aprovisionar.

  • Tipo de regla del grupo de nodos: En los clústeres de GKE Standard, proporciona una lista de grupos de nodos creados de forma manual que están asociados con la ComputeClass en la que GKE debe aprovisionar nodos.

Reglas de prioridad declarativas

Con las reglas de prioridad declarativas, puedes especificar propiedades de la máquina, como la familia o el tipo de máquina, las VMs Spot, las opciones de aceleradores, las opciones de almacenamiento, las reservaciones y los requisitos mínimos de recursos, para que GKE los use cuando aprovisione nodos. Para obtener el conjunto completo de campos admitidos, consulta la referencia del CRD de ComputeClass.

Configuraciones de machineFamily

El campo machineFamily acepta una serie de máquinas de Compute Engine, como n4 o c4. Si no se especifica, el valor predeterminado es e2.

Puedes usar otros spec.priorities campos junto con el campo machineFamily para definir de forma declarativa tus requisitos de procesamiento, por ejemplo:

  • spot: VMs Spot. El valor predeterminado es false.
  • minCores: Es la cantidad mínima de CPU virtuales por nodo. El valor predeterminado es 0.
  • minMemoryGb: Es la memoria mínima por nodo. El valor predeterminado es 0.
  • storage.bootDiskKMSKey: Es la ruta de acceso a la clave de Cloud Key Management Service que se usará para la encriptación del disco de arranque.
  • storage.secondaryBootDisks: Son discos persistentes que se usan para precargar datos en los nodos de GKE, como un modelo de aprendizaje automático (AA) o una imagen de contenedor. Se requiere la versión 1.31.2-gke.1105000 o posterior de GKE. Para configurar un disco de arranque secundario que pueda usar tu clúster, consulta cómo configurar discos de arranque secundarios.
    • storage.secondaryBootDisks.diskImageName: Es el nombre de la imagen de disco que se precargará.
    • storage.secondaryBootDisks.project: Es el nombre del proyecto al que pertenece la imagen de disco. Si no se especifica este valor, el valor predeterminado es el proyecto de tu clúster.
    • storage.secondaryBootDisks.mode: Es el modo en el que se debe usar el disco de arranque secundario. Si este valor se establece en CONTAINER_IMAGE_CACHE, el disco de arranque secundario se usa como caché de imágenes de contenedor. El valor debe ser igual a CONTAINER_IMAGE_CACHE o MODE_UNSPECIFIED. Si no se especifica este valor, el valor predeterminado es MODE_UNSPECIFIED.
  • placement: Detalles específicos sobre la ubicación de la máquina:

En el siguiente ejemplo, se muestra una regla de prioridad que usa machineFamily:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset
Configuraciones de machineType

El campo machineType acepta un tipo de máquina predefinido de Compute Engine, como n4-standard-32, o una cadena de tipo de máquina personalizada, como n4-custom-8-20480. Para usar tipos de máquinas personalizados, se requiere la versión 1.33.2-gke.1111000 de GKE o una posterior.

Puedes especificar otros campos spec.priorities junto con el campo machineType para definir de forma declarativa tus requisitos de procesamiento, por ejemplo:

  • spot: Usa VMs Spot La ruta predeterminada es false.
  • storage: Configura el almacenamiento de nodos.
    • storage.bootDiskType: Tipo de disco de arranque En Autopilot, solo se admite el tipo pd-balanced de bootDiskType.
    • storage.bootDiskKMSKey: Es la ruta de acceso a la clave de Cloud KMS que se usará para la encriptación del disco de arranque.
    • storage.bootDiskSize: Es el tamaño en GB del disco de arranque del nodo.
    • storage.localSSDCount: Es la cantidad de SSD locales que se conectarán al nodo. Si se especifica, debe ser al menos 1.

En el siguiente ejemplo, se muestra una regla de prioridad que usa machineType para aprovisionar tipos de máquinas n4-standard-32:

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
Configuración de GPU

Para seleccionar GPUs en tus reglas de prioridad, especifica el tipo, el recuento y driverVersion (opcional) de la GPU en el campo gpu de una regla de prioridad. Se admiten los siguientes campos:

  • gpu.type: Es un tipo de GPU, como nvidia-l4. Para obtener más información, consulta Elige la compatibilidad con GPU con Autopilot o Standard.
  • gpu.count: Es la cantidad de GPUs que se adjuntarán. Para conocer las cantidades admitidas por tipo de GPU, consulta Cantidades de GPU admitidas.
  • gpu.driverVersion: Es la versión del controlador NVIDIA que se instalará. Debe ser default o latest. Se requiere la versión 1.31.1-gke.1858000 de GKE o una posterior.

También puedes especificar otros spec.priorities campos, como VMs Spot, opciones de almacenamiento y reservas en combinación con los campos gpu.

En el siguiente ejemplo, se muestra una regla para las GPUs:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true
Configuración de TPU

Se requiere la versión 1.31.2-gke.1518000 o posterior de GKE

Para seleccionar TPUs en tus reglas de prioridad, especifica el tipo, la cantidad y la topología de la TPU en el campo tpu de una regla de prioridad. Los siguientes campos son obligatorios:

También puedes especificar otros spec.priorities campos junto con el campo tpu en tu regla de prioridad, por ejemplo:

  • spot: Usa VMs Spot La ruta predeterminada es false.
  • storage: Configura el almacenamiento de nodos.
    • storage.bootDiskType: Tipo de disco de arranque
    • storage.bootDiskKMSKey: Es la ruta de acceso a la clave de Cloud KMS que se usará para la encriptación del disco de arranque.
    • storage.bootDiskSize: Es el tamaño en GB del disco de arranque del nodo.
  • reservations: Usa una reserva de Compute Engine. Para obtener más información, consulta la sección Cómo consumir reservas de Compute Engine.

En el siguiente ejemplo, se muestra una regla para las TPU:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

En este ejemplo, se define el siguiente comportamiento de resguardo:

  1. GKE intenta aprovisionar una porción de TPU v5p de varios hosts con 16 nodos consumiendo una reserva compartida de Compute Engine llamada tpu-reservation del proyecto reservation-project.
  2. Si la reserva no tiene TPUs disponibles, GKE intenta aprovisionar una porción de TPU v5p de varios hosts con 16 nodos que se ejecutan en VMs Spot.
  3. Si no se cumple ninguna de las reglas anteriores, GKE sigue la lógica de la sección Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad.

Después de implementar una ComputeClass personalizada de TPU en tu clúster, selecciona esa ComputeClass personalizada en tu carga de trabajo:

Además, para las cargas de trabajo de TPU, puedes hacer lo siguiente:

Especificaciones de aceleradores y formas de máquinas

Las configuraciones de acelerador declarativas no requieren que se especifiquen de forma explícita los campos machineType o machineFamily, a menos que los uses en combinación con reservas.

Reglas de prioridad de grupos de nodos

El campo nodepools toma una lista de grupos de nodos existentes en los que GKE intenta crear Pods pendientes. GKE no procesa los valores de este campo en orden. No puedes usar otros campos spec.priorities junto con el campo nodepools en el mismo elemento de regla de prioridad porque las reglas con el campo nodepools no son declarativas por naturaleza. Este campo solo es compatible con el modo GKE Standard. Para obtener detalles sobre el uso, consulta Segmenta grupos de nodos específicos en una definición de ComputeClass.

Cómo crea nodos GKE con reglas de prioridad

Cuando implementas una carga de trabajo que solicita un objeto ComputeClass y se necesita un nodo nuevo, GKE procesa la lista de reglas en el campo priorities de la especificación ComputeClass en orden.

Por ejemplo, considera la siguiente especificación:

spec:
  ...
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false

Cuando implementas una carga de trabajo que solicita una ComputeClass con estas reglas de prioridad, GKE hace coincidir los nodos de la siguiente manera:

  1. GKE coloca los Pods en cualquier nodo existente asociado a esta ComputeClass.
  2. Si los nodos existentes no pueden alojar los Pods, GKE aprovisiona nodos nuevos que usan la serie de máquinas N4, son VMs Spot y tienen al menos 64 CPUs virtuales.
  3. Si las VMs Spot N4 con al menos 64 CPUs virtuales no están disponibles en la región, GKE aprovisiona nodos nuevos que usan VMs Spot N4 que pueden ajustarse a los Pods, sin importar la cantidad de núcleos.
  4. Si no hay VMs Spot N4 disponibles en la región, GKE aprovisiona nuevas VMs N4 según demanda.
  5. Si no se cumple ninguna de las reglas anteriores, GKE sigue la lógica de la sección Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad.

Valores predeterminados para las reglas de prioridad

Puedes establecer valores predeterminados para algunos de los campos en las reglas de prioridad de tu especificación de ComputeClass. Estos valores predeterminados se aplican si se omiten los campos correspondientes en una regla específica. Puedes establecer estos valores predeterminados con el campo priorityDefaults en la especificación de ComputeClass.

El campo priorityDefaults tiene las siguientes limitaciones:

  • Se requiere la versión 1.32.1-gke.1729000 o posterior de GKE.
  • No es compatible con la regla de prioridad nodepools, que no contiene ningún campo.

Para obtener detalles sobre los tipos de valores predeterminados que puedes establecer, consulta la sección priorityDefaults en la CustomResourceDefinition de ComputeClass.

Grupos de nodos de GKE Standard y ComputeClasses

Si usas el modo GKE Standard, es posible que debas realizar una configuración manual para asegurarte de que los Pods de ComputeClass se programen como se espera.

Configura grupos de nodos creados de forma manual para el uso de ComputeClass

Si tus clústeres de GKE Standard tienen grupos de nodos que creaste de forma manual, debes configurarlos para asociarlos con ComputeClasses específicas. GKE solo programa los Pods que solicitan una ComputeClass específica en los nodos de los grupos de nodos que asocias con esa ComputeClass. Este requisito no se aplica a una ComputeClass que configures como predeterminada a nivel del clúster.

El modo GKE Autopilot y los grupos de nodos creados automáticamente en el modo GKE Standard realizan esta configuración por ti.

Para asociar un grupo de nodos creado manualmente con un objeto ComputeClass, agrega etiquetas de nodo y taints de nodos al grupo de nodos durante la creación o durante una actualización especificando las marcas --node-labels y --node-taints de la siguiente manera:

  • Etiqueta de nodo: cloud.google.com/compute-class=COMPUTE_CLASS
  • Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

En estos atributos, COMPUTE_CLASS es el nombre de tu ComputeClass personalizada.

Por ejemplo, los siguientes comandos actualizan juntos un grupo de nodos existente y asocian el grupo de nodos con la ComputeClass dev-class:

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class"

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

Puedes asociar cada grupo de nodos de tu clúster con una ComputeClass personalizada. Los Pods que GKE programa en estos grupos de nodos creados de forma manual solo activan la creación de nodos dentro de esos grupos durante los eventos de ajuste de escala automático.

Creación automática de grupos de nodos y ComputeClasses

Puedes usar la creación automática de grupos de nodos con una ComputeClass personalizada para permitir que GKE cree y borre automáticamente grupos de nodos según tus reglas de prioridad.

Para permitir que GKE cree automáticamente grupos de nodos para una ComputeClass, debes hacer lo siguiente:

  1. Agrega el campo nodePoolAutoCreation con el valor enabled: true a la especificación de ComputeClass.
  2. A menos que tu clúster esté inscrito en el canal rápido y ejecute la versión 1.33.3-gke.1136000 de GKE o una posterior, también debes habilitar el aprovisionamiento automático de nodos a nivel del clúster.

Luego, GKE puede crear grupos de nodos nuevos para los Pods que usan tu ComputeClass. GKE decide si escalar verticalmente un grupo de nodos existente o crear uno nuevo en función de factores como el tamaño de los clústeres y los requisitos de los Pods. Los Pods con ComputeClasses que no configuran la creación automática de grupos de nodos seguirán escalando verticalmente solo los grupos de nodos existentes.

Puedes usar ComputeClasses que habiliten la creación automática de grupos de nodos junto con ComputeClasses que interactúen con grupos de nodos creados de forma manual en el mismo clúster.

Ten en cuenta las siguientes interacciones con la creación automática de grupos de nodos:

  • No puedes usar los selectores de nodos de familia de máquinas ni de VMs Spot porque estos selectores entran en conflicto con el comportamiento de ComputeClass. GKE rechaza los Pods que solicitan una ComputeClass y también solicitan VMs Spot o series de máquinas específicas.

  • Si estableces una ComputeClass predeterminada para tu clúster, los Pods que usan un selector de nodos de familia de máquinas solo activan la creación de nodos para esa clase predeterminada en una de las siguientes situaciones:

    • Los Pods seleccionan una familia de máquinas que coincide con una de las reglas de prioridad en la clase predeterminada a nivel del clúster. Por ejemplo, un Pod que selecciona instancias N4 activa la creación de nodos si la clase predeterminada a nivel del clúster tiene una regla de prioridad para las instancias N4.
    • El valor predeterminado de ComputeClass a nivel del clúster es ScaleUpAnyway en el campo spec.whenUnsatisfiable. Incluso si los Pods seleccionan una familia de máquinas que no está en las prioridades de ComputeClass, GKE crea nodos nuevos con esa familia de máquinas.

    Los Pods que seleccionen una familia de máquinas que no esté en las prioridades de la clase predeterminada a nivel del clúster no activarán la creación de nodos si ComputeClass tiene un valor de DoNotScaleUp en el campo whenUnsatisfiable.

  • Puedes configurar la creación automática de grupos de nodos para las ComputeClasses que usan el campo nodepools para hacer referencia a los grupos de nodos existentes. GKE procesa las prioridades en orden y trata de escalar verticalmente los grupos de nodos existentes para colocar tus Pods.

Considera el siguiente ejemplo para un clúster que tiene grupos de nodos creados manualmente y creación automática de grupos de nodos:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n4
  - machineFamily: c4
  nodePoolAutoCreation:
    enabled: true

En este ejemplo, GKE intenta hacer lo siguiente:

  1. Crea nodos nuevos en el grupo de nodos manually-created-pool.
  2. Aprovisiona nodos N4, ya sea en grupos de nodos N4 existentes o creando un grupo de nodos nuevo.
  3. Si GKE no puede crear nodos N4, intenta escalar verticalmente los grupos de nodos C4 existentes o crear grupos de nodos C4 nuevos.

Segmenta grupos de nodos específicos en una definición de ComputeClass

El campo priorities.nodepools te permite especificar una lista de grupos de nodos creados de forma manual en los que GKE intenta programar Pods sin un orden específico en los clústeres de GKE Standard que usan el escalamiento automático de clústeres. Este campo solo admite una lista de grupos de nodos. No puedes especificar propiedades de máquinas adicionales, como la serie de máquinas, en la misma regla de prioridad. Cuando implementas una carga de trabajo que solicita una ComputeClass que tiene grupos de nodos con nombre, GKE intenta programar los Pods pendientes en esos grupos de nodos. GKE podría crear nodos nuevos en esos grupos de nodos para colocar los Pods.

Los grupos de nodos que especifiques en el campo priorities.nodepools deben estar asociados con esa ComputeClass a través de etiquetas de nodos y taints de nodos, como se describe en la sección Configura grupos de nodos creados de forma manual para ComputeClasses.

La lista de grupos de nodos que especificas en el campo nodepools no tiene prioridad. Para configurar un orden de resguardo para los grupos de nodos con nombre, debes especificar varios elementos priorities.nodepools separados. Por ejemplo, considera la siguiente especificación:

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

En este ejemplo, GKE primero intenta colocar los Pods pendientes que solicitan esta ComputeClass en los nodos existentes de los grupos de nodos etiquetados con la ComputeClass. Si no hay nodos existentes disponibles, GKE intenta aprovisionar nodos nuevos en pool1 o pool2. Si GKE no puede aprovisionar nodos nuevos en estos grupos de nodos, GKE intenta aprovisionar Pods nuevos en pool3.

Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad

El recurso personalizado ComputeClass te permite especificar qué debe hacer GKE si no hay nodos que puedan cumplir con ninguna de las reglas de prioridad. El campo whenUnsatisfiable de la especificación admite los siguientes valores.

  • ScaleUpAnyway: Crea un nodo nuevo que use la configuración de máquina predeterminada del clúster. En las versiones de GKE anteriores a la 1.33, este es el comportamiento predeterminado si omites este campo.

    GKE realiza una de las siguientes acciones:

    • En los clústeres de Autopilot, GKE coloca el Pod en un nodo nuevo o existente, independientemente de la configuración de la máquina del nodo.
    • En los clústeres estándar que no usan la creación automática de grupos de nodos, GKE intenta escalar cualquier grupo de nodos creado de forma manual que defina una etiqueta y un aislamiento que coincidan con una ComputeClass determinada.
    • En los clústeres estándar que usan la creación automática de grupos de nodos, es posible que GKE cree un grupo de nodos nuevo que use la serie de máquinas E2 predeterminada para colocar el Pod.

  • DoNotScaleUp: Deja el Pod en el estado Pending hasta que esté disponible un nodo que cumpla con los requisitos de ComputeClass. En la versión 1.33 y posteriores de GKE, este es el comportamiento predeterminado si omites este campo.

Solicita una política de posición

A partir de la versión 1.33.2-gke.1335000 de GKE, en los clústeres de GKE Autopilot, puedes usar la ubicación compacta con una política de ubicación o una política de carga de trabajo personalizadas. Para obtener más información, consulta Comparación entre la política de posición compacta y la política de carga de trabajo.

Tanto la política de posición como la política de carga de trabajo colocan los nodos físicamente cerca para reducir la latencia de red. Para usar una política específica, proporciona su nombre en un campo policyName. La política debe ser una política de recursos de Compute Engine que ya exista en el proyecto de GKE.

Considera el siguiente ejemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

En esta configuración, GKE aplica la política de posición compacta para todas las cargas de trabajo que usan este ComputeClass y aprovisiona sus nodos según la política de recursos existente llamada my-placement-policy.

Configura parámetros de ajuste de escala automático para la consolidación de nodos

De forma predeterminada, GKE quita los nodos que no se usan lo suficiente con cargas de trabajo en ejecución y consolida esas cargas de trabajo en otros nodos que tienen capacidad. Para todas las ComputeClasses, este es el comportamiento predeterminado, ya que todos los clústeres que usan ComputeClasses deben usar el escalador automático del clúster o ser clústeres de Autopilot. Durante una consolidación de nodos, GKE drena un nodo que no se usa lo suficiente, vuelve a crear las cargas de trabajo en otro nodo y, luego, borra el nodo drenado.

El momento y los criterios para quitar nodos dependen del perfil de ajuste de escala automático. Puedes ajustar los umbrales de subutilización de recursos que activan la eliminación de nodos y la consolidación de cargas de trabajo con la sección autoscalingPolicy en la definición de ComputeClass personalizada. Puedes ajustar los siguientes parámetros:

  • consolidationDelayMinutes: Es la cantidad de minutos después de los cuales GKE quita los nodos subutilizados.
  • consolidationThreshold: Es el límite de uso de CPU y memoria como un porcentaje de los recursos disponibles del nodo. GKE solo considera la eliminación de nodos si el uso de recursos es inferior a este umbral.
  • gpuConsolidationThreshold: Es el umbral de uso para GPU como un porcentaje de los recursos disponibles del nodo. GKE solo considera la eliminación de nodos si el uso de recursos es inferior a este umbral. Considera establecer este valor en 100 o en 0 para que GKE consolide los nodos que no tengan un uso del 100% de las GPU conectadas.

Considera el siguiente ejemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

En esta configuración, GKE quita los nodos que no se usan después de cinco minutos, y los nodos solo se convierten en candidatos para la consolidación si el uso de CPU y memoria es inferior al 70%.

Migración activa

La migración activa es una función opcional de ajuste de escala automático en las ComputeClasses personalizadas que reemplaza automáticamente los nodos existentes por nodos nuevos. Los nodos se reemplazan según ciertos criterios, según el tipo de migración.

Cuando se produce una migración activa, GKE crea nodos nuevos y, luego, desvía y borra los nodos obsoletos. La migración se realiza de forma gradual para minimizar la interrupción de la carga de trabajo. La migración activa tiene las siguientes consideraciones:

  • La migración activa no migra los datos almacenados en el almacenamiento persistente, como los discos persistentes de Compute Engine. Para minimizar el riesgo de pérdida de datos, no habilites la migración activa en ComputeClasses que usen cargas de trabajo con estado.
  • Si habilitaste el aprovisionamiento automático de nodos en tus clústeres estándar, la migración activa podría activar la creación de grupos de nodos nuevos si los grupos de nodos existentes no cumplen con los criterios definidos en tu clase de procesamiento personalizada.
  • La migración activa no reemplaza los nodos que no se pueden quitar. Por ejemplo, la migración activa no reemplaza un nodo si hacerlo incumple el parámetro de configuración --min-nodes del grupo de nodos.
  • Para evitar interrupciones en las cargas de trabajo críticas, la migración activa no mueve los siguientes Pods:
    • Pods que establecen un PodDisruptionBudget, si el movimiento excedería el PodDisruptionBudget.
    • Son los Pods que tienen la anotación cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • Es posible que las cargas de trabajo que usan volúmenes persistentes con recursos zonales, como Hyperdisk, no funcionen bien con la migración activa. Las restricciones zonales y las restricciones de tipo de máquina de algunos productos de Hyperdisk pueden reducir la eficacia de la migración activa. Además, es posible que algunas cargas de trabajo con estado no toleren la interrupción causada por la migración activa.
  • Si actualizas una ComputeClass existente para habilitar la migración activa, GKE migrará los Pods existentes a nodos nuevos con el tiempo.

Se admiten los siguientes tipos de migración activa:

Configura la migración activa a nodos de prioridad más alta

Puedes configurar la migración activa para reemplazar los nodos existentes que tienen una prioridad más baja en una lista de prioridad de respaldo de ComputeClass por nodos nuevos que tienen una prioridad más alta en esa lista. Esta configuración ayuda a garantizar que todos tus Pods en ejecución se ejecuten finalmente en los nodos que más prefieras para esa ComputeClass, incluso si GKE originalmente tuvo que ejecutar esos Pods en nodos menos preferidos.

Considera el siguiente ejemplo de especificación de ComputeClass, que prioriza los nodos N4 por sobre los nodos C4:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  activeMigration:
    optimizeRulePriority: true

Si los nodos N4 no estaban disponibles cuando implementaste un Pod con esta ComputeClass, GKE habría usado nodos C4 como opción de resguardo. Si los nodos N4 están disponibles para aprovisionarse más adelante, por ejemplo, si aumenta tu cuota o si las VMs N4 están disponibles en tu ubicación, GKE crea un nodo N4 nuevo y migra gradualmente el Pod del nodo C4 existente al nodo N4 nuevo. Luego, GKE borra el nodo C4 obsoleto.

Configura la migración activa para ejecutar Pods de DaemonSet no programables

Puedes configurar la migración activa para reemplazar automáticamente los nodos existentes que tienen Pods de DaemonSet no programables por nodos más grandes que pueden ejecutar todos los Pods de DaemonSet requeridos.

Considera la siguiente especificación de ComputeClass de ejemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n1
  activeMigration:
    ensureAllDaemonSetPodsRunning: true

Por ejemplo, si implementar un Pod con esta ComputeClass provocó que se aumentara la escala de una máquina n1-standard-2 y, luego, implementaste un DaemonSet que solicita dos CPUs, la migración activa reemplazará el nodo n1-standard-2 por uno más grande de la misma familia de máquinas n1, como un n1-standard-4, para crear suficiente espacio para todos los Pods.

Consume reservas de Compute Engine

Disponible en la versión 1.31.1-gke.2105000 y versiones posteriores de GKE

Si usas reservas de capacidad de Compute Engine para obtener un mayor nivel de garantía de disponibilidad de hardware enGoogle Cloud zonas específicas, puedes configurar cada prioridad de resguardo en tu ComputeClass personalizada para que GKE consuma reservas cuando cree nodos nuevos.

El consumo de reservas en ComputeClasses personalizadas tiene los siguientes requisitos:

  • Debes usar la creación automática de grupos de nodos para que GKE use reservas para crear nodos nuevos. Para obtener más información, consulta la sección Creación automática de grupos de nodos y ComputeClasses. También puedes seguir consumiendo reservas cuando creas grupos de nodos de forma manual en tu clúster.
  • Las reservas que no son de TPU solo se pueden usar cuando se define machineType o machineFamily.
  • Las ComputeClasses que configuran SSDs locales deben usar la regla de prioridad machineType, no machineFamily. Para obtener más detalles, consulta la sección tipo de regla machineType.
  • Los ComputeClasses que especifican reservas para un machineType que tiene SSD locales adjuntos deben incluir un campo localSSDCount: de forma explícita.

Considera la siguiente especificación de ejemplo de ComputeClass, que prioriza una reserva compartida específica para usarla cuando se aprovisionan instancias de a3-highgpu-1g. Si los tipos de instancias priorizados no están disponibles, GKE recurre a las reservaciones coincidentes en la especificación:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

Si implementas un Pod que usa la ComputeClass accelerator-reservations, GKE primero intenta usar la reserva a3-shared-reservation cuando crea instancias a3-highgpu-1g nuevas para ejecutar el Pod. Si esta reserva específica no tiene capacidad disponible, GKE intenta aumentar la escala de las instancias de a3-highgpu-1g con cualquier reserva coincidente. Si no se puede acceder a ninguna reserva, GKE recurre a las VMs Spot a3-highgpu-1g. Por último, si no hay VMs Spot disponibles, la operación de ajuste falla.

En este ejemplo, ambas reglas de prioridad con referencias de reserva requieren explícitamente el campo localSSDCount: porque la forma de máquina a3-highgpu-1g incluye SSDs locales.

En el siguiente ejemplo, se muestra una reserva específica compartida que recurre a las VMs Spot y, luego, a las VMs bajo demanda:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

Puedes consumir los siguientes tipos de reservas:

  • Reservas específicas de un solo proyecto: Configura los siguientes campos:

    • reservations.specific.name: Es el nombre de la reserva.
    • reservations.affinity: Debe ser Specific.

  • Reservas compartidas específicas: Configura los siguientes campos:

    • reservations.specific.name: Es el nombre de la reserva.
    • reservations.specific.project: Es el ID del proyecto al que pertenece la reserva.
    • reservations.affinity: Debe ser Specific.

  • Consume cualquier reserva que coincida: Configura los siguientes campos:

    • reservations.affinity: Debe ser AnyBestEffort.
    • No establezcas un nombre de reserva ni un proyecto.

Las reservas de TPU requieren afinidad específica. reservations.affinity: AnyBestEffort no es compatible.

Si GKE no puede encontrar capacidad disponible en una reserva, el comportamiento resultante depende del tipo de reserva que se seleccione en la regla de prioridad de ComputeClass, de la siguiente manera:

  • Reservas específicas: GKE prueba la siguiente regla de prioridad en ComputeClass.
  • Cualquier reserva que coincida: GKE intenta aprovisionar un nodo a pedido que cumpla con los requisitos de esa regla de prioridad. Si GKE no puede aprovisionar un nodo a pedido, GKE intenta aplicar la siguiente regla de prioridad en ComputeClass.

Si GKE no puede cumplir con los requisitos de ninguna de las reglas de prioridad para ComputeClass, se produce el comportamiento cuando no se aplican reglas.

Consume bloques de reserva específicos

A partir de la versión 1.31.4-gke.1072000 de GKE, puedes segmentar un bloque de reserva específico dentro de una reserva respaldada por hardware. Esta función está disponible para los tipos de máquinas A3 Ultra y A4.

Para consumir un bloque de reserva específico, configura tu recurso ComputeClass como se muestra en este ejemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

Reemplaza RESERVATION_BLOCK_NAME por el nombre del bloque de reserva de destino.

A partir de la versión 1.33.1-gke.1788000 de GKE, puedes segmentar un subbloque de reserva específico dentro de un bloque de reserva. Esta función está disponible para el tipo de máquina A4X.

Para consumir un sub-bloque de reserva específico, configura tu recurso ComputeClass como se muestra en el ejemplo de Consume sub-blocks of specific reservations.

Cuando uses esta función, ten en cuenta las siguientes consideraciones:

  • Estas funciones solo se aplican a las reservas específicas en un proyecto único o compartido.

Personaliza la configuración del sistema de nodos

Puedes personalizar ciertos parámetros en kubelet y el kernel de Linux con el campo nodeSystemConfig en la especificación de ComputeClass. Puedes especificar este campo en cualquier regla de prioridad que defina una serie o un tipo de máquina de Compute Engine. También puedes establecer valores globales predeterminados para cualquier campo de configuración del sistema de nodos que se omita en las reglas de prioridad. Para ello, agrega el campo nodeSystemConfig al campo priorityDefaults en tu ComputeClass.

Esta función está disponible en la versión 1.32.1-gke.1729000 de GKE y versiones posteriores.

Si deseas obtener más información, consulta las siguientes páginas:

ComputeClasses predeterminadas para clústeres y espacios de nombres

Puedes configurar GKE para que aplique una ComputeClass de forma predeterminada a los Pods que no seleccionan una ComputeClass específica. Puedes definir una ComputeClass predeterminada para espacios de nombres específicos o para todo un clúster. Para obtener más información sobre cómo configurar tus clústeres o espacios de nombres con una clase predeterminada, consulta Aplica ComputeClasses a los Pods de forma predeterminada.

Agrupa los grupos de nodos

A partir de la versión 1.32.2-gke.1359000 de GKE, puedes agrupar varios grupos de nodos en una sola unidad lógica llamada colección con el campo nodePoolGroup en la especificación de ComputeClass. Esta agrupación te permite aplicar configuraciones compartidas en muchos grupos de nodos.

Colección de TPU de varios hosts

Puedes agrupar tu implementación de TPU de varios hosts para establecer un objetivo de nivel de servicio (SLO) en todos los grupos de nodos de la colección. Para agrupar grupos de nodos, especifica el nombre del grupo en el campo nodePoolGroup. Todos los grupos de nodos aprovisionados con esta ComputeClass pertenecen al mismo grupo.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

Para obtener más información, consulta lo siguiente:

Configuración de grupos de nodos

El campo nodePoolConfig en la especificación de ComputeClass te permite aplicar una configuración que se refleja en todos los nodos dentro de los grupos de nodos creados con esa clase.

Especifica el tipo de imagen

Puedes especificar el sistema operativo base para los nodos del grupo de nodos con el campo imageType. Este campo te permite elegir un tipo de imagen para los grupos de nodos que se ejecutarán en los nodos. Si omites este campo, el valor predeterminado es cos_containerd. En el siguiente ejemplo, se muestra cómo especificar imageType en tu ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

Para obtener más información, consulta Imágenes de nodo.

Cuenta de servicio

El campo serviceAccount especifica la cuenta de servicio Google Cloud que usan los nodos dentro de los grupos de nodos que administra ComputeClass. En el siguiente ejemplo, se muestra cómo especificar serviceAccount en tu ComputeClass:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

Para obtener más información, consulta Acerca de las cuentas de servicio en GKE.

Define el tipo de carga de trabajo para el SLO de TPU

A partir de la versión 1.32.2-gke.1359000 de GKE, puedes definir el objetivo de nivel de servicio (SLO) para tus cargas de trabajo de TPU con el campo workloadType dentro de nodePoolConfig. El valor de este campo le indica a GKE el uso previsto para los recursos de TPU. El campo workloadType admite los siguientes valores:

  • HIGH_AVAILABILITY: Usa este valor para las cargas de trabajo centradas en la disponibilidad, como la publicación de inferencias, para limitar y optimizar las interrupciones.
  • HIGH_THROUGHPUT: Usa este valor para los trabajos por lotes o de entrenamiento que requieren que toda la infraestructura subyacente se ejecute la mayor parte del tiempo para avanzar. Este valor solo se puede usar cuando también se especifica nodePoolGroup.

En el siguiente ejemplo, se define un objeto ComputeClass para una colección de TPU de varios hosts optimizada para cargas de trabajo de inferencia de alta disponibilidad.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

Si deseas obtener más información, consulta las siguientes páginas:

Solicita ComputeClasses en cargas de trabajo

Para usar una ComputeClass personalizada, tu Pod debe solicitar explícitamente esa ComputeClass con un nodeSelector en la especificación del Pod. De manera opcional, puedes establecer un ComputeClass como predeterminado para un espacio de nombres de Kubernetes específico. Los Pods de ese espacio de nombres usan esa ComputeClass, a menos que soliciten una diferente.

Por ejemplo, el siguiente manifiesto solicita la clase de procesamiento cost-optimized:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

Selectores de nodos para etiquetas de nodos del sistema

GKE agrega etiquetas del sistema a los nodos para identificarlos según criterios como el tipo de máquina, los aceleradores de hardware conectados o el tipo de disco de arranque. Estas etiquetas del sistema tienen uno de los siguientes prefijos en la clave de la etiqueta:

  • k8s.io
  • cloud.google.com
  • gke.io

En la versión 1.32.3-gke.1499000 y posteriores de GKE, puedes implementar cargas de trabajo que usen un selector de nodos para seleccionar etiquetas del sistema y una ComputeClass al mismo tiempo. Si seleccionas etiquetas del sistema en Pods que seleccionan ComputeClasses, verifica que esos Pods se programen según lo esperado. Un conflicto entre la configuración de un ComputeClass y los selectores de nodos en un Pod puede generar problemas como los siguientes:

  • GKE no puede crear nodos que usen la configuración de mayor prioridad para ComputeClass.
  • El Pod permanece en el estado Pending.

GKE también rechaza los Pods que seleccionan etiquetas del sistema que tienen un campo correspondiente en la especificación ComputeClass. Cuando uses ComputeClasses, actualiza tus cargas de trabajo para quitar las siguientes etiquetas de los selectores de nodos y configurar el campo correspondiente en las ComputeClasses que crees:

Etiqueta del nodo Campo ComputeClass
cloud.google.com/machine-family priorities.machineFamily
cloud.google.com/machine-type priorities.machineType
cloud.google.com/gke-spot priorities.spot
cloud.google.com/gke-accelerator priorities.gpu.type
cloud.google.com/gke-gpu-driver-version priorities.gpu.driverVersion
cloud.google.com/reservation-name priorities.reservations.specific.name
cloud.google.com/reservation-project priorities.reservations.specific.project
cloud.google.com/reservation-affinity priorities.reservations.affinity
cloud.google.com/gke-ephemeral-storage-local-ssd priorities.storage.localSSDCount
cloud.google.com/gke-boot-disk priorities.storage.bootDiskType
cloud.google.com/gke-boot-disk-size priorities.storage.bootDiskSize
cloud.google.com/gke-node-pool-group-name nodePoolGroup.name
cloud.google.com/gke-workload-type nodePoolConfig.workloadType

Limitaciones

El nombre de tu ComputeClass no puede comenzar con gke ni autopilot.

¿Qué sigue?