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:
Disponibilidade de bursting | |
---|---|
Modo Autopilot do GKE | Os seguintes tipos de pods podem usar bursts em qualquer versão do GKE que seja compatível com o hardware solicitado pelos pods: Para todos os outros tipos de pods, o bursting fica disponível quando você reinicia o plano de controle depois de garantir que o cluster atenda a todas as condições a seguir:
Para mais detalhes, consulte Limitações. |
Modo GKE Standard | É possível usar bursts nos pods em qualquer versão do GKE. |
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:
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.
Confirme se o cluster executa cgroupv2. Para instruções, consulte Verificar o modo cgroup.
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
ouBalanced
. - 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
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
espec.tolerations
: opcional. Adicione esses campos com rótulos personalizados, comopod-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.
Implantar a carga de trabalho:
kubectl apply -f burstable-deployment.yaml
A inicialização da carga de trabalho pode levar alguns minutos.
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.