Prácticas recomendadas para ComputeClasses

Los ingenieros de plataformas pueden usar ComputeClasses personalizadas para configurar de forma declarativa la configuración de los nodos y las prioridades de resguardo que Google Kubernetes Engine (GKE) usa para crear nodos durante el ajuste de escala automático. Puedes crear ComputeClasses en función de 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 debes estar estar familiarizado con 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 capacidad de obtención y el rendimiento. Las ComputeClasses funcionan con grupos de nodos creados de forma manual y automática.

Diseña cada ComputeClass en función de una estrategia

Diseña cada ComputeClass para cumplir con un objetivo específico para tus cargas de trabajo, equipos o tu 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 capacidad de obtención 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 en función de la disponibilidad de hardware, los requisitos de recursos de los Pods y la capacidad zonal. Esta estrategia elimina la necesidad de crear y ajustar grupos de nodos de forma manual, 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. Debido a que los grupos de nodos de mayor prioridad se crean de forma manual, puedes ajustar el hardware para satisfacer los requisitos exactos de tus Pods.

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

  1. Grupos de nodos creados de forma manual: 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, taints de nodos, reservas de capacidad o configuraciones especiales, como parámetros 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 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 no hay nodos que coincidan con una regla de prioridad en la ComputeClass, GKE escala verticalmente los nodos que usan la serie de máquinas predeterminada del clúster.
  • Cargas de trabajo que necesitan hardware especializado: Para cargas de trabajo de aceleradores o 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 no hay nodos que coincidan con una regla de prioridad en la ComputeClass, los Pods permanecen en 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 apply.

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 estableces 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 del clúster, no agregues etiquetas de nodos ni taints 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 cualquier grupo de nodos que tenga etiquetas de nodos o taints de nodos para otras ComputeClasses.

Establece ComputeClasses predeterminadas para espacios de nombres para separar los tenants

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 varios tenants 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 modo Autopilot

Si tienes cargas de trabajo que no requieren interacción ni administración manuales, ejecútalas en modo Autopilot con ComputeClasses. Puedes habilitar el modo Autopilot en cualquier ComputeClass, incluso cuando tienes un clúster estándar. 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 en 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 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 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 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 cargas de trabajo con estado de las siguientes maneras:

  • Crea volúmenes solo después de la creación de Pods: Si usas el aprovisionamiento de volúmenes dinámicos, especifica un valor de WaitForFirstConsumer en el volumeBindingMode campo de una StorageClass. Este modo de vinculación de volúmenes evita 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 compatibles con 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 de 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 escalador automático del clúster elige de forma dinámica un tipo de disco compatible.

Capacidad de obtención

En las siguientes secciones, se proporcionan prácticas recomendadas para mejorar la capacidad de obtención en ComputeClasses, de modo que tus Pods pasen menos tiempo en 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 machineFamily campo. 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 nodos que más prefieras.

Usa reservas de capacidad para hardware solicitado

Si tus cargas de trabajo dependen de hardware solicitado, 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 capacidad de obtención de recursos. 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, Compute Engine puede omitir las reglas de prioridad de ComputeClass y recurrir al hardware según demanda. Para obtener más información, consulta Consume recursos zonales reservados.

No consumas 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 reserva de capacidad nueva, 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 usan hardware costoso o que tienen disponibilidad limitada. El uso indebido intencional o accidental puede provocar interrupciones en las cargas de trabajo, cargos no planificados por el uso de recursos y el 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 GPU y TPU. Restringe el acceso para crear, modificar y borrar ComputeClasses a las mismas entidades principales que pueden crear, modificar y borrar nodos en tus clústeres. Para controlar el acceso a ComputeClasses, usa políticas de RBAC.

Restringe la disponibilidad de ComputeClass por espacio de nombres

Los clientes de GKE suelen separar diferentes equipos o tipos de cargas de trabajo por espacio de nombres de Kubernetes. Las ComputeClasses son un recurso con permiso 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 indebido 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 el 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 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 los bypasses de tolerancia de comodín: Bloquea o valida de forma explícita las tolerancias de comodín (por ejemplo, la tolerancia operator: Exists sin clave). Estos selectores de comodín pueden abarcar la mayoría de los taints de nodos, incluidos los taints de ComputeClass.
  • Verifica todos los controladores de carga de trabajo: Configura la política matchConstraints para cubrir todos los recursos del controlador de carga de trabajo (como Deployment, StatefulSet, DaemonSet, Job, y CronJob). No limites tus verificaciones solo a los recursos 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 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 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.

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

La migración activa y la configuración de ajuste de escala automático en una ComputeClass afectan directamente la frecuencia con la que GKE finaliza tus Pods para realizar tareas como mover Pods a hardware más preferido y consolidar nodos con poco uso. Las modificaciones en esta configuración en una ComputeClass existente pueden provocar interrupciones inesperadas en las cargas de trabajo. Antes de aplicar cualquier modificación a esta 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 periódicamente 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 nuevas o versiones de parche, verifica si los cambios en la CRD causan problemas en las cargas de trabajo con las siguientes instrucciones:

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 cualquier PodDisruptionBudgets configurado. 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 una expulsión de Pods infringe ese presupuesto, GKE no expulsa el Pod. Especifica PodDisruptionBudgets para cargas de trabajo como las siguientes:

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

No dependas de 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 las cargas de trabajo y permita que se completen funciones como las actualizaciones.

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

Si tienes cargas de trabajo en las que cada Pod debe ejecutarse hasta completarse antes de ser finalizado, 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 pueden tolerar 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 ComputeClasses:

¿Qué sigue?