Ejecuta cargas de trabajo tolerantes a errores a costos más bajos en Spot Pods

Autopilot

En esta página, se muestra cómo ejecutar cargas de trabajo tolerantes a errores a costos más bajos mediante Spot Pods en los clústeres de Autopilot de Google Kubernetes Engine (GKE).

Descripción general

En los clústeres de Autopilot para GKE, Spot Pods son Pods que se ejecutan en nodos respaldados por VM Spot de Compute Engine. Los Spot Pods tienen un precio menor que los de Autopilot estándar, pero GKE los puede expulsar siempre que se necesiten recursos de procesamiento para ejecutar Pods estándar.

Los Spot Pods son ideales para ejecutar cargas de trabajo sin estado, por lotes o tolerantes a errores a costos más bajos en comparación con la ejecución de esas cargas de trabajo como Pods estándar. Para usar Spot Pods en clústeres de Autopilot, modifica el manifiesto con tu especificación de Pod a fin de solicitar Spot Pods.

Puedes ejecutar Pods Spot en la clase de procesamiento de Autopilot de uso general predeterminada, así como en clases de procesamiento especializadas que cumplan con requisitos de hardware específicos. Para obtener información sobre estas clases de procesamiento, consulta Clases de procesamiento en Autopilot.

Para obtener más información sobre los precios de los Spot Pods en los clústeres de Autopilot, consulta los precios de Google Kubernetes Engine.

Ventajas

El uso de Spot Pods en tus clústeres de Autopilot te proporciona los siguientes beneficios:

Precios más bajos que ejecutar las mismas cargas de trabajo en los Pods de Autopilot estándar.
GKE administra automáticamente el ajuste de escala automático y la programación.
GKE realiza taints de automáticamente en los nodos que ejecutan Spot Pods para garantizar que los Pods estándar, como tus cargas de trabajo críticas, no estén programados en esos nodos. Las implementaciones que usan Spot Pods se actualizan de forma automática con una tolerancia correspondiente.

Requisitos y limitaciones

Se requiere la versión 1.21.4 o posterior de GKE.
Los Spot Pods se excluyen del Acuerdo de Nivel de Servicio de Autopilot.
GKE no puede programar Spot Pods en clústeres que ejecutan versiones de GKE anteriores a la 1.21.4.
Los clústeres de Autopilot admiten solicitudes de Pods interrumpibles en los clústeres que ejecutan la versión 1.21.4 o posteriores de GKE mediante el selector cloud.google.com/gke-preemptible. Los Pods que usan este selector se migran de forma automática a Spot Pods y el selector se cambia a cloud.google.com/gke-spot.

Precaución: La migración automática del selector cloud.google.com/gke-preemptible no es compatible con los clústeres que ejecutan versiones de GKE anteriores a la 1.21.4. Si solicitas Pods interrumpibles en estos clústeres, los Pods obtienen un comportamiento interrumpible, pero con precios estándar. Como práctica recomendada, evita usar Pods interrumpibles en tus implementaciones, ya que reduce la disponibilidad de Pods sin beneficio del precio.

Antes de comenzar

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

Habilita la API de Kubernetes Engine de Google.

Habilitar la API de Kubernetes Engine de Google

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Solicita Spot Pods en tus cargas de trabajo de Autopilot

Para solicitar que tus Pods se ejecuten como Spot Pods, usa la etiqueta cloud.google.com/gke-spot=true en un nodeSelector o afinidad de nodos en tu especificación de Pods. GKE aprovisiona nodos de forma automática que pueden ejecutar Spot Pods.

Los Spot Pods pueden expulsarse y finalizarse en cualquier momento, por ejemplo, si los recursos de procesamiento se necesitan en otra parte de Google Cloud. Cuando ocurre una finalización, los Spot Pods en el nodo de finalización pueden solicitar hasta un período de gracia de 25 segundos antes de la finalización, que se otorga según el mejor esfuerzo mediante la especificación del campo terminationGracePeriodSeconds.

El período de gracia máximo que se le otorga a los Spot Pods durante la interrupción es de 25 segundos. Solicitar más de 25 segundos en terminationGracePeriodSeconds no otorga más de 25 segundos durante la interrupción. Cuando se produce la expulsión, el Pod recibe la señal SIGTERM y debe tomar las medidas necesarias para cerrar el servicio durante el período de gracia.

En Autopilot, GKE también habilita taints de forma automática en los nodos creados para ejecutar Spot Pods y modifica esas cargas de trabajo con la tolerancia correspondiente. El taint evita que los Pods estándar se programen en nodos que ejecutan Spot Pods.

Usa un nodeSelector para requerir Spot Pods

Puedes usar un nodeSelector para requerir Spot Pods en una implementación. Agrega la etiqueta cloud.google.com/gke-spot=true a tu Deployment, como en el siguiente ejemplo:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      terminationGracePeriodSeconds: 25
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Usa la afinidad de nodos para solicitar Spot Pods

Como alternativa, puedes usar la afinidad de nodos para solicitar Spot Pods. La afinidad de nodos te brinda una forma más extensible para seleccionar nodos a fin de ejecutar tus cargas de trabajo. Por ejemplo, puedes combinar varios criterios de selección para obtener un control más preciso sobre dónde se ejecutan tus Pods. Cuando usas la afinidad de nodos para solicitar Spot Pods, puedes especificar el tipo de afinidad de nodo que se usará, de la siguiente manera:

requiredDuringSchedulingIgnoredDuringExecution: Debes usar Spot Pods.
preferredDuringSchedulingIgnoredDuringExecution: Usa Spot Pods en función del mejor esfuerzo.

Si deseas usar la afinidad de nodos para requerir Spot Pods en una implementación, agrega la siguiente regla nodeAffinity a tu manifiesto de implementación:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      terminationGracePeriodSeconds: 25
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-spot
                operator: In
                values:
                - "true"
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Solicita Spot Pods según el mejor esfuerzo

Si deseas usar la afinidad de nodos para solicitar Spot Pods en función del mejor esfuerzo, usa preferredDuringSchedulingIgnoredDuringExecution. Cuando solicitas Spot Pods de forma preferida, GKE programa tus Pods en el siguiente orden:

Nodos existentes que pueden ejecutar Spot Pods que tienen capacidad asignable disponible
Nodos estándar existentes que tienen capacidad asignable disponible
Nodos nuevos que pueden ejecutar Spot Pods, si los recursos de procesamiento están disponibles
Nuevos nodos estándar

Debido a que GKE prefiere nodos estándar existentes que tienen capacidad asignable en lugar de crear nodos nuevos para Spot Pods, es posible que notes más Pods que se ejecutan como Pods estándar que como Spot Pods, lo que evita que aproveches al máximo el reducir los precios de los Spot Pods.

Busca y borra los Pods terminados

Durante la finalización ordenada del Pod, el kubelet asigna un estado Failed y un motivo Shutdown a los Pods finalizados. Cuando la cantidad de Pods finalizados alcanza un umbral de 1,000, la recolección de elementos no utilizados limpia los Pods. También puedes borrar los Pods de cierre de forma manual con el siguiente comando:

kubectl get pods --all-namespaces | grep -i shutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n