Estender o ambiente de execução dos pods do Autopilot

Nesta página, mostramos como solicitar tempos de execução estendidos para pods antes que eles sejam removidos pelo Google Kubernetes Engine (GKE).

Sobre a remoção de pods iniciados pelo GKE

As remoções de pods são parte normal da execução de cargas de trabalho no Kubernetes. O GKE remove cargas de trabalho durante eventos programados, como upgrades automáticos de nós e escalonamentos automáticos, para garantir que os nós estejam atualizados e otimizados para uso eficiente de recursos. Por padrão, o GKE envia um sinal de encerramento para o contêiner assim que o evento ocorre. Após esse período, o contêiner tem um período de carência para ser encerrado antes que o Kubernetes remova o pod. Para upgrades automáticos de nós, o período de carência pode ser de até uma hora. Para eventos de redução da escala vertical, o período de carência pode ser de até 10 minutos.

O Kubernetes tem recursos integrados que os contêineres podem usar para lidar de modo típico com remoções, como PodDisruptionBudgets e períodos de carência normal. No entanto, algumas cargas de trabalho, como filas de lotes ou servidores de jogos multiplayer, precisam ser executadas por um período mais longo antes de serem removidas. O período de carência padrão que o GKE concede durante os processos iniciados pelo GKE pode não ser suficiente para essas cargas de trabalho. Nessas situações, você pode informar ao Autopilot para evitar a remoção de cargas de trabalho específicas por até sete dias.

Casos de uso

Veja a seguir algumas situações em que é recomendável dizer ao GKE para evitar o descarte de cargas de trabalho:

  • Você executa servidores de jogo multijogador que expulsam os jogadores de suas sessões se os servidores forem encerrados antecipadamente.
  • executar um software de áudio ou videoconferência que interrompa as reuniões em andamento se os servidores forem encerrados;
  • Você executa tarefas que precisam de tempo para serem concluídas, e o encerramento antecipado causaria a perda do trabalho em andamento.
  • Você executa um serviço com estado que é menos tolerante a interrupções e quer minimizar a frequência das interrupções.

Preços

É possível solicitar tempos de execução estendidos para seus pods sem custo adicional. No entanto, considere as seguintes mudanças comportamentais que podem afetar os preços:

  • Os clusters do Autopilot aplicam valores mínimos mais altos para as solicitações de recursos dos pods de duração estendida. Os clusters do Autopilot cobram pelas solicitações de recursos dos pods em execução. Você não é cobrado pela sobrecarga do sistema ou pela capacidade do nó não utilizada.
  • O uso de pods de duração estendida pode aumentar o número de nós no cluster, o que pode afetar o uso e a escalonabilidade do endereço IP. Se você tiver DaemonSets que são executados em cada nó, isso resulta em mais DaemonSets no cluster,

Para ver os preços, consulte Preços do Autopilot.

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.

Limitações

  • Não é possível solicitar tempos de execução estendidos para seus pods do Spot.
  • Os tempos de extração de imagem são contabilizados ao calcular o tempo de execução estendido.
  • É possível ter no máximo 50 cargas de trabalho de duração estendida (com solicitações de CPU diferentes) em cada cluster. Isso significa que até 50 conjuntos diferentes de valores de solicitação da CPU, após passar os valores mínimos, as proporções e as verificações de tamanho do incremento automático, podem ter duração estendida em cada cluster.
  • Não é possível usar a afinidade entre pods do Kubernetes em pods de duração estendida.
  • Sempre que possível, o GKE coloca cada pod de tempo de execução estendido no próprio nó. Esse comportamento garante que os nós possam ser reduzidos se estiverem subutilizados.

Solicitar tempo de execução estendido

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

  1. Salve 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 implantação:

    kubectl create -f extended-deployment.yaml

Os pods continuam em execução por pelo menos sete dias antes de ocorrer uma redução de escala ou um upgrade automático do nó.

Considerações e recomendações

Ao usar essa funcionalidade, considere o seguinte:

  • Os pods de duração estendida não são protegidos contra remoção com base em prioridade. Se você usa Kubernetes PriorityClasses, considere os seguintes métodos para minimizar a probabilidade de remoção com base na prioridade:
    • Verifique se os pods de duração estendida usam a classe de prioridade mais alta para que outros pods de usuário não os removam.
    • Use a separação de carga de trabalho para executar pods de duração estendida separadamente de outros pods.
  • Os pods do sistema são executados com a prioridade mais alta e sempre podem remover pods de duração estendida. Para minimizar a probabilidade disso, o GKE programa pods do sistema no nó antes de programar o pod de duração estendida.
  • Os pods de duração estendida ainda podem ser removidos antecipadamente nas seguintes situações:
    • Remoção para liberar espaço para pods de usuários de prioridade mais alta (usando uma classe de prioridade mais alta)
    • Remoção para liberar espaço para componentes do sistema do Kubernetes
    • Remoção de memória insuficiente do kubelet se o pod usar mais memória do que o solicitado (OOMKill)
    • Eventos de manutenção de VM do Compute Engine. Os tipos de máquina otimizados para aceleradores são mais propensos a serem afetados por esses eventos porque não são compatíveis com a migração em tempo real.
    • Reparos automáticos de nodes
    • Eventos iniciados pelo usuário, como drenagem de um nó
  • É possível 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 da escala vertical. Isso evita a exclusão de nós subutilizados e faz com que você continue pagando por esses nós. Os pods também não estão protegidos contra remoções causadas por upgrades automáticos de nós.

A seguir