Compartilhar via

Personalizar a configuração de nó para pools de nós do AKS (Serviço Kubernetes do Azure)

Personalizar a configuração de nó permite que você ajuste as configurações do sistema operacional (SO) ou os parâmetros kubelet para corresponder às necessidades das suas cargas de trabalho. Ao criar um cluster AKS ou adicionar um pool de nós ao cluster, você pode personalizar um subconjunto das configurações de SO e kubelet usadas com frequência. Para definir configurações além desse subconjunto, você pode usar um daemon definido para personalizar suas configurações necessárias sem perder o suporte do AKS para os nós.

Criar arquivos de configuração de nós personalizados para pools de nós do AKS

As alterações de configuração de sistema operacional e kubelet exigem que você crie um novo arquivo de configuração com os parâmetros e as configurações desejadas. Se um valor para um parâmetro não for especificado, o valor será definido como o padrão.

Observação

Os exemplos a seguir mostram as configurações comuns. Você pode modificar as configurações para atender aos requisitos de carga de trabalho. Para obter uma lista completa de parâmetros de configuração personalizada com suporte, consulte a seção parâmetros de configuração personalizada com suporte .

Configuração do Kubelet

Crie um arquivo linuxkubeletconfig.json com o seguinte conteúdo:

{
 "cpuManagerPolicy": "static",
 "cpuCfsQuota": true,
 "cpuCfsQuotaPeriod": "200ms",
 "imageGcHighThreshold": 90,
 "imageGcLowThreshold": 70,
 "topologyManagerPolicy": "best-effort",
 "allowedUnsafeSysctls": [
  "kernel.msg*",
  "net.*"
],
 "failSwapOn": false
}

Configuração do SO

Crie um arquivo linuxosconfig.json com o seguinte conteúdo:

{
 "transparentHugePageEnabled": "madvise",
 "transparentHugePageDefrag": "defer+madvise",
 "swapFileSizeMB": 1500,
 "sysctls": {
  "netCoreSomaxconn": 163849,
  "netIpv4TcpTwReuse": true,
  "netIpv4IpLocalPortRange": "32000 60000"
 }
}

Criar um cluster do AKS usando arquivos de configuração personalizados

Observação

Tenha as seguintes informações em mente ao usar arquivos de configuração personalizados ao criar um novo cluster do AKS:

  • Se você especificar uma configuração ao criar um cluster, a configuração se aplicará somente aos nós no pool de nós inicial. Todas as configurações não configuradas no arquivo JSON mantêm seus valores padrão.
  • CustomLinuxOsConfig não há suporte para o tipo de sistema operacional Windows.

Crie um novo cluster usando arquivos de configuração personalizados com o comando az aks create e especifique seus arquivos de configuração para os parâmetros --kubelet-config e --linux-os-config. O seguinte comando de exemplo cria um novo cluster com os arquivos personalizados ./linuxkubeletconfig.json e ./linuxosconfig.json:

az aks create --name <cluster-name> --resource-group <resource-group-name> --kubelet-config ./linuxkubeletconfig.json --linux-os-config ./linuxosconfig.json

Adicionar um pool de nós usando os arquivos de configuração personalizados

Observação

Tenha as seguintes informações em mente ao usar arquivos de configuração personalizados ao adicionar um novo pool de nós a um cluster do AKS existente:

  • Quando você adiciona um pool de nós do Linux a um cluster existente, você pode especificar a configuração do kubelet, a configuração do SO, ou ambos. Quando você adiciona um pool de nós do Windows a um cluster existente, você pode especificar a configuração do kubelet. Se você especificar uma configuração ao adicionar um pool de nós, a configuração se aplicará somente aos nós no novo pool de nós. Todas as configurações não configuradas no arquivo JSON mantêm seus valores padrão.
  • CustomKubeletConfig tem suporte para pools de nós de Linux e Windows.

