Para melhorar a estabilidade da carga de trabalho, o modo Autopilot do Google Kubernetes Engine (GKE) gerencia os valores das solicitações de recursos do pod, como CPU, memória ou armazenamento temporário. Esta página inclui as seguintes informações, que podem ser usadas para planejar cargas de trabalho eficientes, estáveis e econômicas:
- Valores padrão que o Autopilot aplica a pods que não especificam valores.
- Valores mínimos e máximos que o Autopilot aplica para solicitações de recursos.
- Como os valores padrão, mínimo e máximo variam de acordo com o hardware solicitado pelos pods.
Esta página é destinada a operadores e desenvolvedores que provisionam e configuram recursos de nuvem e implantam cargas de trabalho. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE.
Você já precisa conhecer o gerenciamento de recursos do Kubernetes.
Visão geral das solicitações de recursos no Autopilot
O Autopilot usa as solicitações de recurso especificadas na configuração da carga de trabalho para configurar os nós que executam as cargas de trabalho. O Autopilot impõe solicitações mínimas e máximas de recursos com base na classe de computação ou na configuração de hardware usada pelas suas cargas de trabalho. Se você não especificar solicitações para alguns contêineres, o Autopilot vai atribuir valores padrão a fim de permitir que eles sejam executados corretamente.
Quando você implanta uma carga de trabalho em um cluster do Autopilot, o GKE valida a configuração da carga de trabalho com os valores mínimos e máximos permitidos para a classe de computação ou a configuração de hardware selecionadas (como GPUs). Se as solicitações forem menores que o mínimo, o Autopilot modificará automaticamente a configuração da carga de trabalho para colocar as solicitações no intervalo permitido. Se as solicitações forem maiores que o máximo, o Autopilot rejeitará a carga de trabalho e exibirá uma mensagem de erro.
A lista a seguir resume as categorias das solicitações de recursos:
- Solicitações de recursos padrão: o Autopilot os adicionará se você não especificar suas próprias solicitações para cargas de trabalho.
- Solicitações de recursos mínimas e máximas: o Autopilot valida suas solicitações especificadas para garantir que elas estejam dentro desses limites. Se as solicitações estiverem fora dos limites, o Autopilot modificará as solicitações da carga de trabalho.
- Separação da carga de trabalho e solicitações de duração estendida: o Autopilot tem valores padrão e valores mínimos distintos para cargas de trabalho separadas umas das outras ou para pods que recebem proteção estendida da remoção iniciada pelo GKE.
- Solicitações de recursos para DaemonSets: o Autopilot tem valores padrão, mínimo e máximo diferentes para contêineres em DaemonSets.
Como solicitar recursos
No Autopilot, você solicita recursos na especificação do pod. Os recursos mínimos e máximos compatíveis que você pode solicitar mudam com base na configuração de hardware do nó em que os pods são executados. Para saber como solicitar configurações de hardware específicas, consulte as seguintes páginas:
- Escolher classes de computação para pods do Autopilot
- Implantar cargas de trabalho da GPU no Autopilot
Solicitações de recursos padrão
Se você não especificar solicitações de recurso para alguns contêineres em um pod, o Autopilot vai aplicar os valores padrão. Esses padrões são adequados para muitas cargas de trabalho menores.
Além disso, o Autopilot aplica as seguintes solicitações de recursos padrão, independentemente da classe de computação ou da configuração de hardware selecionada:
Contêineres em DaemonSets
- CPU: 50 mCPU
- Memória: 100 MiB
- Armazenamento temporário: 100 MiB
Todos os outros contêineres
- Armazenamento temporário: 1 GiB
Para mais informações sobre os limites do cluster do Autopilot, consulte Cotas e limites.
Solicitações padrão para classes de computação
O Autopilot aplica os seguintes valores padrão aos recursos que não são definidos na especificação do pod para pods executados em classes de computação. Se você definir apenas uma das solicitações e deixar a outra em branco, o GKE usará a proporção CPU:memória definida na seção Solicitações mínimas e máximas para definir a solicitação ausente com um valor de acordo com a proporção.
| Classe de computação | Resource | Solicitação padrão |
|---|---|---|
| Uso geral (padrão) | CPU | 0,5 vCPU |
| Memória | 2 GiB | |
| Accelerator | Nenhuma solicitação padrão aplicada. | |
| Equilibrada | CPU | 0,5 vCPU |
| Memória | 2 GiB | |
| Desempenho | Nenhuma solicitação padrão aplicada. | |
| Escalonar horizontalmente | CPU | 0,5 vCPU |
| Memória | 2 GiB | |
Solicitações de recursos mínimas e máximas
Os recursos totais solicitados pela configuração de implantação precisam estar dentro dos valores mínimos e máximos compatíveis com o Autopilot. Aplicam-se as seguintes condições:
Solicitações de armazenamento temporário:
O armazenamento temporário usa o disco de inicialização da VM, a menos que os nós tenham SSDs locais anexados.
O hardware de computação que inclui SSDs locais, como GPUs A100 (80 GB), H100 (80 GB) ou a série de máquinas Z3, aceita uma solicitação máxima igual ao tamanho do SSD local menos qualquer sobrecarga do sistema. Para informações sobre essa sobrecarga do sistema, consulte Armazenamento temporário com suporte de SSDs locais.
Na versão 1.29.3-gke.1038000 e mais recentes do GKE, os pods de classe de desempenho e os pods de acelerador de hardware aceitam uma solicitação máxima de armazenamento temporário de 56 TiB, a menos que o hardware inclua SSDs locais.
Em todos os outros pods do Autopilot, independente da versão do GKE, a solicitação total de armazenamento temporário em todos os contêineres no pod precisa estar entre 10 MiB e 10 GiB, a menos que especificado de outra forma.
Para volumes maiores, use volumes temporários genéricos, que oferecem funcionalidade e desempenho equivalentes ao armazenamento temporário, mas com muito mais flexibilidade, já que podem ser usados com qualquer opção de armazenamento do GKE. Por exemplo, o tamanho máximo de um volume temporário genérico usando
pd-balancedé 64 TiB.
Para pods de DaemonSet, as solicitações mínimas de recursos são as seguintes:
- Clusters compatíveis com bursting: 1 mCPU por pod, 2 MiB de memória por pod e 10 MiB de armazenamento temporário por contêiner no pod.
- Clusters sem suporte a bursting: 10 mCPU por pod, 10 MiB de memória por pod e 10 MiB de armazenamento temporário por contêiner no pod.
Para verificar se o cluster é compatível com bursting, consulte Disponibilidade de bursting no GKE.
Se o cluster for compatível com bursting, o Autopilot não vai exigir incrementos de 0,25 vCPU para as solicitações de CPU do pod. Se o cluster não for compatível com bursting, o Autopilot vai arredondar as solicitações de CPU para o 0,25 vCPU mais próximo. Para verificar se o cluster é compatível com bursting, consulte Disponibilidade de bursting no GKE.
A proporção de CPU:memória precisa estar dentro do intervalo permitido para a classe de computação ou a configuração de hardware selecionada. Se a proporção CPU:memória estiver fora do intervalo permitido, o Autopilot vai aumentar automaticamente o recurso menor. Por exemplo, se você solicitar 1 vCPU e 16 GiB de memória (proporção de 1:16) para pods em execução na classe
Scale-Out, o Autopilot aumentará a solicitação de CPU para 4 vCPUs, o que mudará a proporção para 1:4.
Mínimos e máximos para classes de computação
A tabela a seguir descreve a proporção mínima, máxima e permitida de CPU para memória para cada classe de computação compatível com o Autopilot:
| Classe de computação | Proporção de CPU:memória (vCPU:GiB) | Resource | Mínimo | Máxima |
|---|---|---|---|---|
| Uso geral (padrão) | Entre 1:1 e 1:6.5 | CPU | O valor depende da compatibilidade do cluster com burst, da seguinte maneira:
Para verificar se o cluster é compatível com bursting, consulte Disponibilidade de bursting no GKE. |
30 vCPUs |
| Memória | O valor depende da compatibilidade do cluster com burst, da seguinte maneira:
Para verificar se o cluster é compatível com bursting, consulte Disponibilidade de bursting no GKE. |
110 GiB | ||
| Accelerator | Consulte Mínimos e máximos para aceleradores. | |||
| Equilibrada | Entre 1:1 e 1:8 | CPU | 0,25 vCPU | 222 vCPU Se a plataforma mínima de CPU for selecionada:
|
| Memória | 0,5 GiB | 851 GiB Se a plataforma mínima de CPU for selecionada:
|
||
| Desempenho | N/A | CPU | Nenhum mínimo de solicitações aplicado |
|
| Memória | Nenhum mínimo de solicitações aplicado |
|
||
| Armazenamento temporário | Nenhum mínimo de solicitações aplicado |
|
||
| Escalonar horizontalmente | Exatamente 1:4 | CPU | 0,25 vCPU |
|
| Memória | 1 GiB |
|
||
Para saber como solicitar classes de computação nos pods do Autopilot, consulte Escolher classes de computação para pods do Autopilot.
Mínimos e máximos para aceleradores
O GKE não impõe solicitações mínimas de CPU, memória ou armazenamento temporário para pods que usam aceleradores. A tabela a seguir descreve o número máximo de solicitações para cada um desses recursos com base no número e no tipo de acelerador usado.
A menos que seja especificado, o armazenamento temporário máximo aceito é de 56 TiB.
| Tipo de acelerador | Recurso | Máximo |
|---|---|---|
NVIDIA B200nvidia-B200 |
CPU |
|
| Memória |
|
|
| Armazenamento temporário |
|
|
NVIDIA H200 (141GB)nvidia-h200-141gb |
CPU |
|
| Memória |
|
|
| Armazenamento temporário |
|
|
NVIDIA H100 Mega (80GB)nvidia-h100-mega-80gb |
CPU |
|
| Memória |
|
|
| Armazenamento temporário |
|
|
NVIDIA H100 (80GB)nvidia-h100-80gb |
CPU |
|
| Memória |
|
|
| Armazenamento temporário |
|
|
NVIDIA A100 (40GB)nvidia-tesla-a100 |
CPU |
A soma das solicitações de CPU de todos os DaemonSets executados em um nó de GPU A100 não pode exceder 2 vCPUs. |
| Memória |
A soma das solicitações de memória de todos os DaemonSets executados em um nó de GPU A100 não pode exceder 14 GiB. |
|
NVIDIA A100 (80GB)nvidia-a100-80gb |
CPU |
A soma das solicitações de CPU de todos os DaemonSets executados em um nó de GPU A100 (80 GB) não pode exceder 2 vCPU. |
| Memória |
A soma das solicitações de memória de todos os DaemonSets executados em um nó de GPU A100 (80 GB) não pode exceder 14 GiB. |
|
| Armazenamento temporário |
|
|
NVIDIA L4nvidia-l4 |
CPU |
A soma das solicitações de CPU de todos os DaemonSets executados em um nó de GPU L4 não pode exceder 2 vCPUs. |
| Memória |
A soma das solicitações de memória de todos os DaemonSets executados em um nó de GPU L4 não pode exceder 14 GiB. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
| Memória |
|
|
TPU v5etpu-v5-lite-podslice |
CPU |
|
| Memória |
|
|
| Armazenamento temporário | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 280 vCPU |
| Memória | 448 GiB | |
| Armazenamento temporário | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 240 vCPU |
| Memória | 407 GiB | |
| Armazenamento temporário | 56 TiB |
Para saber como solicitar GPUs nos pods do Autopilot, consulte Implantar cargas de trabalho da GPU no Autopilot.
Solicitações de recursos para separação da carga de trabalho e duração estendida
O Autopilot permite manipular o comportamento de programação e remoção do Kubernetes usando métodos como os seguintes:
- Use taints e tolerâncias e seletores de nó para garantir que determinados pods sejam colocados apenas em nós específicos. Para obter detalhes, consulte Configurar a separação de cargas de trabalho no GKE.
- Use a antiafinidade de pods para impedir que os pods sejam colocalizados no mesmo nó. As solicitações de recurso padrão e mínimo para cargas de trabalho que usam esses métodos para controlar o comportamento da programação são maiores do que as cargas de trabalho que não as usam.
- Use uma anotação para proteger os pods contra remoção causada por upgrades automáticos de nós e eventos de redução de escala vertical por até sete dias. Para mais detalhes, consulte Estender o ambiente de execução dos pods do Autopilot.
Se as solicitações especificadas forem menores que o valor mínimo, o comportamento do Autopilot mudará com base no método usado, da seguinte maneira:
- Taints, tolerâncias, seletores e pods de duração estendida: o Autopilot modifica seus pods para aumentar as solicitações ao programá-los.
- Antiafinidade de pods: o Autopilot rejeita o pod e exibe uma mensagem de erro.
A tabela a seguir descreve as solicitações padrão e as solicitações de recursos mínimos que você pode especificar. Se uma configuração ou classe de computação não estiver nesta tabela, o Autopilot não aplicará valores mínimos ou padrão especiais.
| Classe de computação | Resource | Padrão | Mínimo |
|---|---|---|---|
| Uso geral | CPU | 0,5 vCPU | 0,5 vCPU |
| Memória | 2 GiB | 0,5 GiB | |
| Equilibrada | CPU | 2 vCPU | 1 vCPU |
| Memória | 8 GiB | 4 GiB | |
| Escalonar horizontalmente | CPU | 0,5 vCPU | 0,5 vCPU |
| Memória | 2 GiB | 2 GiB |
Init containers
Os contêineres
de inicialização
são executados em sequência, e todos precisam terminar a execução antes que os contêineres
de aplicativos possam ser iniciados. Em clusters do Autopilot, se você não especificar solicitações de CPU
ou memória para contêineres de inicialização ou definir explicitamente as solicitações como 0,
o Autopilot modificará seus pods durante a criação para adicionar solicitações de recursos
a cada contêiner de inicialização. As solicitações atribuídas a cada contêiner de inicialização são iguais à soma das solicitações de todos os contêineres de aplicativos no pod. Esse é o comportamento
padrão.
Esse comportamento é diferente dos clusters padrão, em que os contêineres de inicialização usam qualquer recurso não alocado disponível no nó em que o pod está programado.
Alocação automática de recursos para contêineres de inicialização
A alocação automática de recursos para contêineres de inicialização ocorre na criação do pod. Recomendamos que você não especifique manualmente solicitações de recursos para os contêineres de inicialização em clusters do Autopilot. Assim, cada contêiner recebe todos os recursos disponíveis para o pod por padrão.
Se você mudar as solicitações de recursos de contêineres não iniciais no pod após a criação, o Autopilot não vai ajustar automaticamente as solicitações de recursos dos contêineres de inicialização. Como resultado, você pode notar cobranças que não são consistentes com o uso real de recursos do pod. A fatura é baseada na solicitação de recurso efetiva do pod, que é a maior das seguintes opções:
- A maior solicitação de recurso de qualquer contêiner de inicialização no pod.
- A soma das solicitações de todos os contêineres de aplicativos no pod.
Para mais informações, consulte Gerenciamento automático de recursos no Autopilot.
Alocação manual de recursos para contêineres de inicialização
Se você precisar mudar as solicitações de recursos atuais dos contêineres de aplicativos para gerenciar custos e recursos, recomendamos que faça uma das seguintes ações para ajustar as solicitações do contêiner de inicialização:
- Atualize manualmente as solicitações de recursos do contêiner de inicialização para corresponder ao novo total de solicitações no pod. Considere o seguinte ao especificar manualmente as solicitações de recursos:
- Solicitações menores que o total de recursos do pod podem restringir o contêiner de inicialização.
- Solicitações maiores que o total de recursos do pod podem aumentar os custos.
- Remova as solicitações de recursos para permitir que o Autopilot as recalcule. O Autopilot vai realocar os recursos para cada contêiner de inicialização com base no total de recursos solicitados por todos os contêineres de aplicativos no pod.
Como definir limites de recursos no Autopilot
O Kubernetes permite definir requests e limits para recursos na especificação do pod. O comportamento dos pods muda quando as
limits são diferentes de requests, conforme descrito na tabela
a seguir:
| Valores definidos | Comportamento do Autopilot |
|---|---|
requests igual a limits |
Os pods usam a classe QoS Guaranteed.
|
requests definido, limits não definido |
O comportamento depende da compatibilidade do cluster com o burst, da seguinte maneira:
Para verificar se o cluster é compatível com bursting, consulte Disponibilidade de bursting no GKE. |
requests não definido, limits definido |
O Autopilot define requests como o valor
limits, que é o comportamento padrão do Kubernetes.
Antes: resources:
limits:
cpu: "400m"Depois: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests a menos que o hotel limits |
O comportamento depende da compatibilidade do cluster com o burst, da seguinte maneira:
Para verificar se o cluster é compatível com bursting, consulte Disponibilidade de bursting no GKE. |
requests maior que limits |
O Autopilot define requests como o valor
de limits.
Antes: resources:
requests:
cpu: "450m"
limits:
cpu: "400m"Depois: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests não definido, limits não definido |
O Autopilot define O comportamento de
Para verificar se o cluster é compatível com bursting, consulte Disponibilidade de bursting no GKE. |
Na maioria das situações, defina solicitações de recursos adequadas e limites iguais para suas cargas de trabalho.
Para cargas de trabalho que precisam temporariamente de mais recursos do que o estado estável, como durante a inicialização ou durante períodos com tráfego mais alto, defina os limites mais altos que as solicitações para permitir o burst dos pods. Para mais detalhes, acesse Configurar o bursting de pods no GKE.
Gerenciamento automático de recursos no Autopilot
Se as solicitações de recursos especificadas para suas cargas de trabalho estiverem fora dos intervalos permitidos ou se você não solicitar recursos para alguns contêineres, o Autopilot modificará a configuração da carga de trabalho para obedecer aos limites permitidos. O Autopilot calcula taxas de recursos e os requisitos de escalonamento vertical de recursos após aplicar valores padrão a contêineres sem solicitação especificada.
- Solicitações ausentes: se você não solicitar recursos em alguns contêineres, o Autopilot aplicará as solicitações padrão para a classe de computação ou a configuração de hardware.
- Proporção de CPU:memória: o Autopilot escalona o recurso menor para deixar a proporção dentro do intervalo permitido.
- Armazenamento temporário: o Autopilot modifica as solicitações de armazenamento temporário para atender à quantidade mínima exigida por cada contêiner. O valor cumulativo de solicitações de armazenamento em todos os contêineres não pode ser maior que o valor máximo permitido. Antes da versão 1.28.6-gke.1317000, o Autopilot reduzia o escalonamento do armazenamento temporário solicitado se o valor excedesse o máximo. Na versão 1.28.6-gke.1317000 e mais recentes, o Autopilot rejeita sua carga de trabalho.
- Solicitações abaixo do mínimo: se você solicitar menos recursos do que o mínimo permitido para a configuração de hardware selecionada, o Autopilot modificará automaticamente o pod para que solicite pelo menos o valor mínimo de recursos.
Por padrão, quando o Autopilot faz o escalonamento automático de um recurso para cumprir um valor de recursos mínimo ou padrão, o GKE aloca a capacidade extra para o primeiro contêiner no manifesto do pod. No GKE versão 1.27.2-gke.2200 e posterior, é possível instruir o GKE a alocar os recursos extras para um contêiner específico adicionando a linha a seguir ao campo annotations no manifesto do pod:
autopilot.gke.io/primary-container: "CONTAINER_NAME"
Substitua CONTAINER_NAME pelo nome do contêiner.
Exemplos de modificação de recursos
O cenário de exemplo a seguir mostra como o Autopilot modifica a configuração da carga de trabalho para atender aos requisitos dos pods e contêineres em execução.
Contêiner único com menos de 0,05 vCPU
| Número do contêiner | Solicitação original | Solicitação modificada |
|---|---|---|
| 1 |
CPU: 30 mCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
CPU: 50 mCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
Vários contêineres com uma CPU total menor que 0,05 vCPU
| Número do contêiner | Solicitações originais | Solicitações modificadas |
|---|---|---|
| 1 | CPU: 10 mCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
CPU: 30 mCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
| 2 | CPU: 10 mCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
CPU: 10 mCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
| 3 | CPU: 10 mvCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
CPU: 10 mCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
| Recursos totais do pod | CPU: 50 mCPU Memória: 1,5 GiB Armazenamento temporário: 30 MiB |
Contêiner único com memória muito baixa para a CPU solicitada
Neste exemplo, a memória é muito baixa para a quantidade de CPU (mínimo de 1 vCPU:1 GiB). A proporção mínima permitida para CPU para memória é 1:1. Se a proporção for menor que isso, a solicitação de memória aumentará.
| Número do contêiner | Solicitação original | Solicitação modificada |
|---|---|---|
| 1 | CPU: 4 vCPUs Memória: 1 GiB Armazenamento temporário: 10 MiB |
CPU: 4 vCPU Memória: 4 GiB Armazenamento temporário: 10 MiB |
| Recursos totais do pod | CPU: 4 vCPU Memória: 4 GiB Armazenamento temporário: 10 MiB |
A seguir
- Aprenda a selecionar classes de computação nas cargas de trabalho do Autopilot.
- Saiba mais sobre as classes de computação do Autopilot compatíveis.
- Saiba como selecionar GPUs nos pods do Autopilot.