Configure o aumento rápido de pods no GKE

Esta página mostra como configurar pods para expandir a capacidade não usada disponível nos nós do Google Kubernetes Engine (GKE).

O que é o bursting?

O aumento rápido descreve a ação dos pods que usam temporariamente mais capacidade de computação no nó do que pediram originalmente.

O Kubernetes permite-lhe pedir capacidades específicas de recursos, como CPU ou memória, para os seus pods. Define estes pedidos no manifesto do agrupamento. O programador do Kubernetes coloca os seus pods em nós com capacidade suficiente para satisfazer esses pedidos de recursos.

Algumas cargas de trabalho não usam 100% dos recursos pedidos durante todo o tempo de execução. Por exemplo, uma carga de trabalho que consome CPU adicional durante o período de arranque pode não precisar da mesma quantidade de recursos para as operações normais. Nestas situações, pode definir os limites de recursos para a sua carga de trabalho para um valor superior aos pedidos de recursos ou deixar os limites não definidos. O GKE permite que a carga de trabalho use temporariamente mais recursos do que especificou nos pedidos, se essa capacidade estiver disponível.

Para mais informações sobre como este processo funciona no GKE, consulte a secção Capacidade de expansão no GKE nesta página.

Vantagens da expansão de pods

A expansão é útil quando os seus pods só precisam de recursos adicionais durante breves períodos para acomodar picos na utilização de recursos. Exemplos de cenários:

• Tem grupos de cargas de trabalho que estão frequentemente inativos e enviam um pequeno número de pedidos por segundo, mas ocasionalmente registam picos no tráfego e beneficiariam de recursos adicionais para processar esses pedidos.
• As suas cargas de trabalho precisam de mais recursos durante o arranque do que durante as operações normais.
• Quer maximizar a utilização da capacidade de computação que aprovisiona.

A funcionalidade de picos permite-lhe pedir apenas os recursos de que o seu pod precisa durante a maioria do tempo de execução, ao mesmo tempo que garante que o seu pod pode consumir mais recursos, se necessário. As vantagens do aumento rápido incluem o seguinte:

• Custos de execução mais baixos: não precisa de pedir o consumo de recursos de pico esperado da carga de trabalho. Os seus pedidos podem ser para os valores de estado estacionário inferiores. No modo de condução automática, paga a soma dos pedidos de recursos de pods, pelo que os custos de funcionamento são mais baixos.
• Utilização mais eficiente dos recursos: evita a capacidade de computação inativa porque os seus pods entram em erupção na capacidade não utilizada. As suas cargas de trabalho têm maior probabilidade de usar todos os recursos pelos quais pagou.
• Desempenho melhorado: os agrupamentos podem usar recursos adicionais conforme necessário para reduzir o tempo de processamento de pedidos recebidos ou para serem iniciados mais rapidamente durante eventos de expansão.

Quando não usar o bursting

O Kubernetes atribui a classe de Burstable Qualidade de Serviço (QoS) a pods que especificam limites de recursos superiores aos respetivos pedidos. Burstable Os pods de QoS têm maior probabilidade de serem removidos quando o Kubernetes precisa de reclamar recursos no nó. Para mais informações, consulte a secção Classe de QoS com capacidade de expansão na documentação do Kubernetes.

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.

• Certifique-se de que tem um cluster do GKE Autopilot com a versão 1.30.2-gke.1394000 ou posterior, ou qualquer versão de um cluster do GKE Standard. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.

Disponibilidade de picos no GKE

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

Limitações

• As cargas de trabalho do Autopilot só podem usar o aumento rápido para pedidos de CPU e memória.

• Quando atualiza um cluster do Autopilot para uma versão suportada, o GKE atualiza os nós de trabalho para corresponderem à versão do plano de controlo ao longo do tempo. É necessário reiniciar o plano de controlo para ativar o bursting e este tem de ocorrer depois de todos os nós executarem uma versão suportada e um modo cgroup suportado. O plano de controlo é reiniciado automaticamente cerca de uma vez por semana durante operações como o dimensionamento, as atualizações ou a manutenção.

  Para acionar manualmente um reinício do plano de controlo, faça o seguinte:

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

     kubectl get nodes
     

     O resultado é semelhante ao seguinte:

     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 têm de apresentar a versão necessária ou posterior.

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

  3. Inicie manualmente uma atualização do plano de controlo para a mesma versão que o cluster já usa.

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

     Substitua o seguinte:

     • CLUSTER_NAME: o nome do cluster existente.
     • CURRENT_CLUSTER_VERSION: a versão que o cluster está a executar.

Estabeleça ligação ao cluster

