Configurar o bursting de pods no GKE

Nesta página, mostramos como configurar pods para usar o burst na capacidade não utilizada disponível nos nós do Google Kubernetes Engine (GKE).

O que é bursting?

Bursting descreve a ação de pods que usam temporariamente mais capacidade de computação no nó do que a solicitada originalmente.

O Kubernetes permite solicitar capacidades específicas de recursos, como CPU ou memória, para seus pods. Você define essas solicitações no manifesto do pod. O programador do Kubernetes coloca os pods em nós com capacidade suficiente para acomodar essas solicitações de recursos.

Algumas cargas de trabalho não usam 100% dos recursos solicitados durante todo o tempo de execução. Por exemplo, uma carga de trabalho que consome mais da CPU durante o período de inicialização pode não exigir a mesma quantidade de recursos durante operações normais. Nessas situações, você pode definir os limites de recursos para sua carga de trabalho com um valor maior do que as solicitações de recursos ou não definir os limites. O GKE permite que a carga de trabalho use temporariamente mais recursos do que o especificado nas solicitações, se essa capacidade estiver disponível.

Para mais informações sobre como esse processo funciona no GKE, consulte Como o bursting funciona, neste documento.

Benefícios do bursting de pods

O bursting é útil quando seus pods precisam apenas de recursos extras por curtos períodos para acomodar picos no uso de recursos. Os cenários de exemplo incluem o seguinte:

  • Você tem grupos de cargas de trabalho que geralmente estão inativas e enviam um pequeno número de solicitações por segundo, mas ocasionalmente apresentam picos de tráfego e se beneficiariam de recursos extras para processar essas solicitações.
  • Suas cargas de trabalho precisam de mais recursos durante a inicialização do que durante as operações normais.
  • Você quer maximizar o uso da capacidade de computação provisionada.

O bursting permite que você solicite apenas os recursos que seu pod precisa para a maior parte do ambiente de execução, além de garantir que seu pod possa consumir mais recursos, se necessário. Os benefícios do bursting incluem:

  • Custos de execução menores: não é necessário solicitar o pico de consumo de recursos esperado da carga de trabalho. Suas solicitações podem ser para valores de estado estável mais baixos. No Autopilot, você paga pela soma das solicitações de recursos do pod. Assim, os custos de execução são menores.
  • Uso de recursos mais eficiente: você evita a capacidade de computação inativa porque seus pods atingem o burst para a capacidade não utilizada. É mais provável que as cargas de trabalho usem todos os recursos pagos.
  • Melhoria no desempenho: os pods podem usar recursos extras conforme necessário para reduzir o tempo de processamento de solicitações recebidas ou para inicializar mais rapidamente durante eventos de escalonamento vertical.

Quando o bursting não deve ser usado

O Kubernetes atribui a classe Qualidade de Serviço (QoS) Burstable aos pods que especificam limites de recursos mais altos do que as solicitações deles. Há uma maior probabilidade de os pods de QoS Burstable serem removidos quando o Kubernetes precisa recuperar recursos no nó. Para mais informações, consulte Classe de QoS Burstable na documentação do Kubernetes.

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.
  • Verifique se você tem um cluster do Autopilot em execução na versão 1.29.2-gke.1060000 ou mais recente ou em qualquer versão de um cluster do GKE Standard. Para criar um novo cluster, consulte Criar um cluster do Autopilot.

Disponibilidade de burst no GKE

As cargas de trabalho podem ter burst nas seguintes situações:

Disponibilidade de bursting
Modo Autopilot do GKE

Os pods que usam a classe de computação de desempenho ou a classe de computação do acelerador podem usar o burst em qualquer versão do GKE compatível com essa classe de computação.

Em qualquer outra classe de computação e para pods que não especificam uma classe de computação, o bursting só estará disponível se o cluster atender às duas condições a seguir:

  • Você criou o cluster originalmente com a versão 1.26 ou mais recente do GKE
  • O cluster está executando o GKE versão 1.29.2-gke.1060000 ou posterior

Essa restrição existe porque, em clusters do Autopilot, o bursting exige o cgroup v2. O cgroup v2 só está disponível em clusters criados originalmente com a versão 1.26 e mais recente.
Modo GKE Standard É possível usar bursts nos pods em qualquer versão do GKE.

Os clusters do Autopilot que foram criados originalmente com uma versão anterior à 1.26 e foram atualizados para a versão 1.29.2-gke.1060000 e mais recente não oferecem suporte a bursting. Para verificar a versão original de um cluster, execute o seguinte comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(initialClusterVersion)"

