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 Google Kubernetes Engine (GKE) usa para crear nodos durante el ajuste automático de escala. 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 que cumpla con un objetivo específico para tus cargas de trabajo, equipos u organización. Usa el comportamiento de resguardo de ComputeClasses y la capacidad de seleccionar grupos de nodos creados de forma manual y 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 recursos y reduce la sobrecarga manual

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

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

Para ajustar los nodos de mayor prioridad y reducir la latencia de programación, usa una combinación de grupos de nodos creados de forma manual y 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. Como tus grupos de nodos de mayor prioridad se crean de forma manual, puedes ajustar el hardware para cumplir con los requisitos exactos de tus Pods.

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

  1. Grupos de nodos creados manualmente: Estos grupos de nodos tienen las especificaciones exactas en las que deseas que se ejecuten la mayoría de tus Pods. Configura estos grupos de nodos con etiquetas de nodos, exclusiones de nodos, reservas de capacidad o configuraciones especiales, como parámetros de kubelet, específicos. Crea estos grupos de nodos con tantos nodos como creas que necesitarán tus Pods. En tu ComputeClass, asigna la prioridad más alta a estos grupos de nodos.
  2. Grupos de nodos creados automáticamente: Como medida alternativa, usa 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 manualmente.

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 manualmente, ya que GKE no necesita crear nodos nuevos con tanta frecuencia.

Cómo definir de forma explícita el comportamiento de ajuste de escala 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 un ComputeClass. Para evitar comportamientos inesperados 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 clase en una carga de trabajo. El valor recomendado para este campo depende del tipo de carga de trabajo, como se indica a continuación:

  • 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 no hay nodos disponibles que coincidan con una regla de prioridad en ComputeClass, GKE aumenta la cantidad de nodos que usan la serie de máquinas predeterminada del clúster.
  • Cargas de trabajo que necesitan hardware especializado: Para las cargas de trabajo de aceleradores o de computación de alto rendimiento que dependen de hardware específico, como las GPU o ciertas series de máquinas de Compute Engine, especifica un valor de DoNotScaleUp. Si no hay nodos que coincidan con una regla de prioridad en ComputeClass, los Pods permanecen en estado Pending hasta que haya recursos 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 todas las cargas de trabajo que no seleccionan de forma explícita una ComputeClass. Si se establece una ComputeClass predeterminada, los operadores de aplicaciones no necesitan cambiar los selectores de nodos ni solicitar manualmente grupos de nodos y hardware específicos en Pods individuales. Si estableces un valor predeterminado de ComputeClass a nivel del clúster, no agregues etiquetas ni marcas de nodos para otras ComputeClass 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 nodos para otras ComputeClasses.

Establece ComputeClasses predeterminadas para los espacios de nombres y separa a los usuarios

Además de una ComputeClass predeterminada a nivel del clúster, puedes establecer una ComputeClass predeterminada para espacios de nombres específicos. Si tienes entornos de múltiples arrendatarios o deseas 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 baja interacción 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 si tienes un clúster 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.

Inhabilita la migración activa

La migración activa mueve automáticamente los Pods a nodos nuevos que tienen una prioridad más alta en 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 datos en el almacenamiento persistente local, mover los Pods a nodos nuevos puede causar interrupciones porque los Pods pierden el acceso a los datos persistentes. Para evitar este problema, inhabilita la migración activa para las ComputeClasses 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 cargas de trabajo con estado de las siguientes maneras:

  • Crear volúmenes solo después de la creación del Pod: Si usas el aprovisionamiento dinámico de volúmenes, especifica un valor de WaitForFirstConsumer en el volumeBindingMode campo en una StorageClass. Este modo de vinculación de volúmenes impide la creación de un PersistentVolume hasta que GKE crea un Pod que usa el PersistentVolumeClaim correspondiente. GKE aprovisiona el PersistentVolume en la misma zona que el nodo que ejecuta el Pod.
  • Usa StorageClasses que tengan en cuenta la topología: Si tu ComputeClass abarca varias generaciones de una serie de máquinas (por ejemplo, C4 y C3), usa una StorageClass que tenga habilitada la selección automática del tipo de disco y que programe solo en nodos que admitan los tipos de disco especificados. Puedes usar la StorageClass dynamic-rwo integrada o una StorageClass personalizada. Tus cargas de trabajo con estado pueden ejecutarse en varias generaciones de instancias de Compute Engine, ya que el ajuste de escala automático del clúster elige de forma dinámica un tipo de disco compatible.

Diseña tu infraestructura para que tenga flexibilidad, eficiencia y disponibilidad de 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 las 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 campomachineFamily. Durante una operación de ajuste de escala, 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 nodos que más prefieras.

Usa reservas de capacidad para el hardware con demanda

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 usa 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 ignore las reglas de prioridad de ComputeClass y recurra al hardware a pedido. Para obtener más información, consulta Consume recursos zonales reservados.

No consumir nuevas reservas 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 ajuste automático puede tardar hasta una hora en descubrirla. 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 la operación de ajuste de escala automático falle.

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 usan hardware costoso o con disponibilidad limitada. El uso inadecuado intencional o accidental puede provocar interrupciones en las cargas de trabajo, cargos no planificados por uso de recursos y agotamiento de la cuota.

Restringe el acceso a la API a las configuraciones 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 los mismos 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 de tu espacio de nombres de frontend web puedan seleccionar ComputeClasses que creen aceleradores. Verifica que tus ValidatingAdmissionPolicies comprueben las siguientes configuraciones comunes:

  • Verifica todos los campos de selección: Una carga de trabajo puede seleccionar una ComputeClass usando los campos nodeSelector, nodeAffinity o tolerations en la especificación del Pod. Para evitar la selección no intencional de ComputeClass, verifica todos estos campos en las expresiones de tu ValidatingAdmissionPolicy.
  • Verifica si hay omisiones de tolerancia de comodines: Bloquea o valida explícitamente las tolerancias de comodines (por ejemplo, la tolerancia de operator: Exists sin clave). Estos selectores de comodines pueden abarcar la mayoría de los taint de nodos, incluidos los taint 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 las ComputeClasses, lo que reduce el riesgo de interrupciones o Pods atascados.

Evita el uso de selectores de nodos en conflicto

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

Por ejemplo, considera una ComputeClass que solo solicita 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. 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 activa de migración y ajuste de escala automático

La configuración de migración activa y ajuste de escala automático de una ComputeClass afecta directamente la frecuencia con la que GKE finaliza tus Pods para realizar tareas como trasladar Pods a hardware más preferido y consolidar nodos subutilizados. Las modificaciones de estos parámetros de configuración en un objeto ComputeClass existente pueden provocar interrupciones inesperadas en la carga de trabajo. Antes de aplicar cualquier modificación a estos parámetros de configuración en las 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 del desalojo durante el ajuste de escala.

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

GKE actualiza periódicamente la definición de recurso personalizado (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 el CRD causan problemas en la carga de trabajo siguiendo los lineamientos que se indican a continuación:

Usa PodDisruptionBudgets para mejorar la disponibilidad de la carga de trabajo

Las operaciones de ComputeClass que provocan desalojos de Pods, como la migración activa, respetan los PodDisruptionBudgets configurados. Por ejemplo, puedes configurar una 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 la expulsión de un Pod incumple ese presupuesto, GKE no expulsa el Pod. Especifica PodDisruptionBudgets para cargas de trabajo como las siguientes:

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

No confíes en los PodDisruptionBudgets para proteger 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 el desalojo

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 ajuste de escala automático. Usa esta anotación para proteger los Pods que no toleran interrupciones, como las cargas de trabajo con estado de una sola instancia 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?