Solicitações de recursos no Autopilot


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:

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
  • Série de máquinas C3: 2 vCPUs
  • Série de máquinas C3 com SSD local: 2 vCPUs
  • Série de máquinas C3D: 2 vCPUs
  • Série de máquinas C3D com SSD local: 4 vCPUs
  • Série de máquinas H3: 80 vCPU
  • Série de máquinas C2: 2 vCPUs
  • Série de máquinas C2D: 2 vCPUs
  • Série de máquinas T2A: 2 vCPUs
  • Série de máquinas T2D: 2 vCPUs
Memória
  • Série de máquinas C3: 8 GiB
  • Série de máquinas C3 com SSD local: 8 GiB
  • Série de máquinas C3D: 8 GiB
  • Série de máquinas C3D com SSD local: 16 GiB
  • Série de máquinas H3: 320 GiB
  • Série de máquinas C2: 8 GiB
  • Série de máquinas C2D: 8 GiB
  • Série de máquinas T2A: 8 GiB
  • Série de máquinas T2D: 8 GiB
Armazenamento temporário
  • Série de máquinas C3: 1 GiB
  • Série de máquinas C3 com SSD local: 1 GiB
  • Série de máquinas C3D: 1 GiB
  • Série de máquinas C3D com SSD local: 1 GiB
  • Série de máquinas H3: 1 GiB
  • Série de máquinas C2: 1 GiB
  • Série de máquinas C2D: 1 GiB
  • Série de máquinas T2A: 1 GiB
  • Série de máquinas T2D: 1 GiB
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
  • 8 GPUs: 200 vCPU
Memória
  • 8 GPUs: 1400 GiB
Armazenamento temporário
  • 8 GPUs: 1 GiB
GPUs NVIDIA A100 (40 GB)
nvidia-tesla-a100
CPU
  • 1 GPU: 9 vCPUs
  • 2 GPUs: 20 vCPUs
  • 4 GPUs: 44 vCPUs
  • 8 GPUs: 92 vCPUs
  • 16 GPUs: 92 vCPUs
Memória
  • 1 GPU: 60 GiB
  • 2 GPUs: 134 GiB
  • 4 GPUs: 296 GiB
  • 8 GPUs: 618 GiB
  • 16 GPUs: 1.250 GiB
GPUs NVIDIA A100 (80 GB)
nvidia-a100-80gb
CPU
  • 1 GPU: 9 vCPUs
  • 2 GPUs: 20 vCPUs
  • 4 GPUs: 44 vCPUs
  • 8 GPUs: 92 vCPUs
Memória
  • 1 GPU: 134 GiB
  • 2 GPUs: 296 GiB
  • 4 GPUs: 618 GiB
  • 8 GPUs: 1.250 GiB
Armazenamento temporário
  • 1 GPU: 1 GiB
  • 2 GPUs: 1 GiB
  • 4 GPUs: 1 GiB
  • 8 GPUs: 1 GiB
GPUs NVIDIA L4
nvidia-l4
CPU
  • 1 GPU: 2 vCPU
  • 2 GPUs: 21 vCPU
  • 4 GPUs: 45 vCPU
  • 8 GPUs: 93 vCPU
Memória
  • 1 GPU: 7 GiB
  • 2 GPUs: 78 GiB
  • 4 GPUs: 170 GiB
  • 8 GPUs: 355 GiB
GPUs NVIDIA T4
nvidia-tesla-t4
CPU
  • 1 GPU: 0.5 vCPU
  • 8 GPUs: 0.5 vCPU
Memória
  • 1 GPU: 2 GiB
  • 4 GPUs: 2 GiB
TPU v5e
tpu-v5-lite-device (host único)
CPU Todas as topologias: 1 mCPU
Memória Todas as topologias: 1 MiB
TPU v5e
tpu-v5-lite-podslice (vários hosts)
CPU Todas as topologias: 1 mCPU
Memória Todas as topologias: 1 MiB
TPU v5p
tpu-v5p-slice
CPU Todas as topologias: 1 mCPU
Memória Todas as topologias: 1 MiB
TPU v4
tpu-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:

  • Clusters compatíveis com bursting: 50 m CPU
  • Clusters que não são compatíveis com bursting: 250 m CPU

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:

  • Clusters compatíveis com bursting: 52 MiB
  • Clusters que não são compatíveis com bursting: 512 MiB

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:

  • Plataformas Intel: 126 vCPU
  • Plataformas AMD: 222 vCPU
Memória 0,5 GiB

851 GiB

Se a plataforma mínima de CPU for selecionada:

  • Plataformas Intel: 823 GiB
  • Plataformas AMD: 851 GiB
