Acerca de las ComputeClasses personalizadas

Puedes crear tus propias ComputeClasses para controlar las propiedades de los nodos que Google Kubernetes Engine (GKE) aprovisiona al autoescalar tu clúster. Esta página está dirigida a los administradores de plataformas que quieran definir de forma declarativa perfiles de escalado automático para los nodos, de modo que las cargas de trabajo específicas se ejecuten en hardware que cumpla sus requisitos. Para obtener más información sobre qué son las ComputeClasses, consulta el artículo Acerca de las ComputeClasses de GKE.

Información general sobre ComputeClasses

En GKE, una ComputeClass es un perfil que consta de un conjunto de atributos de nodo que GKE usa para aprovisionar los nodos que ejecutan tus cargas de trabajo durante los eventos de autoescalado. Las ComputeClasses pueden orientarse a optimizaciones específicas, como aprovisionar nodos de alto rendimiento o priorizar configuraciones optimizadas para los costes para reducir los costes de ejecución. Las clases de computación personalizadas te permiten definir perfiles que GKE usa para autoescalar nodos y, de esta forma, satisfacer los requisitos de cargas de trabajo específicas.

Las ComputeClasses personalizadas se pueden usar en el modo Autopilot 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 de escalado automático. Las ComputeClasses personalizadas están disponibles para configurarse y usarse en todos los clústeres de GKE aptos de forma predeterminada.

Ventajas de las ComputeClasses personalizadas

Las ComputeClasses personalizadas ofrecen las siguientes ventajas:

• Prioridades de cálculo alternativas: define una jerarquía de configuraciones de nodos en cada ComputeClass para que GKE les dé prioridad. Si la configuración preferida no está disponible, GKE elige automáticamente la siguiente configuración de la jerarquía. Este modelo de respaldo asegura que, aunque los recursos de computación no estén disponibles, tus cargas de trabajo sigan ejecutándose en hardware optimizado con retrasos mínimos en la programación.
• Control granular del autoescalado: define las configuraciones de nodos que mejor se adapten a cargas de trabajo específicas. GKE da prioridad a esas configuraciones al crear nodos durante el escalado.
• Configuración de infraestructura declarativa: adopta un enfoque declarativo para la gestión de la infraestructura de forma que GKE cree automáticamente los nodos que se ajusten a los requisitos específicos de tu carga de trabajo.
• Migración activa: si los recursos de computación de una configuración de máquina preferida están disponibles en tu ubicación, GKE migra automáticamente tus cargas de trabajo a los nuevos nodos que usan la configuración preferida.
• Optimización de costes: prioriza los tipos de nodos rentables, como las VMs de acceso puntual, para reducir los gastos del clúster.
• ComputeClasses personalizados predeterminados: define un ComputeClass personalizado como predeterminado 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 aunque no soliciten un ComputeClass específico.
• 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 está por debajo del umbral, GKE intenta consolidar las cargas de trabajo en un nodo similar disponible y reduce el nodo infrautilizado.

Casos prácticos de ComputeClasses personalizados

Puede usar ComputeClasses personalizados en situaciones como las siguientes:

• Quieres ejecutar tus cargas de trabajo de IA o aprendizaje automático en configuraciones específicas de GPU o TPU.
• Quieres definir configuraciones de hardware predeterminadas para las cargas de trabajo que ejecutan equipos específicos, lo que libera a los operadores de aplicaciones de esta tarea.
• Ejecutas cargas de trabajo que funcionan de forma óptima en series de máquinas o configuraciones de hardware específicas de Compute Engine.
• Quieres declarar configuraciones de hardware que cumplan requisitos empresariales específicos, como alto rendimiento, optimización de costes o alta disponibilidad.
• Quieres que GKE recurra jerárquicamente a configuraciones de hardware específicas cuando no haya recursos de computación disponibles, de forma que tus cargas de trabajo se ejecuten siempre en máquinas que se adapten a sus requisitos.
• Quieres decidir de forma centralizada las configuraciones óptimas de toda la flota de tu empresa para que los costes sean más predecibles y las cargas de trabajo se ejecuten de forma más fiable.
• Quieres especificar de forma centralizada qué reservas de capacidad de Compute Engine debe usar GKE para aprovisionar nuevos nodos para cargas de trabajo específicas.
• Quieres especificar una política de colocación compacta para usarla con GKE Autopilot. Para obtener más información, consulta la sección sobre colocación compacta.

