Controla los atributos de los nodos con ajuste de escala automático con ComputeClasses personalizadas

En este documento, se muestra cómo controlar la infraestructura de procesamiento y el comportamiento de ajuste de escala automático de los clústeres de Google Kubernetes Engine (GKE) en función de las necesidades específicas de tus cargas de trabajo con ComputeClasses personalizadas.

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 y a los operadores de clústeres que desean ejecutar sus cargas de trabajo en ComputeClasses específicas.

Acerca de las ComputeClasses personalizadas

Las ComputeClasses personalizadas son recursos personalizados de Kubernetes que te permiten definir prioridades para que GKE las siga cuando aprovisiona nodos para ejecutar tus cargas de trabajo. Puedes usar una ComputeClass personalizada para hacer lo siguiente:

  • Proporciona a GKE un conjunto de prioridades que se deben seguir de forma secuencial cuando se aprovisionan nodos, cada uno con parámetros específicos, como una serie de máquinas de Compute Engine o una capacidad mínima de recursos
  • Define umbrales y parámetros de ajuste de escala automático para quitar nodos infrautilizados y consolidar las cargas de trabajo de manera eficiente en la capacidad de procesamiento existente
  • Indicarle a GKE que reemplace automáticamente las configuraciones de nodos menos preferidas por configuraciones de nodos más preferidas para obtener un rendimiento óptimo de las cargas de trabajo

Para comprender todas las opciones de configuración y cómo interactúan entre sí, y con el modo Autopilot de GKE y el modo Standard de GKE, consulta Acerca de las ComputeClasses personalizadas.

Precios

El recurso personalizado ComputeClass se proporciona sin costo adicional en GKE. Se aplican las siguientes consideraciones de precios:

Limitaciones

El nombre de tu ComputeClass no puede comenzar con gke ni autopilot.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.

Situación de ejemplo para ComputeClasses

En este documento, se presenta una situación de ejemplo para la que defines una ComputeClass personalizada. En la práctica, debes considerar los requisitos de tus cargas de trabajo y organización específicas, y definir ComputeClasses que cumplan con esos requisitos. Para obtener descripciones completas de todas las opciones de ComputeClasses y consideraciones especiales, consulta Acerca de las ComputeClasses personalizadas.

Considera la siguiente situación de ejemplo:

  • Tu objetivo es optimizar los costos de ejecución de tus cargas de trabajo.
  • Tus cargas de trabajo son tolerantes a errores y no requieren un cierre ordenado ni un tiempo de ejecución extendido
  • Tus cargas de trabajo necesitan al menos 64 CPU virtuales para ejecutarse de manera óptima
  • Estás limitado a la serie de máquinas N4 de Compute Engine

Según la situación de ejemplo, decides que quieres un ComputeClass que haga lo siguiente:

  • Prioriza los nodos Spot N4 que tienen al menos 64 CPU virtuales
  • Permite que GKE recurra a cualquier nodo Spot N4, sin importar la capacidad de procesamiento
  • Si no hay nodos N4 Spot disponibles, permite que GKE use nodos N4 a pedido
  • Le indica a GKE que mueva tus cargas de trabajo a los nodos Spot cuando vuelvan a estar disponibles

Configura una ComputeClass en el modo Autopilot

En GKE Autopilot, defines una ComputeClass, la implementas en el clúster y solicitas esa ComputeClass en tus cargas de trabajo. GKE realiza cualquier paso de configuración de nodos, como aplicar etiquetas y taints, por ti.

Guarda el siguiente manifiesto como compute-class.yaml:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

Configura una ComputeClass en el modo Standard

En los clústeres del 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. La configuración manual depende de si tus grupos de nodos se crean de forma automática, como se indica a continuación:

Para permitir que GKE cree grupos de nodos de forma automática para tu ComputeClass, sigue estos pasos:

  1. Para los clústeres en modo estándar que ejecutan una versión anterior a la 1.33.3-gke.1136000 y no están inscritos en el canal de versiones rápido, habilita el aprovisionamiento automático de nodos a nivel del clúster.

  2. Guarda el siguiente manifiesto de ejemplo como compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

    Cuando implementas Pods que solicitan esta ComputeClass de ejemplo y se deben crear nodos nuevos, GKE prioriza la creación de nodos en el orden de los elementos en el campo priorities. Si es necesario, GKE crea grupos de nodos nuevos que cumplan con los requisitos de hardware de la ComputeClass.

También puedes especificar un tipo personalizado de máquina preciso en tus prioridades. Para usar tipos personalizados de máquinas, se requiere la versión 1.33.2-gke.1111000 o posterior de GKE. En el siguiente ejemplo, se configura una ComputeClass que prioriza las VMs Spot para el tipo personalizado de máquina n4-custom-8-20480 y recurre a las VMs a pedido del mismo tipo si la capacidad de Spot no está disponible:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-machine-type
spec:
  priorities:
  - machineType: n4-custom-8-20480
    spot: true
  - machineType: n4-custom-8-20480
    spot: false
  nodePoolAutoCreation:
    enabled: true

Para optimizar la disponibilidad de la capacidad durante las restricciones de capacidad, define una ComputeClass que abarque varias series y generaciones de máquinas. En el caso de las cargas de trabajo sin estado o tolerantes a interrupciones, también puedes habilitar la migración activa para devolver las cargas de trabajo al hardware preferido cuando se recupere la capacidad:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-family-fallback
spec:
  priorities:
  - machineFamily: c4d
  - machineFamily: c3d
  - machineFamily: c4
  - machineFamily: c3
  - machineFamily: n4
  - machineFamily: n2d
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

