Como personalizar a configuração do sistema de nós

Neste documento, mostramos como personalizar a configuração de nós do Google Kubernetes Engine (GKE) usando um arquivo de configuração chamado configuração do sistema de nós.

Visão geral

É possível personalizar a configuração do nó usando vários métodos. Por exemplo, é possível especificar parâmetros como o tipo de máquina e a plataforma mínima de CPU ao criar um pool de nós.

Uma configuração do sistema de nós é um arquivo de configuração que oferece uma maneira de ajustar um conjunto limitado de configurações do sistema. É possível usar uma configuração do sistema de nós para especificar configurações personalizadas para o agente de nós do Kubernetes ( kubelet) e configurações de kernel de baixo nível do Linux (sysctl) nos pools de nós.

Também é possível personalizar o ambiente de execução do contêiner do containerd nos nós do GKE usando um arquivo diferente chamado arquivo de configuração do ambiente de execução. Para instruções, consulte Personalizar a configuração do containerd nos nós do GKE.

Você também pode fazer personalizações adicionais usando os seguintes métodos:

Como usar uma configuração do sistema de nós

Para usar uma configuração do sistema de nós:

  1. Crie um arquivo de configuração. Este arquivo contém as configurações kubelet e sysctl.
  2. Adicione a configuração ao criar um cluster ou ao criar ou atualizar um pool de nós.

Como criar um arquivo de configuração

Grave o arquivo de configuração do sistema de nós em YAML. O exemplo a seguir mostra como adicionar configurações para as opções kubelet e sysctl:

kubeletConfig:
  cpuManagerPolicy: static
linuxConfig:
 sysctl:
   net.core.somaxconn: '2048'
   net.ipv4.tcp_rmem: '4096 87380 6291456'

Neste exemplo:

  • cpuManagerPolicy: static configura o kubelet para usar a política de gerenciamento de CPU estática.
  • net.core.somaxconn: '2048' limita o backlog socket listen() a 2.048 bytes.
  • net.ipv4.tcp_rmem: '4096 87380 6291456' define o valor mínimo, padrão e máximo do soquete TCP para conter 4.096 bytes, 87.380 bytes e 6.291.456 bytes, respectivamente.

Se você quiser adicionar configurações exclusivamente para kubelet ou sysctl, inclua essa seção apenas no arquivo de configuração. Por exemplo, para adicionar uma configuração kubelet, crie o seguinte arquivo:

kubeletConfig:
  cpuManagerPolicy: static

Para uma lista completa dos campos que podem ser adicionados ao arquivo de configuração, consulte as seções Opções de configuração do Kubelet e Opções de configuração do Sysctl.

Como adicionar a configuração a um pool de nós

Depois de criar o arquivo de configuração, adicione a sinalização --system-config-from-file usando a Google Cloud CLI. É possível adicionar essa sinalização ao criar um cluster ou ao criar ou atualizar um pool de nós. Não é possível adicionar uma configuração do sistema de nós com o Console do Google Cloud.

Para adicionar uma configuração do sistema de nós, execute o seguinte comando:

Criar cluster

gcloud container clusters create CLUSTER_NAME \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • SYSTEM_CONFIG_PATH: o caminho para o arquivo que contém as configurações kubelet e sysctl.

Depois que você aplicar uma configuração de sistema de nós, o pool de nós padrão do cluster usará as configurações definidas.

Criar pool de nós

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --system-config-from-file=SYSTEM_CONFIG_PATH

Substitua:

  • POOL_NAME: o nome do pool de nós.
  • CLUSTER_NAME: o nome do cluster ao qual você quer adicionar um pool de nós.
  • SYSTEM_CONFIG_PATH: o caminho para o arquivo que contém as configurações kubelet e sysctl.

Atualizar pool de nós

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Substitua:

  • POOL_NAME: o nome do pool de nós que você quer atualizar.
  • CLUSTER_NAME: o nome do cluster que você quer atualizar.
  • SYSTEM_CONFIG_PATH: o caminho para o arquivo que contém as configurações kubelet e sysctl.

Como editar uma configuração do sistema de nós