O resultado deve ser a versão 1.26 ou mais recente do GKE.

Limitações

  • As cargas de trabalho do Autopilot só podem usar bursting para solicitações de CPU e memória.
  • Os nós e os planos de controle do Autopilot precisam usar uma versão compatível do GKE. Se você recentemente fez um upgrade dos clusters para uma versão com suporte, verifique se os nós estão executando essa versão antes de usar o bursting.

Conectar-se ao cluster

Execute este comando:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

Substitua:

  • CLUSTER_NAME: o nome do cluster atual.
  • LOCATION: o local do cluster.

Implantar uma carga de trabalho com burst

  1. Salve o seguinte manifesto como burstable-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      nodeSelector:
        pod-type: "non-critical"
      tolerations:
      - key: pod-type
        operator: Equal
        value: "non-critical"
        effect: NoSchedule
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 350m

    Esse manifesto tem os seguintes campos para ativar o bursting:

    • resources.requests: os recursos que o contêiner exige para funcionar. Defina esse valor de acordo com a capacidade necessária para o contêiner no estado estável.
    • resources.limits: a capacidade máxima de recursos que o contêiner pode usar. Definir limites maiores do que as solicitações permite que os pods atinjam o burst para o limite especificado, se essa capacidade estiver disponível no nó. Se você omitir esse campo, os pods poderão atingir os bursts no limite da capacidade disponível no nó. Essa capacidade é calculada da seguinte forma:
      • Modo Autopilot: capacidade não utilizada na soma das solicitações de recursos dos pods no nó.
      • Modo padrão: capacidade não utilizada nos recursos do nó.
    • spec.nodeSelector e spec.tolerations: opcional. Instrui o GKE a criar novos nós para executar pods com burst. O GKE aplica taints a esses novos nós para impedir que outros pods, como os de cargas de trabalho críticas, sejam executados nos mesmos nós. Para obter detalhes, consulte Configurar a separação de cargas de trabalho no GKE.

  2. Implantar a carga de trabalho:

    kubectl apply -f burstable-deployment.yaml

    A inicialização da carga de trabalho pode levar alguns minutos.

  3. Verificar a classe de QoS de um pod:

    kubectl describe pod helloweb | grep -m 1 "QoS"

    A saída é esta:

    QoS Class: Burstable

Capacidade de burst no GKE

Para facilitar o bursting de pods, o GKE calcula a capacidade de burst de cada nó em um cluster. O cálculo para um nó específico é o seguinte:

  • Clusters do Autopilot: a soma das solicitações de recursos de todos os pods nesse nó, independente da capacidade real de recursos dele. Se um pod for encerrado, a capacidade de burst será reduzida de acordo com as solicitações desse pod. A parte da capacidade de burst não utilizada pela execução de pods estará disponível para alocação se um dos pods precisar de burst.

    O Autopilot também adiciona um buffer predefinido à capacidade de burst para que quaisquer pods do sistema no nó que ultrapassem o limite de burst das solicitações não afetem os pods com burst que são seus.

  • Clusters padrão: a capacidade total de recursos disponíveis na VM do nó.

Práticas recomendadas para bursting

Use as seguintes práticas com o bursting de pod:

  • Defina solicitações de recursos correspondentes aos limites para qualquer pod que ofereça uma funcionalidade essencial no ambiente. Isso garante que esses pods recebam a classe de qualidade de serviço (QoS) do Kubernetes Guaranteed.
  • Configure o bursting de memória somente em pods capazes de lidar com a remoção quando o Kubernetes precisar recuperar a memória no nó.
  • Sempre solicite memória suficiente para que o pod seja inicializado. Não dependa do bursting de memória para atender aos seus requisitos de inicialização.
  • Para evitar que pods com burst que tenham bursts consistentemente em várias de suas solicitações de CPU interrompam cargas de trabalho vitais, use a separação de carga de trabalho, para evitar colocar esses pods ao lado dos pods cruciais.

Otimizar a capacidade de burst nos nós do Autopilot

O Autopilot calcula a capacidade de burst como a soma das solicitações de recursos de todos os pods em um nó específico, incluindo os pods do sistema e DaemonSets. É possível otimizar a capacidade de burst em um nó das seguintes maneiras. No entanto, o bursting é oportunista e não é garantido.

  • Para aumentar a capacidade de burst em nós de cargas de trabalho específicas, use a afinidade de pod para juntar pods específicos no mesmo nó.
  • Para garantir que uma capacidade específica de burst esteja sempre disponível em cada nó, crie DaemonSets para serem executados em todos os nós do cluster.

