Partilhar via

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

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

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

As alterações de configuração do sistema operacional e do 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, então o valor é definido para o padrão.

Nota

Os exemplos seguintes mostram definições de configuração comuns. Pode modificar as definições para satisfazer os requisitos da sua carga de trabalho. Para uma lista completa de parâmetros de configuração personalizados suportados, consulte a secção Parâmetros de configuração personalizados suportados .

Configuração do Kubelet

Crie um linuxkubeletconfig.json arquivo 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 linuxosconfig.json arquivo com o seguinte conteúdo:

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

Crie um cluster AKS usando ficheiros de configuração personalizados

Nota

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

  • Se especificar uma configuração ao criar um cluster, a configuração aplica-se apenas aos nós do pool inicial de nós. Quaisquer definições não configuradas no ficheiro JSON mantêm os seus valores predefinidos.
  • CustomLinuxOsConfig não é suportado para o tipo de sistema operativo Windows.

Crie um novo cluster utilizando ficheiros de configuração personalizados com o comando az aks create e especificando os seus ficheiros de configuração para os parâmetros --kubelet-config e --linux-os-config. O comando de exemplo a seguir 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 arquivos de configuração personalizados

Nota

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

  • Ao adicionar um pool de nós Linux a um cluster existente, você pode especificar a configuração do kubelet, a configuração do sistema operacional ou ambas. Ao adicionar um pool de nós do Windows a um cluster existente, você só pode especificar a configuração do kubelet. Se especificar uma configuração ao adicionar um pool de nós, a configuração aplica-se apenas aos nós do novo pool de nós. Quaisquer definições não configuradas no ficheiro JSON mantêm os seus valores predefinidos.
  • CustomKubeletConfig é suportado para pools de nós Linux e Windows.

Crie um novo pool de nós Linux usando o comando az aks nodepool add e especificando os teus ficheiros 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 Linux com o ficheiro personalizado ./linuxkubeletconfig.json :

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

Confirme que as definições foram aplicadas

Depois de aplicares uma configuração personalizada de nós, podes confirmar que as definições foram aplicadas aos nós ligando-te ao host e verificando sysctl ou fazendo alterações de configuração no sistema de ficheiros.

Parâmetros de configuração personalizados suportados

Importante

Ao ativar sysctls inseguros, assumes a responsabilidade pela estabilidade do nó e pelo comportamento da carga de trabalho. Sysctls inseguros podem potencialmente causar instabilidade de nós ou vulnerabilidades de segurança se forem mal configurados. Assegure-se de que compreende as implicações de ativar sysctls específicos e inseguros e monitorize de perto a saúde do seu cluster após efetuar as alterações.

Configuração personalizada do kubelet no Linux

Parâmetro Valores/intervalo permitidos Predefinido Descrição
cpuManagerPolicy nenhum, estático nenhum A política estática permite que contentores em pods garantidos com pedidos de CPU inteiros acessem CPUs exclusivas no nó.
cpuCfsQuota verdadeiro, falso verdadeiro Ativar/desativar a aplicação de quotas CFS da CPU para contentores que especificam limites de CPU.
cpuCfsQuotaPeriod Intervalo em milissegundos (ms) 100ms Define o valor do período de cota CFS da CPU.
imageGcHighThreshold 0-100 85 A porcentagem de uso do disco após a qual a coleta de lixo de imagem é sempre executada. Uso mínimo de disco que desencadeia a recolha de lixo. Para desativar a coleta de lixo de imagem, defina para 100.
imageGcLowThreshold 0-100, não superior a imageGcHighThreshold 80 A porcentagem de uso do disco antes da qual a coleta de lixo de imagem nunca é executada. Uso mínimo de disco que pode acionar o coletor de lixo.
topologyManagerPolicy nenhum, melhor esforço, restrito, nó único nenhum Otimize o alinhamento dos nós NUMA. Para mais informações, consulte Políticas de Gestão de Topologia de Controlo num nó.
allowedUnsafeSysctls kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.*, net.* Nenhuma Lista permitida de sysctls não seguros ou padrões de sysctl não seguros.
containerLogMaxSizeMB Tamanho em megabytes (MB) 50 O tamanho máximo (por exemplo, 10 MB) de um ficheiro de registo de contentor antes de ser rodado.
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 PID do kernel -1 (∞) O número máximo de IDs de processo que podem ser executados num Pod.
seccompDefault Unconfined, RuntimeDefault Unconfined Define o perfil seccomp padrão para todas as cargas de trabalho. RuntimeDefault Usa o perfil Seccomp padrão do Containerd, restringindo determinadas chamadas do sistema para aumentar a segurança. Chamadas de sistema restritas falham. Unconfined não impõe restrições às chamadas de sistema, permitindo todas as chamadas ao sistema e reduzindo a segurança. Para obter mais informações, consulte o perfil seccomp predefinido containerd. Este parâmetro está em pré-visualização. Regista o flag de funcionalidade "KubeletDefaultSeccompProfilePreview" usando o az feature register comando com --namespace "Microsoft.ContainerService".