Para editar uma configuração do sistema de nós, crie um novo pool de nós com a configuração que quiser ou atualize a configuração do sistema de nós de um pool de nós atual.

Como editar criando um pool de nós

Para editar uma configuração do sistema de nós criando um pool de nós:

  1. Crie um arquivo de configuração com a configuração que você quer.
  2. Adicione a configuração a um novo pool de nós.
  3. Migre suas cargas de trabalho para o novo pool de nós.
  4. Exclua o pool de nós antigo.

Como editar atualizando um pool de nós atual

Para editar uma configuração do sistema de nós, atualizando um pool de nós atual, atualize a configuração do sistema do nó com os valores desejados. A atualização de uma configuração do sistema de nós substitui a configuração do sistema do pool de nós pela nova configuração. Se você omitir qualquer parâmetro durante uma atualização, eles serão definidos com os respectivos padrões.

Se você quiser redefinir a configuração do sistema de nós para os padrões, atualize seu arquivo de configuração com valores vazios para kubelet e sysctl. Exemplo:

kubeletConfig: {}
linuxConfig:
  sysctl: {}

Como excluir uma configuração do sistema de nós

Para remover uma configuração do sistema de nós:

  1. Crie um pool de nós.
  2. Migre suas cargas de trabalho para o novo pool de nós.
  3. Exclua o pool de nós que tenha a configuração anterior do sistema de nós.

Opções de configuração do Kubelet

A tabela a seguir mostra as opções de kubelet que você pode modificar.

Configurações do Kubelet Restrições Configuração padrão Descrição
cpuManagerPolicy O valor precisa ser none ou static. none Essa configuração controla a política do Gerenciador de CPU do kubelet. O valor padrão é none, que é o esquema padrão de afinidade da CPU, que não fornece afinidade além do que o programador do SO faz automaticamente.

Definir esse valor como static permite que os pods na classe QoS garantida com solicitações de CPU de número inteiro recebam o uso exclusivo das CPUs.
cpuCFSQuota O valor precisa ser true ou false. true Essa configuração aplica o limite de CPU do pod. Definir esse valor como false significa que os limites de CPU para pods serão ignorados.

Ignorar os limites da CPU pode ser desejável em determinados cenários em que os pods são sensíveis aos limites da CPU. O risco de desativar cpuCFSQuota é que um pod não autorizado pode consumir mais recursos da CPU do que o pretendido.
cpuCFSQuotaPeriod O valor precisa ser uma duração de tempo "100ms" Esta configuração define o valor do período da cota do CFS da CPU, cpu.cfs_period_us, que especifica a frequência com que o acesso de um cgroup aos recursos da CPU precisa ser realocado. Essa opção permite ajustar o comportamento de limitação da CPU.
insecureKubeletReadonlyPortEnabled O valor precisa ser booleano (true ou false) true Essa configuração desativa a porta somente leitura do kubelet não segura 10255 em cada novo pool de nós no cluster. Se você definir essa configuração nesse arquivo, não será possível usar um cliente da API GKE para alterar a configuração no nível do cluster.
podPidsLimit (em inglês) O valor precisa estar entre 1024 e 4194304 none Essa configuração define o número máximo de IDs de processos (PIDs, na sigla em inglês) que cada pod pode usar.

Opções de configuração de Sysctl

Para ajustar o desempenho do sistema, modifique os seguintes atributos do kernel:

Diferentes namespaces Linux podem ter valores exclusivos para um determinado sysctl, enquanto outros são globais para todo o nó. A atualização das opções sysctl usando uma configuração do sistema de nós garante que sysctl seja aplicado globalmente no nó e em cada namespace, resultando em cada pod com valores sysctl idênticos em cada namespace do Linux.

Opções de configuração do modo cgroup do Linux

O kubelet e o ambiente de execução do contêiner usam os cgroups de kernel do Linux para gerenciar recursos, como limitar a quantidade de CPU ou memória que cada contêiner em um pod pode acessar. Há duas versões do subsistema cgroup no kernel: cgroupv1 e cgroupv2. O suporte do Kubernetes para cgroupv2 foi introduzido como Alfa na versão 1.18 do Kubernetes, Beta na versão 1.22 e disponível para todos os usuários na versão 1.25. Para saber mais, consulte a documentação do Kubernetes cgroups v2.

