Nesta página, descrevemos as solicitações de recursos máximas, mínimas e padrão que podem ser especificadas para as cargas de trabalho do Autopilot do Google Kubernetes Engine (GKE) e como o Autopilot modifica automaticamente essas solicitações para manter a estabilidade da carga de trabalho.
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 | Recurso | Solicitação padrão |
|---|---|---|
| Uso geral | CPU | 0,5 vCPU |
| Memória | 2 GiB | |
| Equilibrado | CPU | 0,5 vCPU |
| Memória | 2 GiB | |
| Desempenho | CPU |
|
| Memória |
|
|
| Armazenamento temporário |
|
|
| Escalonar horizontalmente | CPU | 0,5 vCPU |
| Memória | 2 GiB |
Solicitações padrão para outras configurações de hardware
O Autopilot aplica os seguintes valores padrão aos recursos que não estão definidos na especificação do pod para pods executados em nós com hardware especializado, como GPUs:
| Hardware | Recurso | Total de solicitação padrão |
|---|---|---|
GPUs H100 (80 GB)nvidia-h100-80gb |
CPU |
|
| Memória |
|
|
| Armazenamento temporário |
|
|
GPUs A100 (40 GB)nvidia-tesla-a100 |
CPU |
|
| Memória |
|
|
GPUs A100 (80 GB)nvidia-a100-80gb |
CPU |
|
| Memória |
|
|
| Armazenamento temporário |
|
|
GPUs L4nvidia-l4 |
CPU |
|
| Memória |
|
|
T4 GPUsnvidia-tesla-t4 |
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:
- A solicitação de armazenamento temporário precisa ter entre 10 MiB e 10 GiB para todas
as classes de computação e configurações de hardware, a menos que especificado de outra forma. Para volumes maiores,
recomendamos o uso de
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.
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 vCPU, 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: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) | Recurso | Mínimo | Máximo |
|---|---|---|---|---|
| Uso geral | 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 vCPU |
| 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 | ||
| Equilibrado | 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 | 0.001 vCPU |
|
| Memória | 1 MiB |
|
||
| Armazenamento temporário | 10 MiB |
|
||
| Escalonar horizontalmente | 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 outras configurações de hardware
A tabela a seguir descreve a proporção mínima, máxima e permitida de CPU:memória para pods executados em nós com um hardware específico, como GPUs. A menos que seja especificado, o armazenamento temporário máximo aceito é de 122 GiB nas versões 1.28.6-gke.1369000 ou mais recentes e 1.29.1-gke.1575000 ou mais recentes. Para versões anteriores, o armazenamento temporário máximo aceito é de 10 GiB.
| Hardware | Proporção de CPU:memória (vCPU:GiB) | Recurso | Mínimo | Máxima |
|---|---|---|---|---|
GPUs H100 (80 GB)nvidia-h100-80gb |
Não aplicada | CPU |
|
|
| Memória |
|
|
||
| Armazenamento temporário |
|
|
||
GPUs A100 (40 GB)nvidia-tesla-a100 |
Não aplicada | CPU |
|
A soma das solicitações de CPU de todos os DaemonSets executados em um nó de GPU A100 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 não pode exceder 14 GiB. |
||
GPUs A100 (80 GB)nvidia-a100-80gb |
Não aplicada | 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 |
|
|
||
GPUs 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. |
||
T4 GPUsnvidia-tesla-t4 |
Entre 1:1 e 1:6.25 | CPU | 0,5 vCPU |
|
| Memória | 0,5 GiB |
|
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 | Recurso | Padrão | Mínimo |
|---|---|---|---|
| Uso geral | CPU | 0,5 vCPU | 0,5 vCPU |
| Memória | 2 GiB | 0,5 GiB | |
| Equilibrado | 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 |
Contêineres init
Os contêineres de inicialização são executados em série e precisam ser concluídos antes que os contêineres do aplicativo sejam iniciados. Se você não especificar solicitações de recursos para os contêineres de inicialização do Autopilot, o GKE vai alocar os recursos disponíveis para o pod a cada contêiner de inicialização. Esse comportamento é diferente do GKE Standard, em que cada contêiner de inicialização pode usar qualquer recurso não alocado disponível no nó em que o pod está programado.
Ao contrário dos contêineres de aplicativos, o GKE recomenda que você não especifique solicitações de recursos para contêineres de inicialização no Autopilot. Assim, cada contêiner recebe os recursos completos disponíveis para o pod. Se você solicitar menos recursos do que os padrões, isso restringe seu contêiner de inicialização. Se você solicitar mais recursos do que os padrões do Autopilot, isso pode aumentar sua fatura durante o ciclo de vida do 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. O Autopilot reduzirá a solicitação se o valor exceder o máximo.
- 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 |
Vários contêineres com mais de 0,25 vCPU no total
Para vários contêineres com recursos totais >= 0,25 vCPU, a CPU é arredondada para múltiplos de 0,25 vCPU, e a CPU extra é adicionada ao primeiro contêiner. Neste exemplo, a CPU cumulativa original é de 0,32 vCPU, e é modificada para um total de 0,5 vCPU.
| Número do contêiner | Solicitações originais | Solicitações modificadas |
|---|---|---|
| 1 | CPU: 0,17 vCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
CPU: 0,35 vCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
| 2 | CPU: 0,08 vCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
CPU: 0,08 vCPU Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
| 3 | CPU: 0,07 vCPUs Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
CPU: 0,07 vCPUs Memória: 0,5 GiB Armazenamento temporário: 10 MiB |
| 4 | Contêiner de inicialização, recursos não definidos | Receberá recursos de pod |
| Recursos totais do pod | CPU: 0,5 vCPU Memória: 1,5 GiB Armazenamento temporário: 30 MiB |
Contêiner único com memória muito baixa para a CPU solicitada
Nesse 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 vCPU 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.