Acerca de las clases de procesamiento personalizadas

En esta página, se describe cómo puedes usar clases de procesamiento personalizadas 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.

Descripción general de las clases de procesamiento

En GKE, una clase de procesamiento 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. Las clases de procesamiento pueden orientarse a optimizaciones específicas, como aprovisionar nodos de alto rendimiento o priorizar las configuraciones de costo optimizado para costos de ejecución más económicos. Las clases de procesamiento personalizadas te permiten definir perfiles que GKE usa para aprovisionar nodos que cumplen con los requisitos de cargas de trabajo específicas.

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

Beneficios de las clases de procesamiento personalizadas

Las clases de procesamiento personalizadas ofrecen los siguientes beneficios:

  • Prioridades de procesamiento de resguardo: Define una jerarquía de configuraciones de nodos en cada clase de procesamiento para que GKE 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 resguardo garantiza que, incluso cuando los recursos de procesamiento no estén disponibles, tus cargas de trabajo aún se ejecuten en hardware optimizado con retrasos de programación mínimos.
  • Control de ajuste de escala automático detallado: Define la configuración del nodo que sea más adecuada para cargas de trabajo específicas. GKE prioriza esas configuraciones cuando crea nodos durante la escalabilidad.
  • Configuración de infraestructura declarativa: 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.
  • Clases de procesamiento predeterminadas para espacios de nombres: Configura una clase de procesamiento predeterminada en cada espacio de nombres de Kubernetes, de modo que las cargas de trabajo en ese espacio de nombres se ejecuten en hardware optimizado, incluso si no solicitan una clase de procesamiento 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 está por debajo de tu umbral, GKE intenta consolidar las cargas de trabajo en un nodo similar disponible y reducir la escala verticalmente del nodo con poco uso.

Casos de uso para clases de procesamiento personalizadas

Considera usar clases de procesamiento personalizadas en situaciones como las siguientes:

  • Quieres ejecutar tus cargas de trabajo de IA/AA en configuraciones de GPU específicas.
  • Deseas establecer la configuración de hardware predeterminada para las cargas de trabajo que ejecutan equipos específicos y quitar la sobrecarga de los operadores de la aplicación.
  • 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 parámetros de configuración de hardware que cumplan con requisitos empresariales específicos, como alto rendimiento, optimización de costos o alta disponibilidad.
  • Quieres que GKE recurra de forma jerárquica 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, de modo que los costos sean más predecibles y las cargas de trabajo se ejecuten de manera más confiable.

Limitaciones

No puedes usar clases de procesamiento personalizadas con reservas de capacidad de Compute Engine en modo Autopilot o en grupos de nodos de modo Standard aprovisionados automáticamente. Los grupos de nodos del modo Standard creados de forma manual admiten reservas de capacidad.

Cómo funcionan las clases de procesamiento personalizadas

Las clases de procesamiento personalizadas son recursos personalizados de Kubernetes que aprovisionan la infraestructura de Google Cloud. Debes definir un objeto ComputeClass en el clúster y, luego, solicitar esa clase de procesamiento en las cargas de trabajo o establecer esa clase de procesamiento como la predeterminada para un espacio de nombres de Kubernetes. Cuando implementas una carga de trabajo que solicita la clase de procesamiento, GKE intenta colocar los Pods en nodos que cumplan con los requisitos de la clase de procesamiento.

Para asegurarte de que tus clases de procesamiento 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.
  • Elige un tema que guíe el diseño de cada clase de procesamiento. Por ejemplo, una clase de procesamiento optimizada para el rendimiento podría tener una estrategia de resguardo que solo use tipos de máquinas con alta capacidad de CPU.
  • Decide la familia y la serie de máquinas de Compute Engine que se adecuen mejor a tus cargas de trabajo. Para obtener más información, consulta la guía de comparación y recursos de familias de máquinas.
  • Planifica una estrategia de resguardo dentro de cada clase de procesamiento 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 N2.

Visualiza la definición completa de recursos personalizados

Para ver la definición de recursos personalizados (CRD) completa del recurso personalizado ComputeClass, ejecuta el siguiente comando:

kubectl describe crd computeclasses.cloud.google.com

El resultado muestra toda la CRD, incluidos todos los campos compatibles y las relaciones entre los campos. Para comprender mejor las clases de procesamiento personalizadas, consulta esta definición mientras lees este documento.

Planifica una clase de procesamiento personalizada

Para planificar, implementar y usar una clase de procesamiento personalizada en tu clúster de manera eficaz, 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 clase de procesamiento.
  2. Configura los grupos de nodos y las clases de procesamiento de GKE Standard: para los clústeres del modo Standard, realiza los pasos de configuración necesarios para usar la clase de procesamiento con tus grupos de nodos.
  3. Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad: De manera opcional, indica a GKE qué hacer si no se pueden aprovisionar los nodos que cumplen con tus reglas de prioridad.
  4. Establece parámetros de ajuste de escala automático para la consolidación de nodos: Dile a GKE cuándo consolidar las cargas de trabajo y quitar los nodos infrautilizados.
  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.

