Pedidos de recursos no piloto automático

Para melhorar a estabilidade da carga de trabalho, o modo Autopilot do Google Kubernetes Engine (GKE) gere os valores dos pedidos de recursos de pods, como CPU, memória ou armazenamento efémero. Esta página inclui as seguintes informações, que pode usar para planear cargas de trabalho eficientes, estáveis e rentáveis:

• Valores predefinidos que o Autopilot aplica aos pods que não especificam valores.
• Valores mínimos e máximos que o Autopilot aplica aos pedidos de recursos.
• Como os valores predefinidos, mínimos e máximos variam com base no hardware que os seus Pods pedem.

Esta página destina-se a operadores e programadores que preparam e configuram recursos na nuvem, e implementam cargas de trabalho. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Trusted Cloud by S3NS conteúdo, consulteFunções e tarefas comuns do utilizador do GKE.

Já deve estar familiarizado com a gestão de recursos do Kubernetes.

Vista geral dos pedidos de recursos no piloto automático

O Autopilot usa os pedidos de recursos que especifica na configuração da carga de trabalho para configurar os nós que executam as cargas de trabalho. O modo automático aplica pedidos de recursos mínimos e máximos com base na classe de computação ou na configuração de hardware que as suas cargas de trabalho usam. Se não especificar pedidos para alguns contentores, o Autopilot atribui valores predefinidos para permitir que esses contentores sejam executados corretamente.

Quando implementa uma carga de trabalho num cluster do Autopilot, o GKE valida a configuração da carga de trabalho em relação aos valores mínimos e máximos permitidos para a classe de computação selecionada ou a configuração de hardware (como GPUs). Se os seus pedidos forem inferiores ao mínimo, o Autopilot modifica automaticamente a configuração da carga de trabalho para colocar os pedidos dentro do intervalo permitido. Se os seus pedidos forem superiores ao máximo, o Autopilot rejeita a sua carga de trabalho e apresenta uma mensagem de erro.

A lista seguinte resume as categorias de pedidos de recursos:

• Pedidos de recursos predefinidos: o Autopilot adiciona-os se não especificar os seus próprios pedidos para cargas de trabalho
• Pedidos de recursos mínimos e máximos: o Autopilot valida os pedidos especificados para garantir que estão dentro destes limites. Se os seus pedidos estiverem fora dos limites, o Autopilot modifica os pedidos da carga de trabalho.
• Separação da carga de trabalho e pedidos de duração prolongada: o Autopilot tem valores predefinidos diferentes e valores mínimos diferentes para cargas de trabalho que separam umas das outras ou para pods que recebem proteção prolongada contra despejo iniciado pelo GKE.
• Pedidos de recursos para DaemonSets: o Autopilot tem valores predefinidos, mínimos e máximos diferentes para contentores em DaemonSets.

Como pedir recursos

No Autopilot, pede recursos na especificação do pod. Os recursos mínimos e máximos suportados que pode pedir variam consoante a configuração de hardware do nó no qual os pods são executados. Para saber como pedir configurações de hardware específicas, consulte as seguintes páginas:

• Escolha classes de computação para pods do Autopilot
• Implemente cargas de trabalho de GPU no Autopilot

Pedidos de recursos predefinidos

Se não especificar pedidos de recursos para alguns contentores num pod, o Autopilot aplica valores predefinidos. Estas predefinições são adequadas para muitas cargas de trabalho mais pequenas.

Além disso, o Autopilot aplica os seguintes pedidos de recursos predefinidos, independentemente da classe de computação ou da configuração de hardware selecionada:

• Contentores em DaemonSets

  • CPU: 50 mCPU
  • Memória: 100 MiB
  • Armazenamento temporário: 100 MiB

• Todos os outros contentores

  • Armazenamento temporário: 1 GiB

Para mais informações sobre os limites dos clusters do Autopilot, consulte o artigo Quotas e limites.

Pedidos predefinidos para classes de computação

