Prácticas recomendadas para ComputeClasses

Los ingenieros de plataformas pueden usar ComputeClasses personalizadas para configurar de forma declarativa los parámetros de configuración de los nodos y las prioridades de resguardo que usa Google Kubernetes Engine (GKE) para crear nodos durante el ajuste de escala automático. Puedes crear ComputeClasses según estrategias específicas y requisitos de carga de trabajo. En este documento, se proporcionan prácticas recomendadas para diseñar e implementar ComputeClasses en tus clústeres. Ya deberías conocer las ComputeClasses personalizadas. Para obtener una descripción general consolidada de todas las prácticas recomendadas de GKE, consulta Prácticas recomendadas para GKE.

Diseño de ComputeClass

En las siguientes secciones, se proporcionan prácticas recomendadas para diseñar e implementar ComputeClasses en tus clústeres en función de objetivos como maximizar la flexibilidad, la eficiencia, la disponibilidad y el rendimiento de la capacidad de procesamiento. Las ComputeClasses funcionan con grupos de nodos creados de forma manual y automática.

Diseña cada ComputeClass según una estrategia

Diseña cada ComputeClass para cumplir con un objetivo específico para tus cargas de trabajo, equipos o la organización. Usa el comportamiento de resguardo de ComputeClasses y la capacidad de seleccionar grupos de nodos creados de forma manual y de creación automática para priorizar ciertos resultados, como reducir la sobrecarga manual o mejorar el rendimiento de la programación. En las siguientes secciones, se describen las estrategias comunes.

Mejora la disponibilidad de los recursos y reduce la sobrecarga manual

Para delegar la creación de grupos de nodos a GKE, usa solo grupos de nodos creados automáticamente en tu ComputeClass. El escalador automático configura los nodos según la disponibilidad del hardware, los requisitos de recursos de los Pods y la capacidad zonal. Esta estrategia elimina la necesidad de crear y ajustar de forma manual los grupos de nodos y puede reducir los costos asociados con la capacidad de nodos inactivos y sin usar.

Mejora el rendimiento de la programación y ajusta los nodos

Para ajustar tus nodos de mayor prioridad y reducir la latencia de programación, usa una combinación de grupos de nodos creados de forma manual y de creación automática en tu ComputeClass. Esta estrategia híbrida reduce la frecuencia con la que los Pods esperan a que GKE cree grupos de nodos nuevos. Debido a que tus grupos de nodos de mayor prioridad se crean de forma manual, puedes ajustar el hardware para que cumpla con los requisitos exactos de tus Pods.

La estrategia híbrida implica los siguientes tipos de grupos de nodos en orden de prioridad en ComputeClass:

  1. Grupos de nodos creados de forma manual: Estos grupos de nodos tienen las especificaciones exactas en las que deseas que se ejecute la mayoría de tus Pods. Configura estos grupos de nodos con etiquetas de nodo, taints de nodo, reservas de capacidad o parámetros de configuración especiales, como los parámetros de kubelet. Crea estos grupos de nodos con la cantidad de nodos que estimes que necesitarán tus Pods. En tu ComputeClass, asigna la prioridad más alta a estos grupos de nodos.
  2. Grupos de nodos de creación automática: Como medida de resguardo, usa la ComputeClass para solicitar grupos de nodos adicionales que aún estén optimizados para tus Pods. Asigna una prioridad más baja a estos grupos de nodos creados automáticamente que a los grupos de nodos creados de forma manual.

En el siguiente ejemplo de ComputeClass, se usa esta estrategia híbrida:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

Cuando implementas una carga de trabajo que usa esta ComputeClass, GKE coloca los Pods en los nodos disponibles en manual-pool1. GKE crea grupos de nodos nuevos solo cuando el grupo de nodos creado de forma manual no tiene capacidad disponible. La latencia de programación disminuye cuando aumenta la cantidad de nodos existentes en el grupo de nodos creado de forma manual, ya que GKE no necesita crear nodos nuevos con tanta frecuencia.

