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 nodo que GKE usa para aprovisionar los nodos que ejecutan tus cargas de trabajo durante los eventos de escalado automático. Las ComputeClasses pueden orientarse a optimizaciones específicas, como aprovisionar nodos de alto rendimiento o priorizar parámetros de configuración optimizados para costos para reducir los costos de ejecución. Las ComputeClasses personalizadas te permiten definir perfiles que GKE usa para escalar automáticamente los nodos y cumplir con los requisitos de cargas de trabajo específicas.

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

Beneficios de las ComputeClasses personalizadas

Las clases de procesamiento personalizadas ofrecen los siguientes beneficios:

  • Prioridades de procesamiento de respaldo: Define una jerarquía de parámetros de configuración de nodos en cada ComputeClass 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 ayuda a garantizar 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 de escalado automático detallado: Define los parámetros de configuración de los nodos que mejor se adapten a cargas de trabajo específicas. GKE prioriza esos parámetros de configuración cuando crea nodos durante el escalamiento.
  • Configuración de infraestructura declarativa: Adopta un enfoque declarativo para la administración de 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 un clúster completo 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 de tu umbral, GKE intenta consolidar las cargas de trabajo en un nodo similar disponible y reduce la escala verticalmente del nodo infrautilizado.
  • Capacidad mínima declarativa: Mantén una cantidad mínima de nodos de esta ComputeClass en tu clúster de forma proactiva, lo que ayuda a garantizar que la capacidad esté disponible para las cargas de trabajo críticas.

Casos de uso de las ComputeClasses personalizadas

Considera usar ComputeClasses personalizadas en situaciones como las siguientes:

  • Quieres ejecutar tus cargas de trabajo de IA/AA en configuraciones específicas de GPU o TPU.
  • Quieres 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 la aplicación.
  • Ejecutas cargas de trabajo que se desempeñan de manera óptima en series de máquinas o parámetros de configuración de hardware específicos 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.
  • Quieres decidir de forma centralizada las configuraciones óptimas en toda la flota de tu empresa, de modo que tus costos sean más predecibles y tus cargas de trabajo se ejecuten de forma 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.
  • Quieres especificar una política de posición compacta para usarla con GKE Autopilot. Para obtener más detalles, consulta posición compacta.

Cómo funcionan las ComputeClasses personalizadas

Las ComputeClasses personalizadas son recursos personalizados de Kubernetes que aprovisionan la infraestructura deCloud de Confiance by S3NS . Defines un objeto ComputeClass en el clúster y, luego, solicitas ese ComputeClass en las cargas de trabajo o lo configuras como el predeterminado para un espacio de nombres de Kubernetes. Cuando una carga de trabajo coincidente exige una infraestructura nueva, GKE aprovisiona nodos nuevos de acuerdo con las prioridades que estableciste 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 una ComputeClass existente, todos los nodos futuros que GKE crea para esa ComputeClass usan la configuración modificada. GKE no cambia de forma retroactiva la configuración de los nodos existentes para que coincida 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 los nodos existentes estén 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 adaptan 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áquina similares. Por ejemplo, si la serie de máquinas N4 no está disponible, puedes recurrir a las máquinas C3.

Visualiza la definición completa del recurso personalizado

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 forma opcional, indica a GKE qué 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 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.
  6. Consume reservas de Compute Engine: De manera opcional, indica a GKE que consuma las reservas zonales existentes de Compute Engine cuando cree nodos nuevos.
  7. Aprovisiona una cantidad mínima de nodos: De manera opcional, indica a GKE que mantenga una cantidad mínima de nodos en tu clúster.

Elige tus prioridades de procesamiento de respaldo

La principal ventaja de usar una ComputeClass personalizada es tener control sobre la estrategia de resguardo cuando tus nodos preferidos no están disponibles debido a factores como el agotamiento de recursos zonales (como ver mensajes ZONE_RESOURCE_POOL_EXHAUSTED o GCE out of resources durante eventos FailedScaleUp) y limitaciones de cuota. Si defines una lista priorizada de series de máquinas o modelos de aprovisionamiento alternativos, tu clúster puede aprovisionar automáticamente la capacidad disponible en lugar de dejar los Pods en un estado Pending. Para obtener más información sobre cómo solucionar problemas de capacidad de procesamiento insuficiente, consulta La creación del grupo de nodos falla debido a que no hay recursos suficientes y No se pudo escalar verticalmente el nodo: Compute Engine no tiene recursos.

Para crear una estrategia de resguardo, debes definir una lista de reglas de prioridad en el campo priorities de la especificación de ComputeClass. Cada regla de prioridad puede solicitar nodos de una de las siguientes maneras:

  • Propiedades de los nodos: Define las propiedades de los nodos en los que deseas que se ejecuten los Pods, como las familias de máquinas que se usarán. Cuando un Pod activa una operación de escalamiento vertical, GKE intenta crear un nodo que tenga esas propiedades. Cada regla de prioridad debe especificar un tipo de hardware para aprovisionar, como se describe en la sección Propiedades de nodo de nivel superior para reglas de prioridad.

  • Selección de grupos de nodos: En los clústeres de GKE Standard, especifica los nombres de los grupos de nodos existentes que se asociarán con la ComputeClass. Cuando un Pod activa una operación de escalamiento vertical, GKE intenta colocar el Pod en esos grupos de nodos. Las reglas de prioridad que seleccionan grupos de nodos no admiten ningún otro campo. Para obtener más información, consulta la sección Grupos de nodos y ComputeClasses de GKE Standard.

De forma predeterminada, cuando se necesita un nodo nuevo para un Pod entrante que selecciona una ComputeClass, GKE intenta crear nodos en el orden en que aparecen las reglas de prioridad en el manifiesto de ComputeClass. En la versión 1.35.2-gke.1842000 y posteriores de GKE, también puedes establecer de forma explícita una puntuación para cada regla de prioridad en una ComputeClass con el campo priorityScore, en cuyo caso GKE procesa las reglas en orden de la puntuación más alta a la más baja. Si se agotan todas las reglas de prioridad de una ComputeClass, GKE crea nodos según el comportamiento descrito en Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad.

Puntuaciones de las reglas de prioridad

Se requiere la versión 1.35.2-gke.1842000 o posterior de GKE.

