Personalizar a configuração do sistema de nós

Padrão

Este documento mostra como personalizar a configuração dos nós do Google Kubernetes Engine (GKE) através de um ficheiro de configuração denominado configuração do sistema de nós.

Uma configuração do sistema de nós é um ficheiro de configuração que permite ajustar um conjunto limitado de definições do sistema. No seu conjunto de nós, pode usar uma configuração do sistema de nós para especificar definições personalizadas para o agente de nós do Kubernetes kubelet e para as configurações do kernel do Linux de sysctl baixo nível.

Atenção: alterar as definições de kubelet ou sysctl pode levar a um comportamento não intencional que pode afetar negativamente o estado das suas cargas de trabalho e nós. Teste exaustivamente quaisquer alterações kubelet ou sysctl antes de as implementar 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 seus conjuntos de nós padrão do GKE. Tenha em atenção que, uma vez que os clusters do GKE Autopilot têm um ambiente de nós mais gerido, as respetivas opções de configuração do sistema de nós diretos são limitadas em comparação com os conjuntos de nós do GKE Standard.

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

As configurações do sistema de nós oferecem as seguintes vantagens:

• Ajuste do desempenho: otimize o desempenho da pilha de rede, a gestão de memória, o agendamento da CPU ou o comportamento de E/S para aplicações exigentes, como preparação ou fornecimento de IA, bases de dados, servidores Web com tráfego elevado ou serviços sensíveis à latência.
• Reforço da segurança: aplique definições de segurança específicas ao nível do kernel ou restrinja determinados comportamentos do sistema para reduzir a superfície de ataque.
• Gestão de recursos: ajuste a forma como o kubelet gere os PIDs, o espaço em disco, a recolha de lixo de imagens ou os recursos de CPU e memória.
• Compatibilidade da carga de trabalho: ajuda a garantir que o ambiente do nó cumpre os pré-requisitos específicos para software especializado ou aplicações mais antigas que requerem definições específicas do kernel.

Outras opções para personalizar as configurações dos nós

Também pode personalizar a configuração do nó através de outros métodos:

• Ficheiro de configuração de tempo de execução: para personalizar um tempo de execução de contentores do containerd nos seus nós do GKE, pode usar um ficheiro diferente denominado ficheiro de configuração de tempo de execução. Para mais informações, consulte o artigo Personalize a configuração do containerd nos nós do GKE.
• ComputeClass: pode especificar atributos de nós na especificação de ComputeClass do GKE. Pode usar ComputeClasses no modo GKE Autopilot e no modo padrão na versão 1.32.1-gke.1729000 do GKE e posteriores. Para mais informações, consulte o artigo Personalize a configuração do sistema de nós.
• DaemonSets: também pode usar DaemonSets para personalizar nós. Para mais informações, consulte o artigo Inicializar automaticamente nós do GKE com DaemonSets.

As configurações do sistema de nós não são suportadas em nós do Windows Server.

Antes de começar

Antes de começar, certifique-se de que faz o seguinte:

• Instale ferramentas de linhas de comando:
  • Se usar os exemplos da CLI gcloud neste documento, certifique-se de que instala e configura a CLI Google Cloud.
  • Se usar os exemplos do Terraform, certifique-se de que instala e configura o Terraform.
• Conceder autorizações: precisa das autorizações de IAM adequadas para criar e atualizar clusters do GKE e conjuntos de nós, como container.clusterAdmin ou uma função diferente com autorizações equivalentes.
• Planeie uma potencial interrupção da carga de trabalho: as configurações de nós personalizadas são aplicadas ao nível do conjunto de nós. Normalmente, as alterações acionam uma atualização contínua dos nós no conjunto, o que envolve recriar os nós. Planeie uma potencial interrupção da carga de trabalho e use orçamentos de interrupção de pods (PDBs) quando apropriado.
• Faça uma cópia de segurança e teste todas as alterações: teste sempre as alterações de configuração num ambiente de preparação ou desenvolvimento antes de as aplicar à produção. As definições incorretas podem levar à instabilidade do nó ou a falhas de carga de trabalho.
• Reveja as predefinições do GKE: as imagens dos nós do GKE incluem configurações predefinidas otimizadas. Personalize os parâmetros apenas se tiver uma necessidade específica e compreender o impacto das alterações.

Use uma configuração do sistema de nós no modo padrão do GKE

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

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

1. Crie um ficheiro de configuração. Este ficheiro contém as suas configurações do kubelet e do sysctl.
2. Adicione a configuração quando criar um cluster ou quando criar ou atualizar um conjunto de nós.

Crie um ficheiro de configuração

Escreva a configuração do sistema de nós em YAML. O exemplo seguinte 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, aplica-se o seguinte:

• O campo cpuManagerPolicy: static configura o kubelet para usar a política de gestão de CPU estática. + O campo net.core.somaxconn: '2048' limita a fila de tarefas pendentes a 2048 bytes.socket listen()
• O campo net.ipv4.tcp_rmem: '4096 87380 6291456' define o valor mínimo, predefinido e máximo da memória intermédia de receção do soquete TCP como 4096 bytes, 87 380 bytes e 6 291 456 bytes, respetivamente.

Se quiser adicionar configurações apenas para o kubelet ou o sysctl, inclua apenas essa secção na configuração do sistema de nós. Por exemplo, para adicionar uma configuração de kubelet, crie o seguinte ficheiro:

kubeletConfig:
  cpuManagerPolicy: static

Para ver uma lista completa dos campos que pode adicionar à configuração do sistema de nós, consulte as secções Opções de configuração do Kubelet e Opções de configuração do Sysctl.

Adicione a configuração a um grupo de nós padrão

Depois de criar a configuração do sistema de nós, adicione a flag --system-config-from-file através da CLI do Google Cloud. Pode adicionar esta flag quando cria um cluster ou quando cria ou atualiza um conjunto de nós. Não pode adicionar uma configuração do sistema de nós através da consola Google Cloud .

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

Pode adicionar uma configuração do sistema de nós durante a criação do cluster através da CLI gcloud ou do Terraform. As instruções que se seguem aplicam a configuração do sistema do nó ao conjunto de nós predefinido:

CLI gcloud

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

Substitua o seguinte:

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

Depois de aplicar uma configuração do sistema de nós, o conjunto de nós predefinido do cluster usa as definições que definiu.

Terraform

Para criar um cluster regional com uma configuração do sistema de nós personalizada através do Terraform, consulte o seguinte exemplo:

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 a utilização do Terraform, consulte o artigo Apoio técnico do Terraform para o GKE.

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

Pode adicionar uma configuração do sistema de nós quando usa a CLI gcloud ou o Terraform para criar um novo conjunto de nós.

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

CLI gcloud

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

Substitua o seguinte:

• POOL_NAME: o nome do seu node pool
• CLUSTER_NAME: o nome do cluster ao qual quer adicionar um node pool
• LOCATION: a zona de computação ou a região do cluster
• SYSTEM_CONFIG_PATH: o caminho para o ficheiro que contém as configurações de kubelet e sysctl

Terraform

Para criar um node pool com uma configuração do sistema de nós personalizada através do Terraform, consulte o seguinte exemplo:

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 a utilização do Terraform, consulte o artigo Apoio técnico do Terraform para o GKE.

Atualize a configuração do sistema de nós de um node pool existente

Pode atualizar a configuração do sistema de nós de um conjunto de nós existente executando o seguinte comando:

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

Substitua o seguinte:

• POOL_NAME: o nome do node pool que quer atualizar
• CLUSTER_NAME: o nome do cluster que quer atualizar
• LOCATION: a zona de computação ou a região do cluster
• SYSTEM_CONFIG_PATH: o caminho para o ficheiro que contém as configurações do kubelet e do sysctl

Esta alteração requer a recriação dos nós, o que pode causar interrupções nas suas cargas de trabalho em execução. Para mais informações acerca desta alteração específica, encontre a linha correspondente na tabela alterações manuais que recriam os nós através de uma estratégia de atualização de nós sem respeitar as políticas de manutenção.

Para mais informações sobre as atualizações de nós, consulte o artigo Planeamento de interrupções de atualizações de nós.

Aviso: o GKE começa imediatamente a recriar os nós para esta alteração através da estratégia de atualização de nós, independentemente das políticas de manutenção ativas. O GKE depende da disponibilidade de recursos para a alteração. A desativação das atualizações automáticas não impede esta alteração.

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

Para editar a configuração do sistema de um nó, pode criar um novo conjunto de nós com a configuração pretendida ou atualizar a configuração do sistema de nós de um conjunto de nós existente.

Edite criando um node pool

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

1. Crie um ficheiro de configuração com a configuração que quer.
2. Adicione a configuração a um novo conjunto de nós.
3. Migre as suas cargas de trabalho para o novo conjunto de nós.
4. Elimine o node pool antigo.

Edite atualizando um node pool existente

Para editar a configuração do sistema de nós de um node pool existente, siga as instruções no separador Atualizar node pool para adicionar a configuração a um node pool. Quando atualiza uma configuração do sistema de nós e a nova configuração substitui a configuração do sistema existente do node pool, os nós têm de ser recriados. Se omitir parâmetros durante uma atualização, os parâmetros são definidos para as respetivas predefinições.

Se quiser repor a configuração do sistema do nó para as predefinições, atualize o ficheiro de configuração com valores vazios para os campos kubelet e sysctl, por exemplo:

kubeletConfig: {}
linuxConfig:
  sysctl: {}

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

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

1. Crie um node pool.
2. Migre as suas cargas de trabalho para o novo conjunto de nós.
3. Elimine o node pool que tem a configuração do sistema de nós antiga.

Opções de configuração para o kubelet

As tabelas nesta secção descrevem as opções de kubelet que pode modificar.

Gestão da CPU

A tabela seguinte descreve as opções de gestão da CPU para o kubelet.

kubelet definições de config	Restrições	Predefinição	Descrição
cpuCFSQuota	Tem de ser true ou false.	true	Esta definição aplica o limite de CPU do pod. Se definir este valor como false, significa que os limites de CPU para os pods são ignorados. Ignorar os limites de CPU pode ser benéfico em determinados cenários em que os pods são sensíveis aos limites de CPU. O risco de desativar o cpuCFSQuota é que um Pod não autorizado pode consumir mais recursos da CPU do que o pretendido.
cpuCFSQuotaPeriod	Tem de ser uma duração.	"100ms"	Esta definição define o valor do período da quota do CFS da CPU, cpu.cfs_period_us, que especifica o período com que o acesso de um cgroup aos recursos da CPU deve ser realocado. Esta opção permite-lhe ajustar o comportamento de limitação da CPU.

