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

Standard

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.

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. No pool de nós, é 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 para configurações de kernel do Linux de baixo nível sysctl.

Cuidado: alterar as configurações kubelet ou sysctl pode levar a um comportamento não intencional que pode afetar negativamente a integridade das cargas de trabalho e dos nós. Teste extensivamente todas as mudanças kubelet ou sysctl antes de implantá-las em cargas de trabalho de produção.

Este documento detalha as configurações disponíveis para uma configuração do sistema de nós e como aplicá-las aos pools de nós do GKE Standard. Como os clusters do GKE Autopilot têm um ambiente de nós mais gerenciado, as opções de configuração direta do sistema de nós são limitadas em comparação com os pools de nós do GKE Standard.

Por que usar configurações do sistema de nós

As configurações do sistema de nós oferecem os seguintes benefícios:

• Ajuste de performance:otimize o desempenho da pilha de rede, o gerenciamento de memória, o agendamento da CPU ou o comportamento de E/S para aplicativos exigentes, como treinamento ou serviço de IA, bancos de dados, servidores da Web de alto tráfego ou serviços sensíveis à latência.
• Reforço da segurança:aplique configurações de segurança específicas no nível do kernel ou restrinja determinados comportamentos do sistema para reduzir a superfície de ataque.
• Gerenciamento de recursos:ajuste como o kubelet gerencia PIDs, espaço em disco, coleta de lixo de imagens ou recursos de CPU e memória.
• Compatibilidade de carga de trabalho:ajuda a garantir que o ambiente do nó atenda a pré-requisitos específicos para software especializado ou aplicativos mais antigos que exigem configurações de kernel específicas.

Outras opções para personalizar configurações de nós

Também é possível personalizar a configuração do nó usando outros métodos:

• Arquivo de configuração do ambiente de execução: para personalizar um ambiente de execução do contêiner do containerd nos nós do GKE, use um arquivo diferente chamado arquivo de configuração do ambiente de execução. Para mais informações, consulte Personalizar a configuração do containerd em nós do GKE.
• ComputeClass: é possível especificar atributos de nós na especificação da ComputeClass do GKE. É possível usar ComputeClasses nos modos Autopilot e Standard do GKE na versão 1.32.1-gke.1729000 e mais recentes. Para mais informações, consulte Personalizar a configuração do sistema de nós.
• DaemonSets: também é possível usar DaemonSets para personalizar nós. Para mais informações, consulte Inicialização automática dos nós do GKE com DaemonSets.

As configurações do sistema de nós não são compatíveis com os nós do Windows Server.

Antes de começar

Antes de começar, faça o seguinte:

• Instale as ferramentas de linha de comando:
  • Se você usar os exemplos da CLI gcloud neste documento, instale e configure a Google Cloud CLI.
  • Se você usar os exemplos do Terraform, instale e configure o Terraform.
• Conceder permissões: você precisa das permissões adequadas do IAM para criar e atualizar clusters do GKE e pools de nós, como container.clusterAdmin ou um papel diferente com permissões equivalentes.
• Planeje possíveis interrupções na carga de trabalho: as configurações de nós personalizados são aplicadas no nível do pool de nós. As mudanças geralmente acionam uma atualização gradual dos nós no pool, o que envolve recriar os nós. Planeje possíveis interrupções de carga de trabalho e use orçamentos de interrupção de pod (PDBs) quando apropriado.
• Faça backup e teste todas as mudanças:sempre teste as mudanças de configuração em um ambiente de teste ou desenvolvimento antes de aplicá-las à produção. Configurações incorretas podem causar instabilidade no nó ou falhas na carga de trabalho.
• Revise as configurações padrão do GKE:as imagens de nó do GKE vêm com configurações padrão otimizadas. Personalize os parâmetros apenas se você tiver uma necessidade específica e entender o impacto das mudanças.

Usar uma configuração do sistema de nós no modo GKE Standard

Ao usar uma configuração do sistema de nós, você usa um arquivo YAML que contém os parâmetros de configuração do kubelet e do kernel do Linux. Embora as configurações do sistema de nós também estejam disponíveis no modo Autopilot do GKE, as etapas deste documento mostram como criar e usar um arquivo de configuração para o modo GKE Standard.

Para usar uma configuração do sistema de nós no modo GKE Standard, faça o seguinte:

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.

Criar um arquivo de configuração

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

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
    - 'kernel.shm*'
    - 'kernel.msg*'
    - 'kernel.sem'
    - 'fs.mqueue*'
    - 'net.*'
linuxConfig:
  sysctl:
    net.core.somaxconn: '2048'
    net.ipv4.tcp_rmem: '4096 87380 6291456'

Neste exemplo, o seguinte se aplica:

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

Se você quiser adicionar configurações apenas para kubelet ou sysctl, inclua apenas essa seção na configuração do sistema de nós. 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 à configuração do sistema de nós, consulte as seções Opções de configuração do Kubelet e Opções de configuração do Sysctl.