O Autopilot aplica os seguintes valores predefinidos aos recursos que não estão definidos na especificação do pod para pods que são executados em classes de computação. Se definir apenas um dos pedidos e deixar o outro em branco, o GKE usa a proporção CPU:memória definida na secção Pedidos mínimos e máximos para definir o pedido em falta para um valor que esteja em conformidade com a proporção.

Pedidos de recursos mínimos e máximos

Os recursos totais pedidos pela configuração da implementação devem estar dentro dos valores mínimo e máximo suportados permitidos pelo Autopilot. Aplicam-se as seguintes condições:

• Pedidos de armazenamento temporário:

  • O armazenamento efémero usa o disco de arranque da VM, a menos que os seus nós tenham SSDs locais anexados.

    O hardware de computação que inclui SSDs locais, como GPUs A100 (80 GB), GPUs H100 (80 GB) ou a série de máquinas Z3, suporta um máximo de pedidos igual ao tamanho do SSD local menos qualquer sobrecarga do sistema. Para obter informações sobre esta sobrecarga do sistema, consulte o artigo Armazenamento efémero suportado por SSDs locais.

  • Na versão 1.29.3-gke.1038000 e posteriores do GKE, os pods da classe de desempenho e os pods do acelerador de hardware suportam um pedido de armazenamento efémero máximo de 56 TiB, a menos que o hardware inclua SSDs locais.

    Em todos os outros pods do Autopilot, independentemente da versão do GKE, o pedido de armazenamento efémero total em todos os contentores no pod tem de estar entre 10 MiB e 10 GiB, salvo especificação em contrário.

  • Para volumes maiores, use volumes efémeros genéricos, que oferecem funcionalidade e desempenho equivalentes ao armazenamento efémero, mas com significativamente mais flexibilidade, uma vez que podem ser usados com qualquer opção de armazenamento do GKE. Por exemplo, o tamanho máximo de um volume efémero genérico que usa o pd-balanced é de 64 TiB.

• Para pods DaemonSet, os pedidos de recursos mínimos são os seguintes:

  • Clusters que suportam o modo Burst: 1 mCPU por pod, 2 MiB de memória por pod e 10 MiB de armazenamento efémero por contentor no pod.
  • Clusters que não suportam o aumento rápido: 10 mCPU por pod, 10 MiB de memória por pod e 10 MiB de armazenamento efémero por contentor no pod.

  Para verificar se o seu cluster suporta o aumento temporário, consulte o artigo Disponibilidade do aumento temporário no GKE.

• Se o cluster suportar o aumento rápido, o Autopilot não aplica incrementos de 0,25 vCPU aos pedidos de CPU dos seus pods. Se o seu cluster não suportar o aumento rápido, o Autopilot arredonda os seus pedidos de CPU para o número mais próximo de 0,25 vCPU. Para verificar se o seu cluster suporta o aumento rápido, consulte a disponibilidade do aumento rápido no GKE.

• A relação CPU:memória tem de estar dentro do intervalo permitido para a classe de computação ou a configuração de hardware selecionada. Se a relação CPU:memória estiver fora do intervalo permitido, o Autopilot aumenta automaticamente o recurso mais pequeno. Por exemplo, se pedir 1 vCPU e 16 GiB de memória (proporção de 1:16) para pods em execução na classe Scale-Out, o Autopilot aumenta o pedido de CPU para 4 vCPUs, o que altera a proporção para 1:4.

Valores mínimos e máximos para classes de computação

A tabela seguinte descreve a proporção mínima, máxima e permitida de CPU para memória para cada classe de computação suportada pelo Autopilot:

Para saber como pedir classes de computação nos seus pods do Autopilot, consulte o artigo Escolha classes de computação para pods do Autopilot.

Valores mínimos e máximos para aceleradores

O GKE não aplica pedidos mínimos de CPU, memória ou armazenamento efémero para pods que usam aceleradores. A tabela seguinte descreve os pedidos máximos para cada um destes recursos com base no número e no tipo de acelerador que usa.