Exemplo de como o bursting funciona

Nesta seção, para demonstrar como o bursting de pods funciona nos clusters do GKE Autopilot, usamos um exemplo de implantação que tem os seguintes pods com burst:

  • O pod 1 solicita 250 m de CPU, sem limite de CPU. O pod 1 usa 100 m de CPU para ser executado.
  • O pod 2 solicita uma CPU de 200 m e tem um limite de 250 m de CPU. O pod 2 usa 100 m de CPU para ser executado.

Ambos são executados no mesmo nó. A capacidade total de burst no nó é de 450 m de CPU (a soma das solicitações de recursos). Cada pod usa apenas 100 m de CPU para ser executado, o que significa que o nó tem uma capacidade de burst restante de 250 m.

Considere os seguintes cenários em que ocorre um pico de tráfego:

  • O pod 1 precisa de uma CPU extra de 300 m. Ele pode causar bursts e usar uma CPU de 250 m, que é a capacidade disponível para burst. O nó não tem mais capacidade de burst disponível.
  • O pod 2 precisa de uma CPU extra de 150 m. Ele pode causar bursts e usar uma CPU extra de 150 m. Portanto, o nó tem 100 m de CPU restantes de capacidade de burst disponível.
  • O pod 2 precisa de uma CPU extra de 200 m, já que ele pode atingir o ponto de burst e usar uma CPU de 150 m, o que leva o uso total para 250 m de CPU para o pod 2. O pod 2 tem um limite de CPU de 250 m e não pode ultrapassar esse ponto de burst.

Como o GKE lida com pods que excedem a capacidade de burst

Se os pods com burst tentarem usar mais recursos do que a capacidade de burst do nó, o GKE tomará as seguintes ações:

  • CPU: se o uso da CPU exceder a capacidade de burst, o GKE limitará o uso da CPU de alguns contêineres para que todos os contêineres no nó recebam o que precisam da CPU.
  • Memória: se o uso da memória exceder a capacidade de burst, o GKE encerrará os contêineres para recuperar a memória no nó. O GKE começa encerrando contêineres que consomem muitos recursos em pods com um QoS menor.

Recomendamos que você sempre solicite memória suficiente para a operação normal de um pod. Se um contêiner tiver uma dependência no bursting de memória para funcionar normalmente, ele poderá falhar repetidamente se essa memória não estiver disponível.

Usar o bursting de pods com provisionamento de capacidade disponível

O GKE permite implantar pods inativos para reservar capacidade extra de computação para escalonar mais rapidamente o pod durante eventos futuros de grande volume de tráfego, como ofertas relâmpago em lojas on-line. Outros pods no mesmo nó podem usar essa capacidade de burst reservada não utilizada para que a capacidade não fique ociosa no tempo que antecede o evento de grande volume de tráfego. É possível reservar essa capacidade usando vários mecanismos do Kubernetes. Por exemplo, é possível implantar pods que têm uma PriorityClass baixa. Para ver detalhes, consulte Provisionar capacidade extra de computação para o escalonamento rápido de pods.

Bursting de pods em clusters do GKE Standard

Os clusters do GKE Standard também são compatíveis com o bursting de pod ao definir os limites mais altos que as solicitações ou omitindo limites. No entanto, em clusters padrão, você precisa criar e configurar pools de nós com capacidade de recursos apropriada para oferecer suporte ao bursting. Conseguir a possível redução de custos de pods com burst em clusters padrão requer um planejamento de nó mais cuidadoso e empacotamento de pods, visto que você paga pelas VMs do Compute Engine.

Considere o seguinte nos clusters padrão:

  • O limite máximo de consumo de recursos que aciona a remoção do Kubernetes ou a limitação da CPU é a capacidade alocável de recursos no nó. Para determinar esse valor, consulte Planejar tamanhos de nó do GKE Standard.

  • Há uma maior probabilidade de o uso de recursos de um nó em clusters padrão atingir um limite de remoção do Kubernetes porque o GKE não limitará automaticamente o consumo de recursos se você não especificar limites. Portanto, é mais provável que os pods que atinjam o ponto de burst na memória sejam encerrados pela remoção de pressão do nó do Kubernetes.

A seguir