Adicionar a configuração a um pool de nós padrão

Depois de criar a configuração do sistema de nós, adicione a flag --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 usando o console do Google Cloud .

Criar um cluster com a configuração do sistema de nós

É possível adicionar uma configuração de sistema de nós durante a criação do cluster usando a CLI gcloud ou o Terraform. As instruções a seguir aplicam a configuração do sistema de nós ao pool de nós padrão:

CLI da gcloud

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

Substitua:

• CLUSTER_NAME: o nome do cluster.
• LOCATION: a zona ou região do Compute do cluster.
• SYSTEM_CONFIG_PATH: o caminho para o arquivo que contém as configurações kubelet e sysctl.

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

Terraform

Para criar um cluster regional com uma configuração personalizada do sistema de nós usando o Terraform, consulte o exemplo a seguir:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Para mais informações sobre como usar o Terraform, consulte Suporte do Terraform ao GKE.

Criar um novo pool de nós com a configuração do sistema de nós

É possível adicionar uma configuração do sistema de nós ao usar a CLI gcloud ou o Terraform para criar um novo pool de nós.

As instruções a seguir aplicam a configuração do sistema de nós a um novo pool de nós:

CLI da gcloud

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --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.
• LOCATION: a zona ou região do Compute do cluster.
• SYSTEM_CONFIG_PATH: o caminho para o arquivo que contém as configurações kubelet e sysctl.

Terraform

Para criar um pool de nós com uma configuração personalizada do sistema de nós usando o Terraform, consulte o exemplo a seguir:

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Para mais informações sobre como usar o Terraform, consulte Suporte do Terraform ao GKE.

Atualizar a configuração do sistema de nós de um pool de nós atual

Para atualizar a configuração do sistema de nós de um pool de nós atual, execute o seguinte comando:

   gcloud container node-pools update POOL_NAME \
      --cluster=CLUSTER_NAME \
      --location=LOCATION \
      --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.
• LOCATION: a zona ou região do Compute do cluster.
• SYSTEM_CONFIG_PATH: o caminho para o arquivo que contém as configurações kubelet e sysctl.

Essa mudança exige a recriação dos nós, o que pode causar interrupções nas cargas de trabalho em execução. Para mais informações sobre essa mudança específica, encontre a linha correspondente na tabela Mudanças manuais que recriam os nós usando uma estratégia de upgrade de nós sem respeitar as políticas de manutenção.

Para mais informações sobre atualizações de nós, consulte Planejar interrupções de atualização de nós.

Cuidado :o GKE começa imediatamente a recriar os nós para essa mudança usando a estratégia de upgrade de nós, independentemente das políticas de manutenção ativas. O GKE depende da disponibilidade de recursos para a mudança. Desativar os upgrades automáticos de nós não impede essa mudança.

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.

Editar criando um pool de nós

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

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.

Editar atualizando um pool de nós atual

Para editar a configuração do sistema de nós de um pool de nós atual, siga as instruções na guia Atualizar pool de nós para adicionar a configuração a um pool de nós. Quando você atualiza uma configuração do sistema de nós e a nova configuração substitui a configuração do sistema atual do pool de nós, os nós precisam ser recriados. Se você omitir algum 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 os campos kubelet e sysctl, por exemplo:

kubeletConfig: {}
linuxConfig:
  sysctl: {}

Excluir uma configuração do sistema de nós

Para remover uma configuração do sistema de nós, siga estas etapas:

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 para o kubelet

As tabelas nesta seção descrevem as opções de kubelet que podem ser modificadas.

Gerenciamento de CPU

A tabela a seguir descreve as opções de gerenciamento de CPU para o kubelet.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
cpuCFSQuota	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 benéfico em determinados cenários em que os pods são sensíveis a esses limites. O risco de desativar cpuCFSQuota é que um pod não autorizado pode consumir mais recursos da CPU do que o pretendido.
cpuCFSQuotaPeriod	Precisa ser uma duração.	"100ms"	Essa 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.

Gerenciamento e remoção de memória

A tabela a seguir descreve as opções modificáveis para gerenciamento de memória e remoção. Esta seção também contém uma tabela separada que descreve as opções modificáveis para a flag evictionSoft.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
evictionSoft	Mapa de nomes de indicadores. Para restrições de valor, consulte a tabela a seguir.	none	Essa configuração mapeia nomes de indicadores para uma quantidade ou porcentagem que define os limites de remoção suave. Um limite de remoção gradual precisa ter um período de carência. O kubelet não desaloca pods até que o período de carência seja excedido.
evictionSoftGracePeriod	Mapa de nomes de indicadores. Para cada nome de indicador, o valor precisa ser uma duração positiva menor que 5m. As unidades de tempo válidas são ns, us (ou µs), ms, s ou m.	none	Essa configuração mapeia nomes de indicadores para durações que definem períodos de carência para limites de remoção suave. Cada limite de remoção suave precisa ter um período de carência correspondente.
evictionMinimumReclaim	Mapa de nomes de indicadores. Para cada nome de indicador, o valor precisa ser uma porcentagem positiva menor que 10%.	none	Essa configuração mapeia nomes de indicadores para porcentagens que definem a quantidade mínima de um determinado recurso que o kubelet recupera quando realiza uma remoção de pod.
evictionMaxPodGracePeriodSeconds	O valor precisa ser um número inteiro entre 0 e 300.	0	Essa configuração define, em segundos, o período de carência máximo para o encerramento do pod durante a remoção.