Cómo funcionan las ComputeClasses personalizadas

Las Custom ComputeClasses son recursos personalizados de Kubernetes que aprovisionan infraestructura.Trusted Cloud by S3NS Define un objeto ComputeClass en el clúster y, a continuación, solicita esa ComputeClass en las cargas de trabajo o define esa clase de computación como predeterminada para un espacio de nombres de Kubernetes. Cuando una carga de trabajo coincidente demanda una nueva infraestructura, GKE aprovisiona nuevos nodos de acuerdo con las prioridades que hayas definido en tu definición de ComputeClass.

Los atributos que defina en sus ComputeClasses determinan cómo configura GKE los nuevos nodos para ejecutar cargas de trabajo. Cuando modificas una clase de cálculo, todos los nodos futuros que GKE cree para esa clase de cálculo usarán la configuración modificada. GKE no cambia retroactivamente la configuración de los nodos para que coincida con tus modificaciones.

Las ComputeClasses personalizadas influyen en las decisiones de autoescalado, 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, aunque haya nodos disponibles con varias prioridades.

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

• Conocer los requisitos de computación de tu flota, incluidos los requisitos de hardware específicos de cada aplicación.
• Elige un tema que guíe el diseño de cada ComputeClass. Por ejemplo, una ComputeClass optimizada para el rendimiento puede tener una estrategia alternativa que solo use tipos de máquinas con una gran cantidad de CPU.
• Decide la familia y la serie de máquinas de Compute Engine que mejor se adapten a tus cargas de trabajo. Para obtener más información, consulta la guía de comparación y recursos de las familias de máquinas.
• Planifica una estrategia de respaldo en cada ComputeClass para que las cargas de trabajo siempre se ejecuten en nodos que usen configuraciones de máquina similares. Por ejemplo, si la serie de máquinas N4 no está disponible, puedes usar máquinas C3.

Ver 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 el CRD en tu clúster ejecutando el siguiente comando:

kubectl describe crd computeclasses.cloud.google.com

Planificar una ComputeClass personalizada

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

1. Elige las prioridades de cálculo alternativas: define una serie de reglas que rigen las propiedades de los nodos que GKE crea para la ComputeClass.
2. Configura grupos de nodos y ComputeClasses de GKE Standard: en los clústeres del modo Standard, sigue los pasos de configuración obligatorios para usar ComputeClass con tus grupos de nodos.
3. Define el comportamiento de escalado cuando no se apliquen reglas de prioridad: opcionalmente, indica a GKE qué debe hacer si no se pueden aprovisionar nodos que cumplan tus reglas de prioridad.
4. Define los parámetros de escalado automático para la consolidación de nodos: indica a GKE cuándo consolidar las cargas de trabajo y eliminar los nodos infrautilizados.
5. Configurar la migración activa a nodos de mayor prioridad: opcionalmente, indica a GKE que mueva las cargas de trabajo a nodos más preferidos a medida que haya hardware disponible.
6. Consumir reservas de Compute Engine: opcionalmente, indica a GKE que consuma las reservas zonales de Compute Engine que ya tengas al crear nodos.

Elige las prioridades de cálculo alternativas

La principal ventaja de usar una ComputeClass personalizada es tener control sobre la estrategia de respaldo 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 alternativa, define una lista de reglas de prioridad en tu ComputeClass personalizado. Cuando un clúster necesita aumentar su escala, 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 regla de prioridad siguiente y repite este proceso hasta que GKE escale correctamente el clúster o agote todas las reglas. Si se agotan todas las reglas, GKE crea nodos en función del comportamiento predeterminado o especificado que se describe en Definir el comportamiento de escalado cuando no se apliquen 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 admita ese tipo de almacenamiento. Para obtener más información, filtra la tabla de comparación 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 van a aprovisionar. 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.

Hay dos tipos de reglas de prioridad:

• Tipos de reglas declarativas: usa las características de los nodos para describir los nodos que quieres aprovisionar.

• Tipo de regla de grupo de nodos: en los clústeres estándar de GKE, proporciona una lista de grupos de nodos creados manualmente que están asociados a la ComputeClass en la que GKE debe aprovisionar nodos.

Reglas de prioridad declarativas

