Acerca do dimensionamento dos nós do GKE

Autopilot Padrão

Esta página descreve como planear o tamanho dos nós nos conjuntos de nós padrão do Google Kubernetes Engine (GKE) para reduzir o risco de interrupções da carga de trabalho e de encerramentos por falta de recursos.

Este planeamento não é necessário no GKE Autopilot porque o Google Cloud gestiona os nós por si. No entanto, este documento ajuda os operadores do cluster do Autopilot que querem saber que percentagem da capacidade de recursos num nó está disponível para as suas cargas de trabalho usarem.

Vantagens dos nós dimensionados corretamente

Garantir que os seus nós têm o tamanho correto para acomodar as cargas de trabalho e processar picos de atividade oferece vantagens como as seguintes:

• Melhor fiabilidade da carga de trabalho devido a um risco reduzido de despejo por falta de recursos.
• Escalabilidade melhorada para dimensionar cargas de trabalho durante períodos de tráfego elevado.
• Custos mais baixos porque os nós não são demasiado grandes para as suas necessidades, o que pode resultar em recursos desperdiçados.

Recursos atribuíveis de nós

Os nós do GKE executam componentes do sistema que permitem que o nó funcione como parte do seu cluster. Estes componentes usam recursos de nós, como a CPU e a memória. Pode notar uma diferença entre os recursos totais do nó, que se baseiam no tamanho da máquina virtual (VM) do Compute Engine subjacente, e os recursos disponíveis para as suas cargas de trabalho do GKE pedirem. Esta diferença deve-se ao facto de o GKE reservar uma quantidade predefinida de recursos para a funcionalidade do sistema e a fiabilidade dos nós. O espaço em disco que o GKE reserva para recursos do sistema difere com base na imagem do nó. Os recursos restantes que estão disponíveis para as suas cargas de trabalho são denominados recursos atribuíveis.

Quando define agrupamentos num manifesto, pode especificar pedidos e limites de recursos na especificação do agrupamento. Quando o GKE coloca os pods num nó, o pod pede esses recursos especificados aos recursos atribuíveis no nó. Ao planear o tamanho dos nós nos seus conjuntos de nós, deve considerar quantos recursos as suas cargas de trabalho precisam para funcionar corretamente.

Aviso: os volumes hostpath e o sistema de VM do anfitrião usam o mesmo disco. Esta capacidade é partilhada com a utilização do sistema, como imagens de contentores e o kubelet. Se este disco ficar cheio, o sistema pode desalojar cargas de trabalho ou ficar instável. Para saber mais, consulte o artigo Despejo por pressão do nó na documentação do Kubernetes de código aberto.

Verifique os recursos atribuíveis num nó

Para inspecionar os recursos atribuíveis num nó existente, 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 é semelhante ao seguinte:

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"

Neste resultado, os valores na secção allocatable são os recursos atribuíveis no nó. Os valores na secção capacity são os recursos totais no nó. As unidades de armazenamento efémero são bytes.

Reservas de recursos do GKE

O GKE reserva quantidades específicas de recursos de memória e CPU em nós com base no tamanho total do recurso disponível no nó. Os tipos de máquinas maiores executam mais contentores e pods, pelo que a quantidade de recursos que o GKE reserva é dimensionada para máquinas maiores. Os nós do Windows Server também requerem mais recursos do que os nós Linux equivalentes, para ter em conta a execução do SO Windows e os componentes do Windows Server que não podem ser executados em contentores.

Reservas de memória e CPU

As secções seguintes descrevem as reservas de memória e CPU predefinidas com base no tipo de máquina.

Nota: este documento usa gibibytes (GiB) e mebibytes (MiB) para valores de memória e armazenamento. No entanto, a Google Cloud consola usa gigabytes (GB) e megabytes (MB). Esta diferença nas unidades significa que os valores da capacidade atribuível que vê na consola podem ser diferentes dos valores que calcula através deste documento.

Google Cloud

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 GiB de memória
• 25% dos primeiros 4 GiB de memória
• 20% dos 4 GiB seguintes de memória (até 8 GiB)
• 10% dos 8 GiB seguintes de memória (até 16 GiB)
• 6% dos 112 GiB seguintes de memória (até 128 GiB)
• 2% de qualquer memória acima de 128 GiB

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

Nota: se ativar o streaming de imagens, o GKE reserva memória adicional. Para ver detalhes, consulte o artigo Reserva de memória para streaming de imagens.

Reservas de CPU

Para recursos de CPU, o GKE reserva o seguinte:

• 6% do primeiro núcleo
• 1% do núcleo seguinte (até 2 núcleos)
• 0,5% dos 2 núcleos seguintes (até 4 núcleos)
• 0,25% de quaisquer núcleos acima de 4 núcleos

Nota: se aumentar o número máximo de pods por nó para além da predefinição de 110, o GKE reserva mais 400 mCPU além das reservas anteriores.

Para os tipos de máquinas E2 com núcleo partilhado, o GKE reserva um total de 1060 milicores.

Reserva de armazenamento temporário local

O GKE fornece nós com armazenamento efémero, suportado por dispositivos associados localmente, como o disco de arranque do nó ou SSDs locais. O armazenamento efémero não tem garantia de disponibilidade e os dados no armazenamento efémero podem ser perdidos se um nó falhar e for eliminado.

O GKE reserva uma parte do armazenamento efémero total do nó como um único sistema de ficheiros para o kubelet usar durante a remoção de pods e para outros componentes do sistema em execução no nó. Pode atribuir o armazenamento efémero restante aos seus pods para utilização em finalidades como registos. Para saber como especificar pedidos e limites de armazenamento efémero nos seus pods, consulte o artigo Armazenamento efémero local.

O GKE calcula a reserva de armazenamento efémero local da seguinte forma:

EVICTION_THRESHOLD + SYSTEM_RESERVATION

Os valores reais variam com base no tamanho e no tipo de dispositivo que suporta o armazenamento.

Armazenamento temporário com base no disco de arranque do nó

Por predefinição, o armazenamento temporário é suportado pelo disco de arranque do nó. Neste caso, o GKE determina o valor do limite de despejo da seguinte forma:

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

O limite de despejo é sempre de 10% da capacidade total do disco de arranque.

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

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

O valor da reserva do sistema é o mais baixo dos seguintes:

• 50% da capacidade do disco de arranque
• 35% da capacidade do disco de arranque + 6 GiB
• 100 GiB

Por exemplo, se o disco de arranque for de 300 GiB, aplicam-se os seguintes valores:

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

O GKE reservaria o seguinte:

• Reserva do sistema: 100 GiB (o valor mais baixo)
• Limite de despejo: 30 GiB

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

Armazenamento temporário suportado por SSDs locais

Se o seu armazenamento efémero for suportado por SSDs locais, o GKE calcula o limite de remoção da seguinte forma:

EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB

Neste cálculo, SSD_NUMBER é o número de SSDs locais anexados. Todos os SSDs locais têm um tamanho de 375 GiB, pelo que o limite de despejo é de 10% da capacidade de armazenamento efémero total. Tenha em atenção que este valor é calculado antes de os discos serem formatados, pelo que a capacidade utilizável é vários por cento inferior, consoante as versões das imagens dos nós.

O GKE calcula a reserva do sistema consoante o número de SSDs anexados, da seguinte forma:

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

Use reservas de recursos para planear os tamanhos dos nós

1. Considere os requisitos de recursos das suas cargas de trabalho no momento da implementação e sob carga. Isto inclui os pedidos e os limites planeados para as cargas de trabalho, bem como a sobrecarga para acomodar o aumento da escala.

2. Considere se quer um pequeno número de nós grandes ou um grande número de nós pequenos para executar as suas cargas de trabalho.

   • Um pequeno número de nós grandes funciona bem para cargas de trabalho com utilização intensiva de recursos que não requerem alta disponibilidade. O dimensionamento automático de nós é menos ágil porque é necessário despejar mais pods para que ocorra uma redução da escala.
   • Um grande número de pequenos nós funciona bem para cargas de trabalho de elevada disponibilidade que não consomem muitos recursos. O dimensionamento automático de nós é mais ágil porque têm de ser despejados menos pods para que ocorra uma redução.

3. Use o guia de comparação da família de máquinas do Compute Engine para determinar a série e a família de máquinas que quer para os seus nós.

4. Considere os requisitos de armazenamento efémero das suas cargas de trabalho. O disco de arranque do nó é suficiente? Precisa de SSDs locais?

5. Calcule os recursos atribuíveis no tipo de máquina escolhido com as informações nas secções anteriores. Compare isto com os recursos e a sobrecarga de que precisa.

   • Se o tipo de máquina escolhido for demasiado grande, considere usar uma máquina mais pequena para evitar pagar pelos recursos adicionais.
   • Se o tipo de máquina escolhido for demasiado pequeno, considere usar uma máquina maior para reduzir o risco de interrupções da carga de trabalho.

O que se segue?

• Escolha um tipo de máquina para um conjunto de nós