A tabela a seguir mostra as opções modificáveis para a flag evictionSoft. As mesmas opções também se aplicam às flags evictionSoftGracePeriod e evictionMinimumReclaim com restrições diferentes.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
memoryAvailable	O valor precisa ser uma quantidade maior que 100Mi e menor que 50% da memória do nó.	none	Essa configuração representa a quantidade de memória disponível antes da remoção suave. Define a quantidade do indicador memory.available no kubelet .
nodefsAvailable	O valor precisa estar entre 10% e 50%.	none	Essa configuração representa o nodefs disponível antes da remoção suave. Define a quantidade do indicador nodefs.available no kubelet .
nodefsInodesFree	O valor precisa estar entre 5% e 50%.	none	Essa configuração representa os inodes nodefs que estão livres antes da remoção suave. Define a quantidade do indicador nodefs.inodesFree no kubelet .
imagefsAvailable	O valor precisa estar entre 15% e 50%.	none	Essa configuração representa o imagefs disponível antes da remoção suave. Define a quantidade de indicador imagefs.available no kubelet .
imagefsInodesFree	O valor precisa estar entre 5% e 50%.	none	Essa configuração representa os inodes do imagefs que estão livres antes da remoção suave. Define a quantidade do indicador imagefs.inodesFree no kubelet.
pidAvailable	O valor precisa estar entre 10% e 50%.	none	Essa configuração representa os PIDs disponíveis antes da remoção suave. Define a quantidade do indicador pid.available no kubelet.
singleProcessOOMKill	O valor precisa ser true ou false.	true para nós cgroupv1 e false para nós cgroupv2.	Essa configuração define se os processos no contêiner são encerrados por falta de memória individualmente ou em grupo. Disponível nas versões 1.32.4-gke.1132000, 1.33.0-gke.1748000 ou mais recentes do GKE.

Gerenciamento de PID

A tabela a seguir descreve as opções modificáveis para gerenciamento de PID.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
podPidsLimit	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.

Logging

A tabela a seguir descreve as opções modificáveis para geração de registros.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
containerLogMaxSize	O valor precisa ser um número positivo e um sufixo de unidade entre 10Mi e 500Mi, inclusive.	10Mi	Essa configuração controla a opção containerLogMaxSize da política de rotação de registros de contêineres, que permite configurar o tamanho máximo de cada arquivo de registro. O valor padrão é 10Mi. As opções aceitas são Ki, Mi e Gi.
containerLogMaxFiles	O valor precisa ser um número inteiro entre 2 e 10, inclusive.	5	Essa configuração controla a opção containerLogMaxFiles da política de rotação de arquivos de registro do contêiner, que permite configurar o número máximo de arquivos permitidos para cada contêiner, respectivamente. O valor padrão é 5. O tamanho total do registro (container_log_max_size*container_log_max_files) por contêiner não pode exceder 1% do armazenamento total do nó.

Coleta de lixo de imagens

A tabela a seguir descreve as opções modificáveis para coleta de lixo de imagens.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
imageGCHighThresholdPercent	O valor precisa ser um número inteiro entre 10 e 85, inclusive, e maior que imageGcLowThresholdPercent.	85	Essa configuração define o percentual de uso de disco acima do qual a coleta de lixo de imagem é executada. Ele representa o maior uso de disco para coleta de lixo. A porcentagem é calculada dividindo o valor desse campo por 100.
imageGCLowThresholdPercent	O valor precisa ser um número inteiro entre 10 e 85, inclusive, e menor que imageGcHighThresholdPercent.	80	Essa configuração define a porcentagem de uso do disco antes da qual a coleta de lixo de imagem nunca é executada. Ele representa o menor uso de disco para coleta de lixo. A porcentagem é calculada dividindo o valor deste campo por 100.
imageMinimumGcAge	O valor precisa ser uma duração de tempo não maior que 2m. As unidades de tempo válidas são ns, us (ou µs), ms, s, m ou h.	2m	Essa configuração define a idade mínima de uma imagem não usada antes que ela seja coletada como lixo.
imageMaximumGcAge	O valor precisa ser uma duração de tempo.	0s	Essa configuração define a idade máxima que uma imagem pode ter sem ser usada antes de ser coletada como lixo. O valor padrão desse campo é 0s, o que o desativa. Assim, as imagens não serão coletadas como lixo com base no fato de não serem usadas. Quando especificado, esse valor precisa ser maior que o valor do campo imageMinimumGcAge. Disponível nas versões 1.30.7-gke.1076000, 1.31.3-gke.1023000 ou mais recentes do GKE.

