Planejar tamanhos de nós do GKE Standard

Padrão

Nesta página, descrevemos como planejar o tamanho dos nós nos pools de nós do Google Kubernetes Engine (GKE) Standard para reduzir o risco de interrupções da carga de trabalho e encerramentos por recursos insuficientes. Esse planejamento não é necessário no GKE Autopilot porque o Google gerencia os nós para você.

Benefícios dos nós com o tamanho correto

Garantir que os nós tenham o tamanho correto para acomodar as cargas de trabalho e lidar com picos de atividade oferece benefícios como os seguintes:

Melhor confiabilidade da carga de trabalho devido a um risco reduzido de remoção por falta de recursos.
Escalabilidade aprimorada para escalonar cargas de trabalho durante períodos de alto tráfego.
Custos mais baixos porque os nós não são muito grandes para suas necessidades, o que pode resultar em recursos desperdiçados.

Recursos alocáveis de nó

Os nós do GKE executam componentes do sistema que permitem que o nó funcione como parte do cluster. Esses componentes usam recursos de nó, como CPU e memória. Talvez você note uma diferença entre os recursos totais do nó, que são baseados no tamanho da máquina virtual (VM) do Compute Engine, e nos recursos disponíveis para solicitação pelas cargas de trabalho do GKE. Essa diferença ocorre porque o GKE reserva uma quantidade predefinida de recursos para a funcionalidade do sistema e a confiabilidade do nó. O espaço em disco que o GKE reserva para recursos do sistema difere com base na imagem do nó. Os recursos restantes disponíveis para as cargas de trabalho são chamados de recursos alocáveis.

Ao definir pods em um manifesto, é possível especificar as solicitações e os limites de recursos na especificação do pod. Quando o GKE coloca os pods em um nó, o pod solicita esses recursos especificados dos recursos alocáveis no nó. Ao planejar o tamanho dos nós nos seus pools de nós, considere quantos recursos suas cargas de trabalho precisam para funcionar corretamente.

Verificar recursos alocáveis em um nó

Para inspecionar os recursos alocáveis em um nó atual, execute o seguinte comando:

kubectl get node NODE_NAME \
    -o=yaml | grep -A 7 -B 7 capacity

Substitua NODE_NAME pelo nome do nó.

O resultado será assim:

allocatable:
  attachable-volumes-gce-pd: "127"
  cpu: 3920m
  ephemeral-storage: "47060071478"
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 13498416Ki
  pods: "110"
capacity:
  attachable-volumes-gce-pd: "127"
  cpu: "4"
  ephemeral-storage: 98831908Ki
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 16393264Ki
  pods: "110"

Nesta saída, os valores na seção allocatable são os recursos alocáveis no nó. Os valores na seção capacity são o total de recursos no nó. As unidades de armazenamento temporário são bytes.

Reservas de recursos do GKE

O GKE reserva quantidades específicas de recursos de memória e CPU nos nós com base no tamanho total do recurso disponível no nó. Tipos de máquinas maiores executam mais contêineres e pods, portanto, a quantidade de recursos que o GKE reserva escalona verticalmente para máquinas maiores. Os nós do Windows Server também exigem mais recursos do que os nós do Linux equivalentes, para executar o SO do Windows e os componentes do Windows Server que não podem ser executados em contêineres.

Reservas de memória e CPU

As seções a seguir descrevem as reservas de memória e CPU padrão com base no tipo de máquina.

Reservas de memória

Para recursos de memória, o GKE reserva o seguinte:

255 MiB de memória para máquinas com menos de 1 GB de memória
25% dos primeiros 4 GiB de memória
20% dos próximos 4 GiB de memória (até 8 GiB)
10% dos próximos 8 GiB de memória (até 16 GiB)
6% dos próximos 112 GiB de memória (até 128 GiB)
2% de qualquer memória acima de 128 GiB

O GKE também reserva mais 100 MiB de memória em cada nó para lidar com a remoção de pods.

Reservas de CPU

Para recursos de CPU, o GKE reserva o seguinte:

6% do primeiro núcleo
1% do próximo núcleo (até dois núcleos)
0,5% dos próximos dois núcleos (até quatro núcleos)
0,25% de todos os núcleos acima de quatro núcleos

