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

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.

Vista geral

Pode personalizar a configuração do nó através de vários métodos. Por exemplo, pode especificar parâmetros como o tipo de máquina e a plataforma de CPU mínima quando cria um conjunto 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. 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 configurações do kernel do Linux de baixo nível (sysctl) nos seus node pools.

Também pode personalizar o tempo de execução do contentor do containerd nos nós do GKE usando um ficheiro diferente denominado ficheiro de configuração do tempo de execução. Para ver instruções, consulte o artigo Personalize a configuração do containerd em nós do GKE.

Também pode usar DaemonSets para personalizar nós, como em Inicializar automaticamente nós do GKE com DaemonSets.

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

Pode personalizar a configuração do sistema de nós através de qualquer um dos seguintes métodos:

  • Ficheiro de configuração: disponível no modo padrão. Usa um ficheiro YAML que contém os parâmetros de configuração do kubelet e do kernel do Linux. Os passos nesta página mostram como criar e usar um ficheiro de configuração.
  • ComputeClass: disponível no modo Autopilot e no modo padrão. Especifica a configuração do sistema de nós na especificação ComputeClass do GKE. As classes de computação permitem-lhe definir conjuntos de atributos de nós para o GKE usar quando dimensiona o cluster. Disponível na versão 1.32.1-gke.1729000 e posteriores do GKE. Para obter detalhes, consulte o artigo Acerca das classes de computação no GKE.

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

Criar um ficheiro de configuração

Escreva o ficheiro de configuração do sistema de nós em YAML. O exemplo seguinte 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 gestão de CPU estática.
  • O net.core.somaxconn: '2048' limita a fila de tarefas pendentes do socket listen() a 2048 bytes.
  • net.ipv4.tcp_rmem: '4096 87380 6291456' define o valor mínimo, predefinido e máximo do buffer 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 no ficheiro de configuração. Por exemplo, para adicionar uma configuração, crie o seguinte ficheiro:kubelet

kubeletConfig:
  cpuManagerPolicy: static

Para ver uma lista completa dos campos que pode adicionar ao ficheiro de configuração, consulte as secções Opções de configuração do Kubelet e Opções de configuração do Sysctl.

Adicionar a configuração a um conjunto de nós

Depois de criar o ficheiro de configuração, adicione a flag --system-config-from-file com a Google Cloud CLI. 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 com a 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 com a CLI gcloud ou o Terraform. As instruções seguintes aplicam a configuração do sistema de nós 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 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 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. Também pode atualizar a configuração do sistema de nós de um node pool existente.

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