Windows kubelet configuração personalizada

Parâmetro Valores/intervalo permitidos Predefinido Descrição
imageGcHighThreshold 0-100 85 A porcentagem de uso do disco após a qual a coleta de lixo de imagem é sempre executada. Uso mínimo de disco que desencadeia a recolha de lixo. Para desativar a coleta de lixo de imagem, defina para o valor 100.
imageGcLowThreshold 0-100, não superior a imageGcHighThreshold 80 A porcentagem de uso do disco antes da qual a coleta de lixo de imagem nunca é executada. Utilização mínima de disco que pode acionar a recolha de lixo.
containerLogMaxSizeMB Tamanho em megabytes (MB) 10 O tamanho máximo (por exemplo, 10 MB) de um ficheiro de registo de contentor antes de ser rodado.
containerLogMaxFiles ≥ 2 5 O número máximo de arquivos de log de contêiner que podem estar presentes para um contêiner.

Definições de configuração do sistema operacional personalizado do Linux

Importante

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

Por exemplo, se modificar o vm.max_map_count setting, deve formatar para vmMaxMapCount no ficheiro JSON de configuração.

Limites de controlo de ficheiros Linux

Ao servir grandes quantidades de tráfego, esse tráfego normalmente provém de um grande número de ficheiros locais. Pode ajustar as seguintes definições do kernel e os limites incorporados para permitir lidar com mais, à custa de alguma memória do sistema.

A tabela seguinte lista os limites de handles de ficheiros que pode personalizar para cada pool de nós:

Configuração Valores/intervalo permitidos Ubuntu 22.04 predefinido Ubuntu 24.04 por defeito Azure Linux 3.0 predefinição Descrição
fs.file-max 8192 - 9223372036854775807 9223372036854775807 9223372036854775807 9223372036854775807 Número máximo de handles de ficheiros alocados pelo kernel Linux. Este valor é definido para o valor máximo possível (2^63-1) para evitar o esgotamento dos descritores de ficheiro e garantir descritores de ficheiro ilimitados em todo o sistema para cargas de trabalho containerizadas.
fs.inotify.max_user_watches 781250 - 2097152 1048576 1048576 1048576 Número máximo de inspeções de arquivos permitido pelo sistema. Cada relógio 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 de solicitações de E/S assíncronas em todo o sistema. AIO-Max-NR permite que você altere o valor máximo para o qual AIO-NR pode crescer.
fs.nr_open 8192 - 20000500 1048576 1048576 1073741816 O número máximo de descritores de ficheiro que um processo pode alocar.

Nota

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:

  • Previne 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 contentores nunca sejam congestionadas por limites de manipuladores de ficheiros em todo o sistema.
  • Mantém a segurança através de limites por processo (fs.nr_open e ulimit) que ainda se aplicam a processos individuais.
  • Otimiza para plataformas de contentores onde muitos contentores podem correr simultaneamente, cada um potencialmente abrindo muitos ficheiros e ligação à rede.

Ajuste de sockets Linux e rede

Para os nós de agente, que se espera que lidem com um grande número de sessões concorrentes, você pode usar as seguintes opções TCP e de rede e ajustá-las de acordo com o pool de nós:

Configuração Valores/intervalo permitidos Ubuntu 22.04 predefinido Ubuntu 24.04 por defeito Azure Linux 3.0 predefinição 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. Um limite superior para o valor do parâmetro backlog passado para a função listen(2 ). Se o argumento da lista de pendências for maior que o somaxconn, ele será silenciosamente truncado até esse limite.
net.core.netdev_max_backlog 1000 - 3240000 1000 1000 1000 Número máximo de pacotes, enfileirados no lado INPUT, quando a interface recebe pacotes mais rápido do que o kernel pode processá-los.
net.core.rmem_max 212992 - 134217728 1048576 1048576 212992 O tamanho máximo do buffer de soquete de recebimento em bytes.
net.core.wmem_max 212992 - 134217728 212992 212992 212992 O tamanho máximo do buffer de soquete de envio em bytes.
net.core.optmem_max 20480 - 4194304 20480 131072 20480 Tamanho máximo do buffer auxiliar (buffer de memória opcional) 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 pedidos de ligação em fila que não receberam confirmação do cliente de ligação. Se este número for ultrapassado, o kernel começa a perder pedidos.
net.ipv4.tcp_max_tw_buckets 8000 - 1440000 262144 262144 131072 Número máximo de timewait tomadas mantidas pelo sistema simultaneamente. Se esse número for excedido, o soquete de espera é imediatamente destruído e o aviso é impresso.
net.ipv4.tcp_fin_timeout 5 - 120 60 60 60 O tempo em que uma ligação órfã (já não referenciada por qualquer aplicação) permanece no estado FIN_WAIT_2 antes de ser abortada na extremidade local.
net.ipv4.tcp_keepalive_time 30 - 432000 7200 7200 7200 Com que frequência o keepalive TCP envia mensagens quando keepalive está ativado.
net.ipv4.tcp_keepalive_probes 1 - 15 9 9 9 Quantas keepalive sondas o TCP envia, até decidir que a conexão está quebrada.
net.ipv4.tcp_keepalive_intvl 10 - 90 75 75 75 Com que frequência as sondas são enviadas. Multiplicado por tcp_keepalive_probes determina o tempo para desligar uma conexão que não está respondendo, depois que as sondas tiverem começado.
net.ipv4.tcp_tw_reuse 2 2 2 Permitir a reutilização TIME-WAIT de soquetes para novas conexões quando for 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 locais usado pelo tráfego TCP e UDP para escolher a porta local. Consiste em dois números: O primeiro número é a primeira porta local permitida para o tráfego TCP e UDP no nó do agente, e o segundo é o último número de porta local.
net.ipv4.neigh.default.gc_thresh1 128 - 80000 4096 4096 4096 Número mínimo de entradas que podem estar na cache ARP. A recolha de lixo não é ativada se o número de entradas estiver abaixo desta definição.
net.ipv4.neigh.default.gc_thresh2 512 - 90000 8192 8192 8192 Número máximo suave de entradas que podem estar na cache ARP. Esta configuração é, provavelmente, a mais importante, pois a recolha de lixo ARP é ativada cerca de 5 segundos após atingir este limite suave.
net.ipv4.neigh.default.gc_thresh3 1024 - 100000 16384 16384 16384 Número máximo rígido de entradas no cachê ARP.
net.netfilter.nf_conntrack_max 131072 - 2097152 Calculado dinamicamente Calculado dinamicamente Calculado dinamicamente nf_conntrack é um módulo que rastreia entradas de conexão para NAT dentro do Linux. O módulo nf_conntrack utiliza uma tabela hash para registar o registo de ligação estabelecida do protocolo TCP. nf_conntrack_max é o número máximo de nós na tabela hash, ou seja, o número máximo de ligações suportadas pelo módulo nf_conntrack ou o tamanho da tabela de rastreio de ligações. O valor padrão é calculado dinamicamente com base na memória do sistema usando a fórmula: RAM_in_bytes / 16384 (ou RAM_in_MB * 64). Por exemplo, uma VM com 8 GB de RAM tem um padrão de aproximadamente 524.288 ligações. Os valores reais variam consoante o tamanho da VM e a memória disponível.
net.netfilter.nf_conntrack_buckets 65536 - 524288 Calculado dinamicamente Calculado dinamicamente Calculado dinamicamente nf_conntrack é um módulo que rastreia entradas de conexão para NAT dentro do Linux. O módulo nf_conntrack utiliza uma tabela hash para registar o registo de ligação estabelecida do protocolo TCP. nf_conntrack_buckets é o tamanho da tabela hash. O valor padrão é calculado dinamicamente com base na memória do sistema usando a fórmula: RAM_in_bytes / 16384, com um mínimo de 1.024 buckets e um máximo de 262.144 buckets. O padrão nf_conntrack_max é normalmente definido como nf_conntrack_buckets * 4. Os valores reais variam consoante o tamanho da VM e a memória disponível.

Limites de trabalhador Linux

Como os limites do descritor de arquivo, o número de trabalhadores ou threads que um processo pode criar são limitados por uma configuração do kernel e limites de usuário. O limite de usuários no AKS é ilimitado. A tabela seguinte lista as definições do kernel que pode personalizar por grupo de nós.