Define de forma explícita el comportamiento de escalamiento de último recurso

El campo whenUnsatisfiable controla lo que sucede si GKE no puede cumplir con los requisitos de ninguna de las reglas de prioridad en una ComputeClass. Para evitar un comportamiento inesperado después de una actualización de versión, especifica de forma explícita un valor para este campo en cada ComputeClass. Establecer un valor ayuda a los usuarios de ComputeClass a saber qué esperar cuando seleccionan esa ComputeClass en una carga de trabajo. El valor recomendado para este campo depende del tipo de carga de trabajo, de la siguiente manera:

  • Cargas de trabajo de uso general: Si tus cargas de trabajo se pueden ejecutar en cualquier serie de máquinas, especifica un valor de ScaleUpAnyway. Si los nodos que coinciden con una regla de prioridad en la ComputeClass no están disponibles, GKE escala verticalmente los nodos que usan la serie de máquinas predeterminada del clúster.
  • Cargas de trabajo que necesitan hardware especializado: Para aceleradores o cargas de trabajo de computación de alto rendimiento que dependen de hardware específico, como GPU o ciertas series de máquinas de Compute Engine, especifica un valor de DoNotScaleUp. Si los nodos que coinciden con una regla de prioridad en la ComputeClass no están disponibles, los Pods permanecen en un estado Pending hasta que los recursos estén disponibles. Este enfoque evita que los Pods se ejecuten en hardware incompatible.

Para obtener más información, consulta Define el comportamiento de escalamiento cuando no se aplican reglas de prioridad.

Establece una ComputeClass predeterminada a nivel del clúster para la mayoría de las cargas de trabajo

Si la mayoría de tus cargas de trabajo tienen los mismos requisitos de hardware, configura una ComputeClass predeterminada para el clúster. GKE aplica la ComputeClass predeterminada a cualquier carga de trabajo que no seleccione de forma explícita una ComputeClass. Si configuras una ComputeClass predeterminada, los operadores de aplicaciones no necesitan cambiar los selectores de nodos ni solicitar de forma manual grupos de nodos y hardware específicos en Pods individuales. Si estableces una ComputeClass predeterminada a nivel de clúster, no agregues etiquetas ni taints de nodos para otras ComputeClasses a los grupos de nodos existentes en el clúster. Durante la programación de la ComputeClass predeterminada a nivel del clúster, GKE ignora los grupos de nodos que tienen etiquetas o taints de nodo para otras ComputeClasses.

Establece ComputeClasses predeterminadas para los espacios de nombres para separar los usuarios

Además de una ComputeClass predeterminada a nivel de clúster, puedes establecer una ComputeClass predeterminada para espacios de nombres específicos. Si tienes entornos de múltiples usuarios o quieres separar las cargas de trabajo que se ejecutan en hardware especializado, configura ComputeClasses predeterminadas para esos espacios de nombres. Para evitar que los Pods del sistema se ejecuten en hardware especializado, como nodos de GPU, agrega una ComputeClass de uso general como la ComputeClass predeterminada para los espacios de nombres del sistema.

Ejecuta cargas de trabajo de interacción baja en el modo Autopilot

Si tienes cargas de trabajo que no requieren interacción ni administración manuales, ejecútalas en el modo Autopilot con ComputeClasses. Puedes habilitar el modo Autopilot en cualquier ComputeClass, incluso cuando tienes un clúster de Standard. GKE ejecuta las cargas de trabajo que seleccionan una ComputeClass de Autopilot en nodos completamente administrados que implementan las funciones de seguridad, escalamiento y facturación de GKE Autopilot. Para obtener más información, consulta Acerca de las cargas de trabajo del modo Autopilot en GKE Standard.

Cargas de trabajo con estado