Gestão e eliminação de memória

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

kubelet definições de config	Restrições	Predefinição	Descrição
evictionSoft	Mapa de nomes de sinais. Para restrições de valores, consulte a tabela seguinte.	none	Esta definição mapeia os nomes dos sinais para uma quantidade ou uma percentagem que define os limites de remoção temporária. Um limite de remoção suave tem de ter um período de tolerância. O kubelet não remove os pods até que o período de tolerância seja excedido.
evictionSoftGracePeriod	Mapa de nomes de sinais. Para cada nome de sinal, o valor tem de ser uma duração positiva inferior a 5m. As unidades de tempo válidas são ns, us (ou µs), ms, s ou m.	none	Esta definição mapeia os nomes dos sinais para durações que definem os períodos de tolerância para os limites de rejeição parcial. Cada limite de remoção temporária tem de ter um período de tolerância correspondente.
evictionMinimumReclaim	Mapa de nomes de sinais. Para cada nome de sinal, o valor tem de ser uma percentagem positiva inferior a 10%.	none	Esta definição mapeia os nomes dos sinais para percentagens que definem a quantidade mínima de um determinado recurso que o kubelet reclama quando realiza uma remoção de pods.
evictionMaxPodGracePeriodSeconds	O valor tem de ser um número inteiro entre 0 e 300.	0	Esta definição define, em segundos, o período de tolerância máximo para o encerramento do pod durante a expulsão.

A tabela seguinte 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.

kubelet definições de config	Restrições	Predefinição	Descrição
memoryAvailable	O valor tem de ser uma quantidade superior a 100Mi e inferior a 50% da memória do nó.	none	Esta definição representa a quantidade de memória disponível antes da remoção temporária. Define a quantidade do sinal memory.available no kubelet .
nodefsAvailable	O valor tem de estar entre 10% e 50%.	none	Esta definição representa o nodefs disponível antes da remoção temporária. Define a quantidade do sinal nodefs.available no kubelet .
nodefsInodesFree	O valor tem de estar entre 5% e 50%.	none	Esta definição representa os inodos nodefs que estão livres antes da remoção temporária. Define a quantidade do sinal nodefs.inodesFree no kubelet .
imagefsAvailable	O valor tem de estar entre 15% e 50%.	none	Esta definição representa os imagefs disponíveis antes da remoção temporária. Define a quantidade de sinal imagefs.available no kubelet .
imagefsInodesFree	O valor tem de estar entre 5% e 50%.	none	Esta definição representa os inodos imagefs que estão livres antes da remoção temporária. Define a quantidade do sinal imagefs.inodesFree no kubelet.
pidAvailable	O valor tem de estar entre 10% e 50%.	none	Esta definição representa os PIDs disponíveis antes da remoção temporária. Define a quantidade do sinal pid.available no kubelet.
singleProcessOOMKill	O valor tem de ser true ou false.	true para nós cgroupv1 e false para nós cgroupv2.	Esta definição determina se os processos no contentor são terminados por falta de memória individualmente ou como um grupo. Disponível nas versões 1.32.4-gke.1132000, 1.33.0-gke.1748000 ou posteriores do GKE.

Gestão de PIDs

A tabela seguinte descreve as opções modificáveis para a gestão de PIDs.

kubelet definições de config	Restrições	Predefinição	Descrição
podPidsLimit	O valor tem de estar entre 1024 e 4194304.	none	Esta definição define o número máximo de IDs de processos (PIDs) que cada Pod pode usar.

Registo

A tabela seguinte descreve as opções modificáveis para o registo.

kubelet definições de config	Restrições	Predefinição	Descrição
containerLogMaxSize	O valor tem de ser um número positivo e um sufixo de unidade entre 10Mi e 500Mi, inclusive.	10Mi	Esta definição controla a definição containerLogMaxSize da política de rotação de registos do contentor, que lhe permite configurar o tamanho máximo de cada ficheiro de registo. O valor predefinido é 10Mi. As unidades válidas são Ki, Mi e Gi.
containerLogMaxFiles	O valor tem de ser um número inteiro entre 2 e 10, inclusive.	5	Esta definição controla a definição containerLogMaxFiles da política de rotação de ficheiros de registo do contentor, que lhe permite configurar o número máximo de ficheiros permitidos para cada contentor, respetivamente. O valor predefinido é 5. O tamanho total do registo (container_log_max_size*container_log_max_files) por contentor não pode exceder 1% do armazenamento total do nó.

Recolha de lixo de imagens

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

