Prolongue o tempo de execução dos pods do Autopilot

Esta página mostra como pedir tempos de execução prolongados para os pods antes de serem despejados pelo Google Kubernetes Engine (GKE).

Acerca da remoção de pods iniciada pelo GKE

As remoções de pods são uma parte normal da execução de cargas de trabalho no Kubernetes. O GKE remove cargas de trabalho durante eventos agendados, como atualizações automáticas de nós e reduções da escala automática, para garantir que os seus nós estão atualizados e otimizados para uma utilização eficiente dos recursos. Por predefinição, o GKE envia um sinal de rescisão para o contentor assim que o evento ocorre. Após este sinal, o contentor tem um período de tolerância para terminar antes de o Kubernetes desalojar o pod. Para atualizações automáticas de nós, o período de tolerância pode durar até uma hora. Para eventos de redução, o período de tolerância pode durar até 10 minutos.

O Kubernetes tem funcionalidades incorporadas que os contentores podem usar para processar corretamente as expulsões, como PodDisruptionBudgets e períodos de encerramento correto. No entanto, algumas cargas de trabalho, como filas de processamento em lote ou servidores de jogos multijogador, têm de ser executadas durante um período mais longo antes de serem removidas. O período de tolerância predefinido que o GKE concede durante as remoções iniciadas pelo GKE pode não ser suficiente para estas cargas de trabalho. Nestes casos, pode indicar ao Autopilot para evitar a remoção de cargas de trabalho específicas durante um período máximo de 7 dias.

Exemplos de utilização

Seguem-se algumas situações em que pode querer indicar ao GKE para evitar a remoção de cargas de trabalho:

  • Executa servidores de jogos multijogador que expulsariam os jogadores das respetivas sessões se os servidores terminassem prematuramente.
  • Executa software de videoconferências ou áudio que interromperia as reuniões em curso se os servidores fossem terminados.
  • Executa tarefas que precisam de tempo para serem concluídas e a rescisão antecipada causaria uma perda de trabalho em curso.
  • Executa um serviço com estado que é menos tolerante a interrupções e quer minimizar a frequência com que ocorrem interrupções.

Preços

Pode pedir tempos de funcionamento prolongados para os seus Pods sem custos adicionais. No entanto, considere as seguintes alterações comportamentais que podem afetar os seus preços:

  • Os clusters do Autopilot aplicam valores mínimos mais elevados para os pedidos de recursos de pods de duração prolongada. Os clusters do Autopilot cobram-lhe os pedidos de recursos dos seus pods em execução. Não lhe é cobrado nenhum valor pelo processamento geral do sistema nem pela capacidade do nó não utilizada.
  • A utilização de Pods de duração prolongada pode aumentar o número de nós no seu cluster, o que pode afetar a utilização de endereços IP e a escalabilidade. Se tiver DaemonSets que são executados em todos os nós, isto resulta em mais DaemonSets no cluster.

Para ver detalhes dos preços, consulte o artigo Preços do Autopilot.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Limitações

  • Não pode pedir tempos de apresentação prolongados para os seus Spot Pods.
  • Os tempos de obtenção de imagens são contabilizados no cálculo do tempo de execução prolongado.
  • Pode ter um máximo de 50 cargas de trabalho de duração prolongada (com diferentes pedidos de CPU) em cada cluster. Isto significa que até 50 conjuntos diferentes de valores de pedidos de CPU, após a aprovação nos mínimos, nas proporções e nas verificações de tamanho de incremento de recursos do Autopilot, podem ter uma duração prolongada em cada cluster.
  • Não pode usar a afinidade entre pods do Kubernetes em pods de duração prolongada.
  • Sempre que possível, o GKE coloca cada pod de tempo de execução prolongado no seu próprio nó. Este comportamento garante que os nós podem ser reduzidos se estiverem subutilizados.
  • Não pode pedir tempos de execução prolongados para Pods que segmentam classes de computação personalizadas.

Peça uma duração prolongada

Para pedir um tempo de execução prolongado para um pod, defina a anotação do Kubernetes cluster-autoscaler.kubernetes.io/safe-to-evict como false na especificação do pod.

  1. Guarde o seguinte manifesto como extended-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: extended-pods
  labels:
    duration: extended
spec:
  selector:
    matchLabels:
      duration: extended
  template:
    metadata:
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
      labels:
        duration: extended
    spec:
      containers:
      - name: example-container
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 200m

  2. Crie a implementação:

    kubectl create -f extended-deployment.yaml

Os pods continuam a ser executados durante, pelo menos, 7 dias antes de poder ocorrer uma redução ou uma atualização automática de nós.

Considerações e recomendações

Quando usar esta funcionalidade, tenha em atenção o seguinte:

  • Os pods de duração prolongada não estão protegidos contra a remoção baseada na prioridade. Se usar classes de prioridade do Kubernetes, considere os seguintes métodos para minimizar a probabilidade de despejo baseado na prioridade:
    • Certifique-se de que os seus pods de duração prolongada usam a PriorityClass de prioridade mais elevada, para que outros pods de utilizadores não despejem os seus pods de duração prolongada.
    • Use a separação de cargas de trabalho para executar pods de duração prolongada separadamente de outros pods.
  • Os agrupamentos do sistema são executados com a prioridade mais elevada e podem sempre desalojar agrupamentos de duração prolongada. Para minimizar a probabilidade de isto acontecer, o GKE agenda pods do sistema no nó antes de agendar o pod de duração prolongada.
  • Os pods de duração prolongada podem continuar a ser desalojados antecipadamente nas seguintes situações:
    • Despejo para criar espaço para Pods de utilizadores de prioridade mais elevada (com uma PriorityClass mais elevada)
    • Despejo para criar espaço para componentes do sistema Kubernetes
    • kubelet out-of-memory eviction se o pod usar mais memória do que pediu (OOMKill)
    • Eventos de manutenção de VMs do Compute Engine. Os tipos de máquinas otimizados para aceleradores têm maior probabilidade de serem afetados por estes eventos porque essas máquinas não suportam a migração em direto.
    • Reparações automáticas de nós
    • Eventos iniciados pelo utilizador, como esvaziar um nó
  • Pode usar a anotação cluster-autoscaler.kubernetes.io/safe-to-evict em clusters padrão, mas o resultado não é o mesmo. Os pods são executados indefinidamente, mesmo que ocorra um evento de redução, o que impede a eliminação de nós subutilizados e faz com que continue a pagar por esses nós. Os pods também não estão protegidos contra despejos causados por atualizações automáticas de nós.

O que se segue?