En las siguientes secciones, se proporcionan prácticas recomendadas para reducir las interrupciones o el comportamiento inesperado en las cargas de trabajo con estado que dependen de datos persistentes.

Inhabilitar la migración activa

La migración activa mueve automáticamente los Pods a nodos nuevos que tienen una prioridad más alta en la ComputeClass o que tienen la capacidad de ejecutar Pods de DaemonSet no programados. Durante la migración activa, GKE finaliza los Pods en los nodos existentes y crea Pods nuevos en los nodos de mayor prioridad. Si tienes cargas de trabajo que dependen de los datos en el almacenamiento persistente local, mover los Pods a nodos nuevos podría causar interrupciones, ya que los Pods pierden el acceso a los datos persistentes. Para evitar este problema, inhabilita la migración activa para las ComputeClasses que están destinadas a cargas de trabajo con estado.

Mejora la confiabilidad de la programación con StorageClasses

Usa StorageClasses para mejorar la confiabilidad de la programación de las cargas de trabajo con estado de las siguientes maneras:

  • Crea volúmenes solo después de crear el Pod: Si usas el aprovisionamiento dinámico de volúmenes, especifica un valor de WaitForFirstConsumer en el campo volumeBindingMode en una StorageClass. Este modo de vinculación de volumen impide la creación de un PersistentVolume hasta que GKE cree un Pod que use la PersistentVolumeClaim correspondiente. GKE aprovisiona el PersistentVolume en la misma zona que el nodo que ejecuta el Pod.
  • Usa StorageClasses que reconozcan la topología: Si tu ComputeClass abarca varias generaciones de series de máquinas, usa una StorageClass que tenga habilitada la selección automática del tipo de disco (parameters.type: dynamic) y que se programe solo en los nodos que admitan los tipos de disco especificados. Por ejemplo, tu ComputeClass recurre a series solo de Hyperdisk, como C4, C4D o N4, a series de Persistent Disk, como N2 o N2D, durante las restricciones de capacidad zonales. Puedes usar la StorageClass dynamic-rwo integrada o una StorageClass personalizada. Luego, tus cargas de trabajo con estado pueden conmutar por error en varias generaciones de instancias de Compute Engine, ya que el escalador automático de clústeres elige de forma dinámica un tipo de disco compatible (hyperdisk-balanced o pd-balanced) para cualquier nodo de resguardo que se aprovisione.

Diseña tu infraestructura para obtener flexibilidad, eficiencia y disponibilidad de la capacidad de procesamiento

En las siguientes secciones, se proporcionan prácticas recomendadas para mejorar la flexibilidad, la eficiencia y la disponibilidad de la capacidad de procesamiento en ComputeClasses, de modo que tus Pods pasen menos tiempo en un estado Pending.

Solicita series de máquinas en lugar de tipos de máquinas

Puedes solicitar una serie de máquinas de Compute Engine o tipos de máquinas específicos en las reglas de prioridad de ComputeClass. A menos que tengas una dependencia estricta de un tipo de máquina específico, selecciona una serie de máquinas con el campo machineFamily. Durante una operación de escalamiento, GKE puede crear nodos que usen cualquier tipo de máquina viable en esa serie de máquinas, lo que mejora la probabilidad de que tus Pods se ejecuten en la configuración de nodo que prefieras.

Usa reservas de capacidad para el hardware solicitado

Si tus cargas de trabajo dependen de hardware de alta demanda, como TPU o GPU de alto rendimiento, crea reservas de capacidad de Compute Engine para el hardware y consume esas reservas en tus ComputeClasses. Las reservas de capacidad mejoran la probabilidad de que el hardware esté disponible en tu región o zona, lo que te ayuda a aumentar la flexibilidad, la eficiencia y la disponibilidad de la capacidad de procesamiento. Para consumir una reserva en una ComputeClass sin afectar el comportamiento de resguardo, usa la afinidad de reserva Specific o AnyThenFail. Si usas la afinidad AnyBestEffort o Automatic y no hay capacidad reservada disponible, es posible que Compute Engine omita las reglas de prioridad de ComputeClass y recurra al hardware on demand. Para obtener más información, consulta Consume recursos zonales reservados.