Extração de imagens

A tabela a seguir descreve as opções modificáveis para extração de imagens.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
maxParallelImagePulls	O valor precisa ser um número inteiro entre 2 e 5, inclusive.	2 ou 3, dependendo do tipo de disco.	Essa configuração define o número máximo de extrações de imagens em paralelo. O valor padrão é decidido pelo tipo de disco de inicialização.

Segurança e operações não seguras

A tabela a seguir descreve as opções modificáveis para configurar a segurança e processar operações não seguras.

Configurações de kubelet	Restrições	Configuração padrão	Descrição
allowedUnsafeSysctls	Lista de sysctl nomes ou grupos. Os grupos sysctl permitidos são os seguintes: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	none	Essa configuração define uma lista de permissões separada por vírgulas de nomes ou grupos sysctl não seguros que podem ser definidos nos pods.sysctl
insecureKubeletReadonlyPortEnabled	O valor precisa ser booleano, true ou false.	true	Essa configuração desativa a porta somente leitura 10255 não segura kubelet 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.

Gerentes de recursos

O Kubernetes oferece um conjunto de gerenciadores de recursos. É possível configurar esses gerenciadores de recursos para coordenar e otimizar o alinhamento dos recursos de nós para pods configurados com requisitos específicos de CPUs, dispositivos e recursos de memória (hugepages).

A tabela a seguir descreve as opções modificáveis para os gerentes de recursos.

Configurações de 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 que estão na classe QoS Guaranteed e têm solicitações de CPU de número inteiro recebam CPUs exclusivas.
memoryManager.policy	O valor precisa ser None ou Static.	None	Essa configuração controla a política do Gerenciador de memória do kubelet. Com o valor padrão de None, o Kubernetes age da mesma forma que se o gerenciador de memória não estivesse presente. Se você definir esse valor como Static, a política do Memory Manager enviará dicas de topologia que dependem do tipo de pod. Para mais detalhes, consulte Política estática. Essa configuração é compatível com clusters que têm o plano de controle executando a versão 1.32.3-gke.1785000 ou mais recente do GKE.
topologyManager	O valor precisa ser uma das configurações aceitas para cada um dos campos. Não é possível definir o campo topologyManager ao usar as instruções do Terraform para adicionar a configuração a um pool de nós padrão.	policy: none scope: container	Essas configurações controlam a configuração do Gerenciador de topologia (kubelet) usando os subcampos policy e scope. O Topology Manager coordena o conjunto de componentes responsáveis pelas otimizações de desempenho relacionadas ao isolamento da CPU, à memória e à localidade do dispositivo. É possível definir as configurações de política e escopo de forma independente. Para mais informações sobre essas configurações, consulte Escopos e políticas do gerenciador de topologia. Os seguintes recursos do GKE são compatíveis com essa configuração: Clusters com o plano de controle executando a versão 1.32.3-gke.1785000 ou posterior do GKE. Para clusters com o plano de controle e nós executando a versão 1.33.0-gke.1712000 ou mais recente, o Topology Manager também recebe informações sobre a topologia da GPU. Nós com os seguintes tipos de máquina: A2, A3, A4, C3, C4, C4A, G2, G4, M3, N4

Opções de configuração de Sysctl

Para ajustar o desempenho do sistema, modifique os parâmetros do kernel do Linux. As tabelas nesta seção descrevem os vários parâmetros do kernel que podem ser configurados.

Parâmetros do sistema de arquivos (fs.*)

A tabela a seguir descreve os parâmetros modificáveis do sistema de arquivos do Linux. Essas configurações controlam o comportamento do sistema de arquivos do Linux, como limites de identificadores de arquivos e monitoramento de eventos.

Parâmetro Sysctl	Restrições	Descrição
fs.aio-max-nr	Precisa estar entre [65536, 4194304].	Essa configuração define o número máximo de solicitações assíncronas de E/S em todo o sistema.
fs.file-max	Precisa estar entre [104857, 67108864].	Essa configuração define o número máximo de descritores de arquivo que o kernel do Linux pode alocar.
fs.inotify.max_user_instances	Precisa estar entre [8192, 1048576].	Essa configuração define o número máximo de instâncias inotify que um usuário pode criar.
fs.inotify.max_user_watches	Precisa estar entre [8192, 1048576].	Essa configuração define o número máximo de observações inotify que um usuário pode criar.
fs.nr_open	Precisa estar entre [1048576, 2147483584].	Essa configuração define o número máximo de descritores de arquivos que podem ser abertos por um processo.