Las series de máquinas más nuevas, como C4, C4D y N4, solo admiten Hyperdisk, y las series más antiguas, como N2D, usan Persistent Disk. Si las cargas de trabajo con estado usan una ComputeClass que abarca ambas generaciones, inhabilita la migración activa y, en la versión 1.35.3-gke.1290000 y posteriores de GKE, usa la StorageClass dynamic-rwo integrada o una StorageClass personalizada con selección automática del tipo de disco (parameters.type: dynamic), use-allowed-disk-topology: "true" y volumeBindingMode: WaitForFirstConsumer. Luego, GKE selecciona un tipo de disco compatible cuando aprovisiona volúmenes nuevos y programa los volúmenes existentes solo en series de máquinas compatibles.

Usa ComputeClasses con grupos de nodos creados de forma manual

En esta sección, se muestra cómo definir una ComputeClass en un clúster que solo usa grupos de nodos creados de forma manual.

  1. Guarda el siguiente manifiesto como compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true

  2. Crea un nuevo grupo de nodos con ajuste de escala automático que use VMs Spot y asócialo con la ComputeClass:

    gcloud container node-pools create cost-optimized-pool \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --machine-type=n4-standard-64 \
    --spot \
    --enable-autoscaling \
    --max-nodes=9 \
    --node-labels="cloud.google.com/compute-class=cost-optimized" \
    --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"

    Reemplaza lo siguiente:

    • LOCATION: Es la ubicación de tu clúster.
    • CLUSTER_NAME: Es el nombre del clúster existente.

  3. Crea un nuevo grupo de nodos con escalado automático con VMs a pedido y asócialo con la ComputeClass:

    gcloud container node-pools create on-demand-pool \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --machine-type=n4-standard-64 \
    --enable-autoscaling \
    --max-nodes=9 \
    --num-nodes=0 \
    --node-labels="cloud.google.com/compute-class=cost-optimized" \
    --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"

Cuando implementas Pods que solicitan esta ComputeClass y se deben crear nodos nuevos, GKE prioriza la creación de nodos en el grupo de nodos cost-optimized-pool. Si no se pueden crear nodos nuevos, GKE crea nodos en el grupo de nodos on-demand-pool.

Para obtener más detalles sobre cómo interactúan los grupos de nodos creados de forma manual con las ComputeClasses personalizadas, consulta Configura grupos de nodos creados de forma manual para el uso de ComputeClass.

Personaliza los umbrales de ajuste de escala automático para la consolidación de nodos

De forma predeterminada, GKE quita los nodos poco utilizados y reprograma tus cargas de trabajo en otros nodos disponibles. Puedes personalizar aún más los umbrales y el tiempo después del cual un nodo se convierte en candidato para la eliminación con el campo autoscalingPolicy en la definición de ComputeClass, como en el siguiente ejemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  autoscalingPolicy:
    consolidationDelayMinutes : 5
    consolidationThreshold    : 70

En este ejemplo, un nodo se convierte en candidato para la eliminación si se utiliza de forma insuficiente en un 70% de su capacidad de CPU y memoria disponible durante más de cinco minutos. Para obtener una lista de los parámetros disponibles, consulta Configura parámetros de ajuste de escala automático para la consolidación de nodos.

Implementa una ComputeClass en un clúster

Después de definir una ComputeClass, impleméntala en el clúster:

kubectl apply -f compute-class.yaml

Este ComputeClass está listo para usarse en el clúster. Puedes solicitar la ComputeClass en las especificaciones del Pod o, de forma opcional, establecerla como la ComputeClass predeterminada en un espacio de nombres específico.

Solicita una ComputeClass en una carga de trabajo

Para solicitar una ComputeClass en una carga de trabajo, agrega un selector de nodos para esa ComputeClass en tu manifiesto, como en los siguientes pasos:

  1. Guarda el siguiente manifiesto como cc-workload.yaml:

    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"

  2. Implementa la carga de trabajo:

    kubectl apply -f cc-workload.yaml

Cuando implementas esta carga de trabajo, GKE agrega automáticamente una tolerancia a los Pods que corresponde al taint de nodo para la ComputeClass solicitada. Esta tolerancia ayuda a garantizar que solo los Pods que solicitan la ComputeClass se ejecuten en los nodos de ComputeClass.

Filtra los nodos por ComputeClass

Cualquier nodo asociado con ComputeClasses tiene la etiqueta cloud.google.com/compute-class.

Para ver todos los nodos asociados con una ComputeClass específica, ejecuta el siguiente comando:

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

Reemplaza COMPUTECLASS_NAME por el nombre de la ComputeClass (por ejemplo, cost-optimized).

El resultado es similar a lo siguiente:

NAME                                                  STATUS   ROLES    AGE   VERSION
gke-cluster-1-cost-optimized-pool-f213e529-rx7d       Ready    <none>   5m    v1.32.4-gke.1236007
gke-cluster-1-cost-optimized-pool-f213e529-ab12       Ready    <none>   5m    v1.32.4-gke.1236007

Para mostrar todos los nodos del clúster que están asociados con una ComputeClass, ejecuta el siguiente comando:

kubectl get nodes -L cloud.google.com/compute-class

Actualiza una ComputeClass implementada

Para actualizar una ComputeClass implementada, modifica el manifiesto YAML de la ComputeClass. Luego, implementa el manifiesto modificado con el siguiente comando:

kubectl apply -f PATH_TO_FILE

Reemplaza PATH_TO_FILE por la ruta de acceso al manifiesto modificado. Asegúrate de que el valor del campo name no cambie.

Cuando implementas tu ComputeClass actualizada, GKE usa tu configuración actualizada para crear nodos nuevos. GKE no modifica ningún nodo existente con la configuración actualizada.

Con el tiempo, GKE podría mover los Pods existentes a nodos que usen tu configuración actualizada si la ComputeClass usa la migración activa y si los Pods existentes son aptos para migrar.

¿Qué sigue?