Execute cargas de trabalho tolerantes a falhas a custos menores em pods do Spot

Piloto automático

Nesta página, mostramos como executar cargas de trabalho tolerantes a falhas a custos menores usando pods do Spot nos clusters Autopilot do Google Kubernetes Engine (GKE).

Visão geral

Nos clusters do Autopilot do GKE, os pods do Spot são pods executados em nós com suporte de VMs do Spot do Compute Engine. Os pods do Spot têm um preço menor do que os do Autopilot padrão, mas podem ser removidos pelo GKE sempre que os recursos de computação forem necessários para executar os pods padrão.

Os pods do Spot são ideais para executar cargas de trabalho sem estado, em lote ou tolerantes a falhas a custos menores em comparação com a execução dessas cargas de trabalho como pods padrão. Para usar pods do Spot em clusters do Autopilot, modifique o manifesto com sua especificação do pod para solicitar pods do Spot.

É possível executar pods do Spot na classe de computação padrão de uso geral do Autopilot, bem como em classes de computação especializadas que atendam a requisitos específicos de hardware. Para mais informações sobre essas classes de computação, consulte Classes de computação no Autopilot.

Para saber mais sobre os preços dos pods do Spot em clusters do Autopilot, consulte Preços do Google Kubernetes Engine.

Vantagens

O uso de pods do Spot nos clusters do Autopilot oferece os seguintes benefícios:

preços mais baixos do que a execução das mesmas cargas de trabalho em pods padrão do Autopilot;
o GKE gerencia automaticamente o escalonamento automático e a programação;
O GKE faz um taint automaticamente dos nós que executam pods do Spot para garantir que os pods padrão, como suas cargas de trabalho críticas, não sejam programados nesses nós; As implantações que usam pods do Spot são atualizadas automaticamente com uma tolerância correspondente.

Requisitos e limitações

exige a versão 1.21.4 ou mais recente do GKE;
os pods do Spot são excluídos do Contrato de nível de serviço do Autopilot;
o GKE não pode programar pods do Spot em clusters que executam as versões do GKE anteriores à 1.21.4;
Os clusters do Autopilot são compatíveis com solicitações de pods preemptivos em clusters que executam a versão 1.21.4 ou mais recente do GKE usando o seletor cloud.google.com/gke-preemptible. Os pods que usam esse seletor são migrados automaticamente para os pods do Spot, e o seletor é alterado para cloud.google.com/gke-spot.

Cuidado: a migração automática do seletor cloud.google.com/gke-preemptible não é compatível com clusters que executam as versões do GKE anteriores à 1.21.4. Se você solicitar pods preemptivos nesses clusters, eles receberão um comportamento preemptivo, mas com preços padrão. Como prática recomendada, evite usar pods preemptivos nas suas implantações, porque isso reduz a disponibilidade do pod sem benefício de preço.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Definindo os locais padrão, você evita erros como este na CLI gcloud: One of [--zone, --region] must be supplied: Please specify location.

Solicitar pods do Spot nas cargas de trabalho do Autopilot

Para solicitar que os pods sejam executados como pods do Spot, use o rótulo cloud.google.com/gke-spot=true em um nodeSelector ou afinidade de nó na especificação do pod. O GKE provisiona automaticamente os nós que podem executar pods do Spot.

Os pods do Spot podem ser removidos e encerrados a qualquer momento, por exemplo, se os recursos de computação forem necessários em outro lugar no Google Cloud. Quando ocorre um encerramento, os pods do Spot no nó de encerramento podem solicitar um período de carência de 25 segundos antes do encerramento, o que é concedido da melhor maneira possível, especificando o campo terminationGracePeriodSeconds.

O período de carência máximo concedido aos pods do Spot durante a preempção é de 25 segundos. A solicitação de mais de 25s em terminationGracePeriodSeconds não concede mais de 25s durante a preempção. Na remoção, o pod recebe o sinal de SIGTERM e precisa seguir etapas para o encerramento durante o período de carência.

Para o Autopilot, o GKE também faz taint automaticamente dos nós criados para executar pods do Spot e modifica essas cargas de trabalho com a tolerância correspondente. O taint impede que os pods padrão sejam programados em nós que executam pods do Spot.

Usar um nodeSelector para exigir pods do Spot

Use um nodeSelector para exigir pods do Spot em uma implantação. Adicione o rótulo cloud.google.com/gke-spot=true à implantação, como no exemplo a seguir:

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

Usar a afinidade de nó para solicitar pods do Spot

Como alternativa, é possível usar a afinidade de nó para solicitar pods do Spot. A afinidade de nó oferece uma maneira mais extensível de selecionar nós para executar as cargas de trabalho. Por exemplo, é possível combinar vários critérios de seleção para ter um controle mais preciso sobre onde seus pods são executados. Ao usar a afinidade de nó para solicitar pods do Spot, é possível especificar o tipo de afinidade de nó a ser usado da seguinte maneira:

requiredDuringSchedulingIgnoredDuringExecution: precisa usar pods do Spot.
preferredDuringSchedulingIgnoredDuringExecution: usar os pods do Spot da melhor forma possível.

Para usar a afinidade de nó para exigir pods do Spot em uma implantação, adicione a seguinte regra nodeAffinity ao manifesto de implantação:

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

Como solicitar pods do Spot da melhor forma possível

Para usar a afinidade de nós para solicitar pods do Spot com base no melhor esforço, use preferredDuringSchedulingIgnoredDuringExecution. Quando você solicita pods do Spot da forma que prefere, o GKE programa seus pods com base na seguinte ordem:

nós existentes que podem executar pods do Spot que têm capacidade alocável disponível;
nós padrão existentes que têm capacidade alocável disponível;
novos nós que poderão executar pods do Spot, se os recursos de computação estiverem disponíveis;
novos nós padrão.

Como o GKE prefere os nós padrão existentes que têm capacidade alocável em vez de criar novos nós para os pods do Spot, talvez você perceba mais pods em execução como pods padrão do que os pods do Spot, o que impede que você aproveite ao máximo preços mais baixos para pods do Spot.

Encontrar e excluir pods encerrados

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