Para tener un control detallado sobre el orden en que GKE procesa las reglas de prioridad de una ComputeClass, usa el campo priorityScore en tus reglas. Durante el escalamiento, GKE procesa tus reglas de prioridad según la puntuación, y los valores de puntuación más altos tienen una prioridad más alta que los valores más bajos.

El campo priorityScore tiene las siguientes propiedades:

  • El campo acepta un valor entero con un valor mínimo de 1 y un valor máximo de 1000.
  • Debes usar el campo priorityScore en todas tus reglas de prioridad o en ninguna de ellas.

  • Puedes establecer la misma puntuación de prioridad para hasta tres reglas independientes. Durante el escalamiento, GKE procesa las reglas que tienen la misma puntuación en conjunto. GKE elige una regla específica para usar según los criterios de funcionamiento del escalador automático del clúster.

    Las reglas agrupadas pueden aumentar la latencia del escalado automático, ya que GKE debe ejecutar más simulaciones para determinar la configuración óptima del nodo. La probabilidad de que notes un aumento de la latencia depende de la amplitud de la selección de hardware en la regla, de la siguiente manera:

    • Las reglas que tienen un alcance amplio, como la propiedad machineFamily, tienen más probabilidades de contribuir a un ligero aumento en la latencia del ajuste de escala automático. Sin embargo, es más probable que GKE encuentre hardware disponible que cumpla con los requisitos de esas reglas.
    • Es menos probable que las reglas que tienen un alcance limitado, como la propiedad machineType, contribuyan a un aumento de la latencia. Sin embargo, es más probable que GKE no pueda encontrar hardware disponible que cumpla con los requisitos de esas reglas.

En el siguiente ejemplo, se muestra una ComputeClass que establece puntuaciones de reglas de prioridad:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Highest priority score in the ComputeClass
  - machineFamily: e2
    spot: true
    priorityScore: 30
  # Grouped priority rules that have the same score.
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  # Lowest priority score in the ComputeClass.
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

Durante un evento de escalamiento vertical para esta ComputeClass de ejemplo, GKE hace lo siguiente:

  1. GKE intenta crear instancias E2.
  2. Si las instancias E2 no están disponibles, GKE crea instancias N2 o T2D, según el resultado del escalador automático del clúster.
  3. Si las instancias N2 y T2D no están disponibles, GKE intenta crear instancias N1.
  4. Si las instancias N1 no están disponibles, GKE recurre a la serie de máquinas predeterminada para el clúster.

Propiedades de nodo de nivel superior para las reglas de prioridad

Cuando especificas reglas de prioridad que definen las propiedades de los nodos, debes seleccionar un tipo de hardware de nivel superior que desees para los nodos. Las otras propiedades que puedes especificar para una regla dependen de la propiedad de nivel superior de esa regla.

Puedes usar cualquiera de las siguientes propiedades de nivel superior para una regla:

  • machineFamily: Es una serie de máquinas de Compute Engine, como n4.
  • machineType: Es un tipo de máquina de Compute Engine específico, como n4-standard-32.
  • gpu: Es una configuración de GPU, que puede incluir un tipo de GPU, una cantidad específica de GPU y la configuración del controlador.
  • tpu: Es una configuración de Cloud TPU, que puede incluir una versión de TPU, una topología y una cantidad de chips.

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

Cada generación de series de máquinas de Compute Engine admite tipos de discos específicos. Por ejemplo, la serie de máquinas N4 admite los tipos de discos Hyperdisk ML, pero la serie de máquinas N2 no. En las ComputeClasses que abarcan varias generaciones, es posible que las cargas de trabajo con estado que solicitan un tipo de disco específico no puedan acceder a los datos persistentes si el tipo de máquina no admite ese tipo de disco. Según cómo crees y uses los discos en tus cargas de trabajo, usa cualquiera de los siguientes métodos para reducir el riesgo de que los datos persistentes sean inaccesibles:

  • Aprovisionamiento dinámico de volúmenes: En la versión 1.35.3-gke.1290000 y posteriores de GKE, usa una StorageClass que configure la selección automática del tipo de disco. GKE crea un tipo de disco que es compatible con el tipo de máquina del nodo que ejecuta tu carga de trabajo. En versiones anteriores de GKE, verifica que todas las series de máquinas de tu ComputeClass admitan el tipo de disco que aprovisionan tus StorageClasses.

  • Discos persistentes preexistentes: Verifica que todas las series de máquinas de tu ComputeClass admitan los tipos de discos de tus discos persistentes preexistentes.

Para obtener más información sobre los tipos de discos compatibles con cada serie de máquinas, consulta la tabla de comparación de series de máquinas.

Parámetros de configuración de machineFamily

El campo machineFamily acepta cualquier serie de máquinas de Compute Engine que admita GKE, como n2 o c3. Si no se especifica, el valor predeterminado es e2. Cuando usas el campo machineFamily, GKE aprovisiona nodos de esa serie con un tipo de máquina que es lo suficientemente grande como para ejecutar tus Pods. El algoritmo del escalador automático determina el tamaño más adecuado según las solicitudes de recursos agregadas de todos los Pods pendientes. Para tener más control sobre el tamaño exacto de la máquina, usa el campo machineType en su lugar.

Solicitar una familia de máquinas más amplia no aprovisiona tipos de máquinas de Bare Metal. Por ejemplo, solicitar c3 o c4a no aprovisiona tipos de máquinas como c3-standard-192-metal o c4a-standard-72-metal, respectivamente. Debido a que los tipos de nodos de equipos físicos requieren que se solicite un tipo de máquina exacto, tampoco puedes usar la ComputeClass Performance predefinida de Autopilot.

Para aprovisionar tipos de máquinas de equipos físicos, crea una ComputeClass personalizada y especifica el tipo de máquina exacto en el campo machineType. Los tipos de máquinas Bare Metal tienen los siguientes requisitos de versión:

  • Los tipos de máquinas de equipos físicos c3 y c4a con ComputeClasses, la creación automática de grupos de nodos o el modo Autopilot requieren la versión 1.35.3-gke.1389000 o posterior de GKE.
  • Los tipos de máquinas de equipos físicos de c4d con ComputeClasses, la creación automática de grupos de nodos o el modo Autopilot requieren la versión 1.37.0-gke.4713000 o posterior de GKE. Los grupos de nodos en el modo estándar que usan tipos de máquinas de equipos físicos de c4d requieren la versión 1.36 o posterior de GKE. En las versiones anteriores a la 1.37.0-gke.4713000, debes crear y escalar estos grupos de nodos de Standard de forma manual.