Crie um novo pool de nós do Linux usando o comando az aks nodepool add e especificando os arquivos de configuração para os parâmetros --kubelet-config e --linux-os-config. O seguinte comando de exemplo cria um novo pool de nós do Linux com o arquivo personalizado ./linuxkubeletconfig.json :

az aks nodepool add --name <node-pool-name> --cluster-name <cluster-name> --resource-group <resource-group-name> --kubelet-config ./linuxkubeletconfig.json

Confirmar se as configurações foram aplicadas

Depois de aplicar a configuração de nó personalizado, você pode confirmar se as configurações foram aplicadas aos nós pela conexão ao host e verificar sysctl ou se as alterações de configuração foram feitas no sistema de arquivos.

Parâmetros de configuração personalizados com suporte

Configuração personalizada do kubelet do Linux

Parâmetro Os valores/intervalos permitidos Padrão Descrição
cpuManagerPolicy nenhum, estático none A política estática permite que os contêineres em garantissem os pods com as CPU de inteiros solicitando acesso a CPUs exclusivas no nó.
cpuCfsQuota verdadeiro, falso true Habilitar/desabilitar a imposição de cota de CFS da CPU para contêineres que especificam limites de CPU.
cpuCfsQuotaPeriod Intervalo emmilissegundos(ms) 100ms Define o valor do período de cota do CFS da CPU.
imageGcHighThreshold 0-100 85 A porcentagem de uso do disco após a qual a coleta de lixo da imagem é sempre executada. Uso mínimo de disco que inicia a coleta de lixo. Para desabilitar a coleta de lixo de imagem, defina como 100.
imageGcLowThreshold 0-100, não é maior que imageGcHighThreshold 80 A porcentagem de uso do disco antes da qual a coleta de lixo da imagem nunca é executada. Uso mínimo do disco que pode disparar a coleta de lixo.
topologyManagerPolicy nenhum, melhor esforço, restrito, nó único none Otimize o alinhamento do nó NUMA. Para obter mais informações, consulte Políticas de Gerenciamento de Topologia de Controle em um nó.
allowedUnsafeSysctls kernel.shm*, kernel.msg*, kernel.sem, , fs.mqueue.*net.* Nenhum Lista permitida de padrões de sysctl sysctls ou inseguros.
containerLogMaxSizeMB Tamanho em megabytes (MB) 50 O tamanho máximo (por exemplo, 10 MB) de um arquivo de log de contêiner antes de ser rotacionado.
containerLogMaxFiles ≥ 2 5 O número máximo de arquivos de log de contêiner que podem estar presentes para um contêiner.
podMaxPids -1 para o limite de PID do kernel -1 (∞) O número máximo de IDs de processo que podem ser executados em um Pod.
seccompDefault Unconfined, RuntimeDefault Unconfined Define o perfil de seccomp padrão para todas as cargas de trabalho. RuntimeDefault usa o perfil de seccomp padrão do contêiner, restringindo determinadas chamadas do sistema para aprimorar a segurança. As chamadas restritas falham. Unconfined não impõe restrições a chamadas de sistema (syscalls), permitindo todas as chamadas do sistema e reduzindo a segurança. Para obter mais informações, consulte o perfil de seccomp padrão do containerd. Esse parâmetro está em versão prévia. Registre o sinalizador de recurso "KubeletDefaultSeccompProfilePreview" com o comando az feature register usando --namespace "Microsoft.ContainerService".

Configuração personalizada do kubelet do Windows

Parâmetro Os valores/intervalos permitidos Padrão Descrição
imageGcHighThreshold 0-100 85 A porcentagem de uso do disco após a qual a coleta de lixo da imagem é sempre executada. Utilização mínima de disco que aciona a coleta de lixo. Para desabilitar a coleta de lixo de imagem, defina como 100.
imageGcLowThreshold 0-100, não é maior que imageGcHighThreshold 80 A porcentagem de uso do disco antes da qual a coleta de lixo da imagem nunca é executada. Uso mínimo do disco que pode disparar a coleta de lixo.
containerLogMaxSizeMB Tamanho em megabytes (MB) 10 O tamanho máximo (por exemplo, 10 MB) de um arquivo de log de contêiner antes de ser rotacionado.
containerLogMaxFiles ≥ 2 5 O número máximo de arquivos de log de contêiner que podem estar presentes para um contêiner.