Elige tus prioridades de procesamiento de resguardo

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

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

Reglas de prioridad

Debes 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 es la prioridad más alta para el aprovisionamiento de nodos.

Según el tipo de regla de prioridad, puedes especificar propiedades de máquina adicionales, como VMs Spot o capacidad de CPU mínima, para que GKE los use cuando aprovisiona nodos. El campo priorities admite los siguientes tipos de reglas de prioridad:

  • machineFamily: Define nodos con una serie de máquinas de Compute Engine, como n2 o c3.
  • machineType: Define nodos con un tipo de máquina predefinido de Compute Engine, como n2-standard-4.
  • nodepools: En los clústeres de GKE Standard, proporciona una lista de grupos de nodos creados de forma manual que están asociados con la clase de procesamiento en la que GKE debe aprovisionar los nodos.

Tipo de regla machineFamily

El campo machineFamily acepta una serie de máquinas de Compute Engine como n2 o c3. Si no se especifica, el valor predeterminado es e2. Puedes usar los siguientes campos junto con el tipo de regla machineFamily:

  • 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: Ruta de acceso a la clave de Cloud Key Management Service que se usará para la encriptación del disco de arranque.

En el siguiente ejemplo, se muestra la regla de prioridad machineFamily:

priorities:
- machineFamily: n2
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

Tipo de regla machineType

El campo machineType acepta un tipo predefinido de máquina de Compute Engine, como n2-standard-32. El tipo de máquina debe ser compatible con las GPUs que especifiques.

Puedes usar los siguientes campos junto con el tipo de regla machineType:

  • 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.
    • storage.localSSDCount: Es la cantidad de SSD locales que se conectarán al nodo. Si se especifica, debe ser de al menos 1.
  • gpu: Configura las GPUs.

En el siguiente ejemplo, se muestra una regla machineType para los tipos de máquinas n2-standard-32:

priorities:
- machineType: n2-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

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

priorities:
- machineType: g2-standard-16
  spot: false
  gpu:
    type: nvidia-l4
    count: 1

Tipo de regla de nodepools

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 especificar otras propiedades de la máquina junto con este campo en el mismo elemento de la regla de prioridad. 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 clase de procesamiento.

Cómo GKE crea nodos con reglas de prioridad

Cuando implementas una carga de trabajo que solicita una clase de procesamiento 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: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false

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

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

Grupos de nodos y clases de procesamiento de GKE Standard

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

Configura grupos de nodos creados de forma manual para el uso de la clase de procesamiento

Si tus clústeres de GKE Standard tienen grupos de nodos que creaste de forma manual sin aprovisionamiento automático de nodos, debes configurar esos grupos para asociarlos con clases de procesamiento específicas. GKE solo programa Pods que solicitan una clase de procesamiento específica en los nodos de los grupos de nodos que asocias con esa clase de procesamiento. El modo GKE Autopilot y los grupos de nodos del modo GKE Standard que creó el aprovisionamiento automático de nodos realizan esta configuración de forma automática.

Para asociar un grupo de nodos creado manualmente con una clase de procesamiento, 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 clase de procesamiento personalizada.

Por ejemplo, el siguiente comando actualiza un grupo de nodos existente y lo asocia con la clase de procesamiento dev-class:

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

Puedes asociar cada grupo de nodos de tu clúster con una clase de procesamiento 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.

Aprovisionamiento automático de nodos y clases de procesamiento

Puedes usar el aprovisionamiento automático de nodos con una clase de procesamiento personalizada para permitir que GKE cree y borre grupos de nodos de forma automática según tus reglas de prioridad.

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

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

Luego, GKE puede colocar Pods que usan clases de procesamiento que configuran el aprovisionamiento automático de nodos en grupos de nodos nuevos. 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 del Pod. Los Pods con clases de procesamiento que no configuran el aprovisionamiento automático de nodos solo continúan escalando verticalmente los grupos de nodos existentes.

Puedes usar clases de procesamiento que interactúen con el aprovisionamiento automático de nodos junto con las clases de procesamiento que interactúan con grupos de nodos creados de forma manual en el mismo clúster.

Considera las siguientes interacciones con el aprovisionamiento automático 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 la clase de procesamiento. GKE rechaza todos los Pods que soliciten una clase de procesamiento y también VMs Spot o series de máquinas específicas.
  • Puedes configurar el aprovisionamiento automático de nodos para las clases de procesamiento que usan el campo nodepools para hacer referencia a los grupos de nodos existentes. El aprovisionamiento automático de nodos procesa las prioridades en orden y, luego, intenta escalar los grupos de nodos existentes para colocar tus Pods.

