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 Capacidade burstable no GKE nesta página.

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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

• Verifique se você tem um cluster do Autopilot em execução na versão 1.30.2-gke.1394000 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:

Limitações

• As cargas de trabalho do Autopilot só podem usar bursting para solicitações de CPU e memória.

• Ao fazer upgrade de um cluster do Autopilot para uma versão compatível, o GKE faz upgrade dos nós de trabalho para corresponder à versão do plano de controle ao longo do tempo. É necessário reiniciar o plano de controle para ativar o bursting, e isso precisa acontecer depois que todos os nós executarem uma versão e um modo cgroup compatíveis. O plano de controle é reiniciado automaticamente aproximadamente uma vez por semana durante operações como escalonamento, upgrades ou manutenção.

  Para acionar uma reinicialização do plano de controle manualmente, faça o seguinte:

  1. Verifique se todos os nós executam a versão 1.30.2-gke.1394000 ou posterior:

     kubectl get nodes
     

     O resultado será assim:

     NAME                                          STATUS   ROLES    AGE     VERSION
     gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000
     

     Todos os nós na saída precisam mostrar a versão necessária ou posterior.

  2. Confirme se o cluster executa cgroupv2. Para instruções, consulte Verificar o modo cgroup.

  3. Inicie manualmente um upgrade do plano de controle para a mesma versão que o cluster já usa.

     gcloud container clusters upgrade CLUSTER_NAME --master \
         --cluster-version CURRENT_CLUSTER_VERSION
     

     Substitua:

     • CLUSTER_NAME: o nome do cluster atual.
     • CURRENT_CLUSTER_VERSION: a versão em que o cluster está sendo executado.

Conexão 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.

Verificar se o cluster é compatível com bursting

O bursting está sempre ativado em clusters no modo Standard e para cargas de trabalho no modo Autopilot que solicitam aceleradores ou séries de máquinas específicas. Pule para a seção Implantar uma carga de trabalho com burst.

Os seguintes tipos de cargas de trabalho do Autopilot só podem aumentar se um DaemonSet gerenciado pelo GKE chamado efficiency-daemon estiver em execução no cluster:

• Pods do Autopilot que solicitam as classes de computação predefinidas Scale-Out ou Balanced.
• Pods do Autopilot que não solicitam uma classe de computação.

O GKE implanta o DaemonSet efficiency-daemon quando o cluster do Autopilot atende aos requisitos de bursting, conforme descrito na seção Disponibilidade de bursting no GKE.

Para verificar se o DaemonSet efficiency-daemon existe no cluster, execute o seguinte comando:

kubectl get daemonset --namespace=kube-system efficiency-daemon

O resultado será assim:

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

Se a saída estiver vazia, verifique se o cluster atende a todos os requisitos e limitações na seção Antes de começar.

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:
         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. Adicione esses campos com rótulos personalizados, como pod-type: "non-critical", para instruir o GKE a criar novos nós para executar os 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. O Autopilot impõe solicitações mínimas de recursos mais altas para pods que usam separação de cargas de trabalho. Para mais detalhes, consulte Configurar a separação de cargas de trabalho no GKE e Solicitações de recursos no Autopilot.

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:

  • Pods que solicitam aceleradores ou séries de máquinas específicas: a capacidade de recursos alocáveis do nó, que é a capacidade disponível para uso da carga de trabalho. Para mais detalhes , consulte Recursos alocáveis do nó.
  • Todos os outros pods: 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 de recursos alocáveis do nó, que é a capacidade disponível para uso da carga de trabalho. Para mais detalhes , consulte Recursos alocáveis 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

• Saiba como provisionar capacidade extra de computação para escalonamento rápido de pods.
• Saiba como dimensionar as cargas de trabalho do GKE Standard em escala.
• Saiba como resolver problemas de clusters do Autopilot.