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

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

Visão geral

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

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

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

Também é possível usar DaemonSets para personalizar nós, como em Inicialização automática de nós do GKE com DaemonSets.

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

É possível personalizar a configuração do sistema de nós usando um dos seguintes métodos:

  • Arquivo de configuração: disponível no modo Standard. Você usa um arquivo YAML que contém os parâmetros de configuração do kubelet e do kernel do Linux. As etapas nesta página mostram como criar e usar um arquivo de configuração.
  • ComputeClass: disponível nos modos Autopilot e Standard. Você especifica a configuração do sistema de nós na especificação GKE ComputeClass. Com as classes de computação, é possível definir conjuntos de atributos de nó para o GKE usar ao escalonar o cluster verticalmente. Disponível no GKE versão 1.32.1-gke.1729000 e mais recentes. Para mais detalhes, consulte Sobre as classes de computação no GKE.

Para usar um arquivo de configuração do sistema de nós, 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 ou atualizar um pool de nós.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

Como criar um arquivo de configuração

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

kubeletConfig:
  cpuManagerPolicy: static
  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:

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

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

kubeletConfig:
  cpuManagerPolicy: static

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

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

Depois de criar o arquivo de configuração, adicione a sinalização --system-config-from-file usando a Google Cloud CLI.

É possível usar a CLI gcloud ou o Terraform para aplicar uma configuração de sistema de nós ao criar um cluster padrão ou um novo pool de nós. Se você aplicar a configuração durante a criação do cluster, o GKE vai aplicá-la ao pool de nós padrão do cluster. Também é possível atualizar a configuração do sistema de nós de um pool de nós atual. Não é possível adicionar uma configuração do sistema de nós com o console do Google Cloud .

Criar um novo pool de nós com a configuração do sistema 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

