Política de reserva de recursos de nó
Alguns recursos de nó são usados para executar componentes e recursos obrigatórios do sistema Kubernetes para tornar o nó parte do cluster. Portanto, o número total de recursos de nó e o número de recursos de nó alocáveis para o cluster são diferentes. Quanto maiores as especificações do nó, mais os contêineres implementados no nó. Portanto, mais recursos de nó precisam ser reservados para executar componentes do Kubernetes.
Para garantir a estabilidade do nó, um certo número de recursos de nó do CCE será reservado para componentes do Kubernetes (como kubelet, kube-proxy e docker) com base nas especificações do nó.
O CCE calcula os recursos que podem ser alocados aos nós do usuário da seguinte forma:
Allocatable resources = Total amount - Reserved amount - Eviction threshold
O limite de remoção de memória é fixado em 100 MB.
Total amount indica a memória disponível do ECS, excluindo a memória usada pelos componentes do sistema. Portanto, a quantidade total é um pouco menor que a memória do flavor do nó. Para obter detalhes, consulte Por que a memória de um ECS obtida pela execução do comando free é inconsistente com a memória real?
Quando a memória consumida por todos os pods em um nó aumenta, os seguintes comportamentos podem ocorrer:
- Quando a memória disponível do nó é menor que o limite da remoção, o kubelet é acionado para remover o pod. Para obter detalhes sobre o limite de despejo no Kubernetes, consulte Node-pressure Eviction.
- Se um nó acionar um evento de insuficiência de memória (OOM) antes de o kubelet recuperar a memória, o sistema termina o contêiner. No entanto, diferente da remoção do pod, o kubelet reinicia o contêiner com base no RestartPolicy do pod.
Regras v1 para reservar memória de nó
Para clusters de versões anteriores a v1.21.4-r0 e v1.23.3-r0, o modelo v1 é usado para reserva de memória de nó. Para clusters de v1.21.4-r0, v1.23.3-r0 ou posterior, o modelo de reserva de memória de nó é otimizado para v2. Para mais detalhes, consulte Regras para reservar memória de nó v2.
Você pode usar a seguinte fórmula para calcular a quantidade de memória que você deve reservar para executar contêineres em um nó:
Quantidade total reservada = memória reservada para os componentes do sistema + memória reservada para kubelet para gerenciar pods
|
Memória total (TM) |
Memória reservada para componentes do sistema |
|---|---|
|
TM ≤ 8 GB |
0 MB |
|
8 GB < TM ≤ 16 GB |
[(TM – 8 GB) x 1024 x 10%] MB |
|
16 GB < TM ≤ 128 GB |
[8 GB x 1024 x 10% + (TM – 16 GB) x 1024 x 6%] MB |
|
TM > 128 GB |
(8 GB x 1024 x 10% + 112 GB x 1024 x 6% + (TM – 128 GB) x 1024 x 2%) MB |
|
Memória total (TM) |
Número de pods |
Memória reservada para kubelet |
|---|---|---|
|
TM ≤ 2 GB |
Nenhum |
TM x 25% |
|
TM > 2 GB |
0 < Máx. pods em um nó≤ 16 |
700 MB |
|
16 < Máx. pods em um nó≤ 32 |
[700 + (Máx. pods em um nó – 16) x 18,75] MB |
|
|
32 < Máx. pods em um nó≤ 64 |
[1024 + (Máx. pods em um nó – 32) x 6,25] MB |
|
|
64 < Máx. pods em um nó≤ 128 |
[1230 + (Máx. pods em um nó – 64) x 7,80] MB |
|
|
Máx. pods em um nó > 128 |
[1740 + (Máx. pods em um nó – 128) x 11,20] MB |
Para um nó de pequena capacidade, ajuste o número máximo de instâncias com base nos requisitos do site. Alternativamente, ao criar um nó no console do CCE, você pode ajustar o número máximo de instâncias para o nó com base nas especificações do nó.
Regras para reservar memória de nó v2
Para clusters de v1.21.4-r0, v1.23.3-r0 ou posterior, o modelo de reserva de memória de nó é otimizado para v2 e pode ser ajustado dinamicamente usando os parâmetros kube-reserved-mem e system-reserved-mem. Para mais detalhes, consulte Gerenciamento de um pool de nós.
A memória total de nó reservada do modelo v2 é igual à soma da reservada para o sistema operacional e da reservada para o CCE gerenciar pods.
A memória reservada inclui partes básicas e flutuantes. Para o sistema operacional, a memória flutuante depende das especificações do nó. Para CCE, a memória flutuante depende do número de pods em um nó.
|
Reservada para |
Básica/flutuante |
Reservas |
Usada por |
|---|---|---|---|
|
SO |
Básica |
400 MB (fixa) |
Componentes de serviço do SO, como sshd e systemd-journald. |
|
Flutuante (dependendo da memória do nó) |
25 MB/GB |
Kernel |
|
|
CCE |
Básica |
500 MB (fixa) |
Componentes do mecanismo de contêiner, como kubelet e kube-proxy, quando o nó é descarregado |
|
Flutuante (dependendo do número de pods no nó) |
Docker: 20 MB/pod containerd: 5 MB/pod |
Componentes do motor de contêiner quando o número de pods aumenta
NOTA:
Quando o modelo v2 reserva memória para um nó por padrão, o número máximo padrão de pods é estimado com base na memória. Para mais detalhes, consulte Tabela 1. |
Regras para reservar CPU de nó
|
Total de núcleos de CPU (total) |
Núcleos de CPU reservados |
|---|---|
|
Total ≤ 1 núcleo |
Total x 6% |
|
1 núcleo < total ≤ 2 núcleos |
1 núcleo x 6% + (total – 1 núcleo) x 1% |
|
2 núcleos < total ≤ 4 núcleos |
1 núcleo x 6% + 1 núcleo x 1% + (total – 2 núcleos) x 0,5% |
|
Total > 4 núcleos |
1 núcleo x 6% + 1 núcleo x 1% + 2 núcleos x 0,5% + (total – 4 núcleos) x 0,25% |
Regras para o CCE reservar discos de dados em nós
O CCE usa o Logical Volume Manager (LVM) para gerenciar discos. O LVM cria uma área de metadados em um disco para armazenar volumes lógicos e físicos, ocupando espaço de 4 MiB. Portanto, o espaço em disco disponível real de um nó é igual ao tamanho do disco menos 4 MiB.