Configurações de sistema operacional personalizadas do Linux

Importante

Para simplificar a pesquisa e a legibilidade, as configurações do sistema operacional são exibidas neste artigo pelo nome, mas devem ser adicionadas ao arquivo JSON de configuração ou à API do AKS usando a convenção de capitalização camelCase.

Por exemplo, se você modificar o vm.max_map_count setting, deverá reformatar para vmMaxMapCount no arquivo JSON de configuração.

Limites do identificador de arquivo do Linux

Ao atender a altas quantidades de tráfego, esse tráfego geralmente vem de um grande número de arquivos locais. É possível ajustar as seguintes configurações de kernel e limites internos para aumentar a capacidade de processamento, ao custo de uma parte da memória do sistema.

A tabela a seguir lista os limites dos identificadores de arquivo que você pode personalizar por pool de nós.

Configuração Os valores/intervalos permitidos Padrão do Ubuntu 22.04 Padrão do Ubuntu 24.04 Padrão do Azure Linux 3.0 Descrição
fs.file-max 8192 – 9223372036854775807 9223372036854775807 9223372036854775807 9223372036854775807 Número máximo de descritores de arquivo alocados pelo kernel do Linux. Esse valor é definido como o valor máximo possível (2^63-1) para evitar o esgotamento do descritor de arquivo e garantir um número ilimitado de identificadores de arquivo em nível de sistema para cargas de trabalho em contêineres.
fs.inotify.max_user_watches 781250 - 2097152 1048576 1048576 1048576 Número máximo de inspeções de arquivo permitidas pelo sistema. Cada inspeção tem aproximadamente 90 bytes em um kernel de 32 bits e aproximadamente 160 bytes em um kernel de 64 bits.
fs.aio-max-nr 65536 - 6553500 65536 65536 65536 O AIO-NR mostra o número atual do sistema de solicitações de e/s assíncronas. AIO-Max-NR permite que você altere o valor máximo AIO-NR pode aumentar para.
fs.nr_open 8192 - 20000500 1048576 1048576 1073741816 O número máximo de identificadores de arquivo que um processo pode alocar.

Observação

O fs.file-max parâmetro é definido como 9223372036854775807 (o valor máximo para um inteiro de 64 bits assinado) no Ubuntu e no Azure Linux com base em padrões upstream. Esta configuração:

  • Impede ataques de negação de serviço com base no esgotamento do descritor de arquivos em todo o sistema.
  • Garante que as cargas de trabalho de contêiner nunca sejam afuniladas pelos limites de identificador de arquivo de todo o sistema.
  • Mantém a segurança por meio de limites por processo (fs.nr_open e ulimit) que ainda se aplicam a processos individuais.
  • Otimiza para plataformas de contêiner nas quais muitos contêineres podem ser executados simultaneamente, cada um potencialmente abrindo muitos arquivos e conexões de rede.

Ajuste de rede e soquete do Linux

Para nós de agentes, que devem lidar com um grande número de sessões simultâneas, você pode usar as seguintes opções de TCP e rede e ajustá-las por pool de nós:

Configuração Os valores/intervalos permitidos Padrão do Ubuntu 22.04 Padrão do Ubuntu 24.04 Padrão do Azure Linux 3.0 Descrição
net.core.somaxconn 4096 - 3240000 16384 16384 16384 Número máximo de solicitações de conexão que podem ser enfileiradas para qualquer soquete de escuta específico. Um limite superior para o valor do parâmetro backlog passado para a função Listen (2). Se o argumento da pendência for maior que o somaxconn, ele será silenciosamente truncado para esse limite.
net.core.netdev_max_backlog 1000 - 3240000 1000 1000 1000 Número máximo de pacotes, em fila no lado de entrada, quando a interface recebe pacotes mais rápidos do que o kernel pode processá-los.
net.core.rmem_max 212992 - 134217728 1048576 1048576 212992 O tamanho do buffer do soquete recebido máximo em bytes
net.core.wmem_max 212992 - 134217728 212992 212992 212992 O tamanho do buffer do soquete enviado máximo em bytes
net.core.optmem_max 20480 - 4194304 20480 131072 20480 Tamanho máximo de buffer auxiliar (buffer de memória de opção) permitido por soquete. A memória de opção de soquete é usada em alguns casos para armazenar estruturas extras relacionadas ao uso do soquete.
net.ipv4.tcp_max_syn_backlog 128 - 3240000 16384 16384 16384 O número máximo de solicitações de conexão enfileiradas que não receberam uma confirmação do cliente que está se conectando. Se esse número for excedido, o kernel começará a remover solicitações.
net.ipv4.tcp_max_tw_buckets 8000 - 1440000 262144 262144 131072 Número máximo de timewait soquetes mantidos pelo sistema simultaneamente. Se esse número for excedido, o soquete de espera de tempo será destruído imediatamente e o aviso será impresso.
net.ipv4.tcp_fin_timeout 5 - 120 60 60 60 O período que uma conexão órfã (não é mais referenciada por qualquer aplicativo) permanece no estado de FIN_WAIT_2 antes de ser anulada na extremidade local.
net.ipv4.tcp_keepalive_time 30 - 432000 7200 7200 7200 Com que frequência o TCP envia keepalive mensagens quando keepalive está habilitado.
net.ipv4.tcp_keepalive_probes 1 - 15 9 9 9 Quantas keepalive investigações o TCP envia, até que decida que a conexão foi interrompida.
net.ipv4.tcp_keepalive_intvl 10 - 90 75 75 75 Com que frequência as investigações são enviadas. Multiplicado por tcp_keepalive_probes ele torna-se o tempo para eliminar uma conexão que não está respondendo, após o início das investigações.
net.ipv4.tcp_tw_reuse 2 2 2 Permita a reutilização TIME-WAIT de soquetes para novas conexões quando ele estiver seguro do ponto de vista do protocolo.
net.ipv4.ip_local_port_range Primeiro: 1024 - 60999 e último: 32768 - 65535] Primeiro: 32768 e último: 60999 Primeiro: 32768 e último: 60999 Primeiro: 32768 e último: 60999 O intervalo de portas local que é usado pelo tráfego TCP e UDP para escolher a porta local. Composto de dois números: o primeiro número é a primeira porta local permitida para o tráfego TCP e UDP no nó do agente, o segundo é o último número da porta local.
net.ipv4.neigh.default.gc_thresh1 128 - 80000 4096 4096 4096 Número mínimo de entradas que podem estar no cache ARP. A coleta de lixo não será disparada se o número de entradas estiver abaixo dessa configuração.
net.ipv4.neigh.default.gc_thresh2 512 - 90000 8192 8192 8192 Número máximo flexível de entradas que podem estar no cache ARP. Essa configuração é, sem dúvida, a mais importante, pois a coleta de lixo ARP inicia cerca de 5 segundos depois de atingir esse limite flexível.
net.ipv4.neigh.default.gc_thresh3 1024 - 100000 16384 16384 16384 O número máximo inflexível de entradas no cache ARP.
net.netfilter.nf_conntrack_max 131072 - 2097152 524288 524288 262144 nf_conntrack é um módulo que controla as entradas de conexão para NAT no Linux. O nf_conntrack módulo usa uma tabela de hash para registrar o registro de conexão estabelecido do protocolo TCP. nf_conntrack_max é o número máximo de nós na tabela de hash, ou seja, o número máximo de conexões com suporte no nf_conntrack módulo ou o tamanho da tabela de controle de conexão.
net.netfilter.nf_conntrack_buckets 65536 - 524288 262144 262144 262144 nf_conntrack é um módulo que controla as entradas de conexão para NAT no Linux. O nf_conntrack módulo usa uma tabela de hash para registrar o registro de conexão estabelecido do protocolo TCP. nf_conntrack_buckets é o tamanho da tabela de hash.