kubelet definições de config	Restrições	Predefinição	Descrição
imageGCHighThresholdPercent	O valor tem de ser um número inteiro entre 10 e 85, inclusive, e superior a imageGcLowThresholdPercent.	85	Esta definição define a percentagem de utilização do disco acima da qual é executada a recolha de lixo de imagens. Representa a utilização máxima do disco para recolher lixo. A percentagem é calculada dividindo o valor deste campo por 100.
imageGCLowThresholdPercent	O valor tem de ser um número inteiro entre 10 e 85, inclusive, e inferior a imageGcHighThresholdPercent.	80	Esta definição define a percentagem de utilização do disco antes da qual a recolha de lixo de imagens nunca é executada. Representa a utilização de disco mais baixa para a qual se deve recolher lixo. A percentagem é calculada dividindo o valor deste campo por 100.
imageMinimumGcAge	O valor tem de ser uma duração não superior a 2m. As unidades de tempo válidas são ns, us (ou µs), ms, s, m ou h.	2m	Esta definição define a idade mínima de uma imagem não utilizada antes de ser recolhida como lixo.
imageMaximumGcAge	O valor tem de ser uma duração.	0s	Esta definição define a idade máxima que uma imagem pode ter sem ser usada antes de ser recolhida como lixo. O valor predefinido deste campo é 0s, o que desativa este campo. Assim, as imagens não são eliminadas com base no facto de não serem usadas. Quando este valor é especificado, tem de ser superior ao valor do campo imageMinimumGcAge. Disponível nas versões 1.30.7-gke.1076000, 1.31.3-gke.1023000 ou posteriores do GKE.

Extração de imagens

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

kubelet definições de config	Restrições	Predefinição	Descrição
maxParallelImagePulls	O valor tem de ser um número inteiro entre 2 e 5, inclusive.	2 ou 3 com base no tipo de disco.	Esta definição define o número máximo de obtenções de imagens em paralelo. O valor predefinido é decidido pelo tipo de disco de arranque.

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

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

kubelet definições de config	Restrições	Predefiniçã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	Esta definição define uma lista de autorizações separada por vírgulas de nomes ou grupos sysctl não seguros que podem ser definidos nos Pods.sysctl
insecureKubeletReadonlyPortEnabled	O valor tem de ser um valor booleano, true ou false.	true	Esta definição desativa a porta kubelet de leitura apenas 10255 não segura em cada novo conjunto de nós no seu cluster. Se configurar esta definição neste ficheiro, não pode usar um cliente da API GKE para alterar a definição ao nível do cluster.

Gestores de recursos

O Kubernetes oferece um conjunto de gestores de recursos. Pode configurar estes Resource Managers para coordenar e otimizar o alinhamento dos recursos de nós para Pods que estão configurados com requisitos específicos para recursos de CPUs, dispositivos e memória (hugepages).

A tabela seguinte descreve as opções modificáveis para os gestores de recursos.

kubelet definições de config	Restrições	Predefinição	Descrição
cpuManagerPolicy	O valor tem de ser none ou static.	none	Esta definição controla a kubelet política do CPU Manager. O valor predefinido é none, que é o esquema de afinidade de CPU predefinido, não oferecendo afinidade além do que o agendador do SO faz automaticamente. Se definir este valor como static, os pods que estão na classe de QoS Guaranteed e têm pedidos de CPU inteiros podem ser atribuídos a CPUs exclusivas.
memoryManager.policy	O valor tem de ser None ou Static.	None	Esta definição controla a kubelet política do Gestor de memória. Com o valor predefinido de None, o Kubernetes funciona como se o gestor de memória não estivesse presente. Se definir este valor como Static, a política do gestor de memória envia sugestões de topologia que dependem do tipo de Pod. Para ver os detalhes, consulte a política estática. Esta definição é suportada para clusters com o plano de controlo a executar a versão 1.32.3-gke.1785000 ou posterior do GKE.
topologyManager	O valor tem de ser uma das definições suportadas para cada um dos respetivos campos. Não pode definir o campo topologyManager quando usa as instruções do Terraform para adicionar a configuração a um conjunto de nós padrão.	policy: none scope: container	Estas definições controlam a configuração do kubelet Topology Manager através dos subcampos policy e scope. O Topology Manager coordena o conjunto de componentes responsáveis pelas otimizações de desempenho relacionadas com o isolamento da CPU, a memória e a localidade do dispositivo. Pode definir as definições de política e âmbito de forma independente. Para mais informações sobre estas definições, consulte o artigo Âmbitos e políticas do gestor de topologia. Os seguintes recursos do GKE suportam esta definição: Clusters com o plano de controlo a executar a versão 1.32.3-gke.1785000 ou posterior do GKE. Para clusters com o plano de controlo e os nós a executar a versão 1.33.0-gke.1712000 ou posterior, o Topology Manager também recebe informações sobre a topologia da GPU. Nós com os seguintes tipos de máquinas: A2, A3, A4, C3, C4, C4A, G2, G4, M3 e N4

Opções de configuração do Sysctl

Para otimizar o desempenho do seu sistema, pode modificar os parâmetros do kernel do Linux. As tabelas nesta secção descrevem os vários parâmetros do kernel que pode configurar.

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

A tabela seguinte descreve os parâmetros modificáveis para o sistema de ficheiros do Linux. Estas definições controlam o comportamento do sistema de ficheiros Linux, como os limites de identificadores de ficheiros e a monitorização de eventos.

Parâmetro Sysctl	Restrições	Descrição
fs.aio-max-nr	Tem de ser um valor entre [65536, 4194304].	Esta definição define o número máximo de pedidos de E/S assíncronos ao nível do sistema.
fs.file-max	Tem de ser um valor entre [104857, 67108864].	Esta definição define o número máximo de identificadores de ficheiros que o kernel do Linux pode atribuir.
fs.inotify.max_user_instances	Tem de ser um valor entre [8192 e 1048576].	Esta definição define o número máximo de instâncias inotify que um utilizador pode criar.
fs.inotify.max_user_watches	Tem de ser um valor entre [8192 e 1048576].	Esta definição define o número máximo de observações inotify que um utilizador pode criar.
fs.nr_open	Tem de ser um valor entre [1048576 e 2147483584].	Esta definição define o número máximo de descritores de ficheiros que podem ser abertos por um processo.