Configuração Ubuntu 22.04 predefinido Ubuntu 24.04 por defeito Azure Linux 3.0 predefinição Descrição
kernel.threads-max Calculado dinamicamente Calculado dinamicamente Calculado dinamicamente Os processos podem inicializar threads. O número máximo de todos os threads que podem ser criados é definido com a configuração kernel.threads-maxdo kernel. O valor padrão é calculado dinamicamente com base na memória do sistema usando a fórmula: total_ram_pages / 4 (onde cada página tem tipicamente 4 KB). Os valores reais variam consoante o tamanho da VM e a memória disponível.

Memória virtual Linux

A tabela seguinte lista as definições do kernel que pode personalizar por pool de nós para ajustar o funcionamento do subsistema de memória virtual (VM) do kernel Linux e os writeout dados sujos no disco:

Configuração Valores/intervalo permitidos Ubuntu 22.04 predefinido Ubuntu 24.04 por defeito Azure Linux 3.0 predefinição Descrição
vm.max_map_count 65530 1048576 1048576 Este ficheiro contém o número máximo de áreas de mapa de memória que um processo pode ter. As áreas do mapa de memória são usadas como efeito colateral de chamar malloc, diretamente por mmap, mprotect e madvise, assim como ao carregar bibliotecas partilhadas.
vm.vfs_cache_pressure 1 - 100 100 100 100 Esse valor percentual controla a tendência do kernel de recuperar a memória, que é usada para a cache de objetos de diretório e inode.
vm.swappiness 0 - 100 60 60 60 Este controlo é usado para definir quão agressivamente o kernel troca as páginas de memória. Valores mais altos aumentam a agressividade, valores mais baixos diminuem a quantidade de troca. Um valor de 0 instrui o kernel a não iniciar o swap até que a quantidade de páginas livres e suportadas por ficheiros seja menor do que o ponto de referência alto em uma zona.
swapFileSizeMB 1 MB - Tamanho do disco temporário (/dev/sdb) Nenhuma Nenhuma Nenhuma SwapFileSizeMB especifica o tamanho em MB de um ficheiro de swap a criar nos nós agente deste pool de nós.
transparentHugePageEnabled always, madvise, never always always madvise Transparent Hugepages é um recurso do kernel Linux destinado a melhorar o desempenho, fazendo um uso mais eficiente do hardware de mapeamento de memória do seu processador. Quando ativado, o kernel tenta alocar hugepages sempre que possível, e qualquer processo Linux recebe páginas de 2 MB se a região mmap estiver naturalmente alinhada a 2 MB. Em certos casos, quando hugepages estão ativados em todo o sistema, as aplicações podem acabar por alocar mais recursos de memória. Uma aplicação pode mmap ter uma região grande mas tocar apenas 1 byte dela; nesse caso, pode ser alocada uma página de 2 MB em vez de uma de 4k sem razão aparente. Esse cenário é o motivo pelo qual é possível desativar hugepages todo o sistema ou tê-los apenas dentro MADV_HUGEPAGE madvise de regiões.
transparentHugePageDefrag always, defer, defer+madvise, madvise, never 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.

Considerações sobre configurações personalizadas de nós

Tenha em mente as seguintes considerações ao personalizar a configuração do seu nó:

  • Configurações personalizadas de nós são reaplicadas durante as atualizações de imagem dos nós.
  • As configurações personalizadas dos nós são preservadas durante as operações de scale-out.
  • O AKS não realiza a validação pré-voo dos parâmetros ou valores de configuração personalizados dos nós. Certifique-se de que os parâmetros e valores de configuração personalizados dos nós que especifica são suportados e válidos para evitar potenciais problemas com os seus nós do cluster.
  • Os valores predefinidos para parâmetros de configuração personalizados de nós frequentemente mudam com novas versões do sistema operativo. Ao aplicar configurações personalizadas de nós, reveja os valores predefinidos dos parâmetros que está a configurar para garantir que as suas definições personalizadas são adequadas para a versão do sistema operativo dos seus nós do cluster.
  • Recomendamos limitar o número de pessoas com permissões para modificar a configuração personalizada do nó para evitar consequências indesejadas na estabilidade e desempenho do cluster. Considere usar o Azure Role-Based Access Control (RBAC) para restringir o acesso às definições de configuração do cluster.
  • Recomendamos separar pools de nós com configurações personalizadas daqueles sem configurações personalizadas para evitar consequências indesejadas em cargas de trabalho que possam ser sensíveis a certas alterações de configuração. Por exemplo, se tiver uma carga de trabalho crítica que requer definições específicas de kubelet, considere isolar essa carga de trabalho para um pool de nós dedicado com a necessária configuração personalizada de kubelet.

Conteúdo relacionado

  • Last updated on