Salvo especificação em contrário, o armazenamento efémero máximo suportado é de 56 TiB.

Para saber como pedir GPUs nos seus pods do Autopilot, consulte o artigo Implemente cargas de trabalho de GPU no Autopilot.

Pedidos de recursos para separação de cargas de trabalho e duração prolongada

O Autopilot permite-lhe manipular o comportamento de agendamento e despejo do Kubernetes através de métodos como os seguintes:

• Use taints e tolerations e seletores de nós para garantir que determinados pods só são colocados em nós específicos. Para mais detalhes, consulte o artigo Configure a separação de cargas de trabalho no GKE.
• Use a antafinidade de pods para impedir que os pods sejam colocados em conjunto no mesmo nó. Os pedidos de recursos predefinidos e mínimos para cargas de trabalho que usam estes métodos para controlar o comportamento de agendamento são superiores aos das cargas de trabalho que não os usam.
• Use uma anotação para proteger os pods do despejo causado por atualizações automáticas de nós e eventos de redução de escala durante um máximo de sete dias. Para ver detalhes, consulte o artigo Prolongue o tempo de execução dos pods do Autopilot.

Se os pedidos especificados forem inferiores aos mínimos, o comportamento do Autopilot muda com base no método que usou, da seguinte forma:

• Taints, tolerations, seletores e pods de duração prolongada: o Autopilot modifica os seus pods para aumentar os pedidos ao agendar os pods.
• Antiafinidade de pods: o Autopilot rejeita o pod e apresenta uma mensagem de erro.

A tabela seguinte descreve os pedidos predefinidos e os pedidos mínimos de recursos que pode especificar. Se uma configuração ou uma classe de computação não estiver nesta tabela, o Autopilot não aplica valores mínimos ou predefinidos especiais.

Contentores de inicialização

Os contentores de inicialização são executados sequencialmente e todos os contentores de inicialização têm de terminar a execução antes de os contentores de aplicações poderem ser iniciados. Nos clusters do Autopilot, se não especificar pedidos de CPU ou memória para contentores de inicialização ou definir explicitamente pedidos para 0, o Autopilot modifica os seus pods durante a criação para adicionar pedidos de recursos a cada contentor de inicialização. Os pedidos atribuídos a cada contentor de inicialização são iguais à soma dos pedidos de todos os contentores de aplicações no Pod. Este é o comportamento predefinido.

Este comportamento difere dos clusters padrão, em que os contentores de inicialização usam quaisquer recursos não atribuídos disponíveis no nó no qual o pod está agendado.

Alocação automática de recursos para contentores de inicialização

A atribuição automática de recursos para contentores init ocorre na criação de pods. Recomendamos que não especifique manualmente pedidos de recursos para os contentores init em clusters do Autopilot, para que cada contentor receba por predefinição todos os recursos disponíveis para o pod.

Se alterar os pedidos de recursos de contentores não init no pod após a criação, o Autopilot não ajusta automaticamente os pedidos de recursos dos contentores init. Como resultado, pode notar cobranças que não são consistentes com a utilização real de recursos do pod. A sua fatura baseia-se no pedido de recursos efetivo do pod, que é o maior dos seguintes:

• O pedido de recursos mais elevado de qualquer contentor de inicialização único no pod.
• A soma dos pedidos de todos os contentores de aplicações no agrupamento.

Para mais informações, consulte o artigo Gestão automática de recursos no Autopilot.

Atribuição manual de recursos para contentores init

Se precisar de alterar os pedidos de recursos existentes para os contentores da sua aplicação de modo a gerir os custos e os recursos, recomendamos que faça uma das seguintes ações para ajustar os pedidos de contentores de inicialização:

• Atualize manualmente os pedidos de recursos para o contentor de inicialização de modo a corresponderem ao novo total de pedidos no pod. Considere o seguinte quando especificar manualmente os pedidos de recursos:
  • Os pedidos inferiores aos recursos totais do pod podem restringir o contentor init.
  • Os pedidos superiores aos recursos totais do pod podem aumentar os custos.