``` Replace the following:
  • 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 apoio técnico do Terraform para o GKE.

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

Execute 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 de kubelet e sysctl

Esta alteração requer a recriação dos nós, o que pode causar interrupções nas cargas de trabalho em execução. Para ver detalhes 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.

Editar 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.

Edição através da criação de um node pool

Para editar a configuração do sistema de um nó através da criação de um node pool:

  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.

Editar através da atualização de 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. A atualização de uma configuração do sistema de nós substitui a configuração do sistema do node pool pela nova configuração, o que requer a recriação dos nós. Se omitir parâmetros durante uma atualização, estes são definidos para os respetivos valores predefinidos.

Se quiser repor a configuração do sistema de nós para os valores predefinidos, atualize o ficheiro de configuração com valores vazios para kubelet e sysctl. Por exemplo:

kubeletConfig: {}
linuxConfig:
  sysctl: {}

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

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

  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 do Kubelet

A tabela seguinte mostra as opções de kubelet que pode modificar.

Definições de configuração do Kubelet Restrições Predefiniçã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 Esta definição define uma lista de autorizações separada por vírgulas de nomes ou grupos sysctlsysctl não seguros, que podem ser definidos nos pods.

Disponível nas versões 1.32.0-gke.1448000 ou posteriores do GKE.
containerLogMaxSize O valor tem de 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 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.
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ó.
cpuCFSQuota O valor 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 da CPU para os pods sã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 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.
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. Utilização mais baixa do disco para recolher lixo. A percentagem é calculada dividindo o valor deste campo por 100. Quando especificado, o valor tem de ser inferior a imageGcHighThresholdPercent.
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. A utilização de disco mais elevada para a qual a recolha de lixo deve ser feita. A percentagem é calculada dividindo o valor deste campo por 100. Quando especificado, o valor tem de ser superior a imageGcLowThresholdPercent.
imageMinimumGcAge O valor tem de ser uma duração não superior a "2 m". 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 eliminada.
imageMaximumGcAge O valor tem de ser uma duração 0s imageMaximumGcAge é a idade máxima que uma imagem pode ter sem ser usada antes de ser recolhida como lixo. A predefinição deste campo é "0s", o que desativa este campo. Isto significa que as imagens não são eliminadas com base no facto de não serem usadas durante demasiado tempo. Quando especificado, o valor tem de ser superior a imageMinimumGcAge.

Disponível nas versões 1.30.7-gke.1076000, 1.31.3-gke.1023000 ou posteriores do GKE.
insecureKubeletReadonlyPortEnabled O valor tem de ser um valor booleano (true ou false) true Esta definição desativa a porta de leitura do kubelet não segura 10255 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.
podPidsLimit O valor tem de estar compreendido entre 1024 e 4194304 none Esta definição define o número máximo de IDs de processos (PIDs) que cada Pod pode usar.
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:

  • Predefinição 3: pd-balanced, pd-ssd, ou existe um SSD local efémero.
  • Predefinição 2: pd-standard ou outros tipos de disco de arranque.

    • Disponível nas versões 1.33.1-gke.1918000 ou posteriores do GKE.
    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 quantidades ou percentagens que definem os limites de remoção temporária. Um limite de remoção temporária tem de ter um período de tolerância. O kubelet não despeja pods até o período de tolerância ser excedido.
    evictionSoftGracePeriod Mapeamento de nomes de sinais, que tem as mesmas opções que evictionSoft com restrições diferentes. Para cada nome de sinal, o valor tem de ser uma duração positiva inferior a 5m, por exemplo, 30s ou 1m. As unidades de tempo válidas são "ns", "us" (ou "µs"), "ms", "s", "m" ou "h". 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 Mapeamento de nomes de sinais, que tem as mesmas opções que evictionSoft com restrições diferentes. Para cada nome de sinal, o valor tem de ser uma percentagem positiva inferior a 10%. Por exemplo, 5%. 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 para a flag evictionSoft que pode modificar. As mesmas opções também se aplicam às flags evictionSoftGracePeriod e evictionMinimumReclaim com restrições diferentes.

    Definições de configuração do Kubelet 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ó. Por exemplo, 100Mi, 1Gi. none Representa a quantidade de memória disponível antes da remoção temporária. Define a quantidade de sinal memory.available no kubelet.
    nodefsAvailable O valor tem de estar entre 10% e 50%. none 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 Representa os inodos nodefs que estão livres antes da remoção suave. Define a quantidade do sinal nodefs.inodesFree no kubelet.
    imagefsAvailable O valor tem de estar entre 15% e 50%. none 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 Representa os inodos do 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 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.

    Gestores de recursos

    O Kubernetes oferece um conjunto de gestores de recursos. Pode configurar estes ResourceManagers para coordenar e otimizar o alinhamento dos recursos de nós para pods configurados com requisitos específicos para recursos de CPUs, dispositivos e memória (páginas grandes). Para mais informações, consulte o artigo Gestores de recursos de nós.

    Com o GKE, pode configurar as seguintes definições para estes Resource Managers. Pode configurar estas definições de forma independente. No entanto, recomendamos que as use em conjunto para alinhar a gestão de recursos. Pode usar as definições do Topology Manager juntamente com as definições do CPU Manager e do Memory Manager para alinhar a CPU e a memória com outros recursos pedidos na especificação do pod.

    Definições de configuração do Kubelet Restrições Predefinição Descrição 
          cpuManagerPolicy:
    		O valor tem de ser none ou static none Esta definição controla a política do gestor de CPU do kubelet. 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, permite que os pods que estão na classe de QoS Guaranteed e têm pedidos de CPU inteiros sejam atribuídos a CPUs exclusivas.    		 
          memoryManager:
        policy:
    		O valor tem de ser None ou Static None

    Esta definição controla a política do gestor de memória do kubelet. Com o valor predefinido de None, o Kubernetes funciona como se o gestor de memória não estivesse presente. Para ver detalhes, consulte a Política de Nenhum.

    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:
        policy:
        scope:
    		O valor tem de ser uma das definições suportadas para cada um dos respetivos campos
    • A predefinição de topologyManager.policy é none
    • O valor predefinido de topoloyManager.scope é container

    Estas definições controlam a política do gestor de topologia do kubelet, que 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 independentemente umas das outras. 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, M3 e N4

    O exemplo seguinte mostra uma configuração do 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 do Sysctl

    Para otimizar o desempenho do seu sistema, pode modificar os seguintes atributos do kernel:

    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 do Linux podem ter valores únicos para um determinado sysctl, enquanto outros são globais para todo o nó. A atualização das opções sysctl através de uma configuração do sistema de nós garante que o sysctl é aplicado globalmente no nó e em cada espaço de nomes, o que resulta em cada Pod com valores sysctl idênticos em cada espaço de nomes do Linux.

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

    O kubelet e o tempo de execução do contentor 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 detalhes, 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 versões anteriores à 1.26. Para os node pools criados com o aprovisionamento automático de nós, a configuração do cgroup depende da versão inicial do cluster e não da versão do node pool. 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. Apenas a atualização de um pool de nós existente para a versão 1.26 não altera a definição para cgroupv2, uma vez que os pools de nós existentes criados com uma versão anterior à 1.26, sem uma configuração de cgroup personalizada, continuam a usar cgroupv1, a menos que especifique explicitamente o contrário.

    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:

    linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

    As opções cgroupMode compatíveis são:

    • CGROUP_MODE_V1: use cgroupv1 no node pool.
    • CGROUP_MODE_V2: use cgroupv2 no node pool.
    • CGROUP_MODE_UNSPECIFIED: use a configuração do grupo de controlo 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 mais recente da CLI gcloud. Em alternativa, use o gcloud beta com a versão 395.0.0 ou mais recente.
    • 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 o SO otimizado para contentores com o containerd ou o Ubuntu com a imagem do nó do 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.
      • Certifique-se de que todas as ferramentas de monitorização ou de terceiros são compatíveis com o cgroupv2.
    • Se usar o JDK (carga de trabalho Java), 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 terem sido recriados, pode validar a nova configuração.

    Pode validar a configuração do cgroup para nós num conjunto de nós com a CLI gcloud ou a 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

    A saída só mostra a nova configuração do cgroup depois de os nós no conjunto de nós terem sido recriados. A saída está vazia para pools de nós do servidor Windows, que não suportam cgroup.

    kubectl

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

    1. Crie um shell interativo com qualquer nó no node pool. Substitua mynode no comando pelo nome de qualquer nó no conjunto 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

    Pode usar o ficheiro de configuração do sistema de nós para usar a funcionalidade do kernel do Linux huge pages.

    O Kubernetes suporta páginas grandes em nós como um tipo de recurso, semelhante à CPU ou à memória. Use os seguintes parâmetros para instruir os seus nós do Kubernetes a pré-atribuírem páginas grandes para consumo por parte dos pods. Para gerir o consumo de páginas grandes dos pods, consulte o artigo Gerir páginas grandes.

    Para pré-atribuir páginas enormes aos seus nós, especifique as quantidades e os tamanhos. Por exemplo, para configurar os seus nós para alocar três páginas enormes de 1 gigabyte e 1024 páginas enormes de 2 megabytes, use uma configuração do sistema de nós, como a seguinte:

    linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

    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 enormes, o tamanho geral das páginas enormes atribuídas 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, numa máquina e2-standard-2 com 8 GB de memória, não pode alocar mais de 4,8 GB para páginas enormes. E no 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.

    Suporte de páginas enormes transparentes

    Pode usar o ficheiro de configuração do sistema de nós para ativar a funcionalidade do kernel do Linux Suporte de páginas enormes transparentes. O suporte de páginas enormes transparentes (THP) é uma solução alternativa à página enorme estática. Com o THP, o kernel atribui automaticamente páginas grandes aos processos, pelo que não é necessário reservar páginas grandes manualmente. Os seguintes campos são suportados:

    linuxConfig:
  transparentHugepageEnabled: TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS
  transparentHugepageDefrag: TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS

    • transparentHugepageEnabled controla o suporte de páginas enormes transparentes para memória anónima. Os valores suportados são os seguintes:

      • 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 é a configuração predefinida do kernel.
      • TRANSPARENT_HUGEPAGE_ENABLED_NEVER: a página enorme transparente está desativada.
      • TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: valor predefinido. O GKE não modifica a configuração do kernel.

    • transparentHugepageDefrag define a configuração de desfragmentação de páginas enormes transparentes no nó. Os valores suportados são os seguintes:

      • TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: Uma aplicação que pede THP é bloqueada em caso de falha na atribuição e reclama diretamente páginas e compacta a memória para tentar atribuir um THP imediatamente.
      • TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: Uma aplicação ativa o kswapd em segundo plano para reclamar 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 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 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 sempre, 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 a 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: valor predefinido. O GKE não modifica a configuração do kernel.

    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?