Parâmetros do kernel (kernel.*)

A tabela a seguir descreve os parâmetros modificáveis do kernel do Linux. Essas configurações configuram funcionalidades principais do kernel, incluindo alocação de memória compartilhada.

Parâmetro sysctl	Restrições	Descrição
kernel.shmmni	Precisa estar entre [4096, 32768].	Essa configuração define o número máximo de segmentos de memória compartilhada em todo o sistema. Se esse valor não for definido, o padrão será 4096.
kernel.shmmax	Precisa estar entre [0, 18446744073692774399].	Essa configuração define o tamanho máximo, em bytes, de um único segmento de memória compartilhada permitido pelo kernel. Esse valor será ignorado se for maior que a quantidade real de RAM, o que significa que toda a RAM disponível pode ser compartilhada.
kernel.shmall	Precisa estar entre [0, 18446744073692774399].	Essa configuração define a quantidade total de páginas de memória compartilhada que podem ser usadas no sistema de uma só vez. Uma página tem 4.096 bytes nas arquiteturas AMD64 e Intel 64.
kernel.perf_event_paranoid	Precisa estar entre [-1, 3].	Essa configuração controla o uso do sistema de eventos de desempenho por usuários sem privilégios e sem CAP_PERFMON. O valor padrão é 2 no kernel.
kernel.sched_rt_runtime_us	Precisa estar entre [-1, 1000000].	Essa configuração define um limite global de quanto tempo o agendamento em tempo real pode usar.
kernel.softlockup_panic	Opcional (booleano).	Essa configuração controla se o kernel entra em pânico quando um bloqueio parcial é detectado.
kernel.yama.ptrace_scope	Precisa estar entre [0, 3].	Essa configuração define o escopo e as restrições da chamada de sistema ptrace(), afetando a depuração e o rastreamento de processos. Os valores aceitos são: 0: permissões clássicas de ptrace. 1: ptrace restrito, que é o padrão em muitas distribuições. Apenas processos filhos ou CAP_SYS_PTRACE. 2: ptrace somente para administradores. Somente processos com CAP_SYS_PTRACE. 3: sem ptrace. As chamadas de ptrace não são permitidas.
kernel.kptr_restrict	Precisa estar entre [0, 2].	Essa configuração indica se há restrições na exposição de endereços do kernel por /proc e outras interfaces.
kernel.dmesg_restrict	Opcional (booleano).	Essa configuração indica se os usuários sem privilégios estão impedidos de usar dmesg(8) para ver mensagens do buffer de registro do kernel.
kernel.sysrq	Precisa estar entre [0, 511].	Essa configuração controla as funções que podem ser invocadas pela tecla SysRq. Os valores possíveis incluem o seguinte: 0: desativa o sysrq completamente. 1: ativa todas as funções sysrq. >1: máscara de bits de funções sysrq permitidas. Para mais informações, consulte Linux Magic System Request Key Hacks (em inglês).

Parâmetros de rede (net.*)

A tabela a seguir descreve os parâmetros modificáveis para rede. Essas configurações ajustam o desempenho e o comportamento da pilha de rede, desde buffers de soquete até o rastreamento de conexões.