• Remova os pedidos de recursos para permitir que o Autopilot os recalcule. O Autopilot vai voltar a atribuir os recursos a cada contentor init com base no total de recursos atuais pedidos por todos os contentores de aplicações no pod.

Definir limites de recursos no Autopilot

O Kubernetes permite-lhe definir requests e limits para recursos na especificação do pod. O comportamento dos seus Pods muda consoante os limits sejam diferentes dos requests, conforme descrito na tabela seguinte:

resources:
  limits:
    cpu: "400m"

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"

resources:
  requests:
    cpu: "450m"
  limits:
    cpu: "400m"

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"

Na maioria das situações, defina pedidos de recursos adequados e limites iguais para as suas cargas de trabalho.

Para cargas de trabalho que precisam temporariamente de mais recursos do que o respetivo estado estável, como durante o arranque ou durante períodos de tráfego mais elevado, defina os limites mais elevados do que os pedidos para permitir que os pods entrem em burst. Para ver detalhes, consulte o artigo Configure o aumento rápido de pods no GKE.

Gestão automática de recursos no Autopilot

Se os pedidos de recursos especificados para as suas cargas de trabalho estiverem fora dos intervalos permitidos ou se não pedir recursos para alguns contentores, o Autopilot modifica a configuração da carga de trabalho para estar em conformidade com os limites permitidos. O Autopilot calcula as proporções de recursos e os requisitos de aumento da escala de recursos após aplicar os valores predefinidos aos contentores sem pedido especificado.

• Pedidos em falta: se não pedir recursos em alguns contentores, o Autopilot aplica os pedidos predefinidos para a classe de computação ou a configuração de hardware.
• Relação CPU/memória: o piloto automático aumenta o recurso mais pequeno para colocar a relação dentro do intervalo permitido.
• Armazenamento efémero: o Autopilot modifica os seus pedidos de armazenamento efémero para cumprir a quantidade mínima exigida por cada contentor. O valor cumulativo dos pedidos de armazenamento em todos os contentores não pode ser superior ao valor máximo permitido. Antes da versão 1.28.6-gke.1317000, o Autopilot reduz a escala do armazenamento efémero pedido se o valor exceder o máximo. Na versão 1.28.6-gke.1317000 e posteriores, o Autopilot rejeita a sua carga de trabalho.
• Pedidos abaixo dos mínimos: se pedir menos recursos do que o mínimo permitido para a configuração de hardware selecionada, o Autopilot modifica automaticamente o pod para pedir, pelo menos, o valor mínimo do recurso.

Por predefinição, quando o Autopilot dimensiona automaticamente um recurso para satisfazer um valor de recurso mínimo ou predefinido, o GKE atribui a capacidade adicional ao primeiro contentor no manifesto do pod. Na versão 1.27.2-gke.2200 e posteriores do GKE, pode indicar ao GKE que atribua os recursos adicionais a um contentor específico adicionando o seguinte ao campo annotations no manifesto do pod:

autopilot.gke.io/primary-container: "CONTAINER_NAME"

Substitua CONTAINER_NAME pelo nome do recipiente.

Exemplos de modificação de recursos

O cenário de exemplo seguinte mostra como o Autopilot modifica a configuração da carga de trabalho para cumprir os requisitos dos contentores e dos pods em execução.

Contentor único com < 0,05 vCPU

Vários contentores com um total de CPU inferior a 0,05 vCPU

Recipiente único com memória demasiado baixa para a CPU pedida

Neste exemplo, a memória é demasiado baixa para a quantidade de CPU (mínimo de 1 vCPU:1 GiB). A proporção mínima permitida entre a CPU e a memória é de 1:1. Se a relação for inferior, o pedido de memória é aumentado.

O que se segue?

• Saiba como selecionar classes de computação nas suas cargas de trabalho do Autopilot.
• Saiba mais sobre as classes de computação do Autopilot suportadas.
• Saiba como selecionar GPUs nos seus pods do Autopilot.