VMs 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

As VMs do Spot são instâncias de máquina virtual (VM) do Compute Engine que têm um preço menor do que as VMs padrão do Compute Engine e não fornecem garantia de disponibilidade. As VMs do Spot oferecem os mesmos tipos de máquina e opções que as VMs padrão.

É 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.

Com base no melhor esforço, o kubelet concede o seguinte período de encerramento sem complicações com base na versão do GKE do pool de nós:

  • Versão posterior a 1.22.8-gke.200: 15 segundos para pods sem sistema, após os pods do sistema (com as classes de prioridade system-cluster-critical ou system-node-critical) ter 15 segundos para encerrar sem complicações.
  • Versão anterior a 1.22.8-gke.200: 25 segundos para pods que não são do sistema, após os pods do sistema (com as classes de prioridade system-cluster-critical ou system-node-critical) ter 15 segundos para encerrar sem complicações.

Durante o encerramento normal dos nós, o kubelet atualiza o status deles, atribuindo uma fase Failed e um motivo Terminated.

Quando o número de pods encerrados atinge um limite de 1.000 para clusters com menos de 100 nós ou 5.000 para clusters com 100 nós ou mais, a coleta de lixo limpa os pods.

Também é possível excluir pods encerrados manualmente usando os seguintes comandos:

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

Como programar cargas de trabalho em VMs do Spot

O GKE adiciona automaticamente os identificadores cloud.google.com/gke-spot=true e cloud.google.com/gke-provisioning=spot (para nós que executam a versão 1.25.5-gke.2500 ou posterior do GKE) aos nós que usam VMs do Spot. É possível programar pods específicos em nós que usam VMs do Spot usando o campo nodeSelector na especificação do seu pod. Os exemplos a seguir usam o identificador cloud.google.com/gke-spot:

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. Ao programar cargas de trabalho que exigem VMs do Spot usando nodeSelector ou afinidade de nó, o provisionamento automático de nós cria novos pools de nós para acomodar os pods das cargas de trabalho. 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 Spot:

   tolerations:
   - key: cloud.google.com/gke-spot
     operator: Equal
     value: "true"
     effect: NoSchedule

É 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.

Se você programa uma carga de trabalho usando apenas uma tolerância, o GKE poderá programar os pods em VMs do Spot ou em VMs padrão atuais com capacidade. Se você exige que uma carga de trabalho seja programada em VMs do Spot, use uma afinidade de nodeSelector ou de nó, além de uma tolerância. Para saber mais, consulte Como programar cargas de trabalho em VMs do Spot.

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.

Política padrão

A partir da versão 1.24.1-gke.800 do GKE, é possível definir a política de localização do escalonador automático. O escalonador automático de clusters tenta provisionar pools de nós das VMs do Spot quando os recursos estão disponíveis e a política de localização padrão está definida como ANY. Com essa política, as VMs do Spot têm um risco menor de serem antecipadas. Para outros tipos de VM, a política de distribuição de escalonador automático do cluster padrão é BALANCED.

Fazer upgrade de pools de nós padrão usando VMs spot

Se os pools de nós de cluster padrão que usam VMs spot estiverem configurados para usar upgrades de sobretensão, o GKE criará nós de sobretensão com VMs spot. No entanto, o GKE não espera que as VMs spot estejam prontas para restringir e drenar os nós atuais, já que essas VMs não oferecem garantia de disponibilidade. Para saber mais, consulte Upgrades súbitos.

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:

  • 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.
  • 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.
  • 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.
  • Para executar cargas de trabalho com estado em VMs do Spot, teste para garantir que suas cargas de trabalho possam ser encerradas normalmente até 25 segundos após o encerramento para minimizar o risco de corrupção de dados de volumes permanentes.
  • Siga as Práticas recomendadas de encerramento do pod do Kubernetes.

A seguir