No consumir reservas nuevas durante al menos una hora

El escalador automático del clúster almacena información sobre las reservas de capacidad en una caché. Cuando creas una nueva reserva de capacidad, el escalador automático puede tardar hasta una hora en descubrir esa reserva. Después de crear una reserva, espera al menos una hora antes de consumirla en una carga de trabajo. Si implementas una carga de trabajo que usa la reserva antes de que el escalador automático la almacene en la caché, es posible que falle la operación de ajuste de escala automático.

Seguridad

En las siguientes secciones, se proporcionan prácticas recomendadas para mejorar la seguridad de las ComputeClasses en tus clústeres. Estas medidas son importantes porque las ComputeClasses se pueden usar para crear y configurar nodos que usen hardware costoso o con disponibilidad limitada. El uso inadecuado intencional o accidental puede provocar interrupciones en la carga de trabajo, cargos por uso de recursos no planificados y el agotamiento de la cuota.

Restringe el acceso de la API a los parámetros de configuración de ComputeClass

Las cargas de trabajo pueden usar ComputeClasses para crear nodos que ejecuten hardware especializado, incluidas las GPU y las TPU. Restringe el acceso para crear, modificar y borrar ComputeClasses a las mismas principales que pueden crear, modificar y borrar nodos en tus clústeres. Para controlar el acceso a las ComputeClasses, usa políticas de RBAC.

Restringe la disponibilidad de ComputeClass por espacio de nombres

Los clientes de GKE suelen separar los diferentes equipos o tipos de cargas de trabajo por espacio de nombres de Kubernetes. Las ComputeClasses son un recurso con alcance de clúster, lo que significa que cualquier carga de trabajo en cualquier espacio de nombres puede seleccionar cualquier ComputeClass de forma predeterminada. Para evitar el uso inadecuado intencional o accidental, usa ValidatingAdmissionPolicies para controlar el conjunto de ComputeClasses que pueden seleccionar las cargas de trabajo en cada espacio de nombres. Por ejemplo, puedes evitar que los Pods en tu espacio de nombres de frontend web puedan seleccionar ComputeClasses que creen aceleradores. Verifica que tus ValidatingAdmissionPolicies verifiquen los siguientes parámetros de configuración comunes:

  • Verifica todos los campos de selección: Una carga de trabajo puede seleccionar una ComputeClass con los campos nodeSelector, nodeAffinity o tolerations en la especificación del Pod. Para evitar la selección no deseada de ComputeClass, verifica todos estos campos en tus expresiones de ValidatingAdmissionPolicy.
  • Verifica si hay omisiones de tolerancia de comodines: Bloquea o valida de forma explícita las tolerancias de comodines (por ejemplo, la tolerancia operator: Exists sin clave). Estos selectores de comodines pueden abarcar la mayoría de los taints de nodos, incluidos los taints de ComputeClass.
  • Verifica todos los controladores de cargas de trabajo: Configura el matchConstraints de la política para que abarque todos los recursos del controlador de cargas de trabajo (como Deployment, StatefulSet, DaemonSet, Job y CronJob). No limites tus verificaciones solo a los recursos de Pod.

Para obtener más información, consulta Restringe el acceso para modificar y seleccionar ComputeClasses.

Confiabilidad

En las siguientes secciones, se proporcionan prácticas recomendadas para mejorar la confiabilidad del ajuste de escala automático y la migración de Pods para ComputeClasses, lo que reduce el riesgo de interrupciones o Pods bloqueados.

Evita el uso de selectores de nodos en conflicto

