VMs do Spot


Nesta página, explicamos o que são VMs do Spot e como elas funcionam no Google Kubernetes Engine (GKE). Para saber como usar VMs do Spot, consulte Usar VMs do Spot.

Visão geral de VMs do Spot no GKE

VMs do Spot são do Compute Engine;Instâncias de máquina virtual (VM) com um preço mais baixo do que as VMs padrão do Compute Engine. As VMs do Spot oferecem os mesmos tipos de máquina e opções que as VMs padrão, mas não oferecem garantias de disponibilidade.

É possível usar VMs do Spot nos clusters e pools de nós para executar cargas de trabalho sem estado, em lote ou tolerantes a falhas que tolerem interrupções causadas pela natureza temporária das VMs do Spot.

As VMs do Spot permanecem disponíveis até que o Compute Engine exija os recursos das VMs padrão. Para maximizar a eficiência de custos, combine o uso das VMs do Spot com as Práticas recomendadas para executar aplicativos do Kubernetes otimizados para custo no GKE.

Saiba mais em VMs do Spot na documentação do Compute Engine.

Benefícios das VMs do Spot

As VMs do Spot e as VMs preemptivas têm muitos benefícios em comum, incluindo:

Ao contrário das VMs preemptivas, que expiram após 24 horas, as VMs do Spot não têm prazo de validade. As VMs do Spot só são encerradas quando o Compute Engine precisa dos recursos em outro lugar.

Como as VMs do Spot funcionam no GKE

Quando você cria um cluster ou pool de nós com VMs do Spot, o GKE cria VMs do Spot do Compute Engine subjacentes que se comportam como um grupo gerenciado de instâncias (MIG, na sigla em inglês). Os nós que usam VMs do Spot se comportam como nós padrão do GKE, mas sem garantia de disponibilidade. Quando os recursos usados pelas VMs do Spot são necessários para executar VMs sob demanda, o Compute Engine encerra essas VMs do Spot para usar os recursos em outro lugar.

Encerramento e encerramento otimizado das VMs do Spot

Quando o Compute Engine precisa recuperar os recursos usados pelas VMs do Spot, um aviso de encerramento é enviado para o GKE. As VMs do Spot são encerradas 30 segundos após o recebimento de um aviso de encerramento.

Nos clusters que executam o GKE versão 1.20 e mais recente, o recurso de encerramento de nó otimizado do kubelet está ativado por padrão. O kubelet detecta o aviso de encerramento e encerra corretamente os pods em execução no nó. Se os pods fizerem parte de uma implantação, o controlador vai criar e programar novos pods para substituir os pods encerrados.

O kubelet concede pods que não são do sistema 25 segundos para serem encerrados corretamente. Depois disso, os pods do sistema, com as classes de prioridade system-cluster-critical ou system-node-critical, têm cinco segundos para serem encerrados corretamente.

Durante o encerramento do pod, o kubelet atribui um status Failed e um motivo Shutdown aos pods encerrados. Quando o número de pods encerrados atinge um limite de 1.000, a coleta de lixo limpa os pods.

Também é possível excluir pods de desligamento manualmente usando o seguinte comando:

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

Como programar cargas de trabalho em VMs do Spot

O GKE adiciona automaticamente o rótulo cloud.google.com/gke-spot=true aos nós que usam VMs do Spot. É possível programar pods específicos em nós que usam VMs do Spot no campo nodeSelector da especificação do pod, como neste exemplo:

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

Outra opção é usar a afinidade de nó para instruir o GKE a programar pods em VMs do Spot, semelhante ao exemplo a seguir:

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

Você também pode usar nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution para preferir que o GKE coloque pods em nós que usam VMs do Spot. Não recomendamos preferir as VMs do Spot porque o GKE pode programar os pods em nós viáveis existentes que usam VMs sob demanda.

Como usar taints e tolerâncias para programação

Para evitar interrupções no sistema, use um taint de nó para garantir que o GKE não programe cargas de trabalho críticas em VMs do Spot. Quando você tem taint em nós que usam VMs do Spot, o GKE programa apenas os pods que têm a tolerância correspondente nesses nós.

Se você usar taints de nó, verifique se o cluster também tem pelo menos um pool de nós que usa VMs sob demanda do Compute Engine. Os pools de nós que usam VMs sob demanda fornecem um local confiável para o GKE programar componentes críticos do sistema, como DNS.

Saiba mais sobre como usar um taint de nó em VMs do Spot em Usar taints e tolerâncias em VMs do Spot.

Como usar VMs do Spot com pools de nós da GPU

As VMs do Spot oferecem suporte para o uso de GPUs. Quando você cria um novo pool de nós de GPU, o GKE adiciona automaticamente o taint nvidia.com/gpu=present:NoSchedule aos novos nós. Somente pods com a tolerância correspondente podem ser executados nesses nós. O GKE adiciona automaticamente essa tolerância a pods que solicitam GPUs.