Execute o seguinte comando:

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

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster existente.
• LOCATION: a localização do seu cluster.

Verifique se o cluster suporta o aumento rápido

O bursting está sempre ativado em clusters do modo Standard e para cargas de trabalho do modo Autopilot que pedem aceleradores ou séries de máquinas específicas. Avance para a secção Implemente uma carga de trabalho com capacidade de expansão.

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

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

O GKE implementa o efficiency-daemon DaemonSet quando o cluster do Autopilot cumpre os requisitos para o aumento da capacidade, conforme descrito na secção Disponibilidade do aumento da capacidade no GKE.

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

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

O resultado é semelhante ao seguinte:

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

Se o resultado estiver vazio, certifique-se de que o cluster cumpre todos os requisitos e limitações na secção Antes de começar.

Implemente uma carga de trabalho com capacidade de expansão

1. Guarde 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
   

   Este manifesto tem os seguintes campos para ativar o envio rápido:

   • resources.requests: Os recursos que o contentor requer para funcionar. Defina este valor como a capacidade de que o contentor vai precisar no estado estacionário.
   • resources.limits: A capacidade máxima de recursos que o contentor pode usar. Se definir os limites para um valor superior aos pedidos, os pods podem exceder o limite especificado se essa capacidade estiver disponível no nó. Se omitir este campo, os pods podem exceder a capacidade disponível no nó. Esta capacidade é calculada da seguinte forma:
     • Modo de piloto automático: capacidade não utilizada na soma dos pedidos de recursos dos pods no nó.
     • Modo padrão: capacidade não utilizada nos recursos do nó.
   • spec.nodeSelector e spec.tolerations: opcional. Adicione estes campos com etiquetas personalizadas, como pod-type: "non-critical", para indicar ao GKE que crie novos nós para executar os pods com capacidade de expansão. O GKE aplica taints a estes novos nós para impedir que outros pods, como cargas de trabalho críticas, sejam executados nos mesmos nós. O Autopilot aplica pedidos mínimos de recursos mais elevados para pods que usam a separação de cargas de trabalho. Para ver detalhes, consulte os artigos Configure a separação de cargas de trabalho no GKE e Pedidos de recursos no Autopilot.

2. Implemente a carga de trabalho:

   kubectl apply -f burstable-deployment.yaml
   

   A carga de trabalho pode demorar alguns minutos a ser iniciada.

3. Verifique a classe de QoS de um pod:

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

   O resultado é o seguinte:

   QoS Class: Burstable
   

Capacidade de expansão rápida no GKE

Para facilitar o aumento rápido de pods, o GKE calcula a capacidade de aumento rápido para cada nó num cluster. Este cálculo para um nó específico é o seguinte:

• Clusters do Autopilot:

  • Pods que pedem aceleradores ou pedem séries de máquinas específicas: a capacidade de recursos alocáveis do nó, que é a capacidade disponível para utilização da carga de trabalho. Para ver detalhes , consulte o artigo Recursos atribuíveis do nó.
  • Todos os outros pods: a soma dos pedidos de recursos de todos os pods nesse nó, independentemente da capacidade real de recursos do nó. Se um Pod for terminado, a capacidade de expansão diminui com os pedidos desse Pod. A parte da capacidade de expansão que não está a ser usada pelos pods em execução está disponível para atribuição se um dos pods precisar de expansão.

  O modo automático também adiciona um buffer predefinido à capacidade de expansão para que os pods do sistema no nó que excedam os respetivos pedidos não afetem os seus próprios pods de expansão.

• Clusters padrão: a capacidade de recursos alocáveis do nó, que é a capacidade disponível para utilização da carga de trabalho. Para ver detalhes , consulte o artigo Recursos atribuíveis do nó.

Práticas recomendadas para o envio rápido

Use as seguintes práticas com a expansão de pods:

• Defina os pedidos de recursos iguais aos limites para todos os pods que forneçam funcionalidades críticas no seu ambiente. Isto garante que esses pods recebem a classe de Guaranteed qualidade de serviço (QoS) do Kubernetes.
• Certifique-se de que só configura o aumento rápido de memória em pods que podem ser despejados quando o Kubernetes precisa de recuperar memória no nó.
• Peça sempre memória suficiente para o Pod arrancar. Não dependa da sobrecarga de memória para cumprir os requisitos de arranque.
• Para evitar que os agrupamentos com capacidade de expansão que expandem consistentemente os respetivos pedidos de CPU em múltiplos possam interromper as cargas de trabalho críticas, use a separação de cargas de trabalho para evitar colocar esses agrupamentos juntamente com os agrupamentos críticos.