Parâmetro sysctl	Restrições	Descrição
net.core.busy_poll	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o tempo limite de sondagem ocupada de baixa latência para sondagem e seleção. Ele representa o tempo aproximado em µs para o loop ocupado aguardando eventos.
net.core.busy_read	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o tempo limite de sondagem ocupada de baixa latência para leituras de soquete. Representa o tempo aproximado em µs para o loop ocupado aguardando pacotes na fila do dispositivo.
net.core.netdev_max_backlog	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o número máximo de pacotes enfileirados no lado de entrada quando a interface recebe pacotes mais rápido do que o kernel pode processar.
net.core.rmem_default	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o tamanho padrão do buffer de soquete de recebimento, em bytes.
net.core.rmem_max	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o tamanho máximo do buffer de soquete de recebimento, em bytes.
net.core.wmem_default	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o valor padrão, em bytes, do buffer de envio do soquete.
net.core.wmem_max	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o tamanho máximo do buffer de soquete de envio, em bytes.
net.core.optmem_max	Qualquer número inteiro positivo menor que 2147483647.	Essa configuração define o tamanho máximo do buffer auxiliar permitido por soquete.
net.core.somaxconn	Precisa estar entre [128, 2147483647].	Essa configuração define o limite do backlog socket listen(), conhecido no espaço do usuário como SOMAXCONN. Essa configuração é definida como 128 por padrão.
net.ipv4.tcp_rmem	{min, default, max} (cada um > 0, memória em bytes).	Essa configuração define o tamanho mínimo, em bytes, do buffer de recebimento usado por soquetes UDP na moderação. A configuração padrão é uma página.
net.ipv4.tcp_wmem	{min, default, max} (cada um > 0, memória em bytes).	Essa configuração define o tamanho mínimo, em bytes, do buffer de envio usado por sockets UDP na moderação. A configuração padrão é uma página.
net.ipv4.tcp_tw_reuse	Precisa estar entre {0, 1}.	Essa configuração define se é permitido reutilizar sockets no estado TIME_WAIT para novas conexões quando isso é seguro do ponto de vista do protocolo. O valor padrão é 0.
net.ipv4.tcp_max_orphans	Precisa estar entre [16384, 262144].	Essa configuração define o número máximo de sockets TCP que não estão anexados a nenhum identificador de arquivo do usuário.
net.ipv4.tcp_max_tw_buckets	Precisa estar entre [4096, 2147483647].	Essa configuração define o número máximo de sockets de espera de tempo mantidos pelo sistema simultaneamente. Se esse número for excedido, o soquete de espera será destruído imediatamente e um aviso será impresso.
net.ipv4.tcp_syn_retries	Precisa estar entre [1, 127].	Essa configuração define o número de vezes que os SYNs iniciais de uma tentativa de conexão TCP ativa são retransmitidos.
net.ipv4.tcp_ecn	Precisa estar entre [0, 2].	Essa configuração controla o uso da Notificação de congestionamento explícita (ECN, na sigla em inglês) pelo TCP. A ECN é usada apenas quando as duas extremidades da conexão TCP indicam suporte a ela.
net.ipv4.tcp_mtu_probing	Precisa estar entre [0, 2].	Essa configuração controla a descoberta de MTU de caminho da camada de pacotes TCP. Os valores aceitos são: 0: desativada. 1: desativado por padrão, ativado quando um buraco negro ICMP é detectado. 2: sempre ativado. Use o MSS inicial de tcp_base_mss.
net.ipv4.tcp_congestion_control	Precisa ser um dos valores aceitos da coluna Descrição.	Essa configuração não é compatível quando o GKE Dataplane V2 está ativado no cluster. Os valores compatíveis a seguir dependem do tipo de imagem: COS: reno, cubic, bbr, lp Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6	Booleano.	Mudar esse valor é o mesmo que mudar a configuração conf/default/disable_ipv6 e também todas as configurações disable_ipv6 por interface para o mesmo valor.
net.ipv6.conf.default.disable_ipv6	Booleano.	Essa configuração desativa a operação do IPv6.
net.netfilter.nf_conntrack_acct	Precisa estar entre {0, 1}.	Essa configuração ativa a contabilização do fluxo de acompanhamento de conexões. O valor padrão é 0, o que significa que a configuração está desativada. Disponível nas versões 1.32.0-gke.1448000 ou mais recentes do GKE.
net.netfilter.nf_conntrack_max	Precisa estar entre [65536, 4194304].	Essa configuração define o tamanho da tabela de rastreamento de conexão. Se o valor máximo for atingido, a nova conexão vai falhar. Disponível nas versões 1.32.0-gke.1448000 ou mais recentes do GKE.
net.netfilter.nf_conntrack_buckets	Precisa estar entre [65536, 524288].	Essa configuração define o tamanho da tabela hash. A configuração recomendada é o resultado do seguinte: nf_conntrack_max = nf_conntrack_buckets * 4. Disponível nas versões 1.32.0-gke.1448000 ou mais recentes do GKE.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Precisa estar entre [60, 3600].	Essa configuração define o período, em segundos, em que as conexões TCP podem permanecer no estado CLOSE_WAIT. O valor padrão é 3600. Disponível nas versões 1.32.0-gke.1448000 ou mais recentes do GKE.
net.netfilter.nf_conntrack_tcp_timeout_established	Precisa estar entre [600, 86400].	Essa configuração define a duração, em segundos, das conexões inativas antes que elas sejam excluídas automaticamente da tabela de rastreamento de conexões. Disponível nas versões 1.32.0-gke.1448000 ou mais recentes do GKE.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	Precisa estar entre [1, 600].	Essa configuração define o período, em segundos, em que as conexões TCP podem permanecer no estado TIME_WAIT. O valor padrão é 120. Disponível nas versões 1.32.0-gke.1448000 ou mais recentes do GKE.

Parâmetros de memória virtual (vm.*)

A tabela a seguir descreve os parâmetros modificáveis do subsistema de memória virtual. Essas configurações gerenciam o subsistema de memória virtual, que controla como o kernel processa a memória, a troca e o armazenamento em cache de disco.