Parâmetros do kernel (kernel.*)

A tabela seguinte descreve os parâmetros modificáveis para o kernel do Linux. Estas definições configuram as funcionalidades essenciais do kernel, incluindo a alocação de memória partilhada.

Parâmetro Sysctl	Restrições	Descrição
kernel.shmmni	Tem de ser um número entre [4096 e 32768].	Esta definição define o número máximo de segmentos de memória partilhada ao nível do sistema. Se este valor não estiver definido, é utilizado 4096 por predefinição.
kernel.shmmax	Tem de ser um valor entre [0, 18446744073692774399].	Esta definição define o tamanho máximo, em bytes, de um único segmento de memória partilhada permitido pelo kernel. Este valor é ignorado se for superior à quantidade real de RAM, o que significa que toda a RAM disponível pode ser partilhada.
kernel.shmall	Tem de ser um valor entre [0, 18446744073692774399].	Esta definição define a quantidade total de páginas de memória partilhada que podem ser usadas no sistema em simultâneo. Uma página tem 4096 bytes na arquitetura AMD64 e Intel 64.
kernel.perf_event_paranoid	Tem de ser um número entre [-1, 3].	Esta definição controla a utilização do sistema de eventos de desempenho por utilizadores sem privilégios sem CAP_PERFMON. O valor predefinido é 2 no kernel.
kernel.sched_rt_runtime_us	Tem de ser um valor entre [-1, 1000000].	Esta definição define um limite global sobre o tempo que o agendamento em tempo real pode usar.
kernel.softlockup_panic	Opcional (booleano).	Esta definição controla se o kernel entra em pânico quando é detetado um bloqueio temporário.
kernel.yama.ptrace_scope	Tem de ser um valor entre [0 e 3].	Esta definição define o âmbito e as restrições para a chamada do sistema ptrace(), o que afeta a depuração e a monitorização de processos. Os valores suportados incluem o seguinte: 0: autorizações ptrace clássicas. 1: ptrace restrito, que é a predefinição em muitas distribuições. Apenas processos filho ou CAP_SYS_PTRACE. 2: ptrace apenas para administradores. Apenas processos com CAP_SYS_PTRACE. 3: no ptrace. As chamadas ptrace não são permitidas.
kernel.kptr_restrict	Tem de ser um número entre [0, 2].	Esta definição indica se são impostas restrições à exposição de endereços do kernel através do /proc e de outras interfaces.
kernel.dmesg_restrict	Opcional (booleano).	Esta definição indica se os utilizadores sem privilégios estão impedidos de usar o dmesg(8) para ver mensagens da memória intermédia de registo do kernel.
kernel.sysrq	Tem de ser um número entre [0 e 511].	Esta definição controla as funções que podem ser invocadas através da tecla SysRq. Os valores possíveis incluem o seguinte: 0: desativa completamente o sysrq. 1: ativa todas as funções sysrq. >1: bitmask de funções sysrq permitidas. Para mais informações, consulte o artigo Linux Magic System Request Key Hacks.

Parâmetros de rede (net.*)

A tabela seguinte descreve os parâmetros modificáveis para a rede. Estas definições ajustam o desempenho e o comportamento da pilha de rede, desde as memórias intermédias de soquetes ao acompanhamento de ligações.