Desempenho N/A CPU 0.001 vCPU
  • Série de máquinas C3: 174 vCPUs
  • Série de máquinas C3 com SSD local: 174 vCPUs
  • Série de máquinas C3D: 358 vCPUs
  • Série de máquinas C3D com SSD local: 358 vCPUs
  • Série de máquinas H3: 86 vCPUs
  • Série de máquinas C2: 58 vCPUs
  • Série de máquinas C2D: 110 vCPUs
  • Série de máquinas T2A: 46 vCPUs
  • Série de máquinas T2D: 58 vCPUs
Memória 1 MiB
  • Série de máquinas C3: 1.345 GiB
  • Série de máquinas C3 com SSD local: 670 GiB
  • Série de máquinas C3D: 2.750 GiB
  • Série de máquinas C3D com SSD local: 1.375 GiB
  • Série de máquinas H3: 330 GiB
  • Série de máquinas C2: 218 GiB
  • Série de máquinas C2D: 835 GiB
  • Série de máquinas T2A: 172 GiB
  • Série de máquinas T2D: 218 GiB
Armazenamento temporário 10 MiB
  • Série de máquinas C3: 250 GiB
  • Série de máquinas C3 com SSD local: 10.000 GiB
  • Série de máquinas C3D: 250 GiB
  • Série de máquinas C3D com SSD local: 10.000 GiB
  • Série de máquinas H3: 250 GiB
  • Série de máquinas C2: 250 GiB
  • Série de máquinas C2D: 250 GiB
  • Série de máquinas T2A: 250 GiB
  • Série de máquinas T2D: 250 GiB
Escalonar horizontalmente 1:4 CPU 0,25 vCPU
  • arm64: 43 vCPU
  • amd64: 54 vCPU
Memória 1 GiB
  • arm64: 172 GiB
  • amd64: 216 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
  • 8 GPUs: 0,001 vCPU
  • 8 GPUs: 206 vCPU
Memória
  • 8 GPUs: 1 MiB
  • 8 GPUs: 1795 GiB
Armazenamento temporário
  • 8 GPU: 10 MiB
  • 8 GPUs: 5250 GiB
NVIDIA A100 (40GB)
nvidia-tesla-a100
CPU 0.001 vCPU
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 vCPU
  • 16 GPUs: 94 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
  • 1 GPU: 74 GiB
  • 2 GPUs: 148 GiB
  • 4 GPUs: 310 GiB
  • 8 GPUs: 632 GiB
  • 16 GPUs: 1264 GiB

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
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 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
  • 1 GPU: 148 GiB
  • 2 GPUs: 310 GiB
  • 4 GPUs: 632 GiB
  • 8 GPUs: 1.264 GiB

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
  • 1 GPU: 280 GiB
  • 2 GPUs: 585 GiB
  • 4 GPUs: 1220 GiB
  • 8 GPUs: 2540 GiB
NVIDIA L4
nvidia-l4
CPU 0.001 vCPU
  • 1 GPU: 31 vCPU
  • 2 GPUs: 23 vCPU
  • 4 GPUs: 47 vCPU
  • 8 GPUs: 95 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
  • 1 GPU: 115 GiB
  • 2 GPUs: 86 GiB
  • 4 GPUs: 177 GiB
  • 8 GPUs: 363 GiB

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 T4
nvidia-tesla-t4
CPU 0.001 vCPU
  • 1 GPU: 46 vCPU
  • 2 GPUs: 46 vCPU
  • 4 GPUs: 94 vCPU
Memória 1 MiB
  • 1 GPU: 287,5 GiB
  • 2 GPUs: 287,5 GiB
  • 4 GPUs: 587,5 GiB
TPU v5e
tpu-v5-lite-device
CPU 0.001 vCPU
  • Topologia 1 x 1: 24 vCPUs
  • Topologia 2 x 2: 112 vCPUs
  • Topologia 2x4: 224 vCPUs
Memória 1 MiB
  • Topologia 1 x 1: 48 GiB
  • Topologia 2x2: 192 GiB
  • Topologia 2x4: 384 GiB
Armazenamento temporário 10 MiB 56 TiB
TPU v5e
tpu-v5-lite-podslice
CPU 0.001 vCPU
  • Topologia 1 x 1: 24 vCPUs
  • Topologia 2 x 2: 112 vCPUs
  • Topologia 2x4 (solicitação de 4 chips): 112 vCPUs
  • Topologia 2x4 (solicitação de 8 chips): 224 vCPUs
  • Topologia 4x4: 112 vCPUs
  • Topologia 4x8: 112 vCPUs
  • Topologia 8x8: 112 vCPUs
  • Topologia 8x16: 112 vCPUs
  • Topologia 16x16: 112 vCPUs