Parâmetro sysctl	Restrições	Descrição
vm.max_map_count	Precisa estar entre [65536, 2147483647].	Esse arquivo define o número máximo de áreas de mapeamento de memória que um processo pode ter.
vm.dirty_background_ratio	Precisa estar entre [1, 100].	Essa configuração define a porcentagem da memória do sistema que pode ser preenchida com páginas sujas antes que as linhas de execução de limpeza do kernel em segundo plano comecem a gravar de volta. O valor precisa ser menor que o valor do campo vm.dirty_ratio.
vm.dirty_background_bytes	Precisa estar entre [0, 68719476736].	Essa configuração define a quantidade de memória suja em que as linhas de execução do flusher do kernel em segundo plano iniciam o writeback. vm.dirty_background_bytes é a contraparte de vm.dirty_background_ratio. Apenas uma dessas configurações pode ser especificada.
vm.dirty_expire_centisecs	Precisa estar entre [0, 6000].	Essa configuração define a idade máxima, em centésimos de segundo, que os dados sujos podem permanecer na memória antes que as linhas de execução do flusher do kernel os gravem no disco.
vm.dirty_ratio	Precisa estar entre [1, 100].	Essa configuração define a porcentagem da memória do sistema que pode ser preenchida com páginas sujas antes que os processos que realizam gravações sejam forçados a bloquear e gravar dados sujos de forma síncrona.
vm.dirty_bytes	Precisa estar entre [0, 68719476736].	Essa configuração define a quantidade de memória suja em que um processo que gera gravações em disco inicia o writeback. O valor mínimo permitido para vm.dirty_bytes é de duas páginas em bytes. Qualquer valor abaixo desse limite será ignorado, e a configuração antiga será mantida. vm.dirty_bytes é a contraparte de vm.dirty_ratio. Apenas uma dessas configurações pode ser especificada.
vm.dirty_writeback_centisecs	Precisa estar entre [0, 1000].	Essa configuração define o intervalo, em centésimos de segundo, em que as linhas de execução do flusher do kernel são ativadas para gravar dados sujos antigos no disco.
vm.overcommit_memory	Precisa ser entre {0, 1, 2}.	Essa configuração determina a estratégia do kernel para lidar com o excesso de memória. Os valores são os seguintes: 0: rejeitar alocações grandes 1: sempre permitir 2: impede o commit além da troca + proporção de RAM
vm.overcommit_ratio	Precisa estar entre [0, 100].	Essa configuração define a porcentagem de RAM física permitida para overcommit quando o valor do campo vm.overcommit_memory é definido como 2.
vm.vfs_cache_pressure	Precisa estar entre [0, 100].	Essa configuração ajusta a preferência do kernel para recuperar a memória usada para caches de dentry (diretório) e inode.
vm.swappiness	Precisa estar entre [0, 200].	Essa configuração controla a tendência do kernel de mover processos da memória física para o disco de troca. O valor padrão é 60.
vm.watermark_scale_factor	Precisa estar entre [10, 3000].	Essa configuração controla a agressividade do kswapd. Ele define a memória restante antes que o kswapd seja ativado e a memória a ser liberada antes que ele entre em suspensão. O valor padrão é 10.
vm.min_free_kbytes	Precisa estar entre [67584, 1048576].	Essa configuração define a memória livre mínima antes de OOM. O valor padrão é 67584.

Para mais informações sobre os valores aceitos para cada flag sysctl, consulte a documentação da CLI gcloud --system-config-from-file.

Diferentes namespaces Linux podem ter valores exclusivos para uma determinada flag sysctl, mas outras podem ser globais para todo o nó. A atualização das opções sysctl usando uma configuração do sistema de nós ajuda a garantir que sysctl seja aplicado globalmente no nó e em cada namespace, para que cada pod tenha valores sysctl idênticos em cada namespace do Linux.

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

Atenção: o GKE descontinua cgroupv1 com a versão secundária 1.31 e remove o suporte para cgroupv1 com a versão 1.35. Para mais informações sobre como o GKE está fazendo a transição para cgroupv2 e como você pode preparar seus clusters para essa transição, consulte Migrar nós para o cgroupv2 do Linux.

O ambiente de execução do contêiner e o kubelet 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 mais informações, 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 padrão que executam a versão 1.26 e mais recentes e cgroupv1 para pools de nós que executam versões anteriores à 1.26. Para pools de nós criados com provisionamento automático de nós, a configuração do cgroup depende da versão inicial do cluster, não da versão do pool de nós. cgroupv1 não é compatível com máquinas Arm.

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. O upgrade de um pool de nós atual que usa cgroupv1 para a versão 1.26 não muda a configuração para cgroupv2. Os pools de nós atuais que executam uma versão anterior à 1.26 e que não incluem uma configuração de cgroup personalizada vão continuar usando cgroupv1. Para mudar a configuração, especifique explicitamente cgroupv2 para o pool de nós atual.

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'

Confira 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 containerd ou Ubuntu com containerd 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.
• Se você usa ferramentas de monitoramento ou de terceiros, verifique se elas são compatíveis com o cgroupv2.
• Se você usa cargas de trabalho Java (JDK), 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 mudanças. Depois de adicionar a configuração a um pool de nós e recriar os nós, verifique a nova configuração.