Parâmetro sysctl	Restrições	Descrição
net.core.busy_poll	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define o limite de tempo limite de sondagem ocupada de baixa latência para sondagem e seleção. Representa o tempo aproximado em µs para o ciclo de espera ocupado por eventos.
net.core.busy_read	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define o limite de tempo de sondagem ocupada de baixa latência para leituras de tomadas. Representa o tempo aproximado em µs para o ciclo de espera ocupado à espera de pacotes na fila do dispositivo.
net.core.netdev_max_backlog	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define o número máximo de pacotes colocados em fila no lado de ENTRADA quando a interface recebe pacotes mais rapidamente do que o kernel os consegue processar.
net.core.rmem_default	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define o tamanho predefinido do buffer do socket de receção, em bytes.
net.core.rmem_max	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define o tamanho máximo da memória intermédia do socket de receção, em bytes.
net.core.wmem_default	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define a predefinição, em bytes, da memória intermédia de envio do soquete.
net.core.wmem_max	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define o tamanho máximo da memória intermédia do soquete de envio, em bytes.
net.core.optmem_max	Qualquer número inteiro positivo inferior a 2147483647.	Esta definição define o tamanho máximo da memória intermédia auxiliar permitido por tomada.
net.core.somaxconn	Tem de ser um valor entre [128, 2147483647].	Esta definição define o limite da fila de espera do socket listen(), que é conhecido no espaço do utilizador como SOMAXCONN. Esta definição é 128 por predefinição.
net.ipv4.tcp_rmem	{min, default, max} (cada um > 0, memória em bytes).	Esta definição define o tamanho mínimo, em bytes, da memória intermédia de receção usada pelos soquetes UDP na moderação. A predefinição é de 1 página.
net.ipv4.tcp_wmem	{min, default, max} (cada um > 0, memória em bytes).	Esta definição define o tamanho mínimo, em bytes, da memória intermédia de envio usada por sockets UDP na moderação. A predefinição é de 1 página.
net.ipv4.tcp_tw_reuse	Tem de ser um número entre {0, 1}.	Esta definição define se deve permitir a reutilização de sockets no estado TIME_WAIT para novas ligações quando for seguro do ponto de vista do protocolo. O valor predefinido é 0.
net.ipv4.tcp_max_orphans	Tem de ser um valor entre [16384, 262144].	Esta definição define o número máximo de sockets TCP que não estão anexados a nenhum identificador de ficheiro do utilizador.
net.ipv4.tcp_max_tw_buckets	Tem de ser um valor entre [4096, 2147483647].	Esta definição define o número máximo de sockets de espera de tempo mantidos pelo sistema em simultâneo. Se este número for excedido, o soquete de espera é imediatamente destruído e é apresentado um aviso.
net.ipv4.tcp_syn_retries	Tem de ser um número entre [1 e 127].	Esta definição define o número de vezes que os SYNs iniciais de uma tentativa de ligação TCP ativa são retransmitidos.
net.ipv4.tcp_ecn	Tem de ser um número entre [0, 2].	Esta definição controla a utilização da Notificação de Congestão Explícita (ECN) pelo TCP. O ECN é usado apenas quando ambas as extremidades da ligação TCP indicam suporte para o mesmo.
net.ipv4.tcp_mtu_probing	Tem de ser um número entre [0, 2].	Esta definição controla a descoberta de MTU do caminho da camada de packetização de TCP. Os valores suportados são os seguintes: 0: desativada. 1: desativado por predefinição, ativado quando é detetado um buraco negro ICMP. 2: sempre ativada. Use o MSS inicial de tcp_base_mss.
net.ipv4.tcp_congestion_control	Tem de ser um dos valores suportados da coluna Description.	Esta definição não é suportada quando o GKE Dataplane V2 está ativado no cluster. Os seguintes valores suportados dependem do tipo de imagem: COS: reno, cubic, bbr e lp Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood e yeah
net.ipv6.conf.all.disable_ipv6	Booleano.	Alterar este valor é o mesmo que alterar a definição conf/default/disable_ipv6 e também todas as definições disable_ipv6 por interface para o mesmo valor.
net.ipv6.conf.default.disable_ipv6	Booleano.	Esta definição desativa o funcionamento do IPv6.
net.netfilter.nf_conntrack_acct	Tem de ser um número entre {0, 1}.	Esta definição ativa a contabilização do fluxo de acompanhamento de ligações. O valor predefinido é 0, o que significa que a definição está desativada. Disponível nas versões 1.32.0-gke.1448000 ou posteriores do GKE.
net.netfilter.nf_conntrack_max	Tem de ser um valor entre [65536, 4194304].	Esta definição define o tamanho da tabela de acompanhamento de ligações. Se o valor máximo for atingido, a nova associação falha. Disponível nas versões 1.32.0-gke.1448000 ou posteriores do GKE.
net.netfilter.nf_conntrack_buckets	Tem de ser um valor entre [65536, 524288].	Esta definição define o tamanho da tabela de hash. A definição recomendada é o resultado do seguinte: nf_conntrack_max = nf_conntrack_buckets * 4. Disponível nas versões 1.32.0-gke.1448000 ou posteriores do GKE.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Tem de ser um valor entre [60 e 3600].	Esta definição define o período, em segundos, durante o qual as ligações TCP podem permanecer no estado CLOSE_WAIT. O valor predefinido é 3600. Disponível nas versões 1.32.0-gke.1448000 ou posteriores do GKE.
net.netfilter.nf_conntrack_tcp_timeout_established	Tem de ser um valor entre [600, 86400].	Esta definição define a duração, em segundos, das ligações inativas antes de serem eliminadas automaticamente da tabela de monitorização de ligações. Disponível nas versões 1.32.0-gke.1448000 ou posteriores do GKE.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	Tem de ser um número entre [1 e 600].	Esta definição define o período, em segundos, durante o qual as ligações TCP podem permanecer no estado TIME_WAIT. O valor predefinido é 120. Disponível nas versões 1.32.0-gke.1448000 ou posteriores do GKE.

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

A tabela seguinte descreve os parâmetros modificáveis para o subsistema de memória virtual. Estas definições gerem o subsistema de memória virtual, que controla a forma como o kernel processa a memória, a troca e o armazenamento em cache do disco.