Los selectores de nodos en tus Pods afectan el lugar en el que GKE coloca esos Pods y, en el modo Autopilot o con la creación automática de grupos de nodos, podrían activar la creación de grupos de nodos nuevos en tu clúster. Si tienes Pods que seleccionan una ComputeClass y usan selectores de nodos para solicitar nodos que entren en conflicto con la configuración de ComputeClass, es posible que GKE no programe los Pods en absoluto.

Por ejemplo, considera una ComputeClass que solo solicite instancias bajo demanda. Si un Pod selecciona esa ComputeClass y selecciona VMs Spot en un selector de nodos, GKE no puede programar el Pod porque la ComputeClass y el selector de nodos entran en conflicto entre sí. Para evitar este problema, usa métodos como ValidatingAdmissionPolicies para evitar que los Pods que seleccionan ComputeClasses también seleccionen etiquetas de nodos del sistema. Para obtener más información, consulta Selectores de nodos para etiquetas de nodos del sistema.

Prueba todos los cambios en la configuración de migración activa y ajuste de escala automático

La configuración de migración activa y ajuste de escala automático en una ComputeClass afecta directamente la frecuencia con la que GKE finaliza tus Pods para realizar tareas como mover Pods a hardware más preferido y consolidar nodos infrautilizados. Las modificaciones de estos parámetros de configuración en una ComputeClass existente pueden generar interrupciones inesperadas de la carga de trabajo. Antes de aplicar cualquier modificación a estos parámetros de configuración en ComputeClasses existentes, prueba los cambios en un entorno de etapa de pruebas. También puedes usar anotaciones para proteger las cargas de trabajo críticas de la expulsión durante el escalamiento.

Prueba las actualizaciones de CRD de ComputeClass antes de las actualizaciones del clúster

GKE actualiza con regularidad la CustomResourceDefinition (CRD) de ComputeClass para agregar campos, modificar el comportamiento de los campos y corregir problemas. Las adiciones y modificaciones de campos suelen entrar en vigencia en versiones específicas de GKE. Antes de actualizar tus clústeres de producción a versiones secundarias o de parche nuevas, verifica si los cambios en la CRD causan problemas en la carga de trabajo con los siguientes lineamientos:

Usa PodDisruptionBudgets para mejorar la disponibilidad de las cargas de trabajo

Las operaciones de ComputeClass que causan expulsiones de Pods, como la migración activa, respetan los PodDisruptionBudgets configurados. Por ejemplo, puedes configurar un Deployment de inferencia para que tenga un PodDisruptionBudget que requiera que más del 70% de los Pods estén disponibles. Durante la migración activa, si una expulsión de Pod infringe ese presupuesto, GKE no expulsa el Pod. Especifica PodDisruptionBudgets para cargas de trabajo como las siguientes:

  • Cargas de trabajo sin estado, como los Deployments de inferencia.
  • Cargas de trabajo con estado replicadas, como aplicaciones de bases de datos de alta disponibilidad

No dependas de los PodDisruptionBudgets para proteger las cargas de trabajo que deben ejecutarse hasta completarse, que tienen solo una instancia o que dependen de datos persistentes locales. Especifica un presupuesto que equilibre la disponibilidad de la carga de trabajo y permita que se completen funciones como las actualizaciones.

Protege las cargas de trabajo críticas contra la expulsión

Si tienes cargas de trabajo en las que cada Pod debe ejecutarse hasta completarse antes de finalizar, agrega la anotación cluster-autoscaler.kubernetes.io/safe-to-evict: "false" a la especificación del Pod. Esta anotación evita que GKE expulse Pods durante las operaciones de escalado automático. Usa esta anotación para proteger los Pods que no pueden tolerar interrupciones, como las cargas de trabajo con estado de instancia única y los trabajos por lotes de larga duración.

Resumen de prácticas recomendadas

En este documento, se incluyen las siguientes prácticas recomendadas para las ComputeClasses:

¿Qué sigue?