Memória 1 MiB
  • Topologia 1 x 1: 48 GiB
  • Topologia 2x2: 192 GiB
  • Topologia 2x4 (solicitação de 4 chips): 192 GiB
  • Topologia 2x4 (solicitação de 8 chips): 384 GiB
  • Topologia 4x4: 192 GiB
  • Topologia 4x8: 192 GiB
  • Topologia 8x8: 192 GiB
  • Topologia 8x16: 192 GiB
  • Topologia de 16x16: 192 GiB
Armazenamento temporário 10 MiB 56 TiB
TPU v5p
tpu-v5p-slice
CPU 0.001 vCPU 280 vCPU
Memória 1 MiB 448 GiB
Armazenamento temporário 10 MiB 56 TiB
TPU v4
tpu-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
  • 1 GPU: 9 vCPUs
  • 2 GPUs: 20 vCPUs
  • 4 GPUs: 44 vCPUs
  • 8 GPUs: 92 vCPUs
  • 16 GPUs: 92 vCPUs
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 vCPU
  • 16 GPUs: 94 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 GPU: 60 GiB
  • 2 GPUs: 134 GiB
  • 4 GPUs: 296 GiB
  • 8 GPUs: 618 GiB
  • 16 GPUs: 1.250 GiB
  • 1 GPU: 74 GiB
  • 2 GPUs: 148 GiB
  • 4 GPUs: 310 GiB
  • 8 GPUs: 632 GiB
  • 16 GPUs: 1264 GiB

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
  • 1 GPU: 9 vCPUs
  • 2 GPUs: 20 vCPUs
  • 4 GPUs: 44 vCPUs
  • 8 GPUs: 92 vCPUs
  • 1 GPU: 11 vCPU
  • 2 GPUs: 22 vCPU
  • 4 GPUs: 46 vCPU
  • 8 GPUs: 94 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 GPU: 134 GiB
  • 2 GPUs: 296 GiB
  • 4 GPUs: 618 GiB
  • 8 GPUs: 1.250 GiB
  • 1 GPU: 148 GiB
  • 2 GPUs: 310 GiB
  • 4 GPUs: 632 GiB
  • 8 GPUs: 1.264 GiB

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
  • 1 GPU: 512 MiB
  • 2 GPUs: 512 MiB
  • 4 GPUs: 512 MiB
  • 8 GPUs: 512 MiB
  • 1 GPU: 280 GiB
  • 2 GPUs: 585 GiB
  • 4 GPUs: 1220 GiB
  • 8 GPUs: 2540 GiB
NVIDIA L4
nvidia-l4
  • 1 GPU: entre 1:3,5 e 1:4
  • 2, 4 e 8 GPUs: não aplicado
CPU
  • 1 GPU: 2 vCPU
  • 2 GPUs: 21 vCPU
  • 4 GPUs: 45 vCPU
  • 8 GPUs: 93 vCPU
  • 1 GPU: 31 vCPU
  • 2 GPUs: 23 vCPU
  • 4 GPUs: 47 vCPU
  • 8 GPUs: 95 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 GPU: 7 GiB
  • 2 GPUs: 78 GiB
  • 4 GPUs: 170 GiB
  • 8 GPUs: 355 GiB
  • 1 GPU: 115 GiB
  • 2 GPUs: 86 GiB
  • 4 GPUs: 177 GiB
  • 8 GPUs: 363 GiB

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 T4
nvidia-tesla-t4
Entre 1:1 e 1:6.25 CPU 0,5 vCPU
  • 1 GPU: 46 vCPU
  • 2 GPUs: 46 vCPU
  • 4 GPUs: 94 vCPU
Memória 0,5 GiB
  • 1 GPU: 287,5 GiB
  • 2 GPUs: 287,5 GiB
  • 4 GPUs: 587,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:

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 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:

  • Clusters compatíveis com bursting: os pods podem fazer bursts para atingir a capacidade de burst disponível.
  • Clusters que não são compatíveis com bursting: o GKE define limits como igual a requests

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:

  • Clusters compatíveis com bursting: os pods podem fazer bursts até o valor especificado em limits.
  • Clusters que não são compatíveis com bursting: o GKE define limits como igual a requests

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 requests como os valores padrão para a classe de computação ou a configuração de hardware.

O comportamento de limits depende da compatibilidade do cluster com burst, da seguinte maneira:

  • Clusters compatíveis com bursting: o Autopilot não define limits.
  • Clusters que não são compatíveis com bursting: o GKE define limits como igual a requests

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