Para tipos de máquinas E2 com núcleo compartilhado, o GKE reserva um total de 1.060 milicores.

Reserva de armazenamento temporário local

O GKE fornece aos nós armazenamento temporário local, apoiado por dispositivos conectados localmente, como o disco de inicialização do nó ou SSDs locais. O armazenamento temporário não tem garantia de disponibilidade, e os dados no armazenamento temporário podem ser perdidos se um nó falhar e for excluído.

O GKE reserva uma parte do armazenamento temporário total do nó como um único sistema de arquivos para o kubelet usar durante a remoção de pods e para outros componentes do sistema em execução no nó. É possível alocar o armazenamento temporário restante para que os pods usem para fins como registros. Para saber como especificar solicitações e limites de armazenamento temporário nos seus pods, consulte Armazenamento temporário local.

O GKE calcula a reserva de armazenamento temporário local da seguinte maneira:

EVICTION_THRESHOLD + SYSTEM_RESERVATION

Os valores reais variam de acordo com o tamanho e o tipo do dispositivo que apoia o armazenamento.

Armazenamento temporário apoiado pelo disco de inicialização do nó

Por padrão, o armazenamento temporário é protegido pelo disco de inicialização de nós. Nesse caso, o GKE determina o valor do limite de remoção da seguinte maneira:

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

O limite de remoção é sempre 10% da capacidade total do disco de inicialização.

O GKE determina o valor da reserva do sistema da seguinte maneira:

SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)

O valor da reserva do sistema é o menor:

50% da capacidade do disco de inicialização
35% da capacidade do disco de inicialização + 6 GiB
100 GiB

Por exemplo, se o disco de inicialização for 300 GiB, os seguintes valores serão aplicados:

50% da capacidade: 150 GiB
35% da capacidade + 6 GiB: 111 GiB
100 GiB

O GKE reserva o seguinte:

Reserva do sistema: 100 GiB (o valor mais baixo)
Limite de remoção: 30 GiB

O armazenamento temporário total reservado é de 130 GiB. A capacidade restante, 170 GiB, é de armazenamento temporário alocável.

Armazenamento temporário com suporte de SSDs locais

Se o armazenamento temporário for apoiado por SSDs locais, o GKE calculará o limite de remoção da seguinte maneira:

EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GB

Nesse cálculo, SSD_NUMBER é o número de SSDs locais anexados. Todos os SSDs locais têm 375 GB. Portanto, o limite de remoção é de 10% da capacidade total de armazenamento temporário.

O GKE calcula a reserva do sistema, dependendo do número de SSDs anexados, da seguinte maneira:

Número de SSDs locais	Reserva do sistema (GiB)
1	50 GiB
2	75 GiB
3 ou mais	100 GiB

Usar reservas de recursos para planejar tamanhos de nós

Considere os requisitos de recursos das cargas de trabalho no momento da implantação e na carga. Isso inclui as solicitações e os limites planejados para as cargas de trabalho, além da sobrecarga para acomodar o escalonamento vertical.
Considere se você quer um pequeno número de nós grandes ou um grande número de nós pequenos para executar suas cargas de trabalho.
- Um pequeno número de nós grandes funciona bem para cargas de trabalho com uso intensivo de recursos que não exigem alta disponibilidade. O escalonamento automático de nós é menos ágil, porque mais pods precisam ser removidos para que a redução da escala vertical ocorra.
- Um grande número de nós pequenos funciona bem para cargas de trabalho altamente disponíveis que não consomem muitos recursos. O escalonamento automático de nós é mais ágil porque menos pods precisam ser removidos para que a redução da escala vertical ocorra.
Use o guia de comparação de famílias de máquinas do Compute Engine para determinar as séries e famílias de máquinas que você quer para os nós.
Considere os requisitos de armazenamento temporário das suas cargas de trabalho. O disco de inicialização de nós é suficiente? Você precisa de SSDs locais?
Calcule os recursos alocáveis no tipo de máquina escolhido usando as informações das seções anteriores. Compare isso com os recursos e a sobrecarga necessários.
- Se o tipo de máquina escolhido for muito grande, considere uma máquina menor para evitar pagar pelos recursos extras.
- Se o tipo de máquina escolhido for muito pequeno, considere uma máquina maior para reduzir o risco de interrupções da carga de trabalho.