Otimize a capacidade de expansão em nós do Autopilot

O Autopilot calcula a capacidade de expansão como a soma dos pedidos de recursos de todos os pods num nó específico, incluindo os pods do sistema e os DaemonSets. Pode otimizar a capacidade de expansão num nó das seguintes formas. No entanto, o aumento rápido é oportunista e não é garantido.

• Para aumentar a capacidade de burst nos nós para cargas de trabalho específicas, use a afinidade de pods para colocar pods específicos juntos no mesmo nó.
• Para garantir que uma capacidade de expansão específica está sempre disponível em todos os nós, crie DaemonSets para serem executados em todos os nós no cluster.

Exemplo de como funciona o envio rápido

Esta secção usa uma implementação de exemplo com os seguintes pods expansíveis para demonstrar como a expansão de pods funciona nos clusters do GKE Autopilot:

• O pod 1 pede 250 m de CPU e não tem limite de CPU. O pod 1 usa 100 m de CPU para ser executado.
• O pod 2 pede 200 m de CPU e tem um limite de 250 m de CPU. O pod 2 usa 100 m de CPU para ser executado.

Ambos os pods são executados no mesmo nó. A capacidade de expansão total no nó é de 450 m de CPU (a soma dos pedidos de recursos). Cada pod usa apenas 100 m de CPU para ser executado, o que significa que o nó tem uma capacidade de expansão disponível restante de 250 m.

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

• O pod 1 precisa de mais 300 m de CPU: pode aumentar e usar 250 m de CPU, que é a capacidade de aumento disponível. O nó já não tem capacidade expansível disponível.
• O pod 2 precisa de mais 150 m de CPU: pode aumentar o consumo e usar mais 150 m de CPU. O nó tem então 100 m de CPU restantes da capacidade de expansão disponível.
• O pod 2 precisa de mais 200 m de CPU: pode ter um pico e usar 150 m de CPU, o que eleva a utilização 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 limite.

Como o GKE processa pods que excedem a capacidade de expansão

Se os pods com capacidade de expansão tentarem usar mais recursos do que a capacidade de expansão no nó, o GKE toma as seguintes medidas:

• CPU: se a utilização da CPU exceder a capacidade de pico, o GKE limita a utilização da CPU de alguns contentores para que todos os contentores no nó recebam a CPU que pedem.
• Memória: se a utilização de memória exceder a capacidade de expansão, o GKE termina os contentores para recuperar memória no nó. O GKE começa por terminar os contentores com utilização intensiva de recursos em pods com uma QoS inferior.

Recomendamos que peça sempre memória suficiente para o funcionamento normal do pod. Se um contentor tiver uma dependência de picos de memória para funcionar normalmente, pode falhar repetidamente se essa memória não estiver disponível.

Use o aumento rápido de pods com o aprovisionamento de capacidade adicional

O GKE permite-lhe implementar pods inativos para reservar capacidade de computação adicional para um escalamento de pods mais rápido durante eventos futuros de tráfego elevado, como promoções relâmpago de lojas online. Outros pods no mesmo nó podem usar esta capacidade reservada não utilizada para que a capacidade não fique inativa no período que antecede o seu evento de tráfego elevado. Pode reservar esta capacidade através de vários mecanismos do Kubernetes. Por exemplo, pode implementar pods com uma PriorityClass baixa. Para mais detalhes, consulte o artigo Aprovisione capacidade de computação adicional para o escalamento rápido de pods.

Aumento rápido de pods em clusters padrão do GKE

Os clusters padrão do GKE também suportam o aumento rápido de pods definindo os limites acima dos pedidos ou omitindo os limites. No entanto, nos clusters padrão, tem de criar e configurar pools de nós com a capacidade de recursos adequada para suportar o aumento repentino. A obtenção da potencial redução de custos dos pods com capacidade de expansão em clusters padrão requer um planeamento de nós mais cuidadoso e o bin-packing de pods, porque paga pelas VMs do Compute Engine subjacentes.

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 de recursos atribuível no nó. Para determinar este valor, consulte o artigo Planeie os tamanhos dos nós do GKE Standard.

• A utilização de recursos dos nós em clusters Standard tem maior probabilidade de atingir um limite de remoção do Kubernetes porque o GKE não limita automaticamente o consumo de recursos se não especificar limites. Por conseguinte, é mais provável que os pods que entram em memória sejam terminados pela remoção por pressão do nó do Kubernetes.

O que se segue?

• Aprovisione capacidade de computação adicional para o escalamento rápido de pods
• Ajuste o tamanho das suas cargas de trabalho do GKE Standard em grande escala