A configuração do sistema de nós permite personalizar a configuração do cgroup dos pools de nós. É possível usar cgroupv1 ou cgroupv2. O GKE usa cgroupv2 para novos pools de nós que executam a versão 1.26 e mais recentes e cgroupv1 para versões anteriores à 1.26.

Use a configuração do sistema de nós para alterar a definição de um pool de nós para usar cgroupv1 ou cgroupv2 explicitamente. Apenas fazer upgrade de um pool de nós atual para a versão 1.26 não muda a configuração para cgroupv2, porque os pools de nós atuais criados com uma versão anterior à 1.26, sem uma configuração de cgroup personalizada, continuam usando cgroupv1, a menos que você especifique outra configuração.

Por exemplo, para configurar o pool de nós para usar cgroupv2, use um arquivo de configuração do sistema de nós, como:

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

Veja a seguir as opções cgroupMode aceitas:

  • CGROUP_MODE_V1: use cgroupv1 no pool de nós.
  • CGROUP_MODE_V2: use cgroupv2 no pool de nós.
  • CGROUP_MODE_UNSPECIFIED: use a configuração padrão do cgroup do GKE.

Para usar cgroupv2, os seguintes requisitos e limitações se aplicam:

  • Para um pool de nós com uma versão anterior à 1.26, é necessário usar a CLI gcloud versão 408.0.0 ou mais recente. Como alternativa, use a gcloud beta com a versão 395.0.0 ou mais recente.
  • Os pools de nós e de cluster precisam executar a versão 1.24.2-gke.300 ou posterior do GKE.
  • Use o Container-Optimized OS com uma imagem de nó.
  • Se alguma das cargas de trabalho depender da leitura do sistema de arquivos cgroup (/sys/fs/cgroup/...), verifique se ele é compatível com a API cgroupv2.
    • Verifique se as ferramentas de monitoramento ou de terceiros são compatíveis com o cgroupv2.
  • Se você usa o JDK (carga de trabalho do Java), recomendamos utilizar versões com suporte total ao cgroupv2, incluindo JDK 8u372, JDK 11.0.16 ou mais recentes ou JDK 15. ou posterior.

Verificar a configuração do cgroup

Quando você adiciona uma configuração de sistema de nós, o GKE precisa recriar os nós para implementar as alterações. Depois de adicionar a configuração a um pool de nós e recriar os nós, verifique a nova configuração.

Para verificar a configuração do cgroup nos nós neste pool, escolha um nó e conecte-se a ele usando as seguintes instruções:

  1. Crie um shell interativo com qualquer nó no pool. Substitua mynode no comando pelo nome de qualquer nó no pool de nós.
  2. Identifique a versão do cgroup nos nós do Linux.

Opções de configuração de página enorme do Linux

Use o arquivo de configuração do sistema de nós para usar as grandes páginas do recurso do kernel do Linux.

O Kubernetes oferece suporte a páginas enormes em nós como um tipo de recurso, semelhante à CPU ou à memória. Use os parâmetros a seguir para instruir os nós do Kubernetes a alocar grandes páginas para consumo pelos pods. Para gerenciar o consumo de páginas grandes pelos pods, consulte Gerenciar HugePages.

Para pré-alocar páginas grandes para seus nós, especifique as quantidades e os tamanhos. Por exemplo, para configurar seus nós para alocar três páginas enormes de 1 gigabyte e 1.024 páginas enormes de 2 MB, use uma configuração de sistema de nós como esta:

linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

Para usar páginas grandes, as limitações e requisitos a seguir se aplicam:

  • Para garantir que o nó não seja totalmente ocupado por páginas grandes, o tamanho geral de páginas grandes alocadas não pode exceder 60% da memória total. Por exemplo, com uma máquina e2-standard-2, que tem 8 GB de memória, não é possível alocar mais de 4,8 GB para páginas grandes.
  • Páginas enormes de 1 gigabtye estão disponíveis apenas no A3, C2D, C3, C3A, C3D, C4, CT5E, CT5L, CT5LP, CT6E, H3, M2, M3 ou Z3tipos de máquina.

A seguir