Con las reglas de prioridad declarativas, puedes especificar propiedades de las máquinas, como la familia o el tipo de máquina, las máquinas virtuales de Spot, las opciones de acelerador, las opciones de almacenamiento, las reservas y los requisitos mínimos de recursos, para que GKE las use al aprovisionar nodos. Para ver el conjunto completo de campos admitidos, consulta la referencia de 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 computación. Por ejemplo:

• spot: máquinas virtuales de acceso puntual. El valor predeterminado es false.
• minCores: número mínimo de vCPUs por nodo. El valor predeterminado es 0.
• minMemoryGb: memoria mínima por nodo. El valor predeterminado es 0.
• storage.bootDiskKMSKey: ruta a la clave de Cloud Key Management Service que se va a usar para cifrar el disco de arranque.
• storage.secondaryBootDisks: discos persistentes que se usan para precargar datos en nodos de GKE, como un modelo de aprendizaje automático o una imagen de contenedor. Requiere la versión 1.31.2-gke.1105000 de GKE o una posterior. Para configurar un disco de arranque secundario que pueda usar tu clúster, consulta el artículo sobre configurar discos de arranque secundarios.
  • storage.secondaryBootDisks.diskImageName: el nombre de la imagen de disco que se va a precargar.
  • storage.secondaryBootDisks.project: el nombre del proyecto al que pertenece la imagen de disco. Si no se especifica ningún valor, se usará el proyecto de tu clúster.
  • storage.secondaryBootDisks.mode: el modo en el que se debe usar el disco de arranque secundario. Si este valor es 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 ningún valor, se utiliza MODE_UNSPECIFIED de forma predeterminada.
• placement: detalles sobre la colocación de la máquina:
  • policyName: nombre de una política de colocación compacta de Autopilot de GKE o de una política de carga de trabajo.

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 personalizadas, se necesita 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 computación. Por ejemplo:

• spot: usa máquinas virtuales de acceso puntual. El valor predeterminado 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: ruta a la clave de Cloud KMS que se va a usar para cifrar el disco de arranque.
  • storage.bootDiskSize: tamaño en GB del disco de arranque del nodo.
  • storage.localSSDCount: número de SSD locales que se van a asociar al nodo. Si se especifica, debe ser 1 como mínimo.

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 número y la versión del controlador (opcional) de la GPU en el campo gpu de una regla de prioridad. Se admiten los siguientes campos:

• gpu.type: un tipo de GPU, como nvidia-l4. Para obtener más información, consulta Elegir la compatibilidad con GPU mediante Autopilot o Estándar.
• gpu.count: número de GPUs que se van a asociar. Para ver las cantidades admitidas por tipo de GPU, consulta Cantidades de GPU admitidas.
• gpu.driverVersion: la versión del controlador de NVIDIA que se va a instalar. Debe ser default o latest. Requiere la versión 1.31.1-gke.1858000 de GKE o una posterior.

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

En el siguiente ejemplo se muestra una regla para GPUs:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true

Configuración de TPU

Requiere la versión 1.31.2-gke.1518000 de GKE o una posterior

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

• tpu.type: el tipo de TPU, como tpu-v5p-slice. Para obtener más información, consulta Disponibilidad de las TPU en Autopilot de GKE.
• tpu.count: número de TPUs que se van a adjuntar.
• tpu.topology: la topología de TPU que se va a usar, como "2x2x1". Para obtener más información, consulta Elegir una topología para Autopilot.

También puede especificar otros spec.priorities campos junto con el campo tpu en su regla de prioridad. Por ejemplo:

• spot: usa máquinas virtuales de acceso puntual. El valor predeterminado es false.
• storage: configura el almacenamiento de nodos.
  • storage.bootDiskType: tipo de disco de arranque.
  • storage.bootDiskKMSKey: ruta a la clave de Cloud KMS que se va a usar para el cifrado del disco de arranque.
  • storage.bootDiskSize: 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 Consumir reservas de Compute Engine.

En el siguiente ejemplo se muestra una regla para las TPUs:

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 respaldo:

1. GKE intenta aprovisionar un slice de TPU v5p multihost de 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 intentará aprovisionar un slice de TPU v5p de varios hosts con 16 nodos que se ejecute en VMs Spot.
3. Si no se cumple ninguna de las reglas anteriores, GKE sigue la lógica de la sección Definir el comportamiento del escalado cuando no se apliquen 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:

• Cargas de trabajo de Autopilot: consulta la sección "Aprovisionar TPUs mediante ComputeClasses personalizados" en Despliega cargas de trabajo de TPUs en Autopilot de GKE.
• Cargas de trabajo estándar: consulta la sección "Aprovisionar TPUs mediante ComputeClasses personalizados" en Desplegar cargas de trabajo de TPUs en GKE Standard.

Además, en el caso de las cargas de trabajo de TPU, puedes hacer lo siguiente:

• Definir el tipo de carga de trabajo
• Definir SLO

Especificaciones de aceleradores y formas de máquinas

Las configuraciones de aceleradores declarativas no requieren que se especifiquen explícitamente los campos machineType o machineFamily, a menos que se usen en combinación con reservas.

Reglas de prioridad de grupos de nodos

El campo nodepools acepta una lista de grupos de nodos en los que GKE intenta crear pods pendientes. GKE no procesa los valores de este campo en orden. No puede 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. Este campo solo se admite en el modo Estándar de GKE. Para obtener información sobre el uso, consulta Dirigir ComputeClass a grupos de nodos específicos.

Cómo crea nodos GKE mediante reglas de prioridad

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

Por ejemplo, supongamos que se da la siguiente especificación:

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

Cuando despliega una carga de trabajo que solicita un ComputeClass con estas reglas de prioridad, GKE asigna los nodos de la siguiente manera:

1. GKE coloca los pods en los nodos asociados a esta ComputeClass.
2. Si los nodos actuales no pueden alojar los pods, GKE aprovisiona nodos nuevos que usan la serie de máquinas N4, son VMs esporádicas y tienen al menos 64 vCPUs.
3. Si las VMs N4 Spot con al menos 64 vCPUs no están disponibles en la región, GKE aprovisiona nodos nuevos que usan VMs N4 Spot que pueden alojar los pods, independientemente del número de núcleos.
4. Si no hay VMs N4 Spot disponibles en la región, GKE aprovisiona nuevas VMs N4 bajo demanda.
5. Si no se cumple ninguna de las reglas anteriores, GKE sigue la lógica de la sección Definir el comportamiento del escalado cuando no se apliquen reglas de prioridad.

Valores predeterminados de las reglas de prioridad

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

El campo priorityDefaults tiene las siguientes limitaciones:

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

Para obtener información sobre los tipos de valores predeterminados que puedes definir, consulta la sección priorityDefaults del artículo ComputeClass CustomResourceDefinition.

Grupos de nodos y ComputeClasses de GKE Standard

Si usas el modo estándar de GKE, puede que tengas que realizar una configuración manual para asegurarte de que tus pods de ComputeClass se programan como se espera.

• Grupos de nodos gestionados por el aprovisionamiento automático de nodos: no se requiere ninguna configuración manual. El aprovisionamiento automático de nodos realiza automáticamente los pasos de configuración de ComputeClass. Para obtener más información, consulta Aprovisionamiento automático de nodos y ComputeClasses.
• Grupos de nodos creados manualmente: requieren configuración manual. Debes añadir etiquetas y taints de nodo a los grupos de nodos que hayas creado manualmente para asociar los nodos a una ComputeClass específica. Para obtener más información, consulta Configurar grupos de nodos creados manualmente para usar ComputeClass.

Configurar grupos de nodos creados manualmente para usar ComputeClass

Si tus clústeres estándar de GKE tienen grupos de nodos que has creado manualmente sin aprovisionamiento automático de nodos, debes configurar esos grupos de nodos para asociarlos con ComputeClasses específicos. GKE solo programa los pods que solicitan una ComputeClass específica en los nodos de los grupos de nodos que asocies a esa ComputeClass. Este requisito no se aplica a una ComputeClass que configures como predeterminada a nivel de clúster.

Los grupos de nodos de los modos Autopilot y Estándar de GKE que se han creado mediante el aprovisionamiento automático de nodos realizan esta configuración automáticamente.

Para asociar un grupo de nodos creado manualmente con un ComputeClass, añade etiquetas de nodo y taints de nodo al grupo de nodos durante la creación o durante una actualización. Para ello, especifica las marcas --node-labels y --node-taints, como se indica a continuación:

• Etiqueta del 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 personalizado.