Puedes usar otros campos de spec.priorities 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. Este campo es útil para evitar la creación de nodos que sean demasiado pequeños para tus necesidades.
  • minMemoryGb: Es la memoria mínima por nodo. El valor predeterminado es 0.
  • storage.bootDiskType: Es el tipo de disco de arranque. En los clústeres de Autopilot, solo se admite el tipo pd-balanced de bootDiskType. Se requiere la versión 1.34.1-gke.1431000 o posterior de GKE.
  • storage.bootDiskSize: Es el tamaño en GB del disco de arranque del nodo. Se requiere la versión 1.34.1-gke.1431000 o posterior de GKE.
  • 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 nodos de GKE con datos, 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 use tu clúster, consulta Configura 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: los detalles de la ubicación de la máquina:
  • enableNestedVirtualization: Indica si se debe habilitar la virtualización anidada en los nodos. El valor predeterminado es false.

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

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset

Parámetros de configuración de machineType

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

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: Es el 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 de al menos 1.
  • enableNestedVirtualization: Indica si se debe habilitar la virtualización anidada en los nodos. El valor predeterminado es false.

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: hyperdisk-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

Configuración de GPU

Para seleccionar las GPU en tus reglas de prioridad, especifica el tipo, el recuento y la driverVersion (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 detalles, consulta Elige la compatibilidad con GPU con Autopilot o Standard.
  • gpu.count: Es la cantidad de GPUs que se deben adjuntar. 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 o posterior de GKE.
  • acceleratorNetworkProfile: Es el perfil de red del acelerador para la GPU, como auto. Se requiere la versión 1.35.2-gke.1842000 o posterior de GKE.

También puedes especificar otros campos de spec.priorities, 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

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

Para seleccionar TPU 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 campos de spec.priorities 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: Es el 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 detalles, consulta la sección Consume reservas de Compute Engine.
  • location:
    • zones: Es una lista de zonas de Cloud de Confiance en las que GKE puede aprovisionar nodos. Si no se especifica, GKE aprovisiona nodos en las zonas configuradas en los parámetros de configuración de aprovisionamiento automático de nodos del clúster. Si no se configuran zonas para el aprovisionamiento automático de nodos, GKE aprovisiona nodos en cualquiera de las zonas estándar que usa el plano de control.

      Opcional: Usa una zona de IA, como us-central1-ai1a. Las zonas de IA son ubicaciones especializadas que están optimizadas para cargas de trabajo de IA/AA dentro de las regiones de Cloud de Confiance by S3NS .

    • zoneTypes: Es una lista de tipos de zonas que especifica un conjunto de zonas de Cloud de Confiance en las que GKE puede aprovisionar nodos. Los valores admitidos son CLUSTER_DEFAULT (predeterminado), STANDARD y AI. Para obtener más información, consulta Usa la prioridad de zoneTypes de ubicación.

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 de 16 nodos consumiendo una reserva compartida de Compute Engine llamada tpu-reservation del proyecto reservation-project.
  2. Si la reserva no tiene TPU disponibles, GKE intenta aprovisionar una porción de TPU v5p de varios hosts de 16 nodos que se ejecute en VMs Spot.
  3. Si no se puede cumplir 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:

Zonas de IA de destino

También puedes usar una clase de procesamiento para especificar zonas de IA para tus Pods. Las zonas de IA son ubicaciones especializadas dentro de las regiones de Cloud de Confiance by S3NS optimizadas para cargas de trabajo de IA/AA. La siguiente clase de procesamiento establece una lista priorizada de zonas que incluye zonas de IA:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-ai-preferred
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
    # --- Priority 1: TPU in a specific AI zone (On-Demand) ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zones:
          - "us-central1-ai1a" # Specify your target AI zone
      # machineFamily: a3 # Optional

    # --- Priority 2: TPU in any AI zone (On-Demand)  ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zoneTypes:
          - "AI" # All AI zones in the cluster's region

    # --- Priority 3: GPU in a specific Standard zone (On-Demand) ---
    - gpu:
        type: nvidia-tesla-a100
        count: 1
      location:
        zones:
          - "us-central1-a" # Fallback to a standard zone
          - "us-central1-b"
  whenUnsatisfiable: DoNotScaleUp

Esta ComputeClass configura GKE para aprovisionar nodos con TPU v5p o GPU A100 para la carga de trabajo. Los nodos tienen las siguientes preferencias:

  • Prioridad 1: Intenta aprovisionar la TPU en la zona de IA us-central1-ai1a.
  • Prioridad 2: Si la TPU no está disponible en la zona de IA específica, intenta aprovisionarla en cualquier zona de IA de la región del clúster.
  • Prioridad 3: Si la TPU no está disponible en las zonas de IA, intenta aprovisionar la GPU en las zonas estándar us-central1-a o us-central1-b.
  • Si las GPU A100 no están disponibles en ninguna de las zonas especificadas, GKE no escalará verticalmente el grupo de nodos.

Configuración de red de DRANET

Se requiere la versión 1.35.2-gke.1842000 o posterior de GKE.

Para usar DRANET administrado por GKE con el objetivo de solicitar y asignar interfaces de red para Pods, debes habilitar la función en tu ComputeClass. Debes hacer lo siguiente:

  • Habilita el controlador de red DRANET configurando nodePoolConfig.dra.networking.enabled como true.
  • Establece el acceleratorNetworkProfile en auto en la lista priorities.

Para obtener más información sobre cómo usar DRANET, consulta Asigna recursos de red con DRANET administrado por GKE.

Cómo GKE crea nodos con reglas de prioridad

Cuando implementas una carga de trabajo que solicita una ComputeClass y se necesita un nodo nuevo, GKE procesa la lista de reglas en el campo priorities de la especificación ComputeClass en orden de aparición o, si se establece el campo priorityScore, de la puntuación más alta a la más baja.

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 Pods en cualquier nodo existente que esté asociado con 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 a pedido.
  5. Si no se puede cumplir 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 de GKE o una posterior.
  • 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 y ComputeClasses 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 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 Pods que solicitan una ComputeClass específica en nodos de grupos de nodos que asocias con esa ComputeClass. Este requisito no se aplica a una ComputeClass que configures como predeterminada a nivel de clúster.

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

Para asociar un grupo de nodos creado manualmente con una 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 juntos actualizan un grupo de nodos existente y lo asocian 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 grupos de nodos de forma automática según tus reglas de prioridad.

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

  1. Agrega el campo nodePoolAutoCreation con el valor enabled: true a tu especificación de ComputeClass.
  2. Si tu clúster ejecuta una versión anterior a la 1.33.3-gke.1136000 de GKE, 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 según 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 siguen 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.

Considera las siguientes interacciones con la creación automática de grupos de nodos:

  • No puedes usar los selectores de nodos de la familia de máquinas ni de las VMs Spot, ya que estos selectores entran en conflicto con el comportamiento de ComputeClass. GKE rechaza cualquier Pod que solicite una ComputeClass y también solicite 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 de N4 activa la creación de nodos si la clase predeterminada a nivel del clúster tiene una regla de prioridad para las instancias de N4.
    • La ComputeClass predeterminada a nivel del clúster tiene un valor de 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 seleccionan una familia de máquinas que no está en las prioridades de clase predeterminadas a nivel del clúster no activarán la creación de nodos si la 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, luego, intenta escalar verticalmente los grupos de nodos existentes para colocar tus Pods.

Considera el siguiente ejemplo de un clúster que tiene grupos de nodos creados de forma manual 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.

Orienta 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 que están 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 alguna 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, sin importar la configuración de la máquina del nodo.
    • En los clústeres de Standard que no usan la creación automática de grupos 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 ComputeClass determinada.
    • En los clústeres de Standard que usan la creación automática de grupos de nodos, GKE podría crear 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 de carga de trabajo personalizada. Para obtener más información, consulta Comparación de la política de posición compacta y la política de carga de trabajo.

Tanto la política de posición como la de carga de trabajo colocan los nodos físicamente cerca para reducir la latencia de red. Para usar una política específica, debes proporcionar 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 esta 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 las cargas de trabajo en ejecución no utilizan lo suficiente 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 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 momento y los criterios para quitar nodos dependen del perfil de escalado automático. Puedes ajustar los umbrales de infrautilización de recursos que activan la eliminación de nodos y la consolidación de cargas de trabajo con la sección autoscalingPolicy en tu 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 infrautilizados.
  • consolidationThreshold: Es el límite de uso de CPU y memoria como un porcentaje de los recursos disponibles del nodo. GKE solo considera quitar los 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 quitar los 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 de ajuste de escala automático opcional en ComputeClasses que reemplaza automáticamente los nodos existentes por nodos nuevos. Se admiten los siguientes tipos de migración activa:

  • optimizeRulePriority: GKE reemplaza los nodos que usan una configuración de menor prioridad por nodos que usan una configuración de mayor prioridad. Esta opción proporciona una recuperación automática después de una escasez temporal de capacidad zonal (ZONE_RESOURCE_POOL_EXHAUSTED). Esta opción ayuda a garantizar que tus Pods sin estado o tolerantes a interrupciones vuelvan a tu configuración de nodo preferida, incluso si GKE originalmente tuvo que aprovisionar hardware de resguardo de una regla de menor prioridad.
  • ensureAllDaemonSetPodsRunning: GKE reemplaza los nodos que tienen Pods de DaemonSet no programables por nodos más grandes que pueden ejecutar todos los Pods de DaemonSet requeridos. Esta opción te ayuda a garantizar que todos tus DaemonSets se ejecuten en tus nodos.

Durante una migración activa, GKE hace lo siguiente:

  1. GKE crea un nodo nuevo con una configuración que cumple con los requisitos del tipo de migración activo.
  2. GKE acordona el nodo existente para que los Pods nuevos no se ejecuten en ese nodo.

  3. GKE vacía el nodo existente, lo que expulsa los Pods del nodo. Los siguientes factores afectan la rapidez con la que se vacía el nodo:

    Los controladores de Kubernetes, como Deployments o Jobs, crean Pods para reemplazar los Pods expulsados. GKE programa estos Pods nuevos en el nodo nuevo.

  4. Después de que se vacía el nodo existente, GKE lo borra.

La migración activa no afecta a los Pods ni a los nodos en las siguientes situaciones:

  • La migración activa no expulsa los Pods que tienen la anotación cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • La migración activa no expulsa Pods si la expulsión infringe un PodDisruptionBudget.
  • La migración activa no reemplaza los nodos que no se pueden quitar. Por ejemplo, la migración activa no reemplaza un nodo si, al hacerlo, se infringe el parámetro de configuración del grupo de nodos --min-nodes.

Antes de habilitar la migración activa para una ComputeClass, ten en cuenta los siguientes efectos potenciales:

  • La migración activa no migra los datos que se almacenan 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 usan las cargas de trabajo con estado.
  • En los clústeres de Standard, si usas la creación automática de grupos de nodos, 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 ComputeClass.
  • 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 que causa la migración activa.
  • Si actualizas una ComputeClass existente para habilitar la migración activa, GKE migra los Pods existentes a nodos nuevos cuando los recursos de procesamiento estén disponibles.

Migración activa a nodos de prioridad más alta

El tipo de migración activa optimizeRulePriority permite que GKE reemplace los nodos existentes que usan una configuración de menor prioridad por nodos que usan una configuración de mayor prioridad.

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, por ejemplo, debido a una escasez temporal de recursos zonales (ZONE_RESOURCE_POOL_EXHAUSTED), GKE habría usado nodos C4 como opción de resguardo. Cuando la capacidad de N4 se recupere en tu ubicación o aumente tu cuota, GKE migrará automáticamente tus cargas de trabajo de vuelta a los nodos N4:

  1. GKE crea un nodo N4 nuevo.
  2. GKE acordona y vacía el nodo C4 existente. Se expulsan tus Pods, y se respetan los PodDisruptionBudgets y las configuraciones de finalización correcta.
  3. Los controladores de Kubernetes crean Pods para reemplazar los Pods expulsados. Estos Pods nuevos se ejecutan en el nodo N4.
  4. Después de que se drena el nodo C4, GKE lo borra.

Del mismo modo, si usas el campo priorityScore para establecer puntuaciones explícitas para tus reglas de prioridad, GKE reemplaza los nodos que tienen una puntuación más baja por nodos que tienen una puntuación más alta.

Migración activa para ejecutar Pods de DaemonSet no programables

El tipo de migración activa ensureAllDaemonSetPodsRunning permite que GKE reemplace automáticamente los nodos existentes que tienen Pods de DaemonSet no programables por nodos más grandes que puedan ejecutar esos Pods de DaemonSet.

Por ejemplo, la siguiente especificación de ComputeClass configura la familia de máquinas N4:

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

Considera una situación en la que creaste un Deployment de un solo Pod que usó esta ComputeClass y solicitó dos CPUs virtuales. Para ejecutar este Pod, GKE creó un nodo n4-standard-2. Más adelante, creas un DaemonSet que también solicita dos CPUs virtuales. El Pod de DaemonSet no se puede ejecutar en el nodo n4-standard-2. En esta situación, GKE hace lo siguiente:

  1. GKE crea un nodo que usa un tipo de máquina N4 más grande, como n4-standard-4, que puede ejecutar tu Pod y el Pod de DaemonSet. El Pod de DaemonSet pendiente se programa en este nodo nuevo.
  2. GKE acordona y vacía el nodo n4-standard-2.
  3. Cuando se expulsa tu Pod, el Deployment crea un Pod de reemplazo. GKE programa este Pod en el nodo n4-standard-4, junto con el Pod de DaemonSet.
  4. Después de que se vacía el nodo n4-standard-2, GKE lo borra.

Consume reservas de Compute Engine

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

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

Para consumir reservas de Compute Engine con una ComputeClass personalizada, puedes usar los siguientes métodos:

  • Creación automática de grupos de nodos: GKE crea automáticamente grupos de nodos nuevos para consumir las reservas que especificaste. Para obtener más información, consulta Creación automática de grupos de nodos y ComputeClasses.
  • Grupos de nodos creados de forma manual: En los clústeres del modo Estándar, puedes enrutar las cargas de trabajo a los grupos de nodos creados de forma manual especificando el campo spec.priorities.nodepools en tu ComputeClass.

A partir de la versión 1.36.0-gke.3204000 de GKE, puedes configurar tus cargas de trabajo para que consuman cualquier reserva coincidente sin recurrir a la capacidad a pedido con el parámetro de configuración de afinidad AnyThenFail.

Consume reservas en grupos de nodos creados de forma manual

Para consumir reservas en grupos de nodos creados de forma manual en clústeres de Standard con ComputeClasses, sigue estos pasos:

  1. Vincula las reservas a los grupos de nodos siguiendo los pasos que se indican en Consume instancias reservadas en GKE Standard.

  2. Crea una ComputeClass que use la regla de prioridad nodepools para seleccionar los grupos de nodos que creaste de forma manual.

Por ejemplo, imagina una situación en la que tienes dos grupos de nodos, cada uno de los cuales vinculaste a una reserva de capacidad independiente. Prefieres que los Pods usen la capacidad reservada en el grupo de nodos reservation-pool-1 en lugar del grupo de nodos reservation-pool-2. La ComputeClass que implementa estas preferencias es similar al siguiente ejemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: manual-pool-reservations
spec:
  priorities:
  - nodepools: ['reservation-pool-1']
  - nodepools: ['reservation-pool-2']

En este ejemplo, GKE intenta colocar Pods en el reservation-pool-1 primero, porque esa regla de prioridad aparece primero en el campo priorities.

Crea grupos de nodos automáticamente para consumir reservas

Si usas la creación automática de grupos de nodos, puedes solicitar que GKE use reservas de capacidad para crear grupos de nodos para reglas de prioridad específicas. Para consumir reservas en grupos de nodos creados automáticamente, debes cumplir con los siguientes requisitos:

  • La ComputeClass debe habilitar la creación automática de grupos de nodos.
  • Las reservas que no son de TPU solo se pueden usar cuando se define machineType o machineFamily.
  • Las ComputeClasses que configuran SSD locales deben usar la regla de prioridad machineType, no machineFamily. Para obtener más detalles, consulta la sección Tipo de regla machineType.
  • Las ComputeClasses que especifican reservas para un machineType que tiene SSD locales conectados deben incluir un campo localSSDCount: de forma explícita.

Considera la siguiente especificación de ComputeClass de ejemplo, que prioriza una reserva compartida específica para usar cuando se aprovisionan instancias de a3-highgpu-1g. Si los tipos de instancias priorizados no están disponibles, GKE recurre a cualquier reserva coincidente 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 escalar verticalmente las instancias de a3-highgpu-1g con cualquier reserva que coincida. 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 escalamiento falla.

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

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

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 para un único proyecto: configura los siguientes campos:

    • Especifica el nombre de la reserva en el campo reservations.specific.name.
    • Asegúrate de que el valor del campo reservations.affinity sea Specific.

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

    • Especifica el nombre de la reserva en el campo reservations.specific.name.
    • Especifica el ID del proyecto al que pertenece la reserva en el campo reservations.specific.project.
    • Asegúrate de que el valor del campo reservations.affinity sea Specific.

  • Cualquier reserva coincidente con resguardo: Configura los siguientes campos:

    • Asegúrate de que el valor del campo reservations.affinity sea AnyBestEffort.
    • No establezcas un nombre de reserva ni un proyecto.

  • Cualquier reserva coincidente sin resguardo: Configura los siguientes campos:

    • Asegúrate de que el valor del campo reservations.affinity sea AnyThenFail.
    • No establezcas un nombre de reserva ni un proyecto.
    • Es opcional. Para aplicar de forma estricta el error si se agotan las reservas coincidentes, establece el parámetro de configuración whenUnsatisfiable: DoNotScaleUp en el nivel spec de ComputeClass.

Las reservas de TPU requieren afinidad específica. No se admiten los parámetros de configuración reservations.affinity: AnyBestEffort y reservations.affinity: AnyThenFail.

Si GKE no puede encontrar capacidad disponible en una reserva, el comportamiento resultante dependerá 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 la ComputeClass.
  • Cualquier reserva coincidente con resguardo (AnyBestEffort): GKE intenta aprovisionar un nodo bajo demanda que cumpla con los requisitos de esa regla de prioridad. Si GKE no puede aprovisionar un nodo a pedido, GKE intenta con la siguiente regla de prioridad en la ComputeClass.
  • Cualquier reserva coincidente sin resguardo (AnyThenFail): GKE omite el aprovisionamiento de un nodo a pedido y prueba la siguiente regla de prioridad en la ComputeClass. Si no se aplican otras reglas, la operación de escalamiento falla según el valor del parámetro de configuración whenUnsatisfiable.

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

Consume bloques de reservas 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

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 orientar 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 Consume subbloques de reserva específicos.

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

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

Cantidad mínima de nodos

Disponible en la versión 1.36.3-gke.1253000 y posteriores de GKE.

Puedes especificar una cantidad mínima de nodos que GKE debe mantener para una ComputeClass completa o para reglas de prioridad específicas con el campo minimumCapacity.targetNodeCount. GKE mantiene, al menos, la cantidad especificada de nodos, incluso si esa capacidad está inactiva. Especificar una capacidad mínima funciona bien para las cargas de trabajo que necesitan una cantidad de referencia de capacidad de procesamiento, como las cargas de trabajo de entrenamiento de IA o AA grandes o de entrega de baja latencia. GKE sigue escalando automáticamente los nodos por encima del mínimo cuando tus cargas de trabajo necesitan más capacidad.

Cuando especifiques una capacidad mínima para una ComputeClass o una regla de prioridad, ten en cuenta el siguiente comportamiento:

  • Si la capacidad es para toda la ComputeClass, GKE mantiene al menos esa cantidad de nodos en todas las reglas de prioridad de la ComputeClass. Si la capacidad es para una regla de prioridad específica, GKE mantiene al menos esa cantidad de nodos para esa regla de prioridad.
  • Si la cantidad de nodos es menor que la cantidad mínima especificada, GKE crea nodos nuevos de forma automática para mantener la capacidad mínima, incluso si esos nodos adicionales no ejecutan ninguno de tus Pods.
  • GKE no reduce la escala verticalmente de los nodos que conforman la capacidad mínima, incluso si esos nodos están vacíos.
  • La capacidad especificada es un valor mínimo. Durante los eventos de escalamiento vertical, GKE puede superar la cantidad mínima de nodos para ejecutar Pods pendientes.
  • Si habilitas la migración activa a nodos de mayor prioridad, GKE puede reemplazar los nodos de la capacidad mínima por nodos de una regla de mayor prioridad. Sin embargo, GKE no reemplaza un nodo si el reemplazo coloca una regla de prioridad por debajo de su capacidad mínima.
  • La disponibilidad de recursos o las cuotas pueden impedir que GKE cree nodos para el requisito de capacidad mínima.
  • Si GKE no puede crear suficientes nodos para la capacidad mínima de una regla de prioridad, GKE no recurre a otras reglas de prioridad. En su lugar, GKE crea los nodos faltantes para esa regla de prioridad cuando la capacidad está disponible.
  • Es posible que los nodos se borren y reemplacen para mantener el estado del clúster (por ejemplo, para corregir un nodo en mal estado o interrumpir una VM Spot). GKE crea nodos nuevos de forma automática para mantener la capacidad mínima.

Según si configuras una capacidad mínima para una ComputeClass completa o para reglas de prioridad específicas, se aplican los siguientes requisitos:

  • Capacidad mínima para ComputeClass: Si especificas el campo minimumCapacity.targetNodeCount para toda la ComputeClass, todas las reglas de prioridad deben solicitar de forma directa o indirecta un tipo de máquina específico. Cada regla de prioridad debe usar al menos uno de los siguientes parámetros de configuración:

    • machineType
    • gpu
    • tpu
    • Una reserva de capacidad específica

    GKE rechaza las ComputeClasses que usan configuraciones flexibles en una regla de prioridad, como el campo machineFamily, y que también especifican una capacidad mínima para toda la ComputeClass.

  • Capacidad mínima para una regla de prioridad: Si especificas el campo minimumCapacity.targetNodeCount para una regla de prioridad específica, esa regla de prioridad debe solicitar de forma directa o indirecta un tipo de máquina específico con al menos uno de los siguientes parámetros de configuración:

    • machineType
    • gpu
    • tpu
    • Una reserva de capacidad específica

En los siguientes ejemplos, se muestra la configuración de capacidad mínima para una ComputeClass y para una regla de prioridad:

  • ComputeClass:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: gpu-class-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  # Define a global minimum capacity of 5 nodes for this ComputeClass
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - gpu:
      type: "nvidia-tesla-a100"
      count: 1
    machineType: "a2-highgpu-1g"
  - gpu:
      type: "nvidia-l4"
      count: 1
    machineType: "g2-standard-8"

  • Regla de prioridad:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tiered-compute-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: "n2-standard-16"
    # Maintain at least three nodes of this specific configuration
    minimumCapacity:
      targetNodeCount: 3
  - machineType: "e2-standard-4"

Capacidad mínima para una ComputeClass y sus reglas de prioridad

Si especificas una capacidad mínima para una ComputeClass y para algunas de sus reglas de prioridad, los mínimos de las reglas de prioridad se consideran para el mínimo de la ComputeClass. Se aplica un siguiente comportamiento:

  • Si los mínimos de la regla de prioridad suman al menos el mínimo de ComputeClass, los nodos de las reglas de prioridad también cumplen con el mínimo de ComputeClass. GKE no crea nodos adicionales para el mínimo de ComputeClass, incluso en reglas de mayor prioridad que no especifican una capacidad mínima.
  • El mínimo de ComputeClass no limita los mínimos de la regla de prioridad. GKE crea todos los nodos para cada mínimo de regla de prioridad, incluso si el total supera el mínimo de ComputeClass.
  • Si los mínimos de la regla de prioridad suman menos que el mínimo de ComputeClass, GKE crea los nodos restantes con las reglas de prioridad en orden. Si es necesario, GKE recurre a reglas de menor prioridad para estos nodos restantes.

Por ejemplo, considera la siguiente ComputeClass, que especifica una capacidad mínima para la ComputeClass y para la segunda regla de prioridad:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: combined-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - machineType: "n2-standard-16"
  - machineType: "e2-standard-16"
    minimumCapacity:
      targetNodeCount: 3

Para esta ComputeClass, GKE crea tres nodos e2-standard-16 para la segunda regla de prioridad. Estos nodos se consideran para el mínimo de cinco nodos de la ComputeClass. Para los dos nodos restantes, GKE intenta crear nodos n2-standard-16 primero. Si los nodos n2-standard-16 no están disponibles, GKE recurre a los nodos e2-standard-16.

Si habilitas la migración activa a nodos de mayor prioridad, GKE puede reemplazar más adelante hasta dos nodos e2-standard-16 por nodos n2-standard-16. Sin embargo, GKE mantiene al menos tres nodos e2-standard-16 para la capacidad mínima de la segunda regla de prioridad.

Si, en cambio, estableces el campo targetNodeCount en la segunda regla de prioridad en 6, GKE crea seis nodos e2-standard-16. Estos seis nodos cumplen con el mínimo de cinco nodos de ComputeClass, por lo que GKE no crea ningún nodo n2-standard-16 para la capacidad mínima.

Personaliza la configuración del sistema de nodos

Puedes personalizar ciertos parámetros en el kubelet y el kernel de Linux con el campo nodeSystemConfig en tu especificación de ComputeClass. Puedes especificar este campo en cualquier regla de prioridad que defina una serie de máquinas 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 GKE versión 1.32.1-gke.1729000 y versiones posteriores.

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

Especifica etiquetas y taints de nodos

En la especificación de ComputeClass, los campos nodeLabels y taints te permiten definir parámetros de configuración que coincidan con los grupos de nodos existentes y que controlen la creación de otros nuevos. Estas opciones de configuración se pueden aplicar de forma global dentro del campo nodePoolConfig para toda la ComputeClass o se pueden limitar a una prioridad específica con el campo priority. Sin embargo, debes asegurarte de que las etiquetas y los taints definidos en el nivel de prioridad no se superpongan con los que se establecieron de forma global.

Estas funciones están disponibles en los siguientes países:

  • Etiquetas de nodo de prioridad en la versión 1.33.2-gke.1111000 y posteriores de GKE.
  • Priority taints en la versión 1.33.4-gke.1350000 y posteriores de GKE.
  • Etiquetas y taints de nodos globales en la versión 1.34.1-gke.3084002 y posteriores de GKE.

Además de las etiquetas personalizadas, GKE asigna automáticamente la etiqueta del sistema cloud.google.com/compute-class a todos los nodos aprovisionados para una ComputeClass o asociados a ella. Puedes filtrar y enumerar los nodos por ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=COMPUTECLASS_NAME

Para obtener más información, consulta CustomResourceDefinition de ComputeClass.

Configura la tacha predeterminada de la arquitectura de Arm

De forma predeterminada, GKE agrega el taint kubernetes.io/arch=arm64:NoSchedule a todos los nodos de Arm, incluidos los nodos creados para ComputeClasses personalizadas. GKE programa solo las cargas de trabajo que tienen una tolerancia para este taint en los nodos Arm, lo que ayuda a evitar que las cargas de trabajo x86 se ejecuten en una arquitectura incompatible. Si tus cargas de trabajo son compatibles con x86 y Arm, puedes inhabilitar este taint predeterminado. Cualquier carga de trabajo que seleccione la ComputeClass puede ejecutarse en los nodos de Arm, incluso si esas cargas de trabajo no tienen la tolerancia para la arquitectura de Arm.

Puedes actualizar el comportamiento predeterminado de los taints en los grupos de nodos de Standard y con los nodos creados para las ComputeClasses personalizadas. Para obtener más información sobre cómo configurar el comportamiento de los grupos de nodos de Standard, consulta Configura el error de la arquitectura de Arm predeterminada.

Para cambiar el comportamiento predeterminado y permitir que GKE programe cargas de trabajo que no tengan una tolerancia correspondiente a los nodos de Arm que se crean para una ComputeClass personalizada, configura tu ComputeClass como se muestra en este ejemplo:

taintConfig:
  architectureTaintBehavior: NONE

Este campo requiere un clúster que ejecute la versión 1.36.2-gke.1498000 o una posterior de GKE.

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 una ComputeClass predeterminada para espacios de nombres específicos o para un clúster completo. 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 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 parámetros de configuración compartidos en muchos grupos de nodos.

Colección de TPU de varios hosts

Se requiere la versión 1.31.2-gke.1518000 o posterior de GKE. Solo disponible en TPU Trillium (v6e)

Puedes agrupar tu implementación de varios hosts de TPU para establecer 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 lo siguiente:

Configuración de grupos de nodos

El campo nodePoolConfig en tu especificación de ComputeClass te permite aplicar la 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 la 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 de Cloud de Confiance by S3NS que usan los nodos dentro de los grupos de nodos que administra ComputeClass. En el siguiente ejemplo, se muestra cómo especificar el serviceAccount en tu ComputeClass:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.s3ns.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 indica a GKE el uso previsto para los recursos TPU. El campo workloadType admite los siguientes valores:

  • HIGH_AVAILABILITY: Usa este valor para las cargas de trabajo enfocadas en la disponibilidad, como la entrega de inferencias, para limitar y optimizar las interrupciones.
  • HIGH_THROUGHPUT: Usa este valor para 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 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

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

Configuración de la zona de pruebas

Se requiere la versión 1.36.2-gke.1368000 o posterior de GKE

Puedes aislar las cargas de trabajo del kernel del host de los nodos ejecutando los Pods en entornos de pruebas con GKE Sandbox. En ComputeClasses, puedes habilitar GKE Sandbox y seleccionar un tipo de zona de pruebas para los nodos con el campo nodePoolConfig.sandbox. Se admiten los siguientes tipos de entornos de pruebas:

  • gvisor: requiere la versión 1.36.2-gke.1368000 o una posterior de GKE.
  • microvm: requiere la versión 1.37.0-gke.4713000 o posterior de GKE y nodos que usen la virtualización anidada.

Para obtener más información sobre las funciones, las limitaciones y los requisitos de estos tipos de zona de pruebas, consulta Acerca de GKE Sandbox.

Para usar una ComputeClass que habilite y solicite entornos de pruebas, consulta Aísla cargas de trabajo con GKE Sandbox.

Configuración de metadatos de la instancia

Requiere la versión 1.36.2-gke.1498000 de GKE o una posterior.

El campo instanceMetadata en una especificación de ComputeClass te permite agregar pares clave-valor de metadatos personalizados directamente en las instancias de VM de Compute Engine aprovisionadas para tus grupos de nodos por el escalador automático del clúster o el aprovisionamiento automático de nodos. Esto es similar a especificar la marca --metadata cuando creas grupos de nodos de forma manual con Google Cloud CLI.

La configuración de metadatos de instancias personalizadas con ComputeClasses solo se admite en clústeres en modo GKE Standard (spec.autopilot.enabled: false).

Puedes especificar instanceMetadata en dos lugares dentro de una ComputeClass:

  • Configuración global (spec.nodePoolConfig.instanceMetadata): Aplica pares clave-valor de metadatos personalizados de forma global a todos los grupos de nodos y VMs nuevos creados por ComputeClass.
  • Anulaciones específicas de prioridad (spec.priorities[].instanceMetadata): aplica pares clave-valor de metadatos personalizados solo cuando GKE aprovisiona nodos con esa prioridad específica en la jerarquía.

Si se define la misma clave de metadatos en nodePoolConfig.instanceMetadata y priorities[].instanceMetadata, el valor especificado en priorities[].instanceMetadata anula el valor global.

Esquema y reglas de validación

Cuando definas instanceMetadata, cumple con las siguientes restricciones de validación:

  • Tipo: pares clave-valor estructurados como un map (map[string]string).
  • Límites de tamaño:
    • El tamaño máximo de un valor de metadatos individual es de 32 KB (32,768 bytes).
    • El tamaño máximo combinado de todos los pares clave-valor de metadatos en todo el recurso ComputeClass no puede superar los 512 KB (524,288 bytes).
  • Límites y formato de las claves:
    • Puedes definir un máximo de 32 pares clave-valor de metadatos personalizados por ComputeClass.
    • Las claves deben tener menos de 128 caracteres y solo pueden contener caracteres alfanuméricos, guiones (-) y guiones bajos (_).
  • Claves reservadas: GKE y Compute Engine reservan claves de metadatos del sistema específicas que se necesitan para administrar las operaciones del clúster (como kube-env, user-data, startup-script y cluster-name). No puedes anular ni especificar claves de metadatos del sistema reservadas.
  • Inmutabilidad en grupos de nodos existentes: Modificar instanceMetadata en un ComputeClass existente solo se aplica cuando GKE aprovisiona grupos de nodos nuevos (cuando nodePoolAutoCreation está habilitado). Los grupos de nodos y las VMs existentes no se modifican de forma retroactiva.

En el siguiente ejemplo, se muestra cómo configurar los metadatos de instancia globales en todos los grupos de nodos y una anulación de metadatos específica de la prioridad:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: metadata-example-class
spec:
  nodePoolAutoCreation:
    enabled: true
  nodePoolConfig:
    instanceMetadata:
      environment: "production"
      team: "backend-platform"
  priorities:
  - machineFamily: n4
    instanceMetadata:
      workload-tier: "high-performance"
  - machineFamily: e2
    instanceMetadata:
      workload-tier: "fallback-general"
      team: "shared-infra"

Configura los límites del ajuste de escala automático

Disponible en GKE versión 1.36.2-gke.2064000 y posteriores.

De forma predeterminada, GKE aprovisiona nodos nuevos para una ComputeClass hasta los límites de ajuste de escala automático del clúster general. Para aplicar límites de recursos más estrictos a una ComputeClass específica, como limitar la cantidad máxima de GPUs, CPUs o nodos totales que se pueden aprovisionar para la ComputeClass, puedes aplicar un recurso personalizado CapacityQuota.

Para obtener más información, consulta Configura límites de recursos detallados.

Configuración de nodos de GKE protegidos

Se requiere la versión 1.36.3-gke.1244000 o posterior de GKE.

Para configurar las funciones de los nodos de GKE protegidos, como el inicio seguro y la supervisión de integridad, para los grupos de nodos creados automáticamente que administra una ComputeClass, especifica el campo shieldedInstanceConfig en el bloque nodePoolAutoCreation (spec.nodePoolAutoCreation.shieldedInstanceConfig).

Los valores predeterminados de shieldedInstanceConfig dependen del modo de clúster y de la configuración de ComputeClass:

  • En los clústeres en modo Estándar: cuando se inicializa shieldedInstanceConfig durante la conciliación de nodePoolAutoCreation, el campo enableIntegrityMonitoring se establece de forma predeterminada en true y el campo enableSecureBoot se establece de forma predeterminada en false, a menos que los configures de forma explícita.
  • En los clústeres de Autopilot (o cuando spec.autopilot.enabled es true en una ComputeClass), los campos enableSecureBoot y enableIntegrityMonitoring se establecen de forma predeterminada en true y no se pueden inhabilitar.

En el siguiente ejemplo, se muestra cómo configurar el campo shieldedInstanceConfig dentro del bloque nodePoolAutoCreation para habilitar las funciones de Nodos de GKE protegidos en los grupos de nodos de creación automática:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shielded-ccc
spec:
  nodePoolAutoCreation:
    enabled: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableIntegrityMonitoring: true

Solicita ComputeClasses en las cargas de trabajo

Para usar una ComputeClass personalizada, tu Pod debe solicitarla de forma explícita con un nodeSelector en la especificación del Pod. De manera opcional, puedes establecer 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 los Pods soliciten una ComputeClass diferente.

Por ejemplo, el siguiente manifiesto solicita la 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: registry.k8s.io/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 etiqueta:

  • k8s.io
  • cloud.google.com
  • gke.io
  • node.kubernetes.io/instance-type

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 como se espera. Un conflicto entre la configuración de una 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 prioridad más alta para la ComputeClass.
  • El Pod permanece en el estado Pending.

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

Etiqueta de 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
node.kubernetes.io/instance-type priorities.machineType

Supervisa el uso de ComputeClass

Puedes supervisar cómo interactúa el escalador automático del clúster con ComputeClasses con las métricas de Cloud Monitoring. Las métricas como kubernetes.io/autoscaler/cluster_pending_pods_per_ccc, kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc y kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc realizan un seguimiento de los Pods pendientes, los intentos de aprovisionamiento de nodos y las fallas de aprovisionamiento. Estas métricas están disponibles en GKE versión 1.37 y posteriores.

Para obtener información detallada sobre cómo consultar estas métricas y cómo interpretar las etiquetas, consulta Visualiza eventos y métricas del escalador automático de clústeres.

Limitaciones

  • El nombre de ComputeClass no puede comenzar con gke ni autopilot (reservado para ComputeClasses del sistema).
  • Algunos clústeres tienen tasas altas de creación y eliminación de Pods, lo que aumenta el tiempo de evaluación del escalador automático del clúster. Durante una operación de escalamiento, es posible que el escalador automático del clúster no tenga tiempo para evaluar las reglas de prioridad posteriores en una ComputeClass antes de que venza el período de retirada de las reglas de prioridad anteriores. Como resultado, es posible que los Pods permanezcan en estado Pendiente. Para mitigar este problema, reduce la tasa de creación y eliminación de Pods, por ejemplo, inhabilitando la migración activa para ComputeClass.

¿Qué sigue?