``` Replace the following:
  • 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 do sistema de nós personalizada 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 para GKE.

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

Execute este 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 detalhes 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.

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

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

Como editar criando um pool de nós

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

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

Como editar atualizando um pool de nós atual

Para editar 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. A atualização de uma configuração do sistema de nós substitui a configuração do sistema do pool de nós pela nova configuração, o que exige a recriação dos nós. Se você omitir qualquer parâmetro durante uma atualização, eles serão definidos com os respectivos padrões.

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

kubeletConfig: {}
linuxConfig:
  sysctl: {}

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

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

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

Opções de configuração do Kubelet

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

Configurações do Kubelet Restrições Configuração padrão Descrição
allowedUnsafeSysctls Lista de sysctl nomes ou grupos. Grupos sysctl permitidos: kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.* e net.*. Exemplo: [kernel.msg*, net.ipv4.route.min_pmtu]. 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

Disponível nas versões 1.32.0-gke.1448000 ou mais recentes do GKE.
containerLogMaxSize O valor precisa ser um número positivo e um sufixo de unidade entre 10Mi e 500Mi, inclusive. As unidades válidas são Ki, Mi, Gi. 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.
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 de 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ó.
cpuCFSQuota O valor precisa ser true ou false. true Essa configuração aplica o limite de CPU do pod. Definir esse valor como false significa que os limites de CPU para pods serão ignorados.

Ignorar os limites da CPU pode ser desejável em determinados cenários em que os pods são sensíveis aos limites da CPU. O risco de desativar cpuCFSQuota é que um pod não autorizado pode consumir mais recursos da CPU do que o pretendido.
cpuCFSQuotaPeriod O valor precisa ser uma duração de tempo entre 1 ms e 1 segundo, inclusive. "100ms" Esta configuração define o valor do período da cota do CFS da CPU, cpu.cfs_period_us, que especifica a frequência com que o acesso de um cgroup aos recursos da CPU precisa ser realocado. Essa opção permite ajustar o comportamento de limitação da CPU.
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. O menor uso de disco para coleta de lixo. A porcentagem é calculada dividindo o valor do campo por 100. Quando especificado, o valor precisa ser menor que imageGcHighThresholdPercent.
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. Maior uso de disco para coleta de lixo. A porcentagem é calculada dividindo o valor do campo por 100. Quando especificado, o valor precisa ser maior que imageGcLowThresholdPercent.
imageMinimumGcAge O valor precisa ser uma duração de tempo não superior a "2m". As unidades de tempo válidas são "ns", "us" (or "µs"), "ms", "s", "m", "h" 2m imageMinimumGcAge é a idade mínima de uma imagem não usada antes de ser coletada como lixo.
imageMaximumGcAge O valor precisa ser uma duração de tempo 0s imageMaximumGcAge é a idade máxima que uma imagem pode ter sem ser usada antes de ser coletada como lixo. O padrão desse campo é "0s", que o desativa. Ou seja, as imagens não serão coletadas como lixo com base no fato de não serem usadas há muito tempo. Quando especificado, o valor precisa ser maior que imageMinimumGcAge.

Disponível nas versões 1.30.7-gke.1076000, 1.31.3-gke.1023000 ou mais recentes do GKE.
insecureKubeletReadonlyPortEnabled O valor precisa ser booleano (true ou false) true Essa configuração desativa a porta somente leitura do kubelet não segura 10255 em cada novo pool de nós no cluster. Se você definir essa configuração nesse arquivo, não será possível usar um cliente da API GKE para alterar a configuração no nível do cluster.
podPidsLimit (em inglês) O valor precisa estar entre 1024 e 4194304 none Essa configuração define o número máximo de IDs de processos (PIDs, na sigla em inglês) que cada pod pode usar.
maxParallelImagePulls O valor precisa ser um número inteiro entre 2 e 5 2 ou 3 com base no 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:

  • Padrão 3: pd-balanced, pd-ssd ou SSD local efêmero.
  • 2 padrão: pd-standard ou outros tipos de disco de inicialização.

    • Disponível nas versões 1.33.1-gke.1918000 ou mais recentes do GKE.
    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 quantidades ou porcentagens que definem limites de remoção suave. Um limite de remoção suave precisa ter um período de carência. O kubelet não remove os pods até que o período de carência seja excedido.
    evictionSoftGracePeriod Mapa de nomes de indicadores, que tem as mesmas opções que evictionSoft com restrições diferentes. Para cada nome de indicador, o valor precisa ser uma duração positiva menor que 5m, por exemplo, 30s ou 1m. As unidades de tempo válidas são "ns", "us" (ou "µs"), "ms", "s", "m" ou "h". 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 gradual precisa ter um período de carência correspondente.
    evictionMinimumReclaim Mapa de nomes de indicadores, que tem as mesmas opções que evictionSoft com restrições diferentes. Para cada nome de indicador, o valor precisa ser uma porcentagem positiva menor que 10%, por exemplo, 5%. 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 da flag evictionSoft que podem ser modificadas. As mesmas opções também se aplicam às flags evictionSoftGracePeriod e evictionMinimumReclaim com restrições diferentes.

    Configurações do 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ó. Exemplo: 100Mi, 1Gi. none Representa a quantidade de memória disponível antes da remoção forçada. Define a quantidade do sinal memory.available no kubelet.
    nodefsAvailable O valor precisa estar entre 10% e 50%. none Representa o nodefs disponível antes da remoção forçada reversível. Define a quantidade do indicador nodefs.available no kubelet.
    nodefsInodesFree O valor precisa estar entre 5% e 50%. none 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 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 Representa os nós i do imagefs que estão livres antes da remoção forçada. Define a quantidade do indicador imagefs.inodesFree no kubelet.
    pidAvailable O valor precisa estar entre 10% e 50%. none 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.

    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). Para mais informações, consulte Gerenciadores de recursos de nós.

    Com o GKE, é possível configurar as seguintes opções para esses gerenciadores de recursos. É possível configurar essas opções de forma independente, mas recomendamos usá-las juntas para alinhar o gerenciamento de recursos. É possível usar as configurações do Topology Manager com as do CPU Manager e do Memory Manager para alinhar a CPU e a memória com outros recursos solicitados na especificação do pod.

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

    Definir esse valor como static permite que os pods 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. Para mais detalhes, consulte Política "Nenhuma".

    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:
        policy:
        scope:
    		O valor precisa ser uma das configurações compatíveis para cada um dos campos respectivos.
    • O padrão de topologyManager.policy é none
    • O padrão de topoloyManager.scope é container

    Essas configurações controlam a política do gerenciador de topologia do kubelet, que 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, M3, N4

    O exemplo a seguir mostra uma configuração de sistema de nós em que todas as três políticas do Resource Manager estão configuradas:

    cpuManagerPolicy: static
memoryManager:
  policy: Static
topologyManager:
  policy: best-effort
  scope: pod

    Opções de configuração de Sysctl

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

    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 um determinado sysctl, enquanto outros são globais para todo o nó. A atualização das opções sysctl usando uma configuração do sistema de nós garante que sysctl seja aplicado globalmente no nó e em cada namespace, resultando em cada pod com valores sysctl idênticos em cada namespace do Linux.

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

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

    A configuração do sistema de nós permite personalizar a configuração do cgroup dos pools de nós. É possível usar cgroupv1 ou cgroupv2. O GKE usa cgroupv2 para novos pools de nós do Standard que executam a versão 1.26 e mais recentes e cgroupv1 para 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. Apenas fazer upgrade de um pool de nós atual para a versão 1.26 não muda a configuração para cgroupv2, porque os pools de nós atuais criados com uma versão anterior à 1.26, sem uma configuração de cgroup personalizada, continuam usando cgroupv1, a menos que você especifique outra configuração.

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

    linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

    Veja a seguir as opções cgroupMode aceitas:

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

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

    • Para um pool de nós com uma versão anterior à 1.26, é necessário usar a CLI gcloud versão 408.0.0 ou mais recente. Como alternativa, use a gcloud beta com a versão 395.0.0 ou mais recente.
    • Os pools de nós e de cluster precisam executar a versão 1.24.2-gke.300 ou posterior do GKE.
    • Use o Container-Optimized OS com containerd ou o 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.
      • Verifique se as ferramentas de monitoramento ou de terceiros são compatíveis com o cgroupv2.
    • Se você usa o JDK (carga de trabalho do Java), recomendamos utilizar versões com suporte total ao cgroupv2, incluindo JDK 8u372, JDK 11.0.16 ou mais recentes ou JDK 15. ou posterior.

    Verificar a configuração do cgroup

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

    É possível verificar a configuração do cgroup para nós em um pool de nós com 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 só mostra 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 verificar a configuração do cgroup nos nós pool de nós com kubectl, escolha um nó e conecte-se a ele usando as seguintes instruções:

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

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

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

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

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

    linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

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

    • Para garantir que o nó não seja totalmente ocupado por páginas grandes, o tamanho geral de páginas grandes alocadas não pode exceder 60% da memória total em máquinas com menos de 30 GB de memória e 80% em máquinas com mais de 30 GB de memória. 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. E em c4a-standard-8 com 32 GB de memória, as páginas enormes 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.

    Suporte a páginas enormes transparentes

    Use o arquivo de configuração do sistema de nós para ativar o recurso do kernel do Linux Suporte a Transparent HugePage. O suporte a páginas enormes transparentes (THP, na sigla em inglês) é uma solução alternativa para a página enorme estática. Com o THP, o kernel atribui automaticamente páginas enormes aos processos, então não é necessário reservá-las manualmente. Os seguintes campos são compatíveis:

    linuxConfig:
  transparentHugepageEnabled: TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS
  transparentHugepageDefrag: TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS

    • transparentHugepageEnabled controla o suporte a páginas enormes transparentes para memória anônima. Os valores aceitos são:

      • TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: a página enorme transparente está ativada em todo o sistema.
      • TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: páginas enormes transparentes são ativadas em 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: valor padrão. O GKE não modifica a configuração do kernel.

    • transparentHugepageDefrag define a configuração de desfragmentação de hugepage transparente no nó. Os valores aceitos são:

      • TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: um aplicativo que solicita THP para em caso de falha na alocação e recupera páginas diretamente, além de compactar a memória 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 para 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 sempre, 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 ativam o kcompactd para compactar a memória para que o THP esteja disponível em breve.
      • TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: um aplicativo entra na recuperação e compactação diretas como sempre, 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 ativam 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: valor padrão. O GKE não modifica a configuração do kernel.

    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