Por ejemplo, los siguientes comandos actualizan un grupo de nodos y asocian el grupo de nodos con la clase de Compute 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"

Puede asociar cada grupo de nodos de su clúster a una ComputeClass personalizada. Los pods que GKE programa en estos grupos de nodos creados manualmente solo activan la creación de nodos en esos grupos durante los eventos de autoescalado.

Aprovisionamiento automático de nodos y ComputeClasses

Puedes usar el aprovisionamiento automático de nodos con una ComputeClass personalizada para que GKE cree y elimine automáticamente grupos de nodos en función de tus reglas de prioridad.

Para usar el aprovisionamiento automático de nodos con una ComputeClass, debes hacer lo siguiente:

1. Asegúrate de que el aprovisionamiento automático de nodos esté habilitado en tu clúster.
2. Añade el campo nodePoolAutoCreation con el valor enabled: true a tu especificación ComputeClass.

GKE puede colocar pods que usen ComputeClasses que configuren el aprovisionamiento automático de nodos en grupos de nodos nuevos. GKE decide si debe aumentar la escala de un grupo de nodos 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 configuren el aprovisionamiento automático de nodos seguirán escalando verticalmente solo los grupos de nodos que ya existan.

Puedes usar ComputeClasses que interactúen con el aprovisionamiento automático de nodos junto con ComputeClasses que interactúen con grupos de nodos creados manualmente en el mismo clúster.

Ten en cuenta las siguientes interacciones con el aprovisionamiento automático de nodos:

• No puedes usar la familia de máquinas ni los selectores de nodos 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 Spot VMs o series de máquinas específicas.

• Si estableces una ComputeClass predeterminada para tu clúster, los pods que usen un selector de nodos de familia de máquinas solo activarán 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 de la clase predeterminada a nivel de clúster. Por ejemplo, un pod que selecciona instancias N4 activa la creación de nodos si la clase predeterminada a nivel de clúster tiene una regla de prioridad para instancias N4.
  • El valor predeterminado de ComputeClass a nivel de clúster es ScaleUpAnyway en el campo spec.whenUnsatisfiable. Aunque los pods seleccionen una familia de máquinas que no esté en las prioridades de ComputeClass, GKE crea nodos con esa familia de máquinas.

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

• Puedes configurar el aprovisionamiento automático de nodos para las clases de computación que usan el campo nodepools para hacer referencia a los pools de nodos. El aprovisionamiento automático de nodos procesa las prioridades en orden e intenta escalar los grupos de nodos existentes para colocar tus pods.

Veamos el siguiente ejemplo de un clúster que tiene grupos de nodos creados manualmente y aprovisionamiento automático 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 en el grupo de nodos manually-created-pool.
2. Aprovisiona nodos N4, ya sea en grupos de nodos N4 que ya tengas o creando un grupo de nodos.
3. Si GKE no puede crear nodos N4, intenta aumentar la escala de los grupos de nodos C4 que ya existen o crear grupos de nodos C4.

Orientar a 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 manualmente en los que GKE intenta programar pods sin ningún orden específico en los clústeres estándar de GKE que usan el escalado automático de clústeres. Este campo solo admite una lista de grupos de nodos. No puedes especificar propiedades de máquina adicionales, como la serie de la máquina, 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 puede crear nodos en esos grupos de nodos para colocar los pods.

Los grupos de nodos que especifiques en el campo priorities.nodepools deben estar asociados a esa ComputeClass mediante etiquetas y taints de nodos, tal como se describe en la sección Configurar grupos de nodos creados manualmente para ComputeClasses.

La lista de grupos de nodos que especifiques en el campo nodepools no tiene prioridad. Para configurar un orden de respaldo para grupos de nodos con nombre, debe especificar varios elementos priorities.nodepools independientes. Por ejemplo, echa un vistazo a la siguiente especificación:

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

En este ejemplo, GKE intenta colocar primero los pods pendientes que solicitan esta ComputeClass en los nodos de los grupos de nodos que tienen la etiqueta de la ComputeClass. Si los nodos no están disponibles, GKE intenta aprovisionar nodos nuevos en pool1 o pool2. Si GKE no puede aprovisionar nodos nuevos en estos grupos de nodos, intentará aprovisionar pods nuevos en pool3.

Definir el comportamiento de escalado cuando no se aplican reglas de prioridad