Considera el siguiente ejemplo para un clúster que tiene grupos de nodos creados de forma manual y aprovisionamiento automático de nodos:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n2
  - machineFamily: n2d
  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 N2, ya sea en grupos de nodos N2 existentes o creando un grupo de nodos nuevo.
  3. Si GKE no puede crear nodos N2, intenta escalar verticalmente los grupos de nodos N2D existentes o crear grupos de nodos N2D nuevos.

Orienta grupos de nodos específicos en una definición de clase de procesamiento

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 clase de procesamiento 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 clase de procesamiento mediante etiquetas de nodos y taints de nodos, como se describe en la sección Configura grupos de nodos creados de forma manual para clases de procesamiento.

La lista de grupos de nodos que especifiques en el campo nodepools no tiene prioridad. Para configurar un orden de resguardo para 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 Pods pendientes que soliciten esta clase de procesamiento en nodos existentes en grupos de nodos etiquetados con la clase de procesamiento. Si los nodos existentes 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, 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 lo que GKE debería hacer 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. Este es el comportamiento predeterminado.
    • En los clústeres de Autopilot, GKE coloca el Pod en un nodo nuevo o existente, sin importar la configuración de la máquina del nodo.
    • En los clústeres Standard que no usan el aprovisionamiento automático de nodos, GKE intenta escalar verticalmente cualquier grupo de nodos creado de forma manual que defina una etiqueta y un taint que coincidan con una clase de procesamiento determinada.
    • En los clústeres estándar que usan el aprovisionamiento automático de nodos, GKE puede crear un grupo de nodos nuevo que use la serie de máquinas E2 predeterminada para colocar el Pod.
  • DoNotScaleUp: Deja el Pod con el estado Pending hasta que un nodo que cumpla con los requisitos de la clase de procesamiento esté disponible.

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

De forma predeterminada, GKE quita los nodos que tienen poco uso mediante la ejecución de cargas de trabajo y consolida esas cargas de trabajo en otros nodos que tengan capacidad. Para todas las clases de procesamiento, este es el comportamiento predeterminado porque todos los clústeres que usan clases de procesamiento deben usar el escalador automático del clúster o son 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 tiempo y los criterios para quitar nodos dependen del perfil de ajuste de escala automático. Puedes ajustar los umbrales de poco uso de recursos que activan la eliminación de nodos y la consolidación de cargas de trabajo mediante la sección autoscalingPolicy en tu definición de clase de procesamiento personalizada. Puedes ajustar los siguientes parámetros:

  • consolidationDelayMinutes: Es la cantidad de minutos después de los cuales GKE quita los nodos infrautilizados.
  • 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 0 para que GKE consolide los nodos que no tengan el 100% de la utilización de las GPUs conectadas.

Considera el siguiente ejemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  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%.

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

La migración activa es una función opcional de ajuste de escala automático en las clases de procesamiento personalizadas que reemplaza automáticamente los nodos existentes que están más abajo en una lista de prioridad de resguardo de una clase de procesamiento por nodos nuevos que están más arriba en esa lista de prioridad. Esto garantiza que todos tus Pods en ejecución se ejecuten, en última instancia, en los nodos más preferidos para esa clase de procesamiento, incluso si GKE originalmente tuvo que ejecutar esos Pods en nodos menos preferidos.

Cuando se produce una migración activa, GKE crea nodos nuevos según las reglas de prioridad de la clase de procesamiento y, luego, desvía y borra los nodos de menor prioridad obsoletos. 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 solo está disponible en las clases de procesamiento que usan el tipo de regla de prioridad machineFamily. Si tu clase de procesamiento tiene las reglas de prioridad nodepools o machineType, no se admite la migración activa.
  • 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 de prioridad más alto definidos en tu clase de procesamiento personalizada.
  • Para evitar interrupciones críticas de la carga de trabajo, la migración activa no mueve los siguientes Pods:
    • Pods que establecen un PodDisruptionBudget, si el movimiento superaría el PodDisruptionBudget.
    • Pods que tienen la anotación cluster-autoscaler.kubernetes.io/safe-to-evict: "false".

Considera la siguiente especificación de clase de procesamiento de ejemplo, que prioriza los nodos N2 sobre los nodos E2:

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

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

Solicita clases de procesamiento en cargas de trabajo

Para usar una clase de procesamiento personalizada después de terminar de diseñarla, tu Pod debe solicitar esa clase de procesamiento de forma explícita en la especificación del Pod. De manera opcional, puedes establecer una clase de procesamiento como predeterminada en un espacio de nombres específico de Kubernetes, en cuyo caso los Pods en ese espacio de nombres usarán esa clase de procesamiento, a menos que los Pods soliciten una clase de procesamiento diferente.

Si deseas obtener instrucciones para solicitar y usar clases de procesamiento en GKE, consulta Controla los atributos del nodo con ajuste de escala automático con clases de procesamiento personalizadas.

¿Qué sigue?