Limites de trabalho do Linux

Como os limites do descritor de arquivo, o número de trabalhos ou threads que um processo pode criar são limitados por uma configuração de kernel e limites de usuário. O limite de usuários em AKS é ilimitado. A tabela a seguir lista a configuração do kernel que você pode personalizar por pool de nós:

Configuração Padrão do Ubuntu 22.04 Padrão do Ubuntu 24.04 Padrão do Azure Linux 3.0 Descrição
kernel.threads-max 1030425 1030462 256596 Os processos podem criar threads de trabalho. O número máximo de todos os threads que podem ser criados é definido com a configuração do kernel kernel.threads-max.

Memória virtual do Linux

A tabela a seguir lista as configurações de kernel que você pode personalizar por pool de nós para ajustar a operação do subsistema de memória virtual (VM) do kernel do Linux e writeout dos dados sujos no disco:

Configuração Os valores/intervalos permitidos Padrão do Ubuntu 22.04 Padrão do Ubuntu 24.04 Padrão do Azure Linux 3.0 Descrição
vm.max_map_count 65530 1048576 1048576 Esse arquivo contém o número máximo de áreas de mapa de memória que um processo pode ter. As áreas de mapa de memória são usadas como um efeito colateral de chamar malloc , diretamente por mmap, mprotect e madvise também ao carregar bibliotecas compartilhadas.
vm.vfs_cache_pressure 1 a 100 100 100 100 Esse valor de porcentagem controla a tendência do kernel de recuperar a memória, que é usada para armazenar em cache os objetos de diretório e inode.
vm.swappiness 0–100 60 60 60 Esse controle é usado para definir a agressividade com que o kernel troca páginas de memória. Valores mais altos aumentam a agressividade, os valores mais baixos diminuem a quantidade de troca. Um valor de 0 instrui o kernel a não iniciar a permuta até que a quantidade de páginas livres e com backup em arquivo seja menor que a marca d' água alta em uma zona.
swapFileSizeMB 1 MB - Tamanho temporário de disco (/dev/sdb) Nenhum Nenhum Nenhum SwapFileSizeMB especifica o tamanho em MB de um arquivo de permuta que será criado direto dos nós de agente do pool de nós.
transparentHugePageEnabled always madvise never always always madvise Transparent Hugepages é um recurso de kernel do Linux destinado a melhorar o desempenho, fazendo uso mais eficiente do hardware de mapeamento de memória do processador. Quando habilitado, o kernel tenta alocar hugepages sempre que possível e os processos do Linux receberão as páginas de 2 MB se a região mmap for de 2 MB alinhados naturalmente. Quando hugepages estão habilitados para todo o sistema, os aplicativos podem acabar alocando mais recursos de memória. Um aplicativo pode mmap ser uma região grande, mas tocar em apenas 1 byte dela; nesse caso, uma página de 2 MB poderá ser alocada em vez de uma página de 4 K sem um bom motivo. Esse cenário é o motivo pelo qual é possível desabilitar hugepages todo o sistema ou apenas tê-los dentro de MADV_HUGEPAGE madvise regiões.
transparentHugePageDefrag always, defer, defer+madvise, , madvisenever madvise madvise madvise Esse valor controla se o kernel deve fazer uso agressivo da compactação de memória para tornar mais hugepages disponível.

Conteúdo relacionado

  • Last updated on