El recurso personalizado ComputeClass te permite especificar qué debe hacer GKE si no hay ningún nodo que cumpla alguna de las reglas de prioridad. El campo whenUnsatisfiable de la especificación admite los siguientes valores.

• ScaleUpAnyway: crea un nodo 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 se omite este campo.

  GKE lleva a cabo una de las siguientes acciones:

  • En los clústeres de Autopilot, GKE coloca el pod en un nodo nuevo o en uno ya creado, independientemente de la configuración del nodo.
  • En los clústeres estándar que no usan el aprovisionamiento automático de nodos, GKE intenta aumentar la escala de cualquier grupo de nodos creado manualmente que defina una etiqueta y un taint que coincidan con una ComputeClass determinada.
  • En los clústeres estándar que usan el aprovisionamiento automático de nodos, es posible que GKE cree un grupo de nodos que use la serie de máquinas E2 predeterminada para colocar el pod.

• DoNotScaleUp: deja el pod en el estado Pending hasta que haya disponible un nodo que cumpla los requisitos de ComputeClass. En la versión 1.33 y posteriores de GKE, este es el comportamiento predeterminado si se omite este campo.

Solicitar una política de emplazamiento

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

Tanto la política de colocación como la política de cargas de trabajo colocan los nodos muy cerca entre sí para reducir la latencia de la red. Para usar una política específica, debes indicar 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.

Veamos un 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 emplazamiento compacto a todas las cargas de trabajo que usan esta ComputeClass y aprovisiona sus nodos de acuerdo con la política de recursos my-placement-policy.

Definir los parámetros de escalado automático para la consolidación de nodos

De forma predeterminada, GKE elimina los nodos que no se utilizan lo suficiente al ejecutar cargas de trabajo y consolida esas cargas de trabajo en otros nodos que tienen capacidad. En todas las ComputeClasses, este es el comportamiento predeterminado, ya que todos los clústeres que usan ComputeClasses deben usar el escalador automático de clústeres o ser clústeres de Autopilot. Durante una consolidación de nodos, GKE vacía un nodo infrautilizado, vuelve a crear las cargas de trabajo en otro nodo y, a continuación, elimina el nodo vaciado.

El momento y los criterios para eliminar nodos dependen del perfil de autoescalado. Puedes ajustar los umbrales de infrautilización de recursos que activan la eliminación de nodos y la consolidación de cargas de trabajo mediante la sección autoscalingPolicy de tu definición de ComputeClass personalizada. Puedes ajustar los siguientes parámetros:

• consolidationDelayMinutes: número de minutos tras los cuales GKE elimina los nodos infrautilizados.
• consolidationThreshold: umbral de utilización de la CPU y la memoria como porcentaje de los recursos disponibles del nodo. GKE solo tiene en cuenta los nodos para eliminarlos si la utilización de recursos es inferior a este umbral.
• gpuConsolidationThreshold: umbral de uso de la GPU como porcentaje de los recursos disponibles del nodo. GKE solo tiene en cuenta los nodos para eliminarlos si la utilización de recursos es inferior a este umbral. Te recomendamos que asignes el valor 100 o 0 para que GKE consolide los nodos que no tengan una utilización del 100% de las GPUs conectadas.

Veamos un 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 elimina los nodos no utilizados después de cinco minutos y los nodos solo se convierten en candidatos para la consolidación si su uso de CPU y memoria es inferior al 70%.

Configurar la migración activa a nodos de mayor prioridad

La migración activa es una función de escalado automático opcional de las ComputeClasses personalizadas que sustituye automáticamente los nodos existentes que tienen una prioridad inferior en una lista de prioridad de reserva de ComputeClass por nodos nuevos que tienen una prioridad superior en esa lista. De esta forma, todos los pods en ejecución se ejecutarán en los nodos que prefieras para esa ComputeClass, aunque GKE haya tenido que ejecutar esos pods en nodos menos preferidos.

Cuando se produce una migración activa, GKE crea nodos basados en las reglas de prioridad de ComputeClass y, a continuación, vacía y elimina los nodos obsoletos de menor prioridad. La migración se realiza de forma gradual para minimizar las interrupciones en la carga de trabajo. La migración activa tiene las siguientes consideraciones:

• La migración activa no migra los datos almacenados en 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 las clases de Compute que usen cargas de trabajo con estado.
• Si has habilitado el aprovisionamiento automático de nodos en tus clústeres estándar, la migración activa puede activar la creación de grupos de nodos si los grupos de nodos no cumplen los criterios de mayor prioridad definidos en tu clase de cálculo personalizada.
• La migración activa no sustituye los nodos que no se pueden quitar. Por ejemplo, la migración activa no sustituye un nodo si al hacerlo se infringe el ajuste --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 definan un PodDisruptionBudget, si el movimiento supera el PodDisruptionBudget.
  • 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 las interrupciones causadas por la migración activa.
• Si actualizas un ComputeClass para habilitar la migración activa, GKE migrará los pods a nodos de mayor prioridad con el tiempo.

Veamos el siguiente ejemplo de especificación de ComputeClass, que prioriza los nodos N4 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 desplegaste un pod con este ComputeClass, GKE habría usado los nodos C4 como opción alternativa. Si los nodos N4 se pueden aprovisionar 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 y migra gradualmente el pod del nodo C4 al nodo N4. A continuación, GKE elimina el nodo C4 obsoleto.

Consumir reservas de Compute Engine

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

Si usas reservas de capacidad de Compute Engine para obtener un mayor nivel de garantía de disponibilidad de hardware en zonasTrusted Cloud específicas, puedes configurar cada prioridad de reserva en tu ComputeClass personalizado para que GKE consuma reservas al crear nodos.

Para consumir reservas en ComputeClasses personalizadas, se deben cumplir los siguientes requisitos:

• Los clústeres en modo estándar deben usar el aprovisionamiento automático de nodos para que GKE use las reservas y cree nodos. Para obtener más información, consulta la sección Aprovisionamiento automático de nodos y ComputeClasses. También puedes seguir usando reservas cuando crees manualmente grupos de nodos 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 información, consulta la sección machineType rule type.
• Los ComputeClasses que especifiquen reservas para un machineType que tenga unidades SSD locales conectadas deben incluir un campo localSSDCount: de forma explícita.

Consulta el siguiente ejemplo de especificación de ComputeClass, que prioriza una reserva compartida específica para usarla al aprovisionar instancias a3-highgpu-1g. Si los tipos de instancia priorizados no están disponibles, GKE recurre a las reservas coincidentes de 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 accelerator-reservations ComputeClass, GKE intenta usar primero la reserva a3-shared-reservation al crear nuevas instancias a3-highgpu-1g para ejecutar el pod. Si esta reserva específica no tiene capacidad disponible, GKE intenta aumentar el número de instancias a3-highgpu-1g usando cualquier reserva coincidente. Si no se puede acceder a ninguna reserva, GKE recurre a las a3-highgpu-1g máquinas virtuales de tipo spot. Por último, si no hay VMs de acceso puntual disponibles, la operación de escalado falla.

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

En el siguiente ejemplo se muestra una reserva específica compartida que recurre a las máquinas virtuales spot y, por último, a las máquinas virtuales 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 usar los siguientes tipos de reservas:

• Reservas de un solo proyecto específico: configura los siguientes campos:

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

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

  • reservations.specific.name: el nombre de la reserva.
  • reservations.specific.project: el ID del proyecto propietario de la reserva.
  • reservations.affinity: debe ser Specific.

• Cualquier reserva que coincida: configure los siguientes campos:

  • reservations.affinity: debe ser AnyBestEffort.
  • No indiques un nombre de reserva ni un proyecto.

Las reservas de TPU requieren una afinidad específica. reservations.affinity: AnyBestEffort no se admite.

Si GKE no encuentra capacidad disponible en una reserva, el comportamiento resultante depende del tipo de reserva que se haya seleccionado en la regla de prioridad de ComputeClass, como se indica a continuación:

• Reservas específicas: GKE prueba la siguiente regla de prioridad de ComputeClass.
• Reservas coincidentes: GKE intenta aprovisionar un nodo bajo demanda que cumpla los requisitos de esa regla de prioridad. Si GKE no puede aprovisionar un nodo bajo demanda, GKE prueba la siguiente regla de prioridad de ComputeClass.

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

Consumir bloques de reserva específicos

A partir de la versión 1.31.4-gke.1072000 de GKE, puedes orientar 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

Sustituye 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 orientar a 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 subbloque de reserva específico, configura tu recurso ComputeClass como se muestra en el ejemplo de Consumir subbloques de reserva específicos.