Parâmetro sysctl	Restrições	Descrição
vm.max_map_count	Tem de ser um valor entre [65536, 2147483647].	Este ficheiro define o número máximo de áreas de mapeamento de memória que um processo pode ter.
vm.dirty_background_ratio	Tem de ser um número entre 1 e 100.	Esta definição define a percentagem de memória do sistema que pode ser preenchida com páginas sujas antes de os threads de limpeza do kernel em segundo plano começarem a escrever de volta. O valor tem de ser inferior ao valor do campo vm.dirty_ratio.
vm.dirty_background_bytes	Tem de ser um número entre [0, 68719476736].	Esta definição define a quantidade de memória suja na qual os threads de limpeza do kernel em segundo plano iniciam a gravação. Tenha em atenção que vm.dirty_background_bytes é a contrapartida de vm.dirty_background_ratio. Só é possível especificar uma destas definições.
vm.dirty_expire_centisecs	Tem de ser um número entre [0, 6000].	Esta definição define a idade máxima, em centésimos de segundo, que os dados sujos podem permanecer na memória antes de os threads de descarga do kernel os escreverem no disco.
vm.dirty_ratio	Tem de ser um número entre 1 e 100.	Esta definição define a percentagem de memória do sistema que pode ser preenchida com páginas sujas antes de os processos que realizam escritas serem forçados a bloquear e escrever dados sujos de forma síncrona.
vm.dirty_bytes	Tem de ser um número entre [0, 68719476736].	Esta definição define a quantidade de memória suja na qual um processo que gera escritas no disco inicia a gravação de volta. O valor mínimo permitido para vm.dirty_bytes é de duas páginas em bytes. Qualquer valor inferior a este limite é ignorado e a configuração antiga é mantida. Tenha em atenção que vm.dirty_bytes é a contrapartida de vm.dirty_ratio. Só é possível especificar uma destas definições.
vm.dirty_writeback_centisecs	Tem de ser um número entre [0 e 1000].	Esta definição define o intervalo, em centésimos de segundo, ao qual os threads de descarga do kernel são ativados para escrever dados antigos alterados no disco.
vm.overcommit_memory	Tem de ser um número entre {0, 1, 2}.	Esta definição determina a estratégia do kernel para processar a sobrecarga de memória. Os valores são os seguintes: 0: rejeitar atribuições grandes 1: permitir sempre 2: impedir a confirmação além da troca + proporção da RAM
vm.overcommit_ratio	Tem de ser um valor entre [0 e 100].	Esta definição define a percentagem de RAM física permitida para o excesso de compromisso quando o valor do campo vm.overcommit_memory está definido como 2.
vm.vfs_cache_pressure	Tem de ser um valor entre [0 e 100].	Esta definição ajusta a preferência do kernel para reclamar memória usada para caches de dentry (diretório) e inode.
vm.swappiness	Tem de ser um número entre [0 e 200].	Esta definição controla a tendência do kernel para mover processos da memória física para o disco de troca. O valor predefinido é 60.
vm.watermark_scale_factor	Tem de ser um valor entre [10, 3000].	Esta definição controla a agressividade do kswapd. Define a memória restante antes de o kswapd ser ativado e a memória a libertar antes de ser desativado. O valor predefinido é 10.
vm.min_free_kbytes	Tem de ser um valor entre [67584 e 1048576].	Esta definição define a memória livre mínima antes de OOM. O valor predefinido é 67584.

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

Os diferentes namespaces Linux podem ter valores únicos para uma determinada flag sysctl, mas outros podem ser globais para todo o nó. A atualização das opções sysctl através de uma configuração do sistema de nós ajuda a garantir que o sysctl é aplicado globalmente no nó e em cada espaço de nomes, para que cada Pod tenha valores sysctl idênticos em cada espaço de nomes do Linux.

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

Aviso: o GKE descontinua o cgroupv1 com a versão secundária 1.31 e remove o suporte para o cgroupv1 com a versão 1.35. Para mais informações sobre a transição do GKE para o cgroupv2 e como pode preparar os seus clusters para esta transição, consulte o artigo Migre nós para o cgroupv2 do Linux.

O tempo de execução do contentor e o kubelet usam cgroups do kernel do Linux para a gestão de recursos, como limitar a quantidade de CPU ou memória a que cada contentor num pod pode aceder. Existem 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 1.22 e DG na 1.25. Para mais informações, consulte a documentação cgroups v2 do Kubernetes.

A configuração do sistema de nós permite-lhe personalizar a configuração do cgroup dos seus node pools. Pode usar o cgroupv1 ou o cgroupv2. O GKE usa o cgroupv2 para novos conjuntos de nós padrão que executam a versão 1.26 e posterior, e o cgroupv1 para conjuntos de nós que executam versões anteriores à 1.26. Para os conjuntos de nós criados com a administração de contas automática de nós, a configuração do cgroup depende da versão inicial do cluster e não da versão do conjunto de nós. O cgroupv1 não é suportado em máquinas Arm.

Pode usar a configuração do sistema de nós para alterar a definição de um conjunto de nós para usar cgroupv1 ou cgroupv2 explicitamente. A atualização de um node pool existente que usa cgroupv1 para a versão 1.26 não altera a definição para cgroupv2. Os conjuntos de nós existentes que executam uma versão anterior à 1.26 e que não incluem uma configuração de cgroup personalizada continuam a usar o cgroupv1. Para alterar a definição, tem de especificar explicitamente cgroupv2 para o conjunto de nós existente.

Por exemplo, para configurar o seu conjunto de nós para usar cgroupv2, use um ficheiro de configuração do sistema de nós, como o seguinte:

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

As opções cgroupMode suportadas são as seguintes:

• CGROUP_MODE_V1: use cgroupv1 no node pool.
• CGROUP_MODE_V2: use cgroupv2 no node pool.
• CGROUP_MODE_UNSPECIFIED: use a configuração de cgroup do GKE predefinida.

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

