VM Spot


En esta página, se explica qué son las VM Spot y cómo funcionan en Google Kubernetes Engine (GKE). Para aprender a usar VM Spot, consulta Usa VM Spot.

Descripción general de las VM Spot en GKE

Las VM Spot son instancias de máquinas virtuales (VM) de Compute Engine que tienen un precio menor que las VM estándar de Compute Engine. Las VM Spot ofrecen los mismos tipos de máquinas y opciones que las VM estándar, pero no proporcionan garantías de disponibilidad.

Puedes usar VM Spot en tus clústeres y grupos de nodos para ejecutar cargas de trabajo sin estado, por lotes o tolerantes a errores que pueden tolerar interrupciones causadas por la naturaleza efímera de las VM Spot.

Las VM Spot permanecen disponibles hasta que Compute Engine requiera los recursos para las VM estándar. Si deseas maximizar la rentabilidad, combina las VM Spot con las Prácticas recomendadas para la ejecución de aplicaciones de Kubernetes con optimización de costos en GKE.

Para obtener más información sobre las VM Spot, consulta VM Spot en la documentación de Compute Engine.

Beneficios de las VM Spot

Las VM Spot y las VM interrumpibles comparten muchos beneficios, incluidos los siguientes:

A diferencia de las VM interrumpibles, que vencen después de 24 horas, las VM Spot no tienen tiempo de vencimiento. Las VM Spot solo se finalizan cuando Compute Engine necesita los recursos en otra ubicación.

Cómo funcionan las VM Spot en GKE

Cuando creas un clúster o grupo de nodos con VM Spot, GKE crea VM Spot subyacentes de Compute Engine que se comportan como un grupo de instancias administrado (MIG). Los nodos que usan VM Spot se comportan como nodos estándar de GKE, pero sin garantía de disponibilidad. Cuando los recursos que usan las VM Spot son necesarios para ejecutar las VM estándar, Compute Engine las finaliza para usar los recursos en otro lugar.

Rescisión y cierre ordenado de VM Spot

Cuando Compute Engine necesita reclamar los recursos que usan las VM Spot, se envía un aviso de finalización a GKE. Las VM Spot finalizan 30 segundos después de recibir una notificación de finalización.

En los clústeres que ejecutan la versión 1.20 de GKE y versiones posteriores, la función de cierre de nodos ordenado de kubelet está habilitada de forma predeterminada. kubelet observa el aviso de finalización y finaliza sin problemas los Pods que se ejecutan en el nodo. Si los Pods son parte de una implementación, el controlador crea y programa Pods nuevos para reemplazar los Pods cerrados.

El kubelet otorga a los Pods que no son del sistema 25 segundos para finalizar de forma correcta y, luego, los Pods del sistema (con las clases de prioridad system-cluster-critical o system-node-critical) tienen cinco segundos para finalizar de forma correcta.

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

Programa cargas de trabajo en VM Spot

GKE agrega de forma automática la etiqueta cloud.google.com/gke-spot=true a los nodos que usan las VM Spot. Puedes programar pods específicos en los nodos que usan VM Spot mediante el campo nodeSelector en las especificaciones de tu pod, como en el siguiente ejemplo:

apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    cloud.google.com/gke-spot: "true"

Como alternativa, puedes usar la afinidad de nodos para que GKE programe Pods en VM Spot, similar al siguiente ejemplo:

apiVersion: v1
kind: Pod
spec:
...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/gke-spot
            operator: In
            values:
            - true
...

También puedes usar nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution para preferir que GKE coloque los Pods en los nodos que usan VM Spot. No se recomienda usar VM Spot, ya que GKE podría programar los Pods en nodos viables existentes que usan VM estándar.

Usa taints y tolerancias para la programación

Para evitar interrupciones del sistema, usa un taint de nodo a fin de asegurarte de que GKE no programe las cargas de trabajo críticas en las VM Spot. Cuando realizas un taint de nodos que usan VM Spot, GKE solo programa Pods que tienen la tolerancia correspondiente en esos nodos.

Si usas taints de nodos, asegúrate de que tu clúster también tenga al menos un grupo de nodos que use las VM estándar de Compute Engine. Los grupos de nodos que usan las VM estándar proporcionan un lugar confiable para que GKE programe los componentes críticos del sistema, como el DNS.

Si deseas obtener información sobre cómo usar un taint de nodo para VM Spot, consulta Usa taints y tolerancias para VM Spot.

Usa VM Spot con grupos de nodos de GPU

Compatibilidad de VM Spot con GPU Cuando creas un grupo de nodos de GPU nuevo, GKE agrega de forma automática el taint nvidia.com/gpu=present:NoSchedule a los nodos nuevos. Solo los Pods con la tolerancia correspondiente pueden ejecutarse en estos nodos. GKE agrega de forma automática esta tolerancia a los Pods que solicitan GPU.

