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 | Resource | Solicitação padrão |
---|---|---|
Uso geral (padrão) | CPU | 0,5 vCPU |
Memória | 2 GiB | |
Accelerator | Consulte a seção Recursos padrão para aceleradores. | |
Equilibrada | 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 aceleradores
A tabela a seguir descreve os valores padrão que o GKE atribui aos pods que não especificam valores no campo requests
da especificação do pod. Esta tabela se aplica a pods que usam a classe de computação
Accelerator
, que é a maneira recomendada de executar aceleradores em clusters
do Autopilot.
Accelerator | Resource | Total de solicitação padrão |
---|---|---|
GPUs NVIDIA H100 (80GB)nvidia-h100-80gb |
CPU |
|
Memória |
|
|
Armazenamento temporário |
|
|
GPUs NVIDIA A100 (40 GB)nvidia-tesla-a100 |
CPU |
|
Memória |
|
|
GPUs NVIDIA A100 (80 GB)nvidia-a100-80gb |
CPU |
|
Memória |
|
|
Armazenamento temporário |
|
|
GPUs NVIDIA L4nvidia-l4 |
CPU |
|
Memória |
|
|
GPUs NVIDIA T4nvidia-tesla-t4 |
CPU |
|
Memória |
|
|
TPU v5etpu-v5-lite-device (host único) |
CPU | Todas as topologias: 1 mCPU |
Memória | Todas as topologias: 1 MiB | |
TPU v5etpu-v5-lite-podslice (vários hosts) |
CPU | Todas as topologias: 1 mCPU |
Memória | Todas as topologias: 1 MiB | |
TPU v5ptpu-v5p-slice |
CPU | Todas as topologias: 1 mCPU |
Memória | Todas as topologias: 1 MiB | |
TPU v4tpu-v4-podslice |
CPU | Todas as topologias: 1 mCPU |
Memória | Todas as topologias: 1 MiB |
GPUs compatíveis sem a classe de computação Accelerator
Se você não usar a classe de computação do Accelerator, apenas as GPUs a seguir serão compatíveis. As solicitações de recursos padrão para essas GPUs são as mesmas da classe de computação do Accelerator:
- NVIDIA A100 (40 GB)
- NVIDIA A100 (80 GB)
- NVIDIA L4
- NVIDIA Tesla T4
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 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 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 | ||
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 | 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 aceleradores
As seções a seguir descrevem a proporção mínima, máxima e permitida de CPU para memória para pods que usam aceleradores de hardware, como GPUs e TPUs.
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.
Mínimos e máximos para a classe de computação do Accelerator
A tabela a seguir mostra as solicitações mínima e máxima de recursos para pods que usam a classe de computação do Accelerator, que é a maneira recomendada de executar aceleradores com clusters do Autopilot do GKE. Na classe de computação do Accelerator, o GKE não impõe proporções de solicitação de CPU para memória.
Tipo de acelerador | Resource | Mínimo | Máxima |
---|---|---|---|
NVIDIA H100 (80GB)nvidia-h100-80gb |
CPU |
|
|
Memória |
|
|
|
Armazenamento temporário |
|
|
|
NVIDIA A100 (40GB)nvidia-tesla-a100 |
CPU | 0.001 vCPU |
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 | 1 MiB |
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 | 0.001 vCPU |
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 | 1 MiB |
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 | 512 MiB |
|
|
NVIDIA L4nvidia-l4 |
CPU | 0.001 vCPU |
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 | 1 MiB |
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 | 0.001 vCPU |
|
Memória | 1 MiB |
|
|
TPU v5etpu-v5-lite-device |
CPU | 0.001 vCPU |
|
Memória | 1 MiB |
|
|
Armazenamento temporário | 10 MiB | 56 TiB | |
TPU v5etpu-v5-lite-podslice |
CPU | 0.001 vCPU |
|
Memória | 1 MiB |
|
|
Armazenamento temporário | 10 MiB | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 0.001 vCPU | 280 vCPU |
Memória | 1 MiB | 448 GiB | |
Armazenamento temporário | 10 MiB | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 0.001 vCPU | 240 vCPU |
Memória | 1 MiB | 407 GiB | |
Armazenamento temporário | 10 MiB | 56 TiB |
Para saber como solicitar GPUs nos pods do Autopilot, consulte Implantar cargas de trabalho da GPU no Autopilot.
Mínimos e máximos para GPUs sem uma classe de computação
A tabela a seguir mostra as solicitações mínima e máxima de recursos para pods que não usam a classe de computação do Accelerator:
Tipo de GPU | Proporção de CPU:memória (vCPU:GiB) | Resource | Mínimo | Máxima |
---|---|---|---|---|
NVIDIA A100 (40GB)nvidia-tesla-a100 |
Não aplicado | 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. |
||
NVIDIA A100 (80GB)nvidia-a100-80gb |
Não aplicado | 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 |
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 | 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 |
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.