• Para um conjunto de nós que execute uma versão anterior à 1.26, tem de usar a versão 408.0.0 ou posterior da CLI gcloud. Em alternativa, use o gcloud beta com a versão 395.0.0 ou posterior.
• O cluster e os conjuntos de nós têm de executar a versão 1.24.2-gke.300 ou posterior do GKE.
• Tem de usar a imagem do nó do SO otimizado para contentores com o containerd ou do Ubuntu com o containerd.
• Se alguma das suas cargas de trabalho depender da leitura do sistema de ficheiros cgroup (/sys/fs/cgroup/...), certifique-se de que são compatíveis com a API cgroupv2.
• Se usar ferramentas de monitorização ou de terceiros, certifique-se de que são compatíveis com o cgroupv2.
• Se usar cargas de trabalho Java (JDK), recomendamos que use versões que suportem totalmente o cgroupv2, incluindo o JDK 8u372, o JDK 11.0.16 ou posterior, ou o JDK 15 ou posterior.

Valide a configuração do cgroup

Quando adiciona uma configuração do sistema de nós, o GKE tem de recriar os nós para implementar as alterações. Depois de adicionar a configuração a um conjunto de nós e os nós serem recriados, pode validar a nova configuração.

Pode validar a configuração do cgroup para nós num conjunto de nós através da CLI gcloud ou da ferramenta de linha de comandos kubectl:

CLI gcloud

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

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

Substitua POOL_NAME pelo nome do seu conjunto de nós.

O potencial resultado é um dos seguintes:

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

O resultado mostra apenas a nova configuração do cgroup após a recriação dos nós no conjunto de nós. A saída está vazia para pools de nós do servidor Windows, que não suportam cgroup.

kubectl

Para usar kubectl para validar a configuração do cgroup para nós neste conjunto de nós, selecione um nó e ligue-se a ele através das seguintes instruções:

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

Opções de configuração de páginas enormes do Linux

Pode usar um ficheiro de configuração do sistema de nós para pré-atribuir páginas grandes. O Kubernetes suporta páginas grandes pré-atribuídas como um tipo de recurso, semelhante à CPU ou à memória.

Para usar páginas enormes, aplicam-se as seguintes limitações e requisitos:

• Para garantir que o nó não está totalmente ocupado por páginas grandes, o tamanho geral das páginas grandes atribuídas não pode exceder nenhuma das seguintes opções:
  • Em máquinas com menos de 30 GB de memória: 60% da memória total. Por exemplo, numa máquina e2-standard-2 com 8 GB de memória, não pode 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 enormes não podem exceder 25,6 GB.
• As páginas enormes de 1 GB só estão disponíveis nos tipos de máquinas A3, C2D, C3, C3D, C4, C4A, C4D, CT5E, CT5LP, CT6E, H3, M2, M3, M4 ou Z3.

A tabela seguinte descreve as definições modificáveis para páginas grandes do Linux.

Parâmetro de configuração	Restrições	Valor predefinido	Descrição
hugepage_size2m	Contagem de números inteiros. Sujeito aos limites de atribuição de memória descritos anteriormente.	0	Esta definição pré-atribui um número específico de páginas enormes de 2 MB.
hugepage_size1g	Contagem de números inteiros. Sujeito a ambas as limitações de memória e tipo de máquina descritas anteriormente.	0	Esta definição pré-atribui um número específico de páginas enormes de 1 GB.

Páginas enormes transparentes (THP)

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

A tabela seguinte descreve os parâmetros modificáveis para o THP.

Parâmetro de configuração	Valores suportados	Valor predefinido	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 está ativada nas regiões MADV_HUGEPAGE. Esta definição é a configuração predefinida do kernel. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: a página enorme transparente está desativada. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: o valor predefinido. O GKE não modifica a configuração do kernel.	UNSPECIFIED	Esta definição controla se o THP está ativado para memória anónima.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: uma aplicação que pede paragens de THP em caso de falha na atribuição e reclama diretamente páginas e memória compacta num esforço para atribuir um THP imediatamente. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: uma aplicação 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 num futuro próximo. É da responsabilidade do khugepaged instalar as páginas THP mais tarde. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: uma aplicação entra na recuperação direta e na compactação como habitualmente, mas apenas para regiões que tenham usado madvise(MADV_HUGEPAGE). Todas as outras regiões ativam o kswapd em segundo plano para reclamar páginas e ativam o kcompactd para compactar a memória, de modo que a THP esteja disponível num futuro próximo. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: uma aplicação entra na recuperação direta e na compactação como habitualmente, mas apenas para regiões que tenham usado madvise(MADV_HUGEPAGE). Todas as outras regiões ativam o kswapd em segundo plano para recuperar páginas e ativam o kcompactd para compactar a memória, de modo que o THP esteja disponível num futuro próximo. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: uma aplicação nunca entra na recuperação direta nem na compactação. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: o valor predefinido. O GKE não modifica a configuração do kernel.	UNSPECIFIED	Esta definição define a configuração de desfragmentação para THP.

O THP está disponível na versão 1.33.2-gke.4655000 ou posterior do GKE. Também está ativado por predefinição em novos pools de nós de TPU na versão 1.33.2-gke.4655000 ou posterior do GKE. O THP não está ativado quando atualiza os conjuntos de nós existentes para uma versão suportada ou posterior.

O que se segue?

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