Cuando uses esta función, ten en cuenta lo siguiente:

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

Personalizar la configuración del sistema de nodos

Puede personalizar determinados parámetros en kubelet y en el kernel de Linux mediante el campo nodeSystemConfig de la especificación de ComputeClass. Puede especificar este campo en cualquier regla de prioridad que defina una serie o un tipo de máquina de Compute Engine. También puedes definir valores globales predeterminados para cualquier campo de configuración del sistema de nodos que se omita en las reglas de prioridad añadiendo el campo nodeSystemConfig al campo priorityDefaults de tu clase de cálculo.

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

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

• CustomResourceDefinition de ComputeClass
• Personalizar la configuración del sistema de nodos

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 seleccionen una ComputeClass específica. Puedes definir un ComputeClass predeterminado 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 Aplicar ComputeClasses a los pods de forma predeterminada.

Agrupar 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 mediante el campo nodePoolGroup en tu especificación de ComputeClass. Esta agrupación te permite aplicar configuraciones compartidas a muchos grupos de nodos.

Recogida de TPUs de varios hosts

Puedes agrupar tu implementación de TPU multihost para definir un objetivo de nivel de servicio (SLO) en todos los grupos de nodos de la colección. Para agrupar los 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 las siguientes secciones:

• Planificar las TPUs en GKE
• Grupos de nodos de slices de TPU multihost
• Programar colecciones de TPUs para cargas de trabajo de inferencia

Configuración del grupo de nodos

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

Especificar el tipo de imagen

Puedes especificar el sistema operativo base de los nodos del grupo de nodos mediante 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 omite este campo, el valor predeterminado es cos_containerd. En el siguiente ejemplo se muestra cómo especificar el 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 nodos.

Cuenta de servicio

El campo serviceAccount especifica la Trusted Cloud by S3NS cuenta de servicio que usan los nodos de los grupos de nodos gestionados por ComputeClass. En el siguiente ejemplo se muestra cómo especificar el serviceAccount en tu ComputeClass:

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

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

Definir el tipo de carga de trabajo de un 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) de tus cargas de trabajo de TPU mediante el campo workloadType de nodePoolConfig. El valor de este campo indica a GKE el uso previsto de los recursos de TPU. El campo workloadType admite los siguientes valores:

• HIGH_AVAILABILITY: usa este valor en cargas de trabajo centradas en la disponibilidad, como el servicio de inferencias, para limitar y optimizar las interrupciones.
• HIGH_THROUGHPUT: usa este valor en los trabajos por lotes o de entrenamiento que requieran 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 una ComputeClass para una colección de TPUs multihost 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

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

• Acerca de las TPUs en GKE
• Planificar las TPUs en GKE

Solicitar ComputeClasses en cargas de trabajo

Para usar una ComputeClass personalizada, tu pod debe solicitar explícitamente esa ComputeClass mediante un nodeSelector en la especificación del pod. También puedes definir una ComputeClass como predeterminada para un espacio de nombres de Kubernetes específico. Los pods de ese espacio de nombres usan esa ComputeClass, a menos que soliciten otra.

Por ejemplo, el siguiente manifiesto solicita la clase ComputeClass 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 añade etiquetas de 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 de sistema tienen uno de los siguientes prefijos en la clave de la etiqueta:

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

En GKE 1.32.3-gke.1499000 y versiones posteriores, puedes desplegar cargas de trabajo que usen un selector de nodos para seleccionar etiquetas del sistema y una ComputeClass al mismo tiempo. Si seleccionas etiquetas de sistema en los pods que seleccionan clases de cálculo, comprueba que esos pods se programan según lo previsto. Si hay un conflicto entre la configuración de un ComputeClass y los selectores de nodos de un pod, pueden producirse problemas como los siguientes:

• GKE no puede crear nodos que usen la configuración de mayor prioridad de ComputeClass.
• El Pod sigue teniendo 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 clases de cálculo, actualiza tus cargas de trabajo para quitar las siguientes etiquetas de los selectores de nodos y configura el campo correspondiente en las clases de cálculo que crees:

Siguientes pasos

• Consulta otras recomendaciones de implementación de cargas de trabajo en Autopilot de GKE
• Consulta cómo configurar, desplegar y solicitar ComputeClasses personalizados.