Tu clúster debe tener al menos un grupo de nodos existente que no sea de GPU que use las VM estándar antes de crear un grupo de nodos de GPU que use VM Spot. Si tu clúster solo tiene un grupo de nodos de GPU con VM Spot, GKE no agrega el taint nvidia.com/gpu=present:NoSchedule a esos nodos. Como resultado, GKE podría programar cargas de trabajo del sistema en los grupos de nodos de GPU con VM Spot, lo que puede provocar interrupciones debido a las VM Spot y puede aumentar el consumo de recursos porque los nodos de GPU son más costosos que nodos que no son de GPU.

Aprovisionamiento automático de nodos y escalador automático del clúster

Puedes usar el escalador automático del clúster y el aprovisionamiento automático de nodos para escalar los clústeres y grupos de nodos de forma automática según las demandas de tus cargas de trabajo. La asistencia para el aprovisionamiento automático de nodos y el escalador automático del clúster mediante VM Spot.

VM Spot y aprovisionamiento automático de nodos

El aprovisionamiento automático de nodos crea y borra de forma automática grupos de nodos en tu clúster para satisfacer las demandas de tus cargas de trabajo. Cuando el aprovisionamiento automático de nodos crea grupos de nodos nuevos para alojar Pods que requieren VM Spot, GKE agrega de forma automática el taint cloud.google.com/gke-spot=true:NoSchedule a los nodos en los grupos de nodos nuevos. Solo los Pods con la tolerancia correspondiente pueden ejecutarse en nodos en esos grupos de nodos. Debes agregar la tolerancia correspondiente a tus implementaciones para permitir que GKE coloque los Pods en las VM Spot.

Puedes asegurarte de que GKE solo programe tus pods en las VM Spot mediante la tolerancia y una regla de afinidad de nodo o nodeSelector para filtrar. para las VM Spot.

También puedes usar solo una tolerancia sin filtrar las VM Spot mediante nodeSelector o una afinidad de nodos. En este caso, GKE intenta programar los Pods en las VM Spot. Si no hay VM Spot disponibles, pero hay VM estándar existentes con capacidad, GKE programa los Pods en las VM estándar en su lugar.

VM Spot y escalador automático de clústeres

El escalador automático del clúster agrega y quita nodos de tus grupos de nodos de forma automática según la demanda. Si tu clúster tiene Pods que no se pueden colocar en las VM Spot existentes, el escalador automático del clúster agrega nodos nuevos que usan las VM Spot.

Modificaciones del comportamiento de Kubernetes

El uso de VM Spot en GKE modifica algunas garantías y restricciones que proporciona Kubernetes, como las siguientes:

  • En los clústeres que ejecutan versiones de GKE anteriores a la 1.20, la función de cierre de nodos ordenado de kubelet está inhabilitada de forma predeterminada. GKE cierra las VM Spot sin un período de gracia para pods, 30 segundos después de recibir una notificación de interrupción de Compute Engine.

  • La reclamación de VM Spot es involuntaria y no está cubierta por las garantías de PodDisruptionBudgets. Es posible que experimentes una falta de disponibilidad superior al PodDisruptionBudget configurado.

Prácticas recomendadas para las VM Spot

Cuando diseñes un sistema que use VM Spot, puedes evitar interrupciones importantes mediante los siguientes lineamientos:

  • Las VM Spot no tienen garantías de disponibilidad. Diseña tus sistemas a partir de la suposición de que GKE podría recuperar cualquiera o todas tus VM Spot en cualquier momento, sin garantizar cuándo estarán disponibles instancias nuevas.
  • No hay garantía de que los Pods que se ejecutan en VM Spot se cierren de manera ordenada. Es posible que GKE no detecte que el nodo se recuperó hasta unos minutos después de que se realiza la reclamación, lo que retrasa la reprogramación de esos Pods en un nuevo nodo.
  • Para garantizar que tus cargas de trabajo y trabajos se procesen incluso cuando no hay VM Spot disponibles, asegúrate de que tus clústeres tengan una combinación de grupos de nodos que usen VM Spot y grupos de nodos que usen VM estándar de Compute Engine.
  • Asegúrate de que tu clúster tenga al menos un grupo de nodos de GPU que use VM estándar antes de agregar un grupo de nodos de GPU que use VM Spot.
  • Usa el controlador de eventos de finalización de nodos de Kubernetes en GCP en clústeres que ejecutan versiones de GKE anteriores a la 1.20, en la que la función de cierre de nodos ordenado de kubelet está inhabilitada. El controlador finaliza de forma correcta tus Pods cuando se interrumpen las VM Spot.
  • Si bien los nombres de los nodos no suelen cambiar cuando se vuelven a crear los nodos, las direcciones IP internas y externas que usan las VM Spot pueden cambiar después de la recreación.
  • Usa taints y tolerancias de nodo para asegurarte de que los Pods críticos no estén programados en los grupos de nodos que usan VM Spot.
  • No uses Pods con estado con VM Spot. Los StatefulSets, de manera inherente, tienen una semántica de Pod por índice, como máximo, que la interrupción de las VM Spot podría infringir, lo que genera una pérdida de datos.
  • Sigue las prácticas recomendadas de finalización de Pods de Kubernetes.

¿Qué sigue?