O cluster precisa ter pelo menos um pool de nós que não seja de GPU que use VMs sob demanda antes de criar um pool de nós de GPU que use VMs do Spot. Se o cluster tiver apenas um pool de nós de GPU com VMs do Spot, o GKE não vai adicionar o taint nvidia.com/gpu=present:NoSchedule a esses nós. Como resultado, o GKE pode programar cargas de trabalho do sistema nos pools de nós de GPU com VMs do Spot, o que pode levar a interrupções devido às VMs do Spot e aumentar o consumo de recursos porque os nós de GPU são mais caros do que os nós que não são de GPU.

Escalonador automático de clusters e provisionamento automático de nós

Use o escalonador automático de clusters e o provisionamento automático de nós para fazer o escalonamento automático de clusters e pools de nós com base nas demandas das cargas de trabalho. Tanto o escalonador automático de clusters quanto o provisionamento automático de nós são aceitos pelas VMs do Spot.

VMs do Spot e provisionamento automático de nós

O provisionamento automático de nós cria e exclui automaticamente pools de nós no cluster para atender às demandas das cargas de trabalho. Quando o provisionamento automático de nós cria novos pools de nós para acomodar pods que exigem VMs do Spot, o GKE adiciona automaticamente o taint cloud.google.com/gke-spot=true:NoSchedule aos nós nos novos pools de nós. Somente pods com a tolerância correspondente podem ser executados em nós nesses pools. Adicione a tolerância correspondente às suas implantações para permitir que o GKE coloque os pods em VMs do Spot.

É possível garantir que o GKE programe apenas os pods das VMs do Spot usando ambas uma tolerância e um nodeSelector ou uma regra de afinidade de nó para filtrar por VMs do Spot.

Também é possível usar apenas uma tolerância sem filtrar por VMs do Spot usando nodeSelector ou uma afinidade de nó. Nesse caso, o GKE tenta programar os pods em VMs do Spot. Se não houver VMs do Spot disponíveis, mas existir VMs padrão com capacidade, o GKE programará os pods nas VMs padrão.

VMs do Spot e escalonador automático de clusters

O escalonador automático de clusters adiciona e remove automaticamente os nós nos pools com base na demanda. Se o cluster tiver pods que não podem ser colocados em VMs do Spot, o escalonador automático de clusters adicionará novos nós que usam VMs do Spot.

Alterações no comportamento do Kubernetes

O uso de VMs do Spot no GKE altera algumas garantias e restrições que o Kubernetes fornece, como:

  • Em clusters que executam versões do GKE anteriores à 1.20, o recurso de encerramento otimizado de nós do kubelet está desativado por padrão. O GKE encerra as VMs do Spot sem um período de carência para os pods, 30 segundos após receber um aviso de preempção do Compute Engine.

  • A recuperação de VMs do Spot é involuntária e não está coberta pelas garantias de PodDisruptionBudgets. Pode haver indisponibilidade maior do que o PodDisruptionBudget configurado.

práticas recomendadas para VMs do Spot;

Ao criar um sistema que usa VMs do Spot, você pode evitar grandes interrupções seguindo estas diretrizes:

  • As VMs do Spot não têm garantias de disponibilidade. Projete os seus sistemas pressupondo que o GKE poderá recuperar qualquer ou todas as VMs do Spot a qualquer momento, sem a garantia de quando novas instâncias vão ficar disponíveis.
  • Não há garantia de que os pods em execução nas VMs do Spot vão ser encerrados normalmente. Talvez o GKE perceba que o nó foi recuperado somente alguns minutos após a recuperação, o que atrasa a reprogramação desses pods em um novo nó.
  • Para garantir que as cargas de trabalho e jobs sejam processados mesmo quando não há VM do Spot disponível, verifique se os clusters têm uma mistura de pools de nós que usam VMs do Spot e pools de nós que usam VMs sob demanda do Compute Engine.
  • Verifique se o cluster tem pelo menos um pool de nós que não seja de GPU e que usa VMs sob demanda antes de adicionar um pool de nós de GPU que use VMs do Spot.
  • Use o manipulador de eventos de encerramento de nós do Kubernetes no GCP em clusters que executam as versões do GKE anteriores à 1.20, em que o recurso de encerramento de nó otimizado do kubelet está desativado. O gerenciador encerra os pods normalmente quando as VMs do Spot são interrompidas.
  • Os nomes dos nós geralmente não mudam quando os nós são recriados, mas os endereços IP internos e externos usados pelas VMs do Spot podem mudar após a recriação.
  • Use taints e tolerâncias de nós para garantir que os pods críticos não sejam programados em pools de nós que usam VMs do Spot.
  • Não use pods com estado com VMs do Spot. StatefulSets têm inerentemente no máximo uma semântica de pod por índice, o que pode ser violado pela preempção das VMs do Spot, levando à perda de dados.
  • Siga as Práticas recomendadas de encerramento do pod do Kubernetes.

A seguir