É possível verificar a configuração do cgroup para nós em um pool de nós usando a CLI gcloud ou a ferramenta de linha de comando kubectl:

CLI da gcloud

Verifique a configuração do cgroup para um pool de nós:

gcloud container node-pools describe POOL_NAME \
  --format='value(Config.effectiveCgroupMode)'

Substitua POOL_NAME pelo nome do pool de nós.

A saída possível é uma das seguintes:

• EFFECTIVE_CGROUP_MODE_V1: os nós usam cgroupv1
• EFFECTIVE_CGROUP_MODE_V2: os nós usam cgroupv2

A saída mostra apenas a nova configuração de cgroup depois que os nós no pool de nós são recriados. A saída fica vazia para pools de nós do Windows Server, que não são compatíveis com cgroup.

kubectl

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

1. Crie um shell interativo com qualquer nó no pool de nós. No comando, substitua mynode 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áginas enormes do Linux

É possível usar um arquivo de configuração do sistema de nós para pré-alocar hugepages. O Kubernetes oferece suporte a páginas enormes pré-alocadas como um tipo de recurso, semelhante à CPU ou à memória.

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 das páginas grandes alocadas não pode exceder o seguinte:
  • Em máquinas com menos de 30 GB de memória: 60% da memória total. Por exemplo, em uma máquina e2-standard-2 com 8 GB de memória, não é possível alocar mais de 4,8 GB para páginas grandes.
  • Em máquinas com mais de 30 GB de memória: 80% da memória total. Por exemplo, em máquinas c4a-standard-8 com 32 GB de memória, as páginas grandes não podem exceder 25,6 GB.
• Páginas enormes de 1 GB estão disponíveis apenas nos tipos de máquina A3, C2D, C3, C3D, C4, C4A, C4D, CT5E, CT5LP, CT6E, H3, M2, M3, M4 ou Z3.

A tabela a seguir descreve as configurações modificáveis para páginas enormes do Linux.

Parâmetro de configuração	Restrições	Valor padrão	Descrição
hugepage_size2m	Contagem de números inteiros. Sujeito aos limites de alocação de memória descritos anteriormente.	0	Essa configuração pré-aloca um número específico de hugepages de 2 MB.
hugepage_size1g	Contagem de números inteiros. Sujeito às limitações de memória e tipo de máquina descritas anteriormente.	0	Essa configuração pré-aloca um número específico de hugepages de 1 GB.

Hugepages transparentes (THP)

Use um arquivo de configuração do sistema de nós para ativar o suporte a páginas enormes transparentes do kernel do Linux. Com o THP, o kernel atribui automaticamente hugepages a processos sem pré-alocação manual.

A tabela a seguir descreve os parâmetros modificáveis para THP.

Parâmetro de configuração	Valores aceitos	Valor padrão	Descrição
transparentHugepageEnabled	TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: a página enorme transparente está ativada em todo o sistema. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: a página enorme transparente é ativada nas regiões MADV_HUGEPAGE. Essa é a configuração padrão do kernel. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: a página enorme transparente está desativada. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: o valor padrão. O GKE não modifica a configuração do kernel.	UNSPECIFIED	Essa configuração controla se o THP está ativado para memória anônima.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: um aplicativo que solicita THP para em caso de falha na alocação e recupera páginas e compacta a memória diretamente para alocar um THP imediatamente. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: um aplicativo ativa o kswapd em segundo plano para recuperar páginas e ativa o kcompactd para compactar a memória, de modo que o THP esteja disponível em breve. É responsabilidade do khugepaged instalar as páginas THP mais tarde. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: um aplicativo entra na recuperação e compactação diretas como de costume, mas apenas para regiões que usaram madvise(MADV_HUGEPAGE). Todas as outras regiões ativam o kswapd em segundo plano para recuperar páginas e o kcompactd para compactar a memória, de modo que o THP esteja disponível em breve. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: um aplicativo entra na recuperação e compactação diretas como de costume, mas apenas para regiões que usaram madvise(MADV_HUGEPAGE). Todas as outras regiões ativam o kswapd em segundo plano para recuperar páginas e o kcompactd para compactar a memória, de modo que o THP esteja disponível em breve. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: um aplicativo nunca entra em recuperação ou compactação direta. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: o valor padrão. O GKE não modifica a configuração do kernel.	UNSPECIFIED	Essa configuração define a configuração de desfragmentação para THP.

O THP está disponível no GKE versão 1.33.2-gke.4655000 ou mais recente. Ele também é ativado por padrão em novos pools de nós de TPU na versão 1.33.2-gke.4655000 ou mais recente do GKE. O THP não é ativado quando você faz upgrade de pools de nós atuais para uma versão compatível ou mais recente.

A seguir

• Saiba mais sobre pools de nós.
• Saiba como criar pools de nós.