Partager via

Personnaliser la configuration des nœuds pour les pools de nœuds Azure Kubernetes service (AKS)

La personnalisation de la configuration de votre nœud vous permet d’ajuster les paramètres du système d’exploitation (OS) ou les paramètres kubelet pour répondre aux besoins de vos charges de travail. Lorsque vous créez un cluster AKS ou ajoutez un pool de nœuds à votre cluster, vous pouvez personnaliser un sous-ensemble de paramètres de système d’exploitation et kubelet couramment utilisés. Pour configurer des paramètres au-delà de ce sous-ensemble, vous pouvez utiliser un ensemble de démons pour personnaliser vos configurations nécessaires sans perdre la prise en charge AKS de vos nœuds.

Créer des fichiers de configuration de nœud personnalisés pour les pools de nœuds AKS

Les modifications de configuration du système d’exploitation et de kubelet nécessitent que vous créiez un fichier de configuration avec les paramètres et les réglages souhaités. Si une valeur pour un paramètre n’est pas spécifiée, la valeur est définie sur la valeur par défaut.

Remarque

Les exemples suivants montrent les paramètres de configuration courants. Vous pouvez modifier les paramètres pour répondre aux besoins de votre charge de travail. Pour obtenir la liste complète des paramètres de configuration personnalisés pris en charge, consultez la section Paramètres de configuration personnalisés pris en charge .

Configuration de kubelet

Créez un fichier linuxkubeletconfig.json avec le contenu suivant :

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

Configuration du système d’exploitation

Créez un fichier linuxosconfig.json avec le contenu suivant :

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

Créer un cluster AKS à l’aide de fichiers de configuration personnalisés

Remarque

Gardez à l’esprit les informations suivantes lors de l’utilisation de fichiers de configuration personnalisés lors de la création d’un cluster AKS :

  • Si vous spécifiez une configuration lors de la création d’un cluster, la configuration s’applique uniquement aux nœuds du pool de nœuds initial. Tous les paramètres non configurés dans le fichier JSON conservent leurs valeurs par défaut.
  • CustomLinuxOsConfig n’est pas pris en charge pour le type de système d’exploitation Windows.

Créez un nouveau cluster à l'aide de fichiers de configuration personnalisés en utilisant la commande az aks create et en spécifiant vos fichiers de configuration pour les paramètres --kubelet-config et --linux-os-config. L’exemple de commande suivant crée un cluster avec les fichiers personnalisés ./linuxkubeletconfig.json et ./linuxosconfig.json :

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

Ajouter un pool de nœuds à l’aide de fichiers config personnalisés

Remarque

Gardez à l’esprit les informations suivantes lors de l’utilisation de fichiers de configuration personnalisés lors de l’ajout d’un nouveau pool de nœuds à un cluster AKS existant :

  • Lorsque vous ajoutez un pool de nœuds Linux à un cluster existant, vous pouvez spécifier la configuration Kubelet, la configuration du système d’exploitation ou les deux. Lorsque vous ajoutez un pool de nœuds Windows à un cluster existant, vous pouvez spécifier uniquement la configuration Kubelet. Si vous spécifiez une configuration lors de l’ajout d’un pool de nœuds, la configuration s’applique uniquement aux nœuds du nouveau pool de nœuds. Tous les paramètres non configurés dans le fichier JSON conservent leurs valeurs par défaut.
  • CustomKubeletConfig est pris en charge pour les pools de nœuds Linux et Windows.

Créez un pool de nœuds Linux à l’aide de la commande az aks nodepool add et spécifiez vos fichiers de configuration pour les paramètres --kubelet-config et --linux-os-config. L’exemple de commande suivant crée un pool de nœuds Linux avec le fichier personnalisé ./linuxkubeletconfig.json :

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

Confirmer que les paramètres ont été appliqués

Après avoir appliqué une configuration de nœud personnalisée, vous pouvez confirmer que les paramètres ont été appliqués aux nœuds en vous connectant à l’hôte et en vérifiant que des modifications de configuration ont été apportées sur le système de fichiers.

Paramètres de configuration personnalisés pris en charge

Configuration personnalisée de kubelet Linux

Paramètre Valeurs autorisées/intervalle Default Description
cpuManagerPolicy aucun, statique Aucun La stratégie statique permet aux conteneurs se trouvant dans des pods garantis avec des requêtes d’UC entières d’accéder aux UC exclusives sur le nœud.
cpuCfsQuota vrai, faux true Activez/désactivez l’application du quota CFS de la CPU pour les conteneurs qui spécifient des limites de CPU.
cpuCfsQuotaPeriod intervalle en millisecondes (ms) 100ms Définit la valeur de la période du quota CFS de l’UC.
imageGcHighThreshold 0-100 85 % Pourcentage d’utilisation du disque après lequel le nettoyage de la mémoire d’images est toujours exécuté. Utilisation minimale du disque qui déclenche le nettoyage de la mémoire. Pour désactiver le nettoyage de la mémoire d’images, définissez sur 100.
imageGcLowThreshold 0 à 100, pas plus que imageGcHighThreshold 80 Pourcentage d’utilisation du disque avant lequel le nettoyage de la mémoire d’images n’est jamais exécuté. Utilisation minimale du disque qui peut déclencher le nettoyage de la mémoire.
topologyManagerPolicy none, best-effort, restricted, single-numa-node Aucun Optimisez l’alignement des nœuds NUMA. Pour plus d’informations, consultez Stratégies de gestion de la topologie de contrôle sur un nœud.
allowedUnsafeSysctls kernel.shm*, kernel.msg*, , kernel.sem, fs.mqueue.*, net.* None Liste autorisée de modèles sysctls ou sysctl non sécurisés.
containerLogMaxSizeMB Taille en mégaoctets (Mo) 50 Taille maximale (10 Mo, par exemple) d’un fichier journal de conteneur avant sa rotation.
containerLogMaxFiles ≥ 2 5 Nombre maximal de fichiers journaux de conteneur pouvant être présents pour un conteneur.
podMaxPids De -1 à la limite PID du noyau -1 (∞) Nombre maximal d’ID de processus pouvant s’exécuter dans un pod.
seccompDefault Unconfined, RuntimeDefault Unconfined Définit le profil seccomp par défaut pour toutes les charges de travail. RuntimeDefault utilise le profil seccomp de containerD par défaut, qui restreint certains appels système afin d’améliorer la sécurité. Les syscalls restreints échouent. Unconfined ne place aucune restriction sur les syscalls, ce qui permet tous les appels système et réduit la sécurité. Pour plus d’informations, consultez le profil seccomp par défaut de containerd. Ce paramètre est toujours en préversion. Inscrire l’indicateur de fonctionnalité « KubeletDefaultSeccompProfilePreview » à l’aide de la commande az feature register avec --namespace "Microsoft.ContainerService".

Configuration personnalisée de Windows Kubelet

Paramètre Valeurs autorisées/intervalle Default Description
imageGcHighThreshold 0-100 85 % Pourcentage d’utilisation du disque après lequel le nettoyage de la mémoire d’images est toujours exécuté. Utilisation minimale du disque qui déclenche le nettoyage de la mémoire. Pour désactiver le nettoyage de la mémoire d’images, définissez sur 100.
imageGcLowThreshold 0 à 100, pas plus que imageGcHighThreshold 80 Pourcentage d’utilisation du disque avant lequel le nettoyage de la mémoire d’images n’est jamais exécuté. Utilisation minimale du disque qui peut déclencher le nettoyage de la mémoire.
containerLogMaxSizeMB Taille en mégaoctets (Mo) 10 Taille maximale (par exemple, 10 Mo) d’un fichier journal de conteneur avant sa rotation.
containerLogMaxFiles ≥ 2 5 Nombre maximal de fichiers journaux de conteneur pouvant être présents pour un conteneur.

Paramètres de configuration du système d’exploitation personnalisé Linux

Important

Pour simplifier la recherche et la lisibilité, les paramètres du système d’exploitation sont affichés dans cet article par leur nom, mais ils doivent être ajoutés au fichier JSON de configuration ou à l’API AKS à l’aide de la convention de mise en majuscules camelCase.

Par exemple, si vous modifiez le vm.max_map_count setting, vous devez le reformater en vmMaxMapCount dans le fichier JSON de configuration.

Limites de descripteur de fichier Linux

Lorsque vous traitez de grandes quantités de trafic, ce trafic provient généralement d’un grand nombre de fichiers locaux. Vous pouvez ajuster les paramètres de noyau suivants et les limites intégrées pour vous permettre de gérer davantage, au coût de la mémoire système.

Le tableau suivant répertorie les limites de handle de fichier que vous pouvez personnaliser par pool de nœuds :

Paramètre Valeurs autorisées/intervalle Ubuntu 22.04 par défaut Ubuntu 24.04 par défaut Azure Linux 3.0 par défaut Description
fs.file-max 8192 - 9223372036854775807 9223372036854775807 9223372036854775807 9223372036854775807 Nombre maximal de handles de fichiers que le noyau Linux alloue. Cette valeur est définie sur la valeur maximale possible (2^63-1) pour empêcher l’épuisement du descripteur de fichier et garantir un nombre illimité de handles de fichiers à l’échelle du système pour les charges de travail conteneurisées.
fs.inotify.max_user_watches 781250 à 2097152 1 048 576 1 048 576 1 048 576 Nombre maximal d’espions de fichiers autorisés par le système. Chaque espion fait approximativement 90 octets sur un noyau de 32 bits, et environ 160 octets sur un noyau de 64 bits.
fs.aio-max-nr 65536 à 6553500 65536 65536 65536 aio-nr indique le nombre actuel de requêtes io asynchrones à l’échelle du système. aio-max-nr vous permet de modifier la valeur maximale qu’aio-nr peut atteindre.
fs.nr_open 8192 à 20000500 1 048 576 1 048 576 1073741816 Nombre maximal de traitements de fichier pouvant être alloués par un processus.

Remarque

Le fs.file-max paramètre est défini sur 9223372036854775807 (valeur maximale d’un entier 64 bits signé) sur Ubuntu et Linux Azure en fonction des valeurs par défaut en amont. Cette configuration :

  • Empêche les attaques par déni de service basées sur l’épuisement du descripteur de fichier à l’échelle du système.
  • Garantit que les charges de travail de conteneur ne sont jamais bloquées par des limites de handles de fichiers à l’échelle du système.
  • Maintient la sécurité via des limites par processus (fs.nr_open et ulimit) qui s’appliquent toujours à des processus individuels.
  • Optimise les plateformes de conteneur où de nombreux conteneurs peuvent s’exécuter simultanément, chacune ouvrant potentiellement de nombreux fichiers et connexion réseau.

Paramétrage du socket Linux et du réseau

Pour les nœuds d’agent, qui sont censés gérer un grand nombre de sessions simultanées, vous pouvez utiliser les options TCP et réseau suivantes et les ajuster par pool de nœuds :

Paramètre Valeurs autorisées/intervalle Ubuntu 22.04 par défaut Ubuntu 24.04 par défaut Azure Linux 3.0 par défaut Description
net.core.somaxconn 4096 à 3240000 16384 16384 16384 Nombre maximal de demandes de connexion qui peuvent être mises en file d’attente pour un socket d’écoute donné. Limite supérieure pour la valeur du paramètre backlog passé à la fonction listen(2). Si l’argument du backlog est supérieur à somaxconn, il est tronqué en mode silencieux à cette limite.
net.core.netdev_max_backlog 1000 à 3240000 1 000 1 000 1 000 Nombre maximal de paquets, mis en file d’attente côté ENTRÉE, lorsque l’interface reçoit des paquets plus rapidement que le noyau ne peut les traiter.
net.core.rmem_max 212992 à 134217728 1 048 576 1 048 576 212992 Taille maximale de la mémoire tampon du socket de réception, en octets.
net.core.wmem_max 212992 à 134217728 212992 212992 212992 Taille maximale de la mémoire tampon du socket d’envoi, en octets.
net.core.optmem_max 20480 à 4194304 20480 131 072 20480 Taille maximale de la mémoire tampon auxiliaire (mémoire tampon facultative) autorisée par socket. La mémoire facultative du socket est utilisée dans certains cas pour stocker des structures supplémentaires relatives à l’utilisation du socket.
net.ipv4.tcp_max_syn_backlog 128 à 3240000 16384 16384 16384 Nombre maximal de demandes de connexion en file d’attente qui n’ont pas reçu d’accusé de réception du client de connexion. Si ce nombre est dépassé, le noyau commence à supprimer des demandes.
net.ipv4.tcp_max_tw_buckets 8000 à 1440000 262144 262144 131 072 Nombre maximal de sockets timewait détenus simultanément par le système. Si ce nombre est dépassé, le socket time-wait est immédiatement détruit et l’avertissement est imprimé.
net.ipv4.tcp_fin_timeout 5 à 120 60 60 60 La durée pendant laquelle une connexion orpheline (n’est plus référencée par une application) reste dans l’état FIN_WAIT_2 avant d’être abandonnée au niveau local.
net.ipv4.tcp_keepalive_time 30 à 432000 7200 7200 7200 Fréquence à laquelle TCP envoie des messages keepalive lorsque keepalive est activée.
net.ipv4.tcp_keepalive_probes 1 à 15 9 9 9 Nombre de sondes keepalive que TCP envoie, jusqu’à ce qu’il décide que la connexion est rompue.
net.ipv4.tcp_keepalive_intvl 10 – 90 75 75 75 Fréquence à laquelle les sondes sont envoyées. Multipliée par tcp_keepalive_probes, elle constitue le temps nécessaire pour tuer une connexion qui ne répond pas, après le démarrage des sondes.
net.ipv4.tcp_tw_reuse 2 2 2 Permet de réutiliser les sockets TIME-WAIT pour les nouvelles connexions lorsque cela est sûr du point de vue du protocole.
net.ipv4.ip_local_port_range Premier : 1024 – 60999 et Dernier : 32768 – 65535] Premier : 32768 et Dernier : 60999 Premier : 32768 et Dernier : 60999 Premier : 32768 et Dernier : 60999 Plage de ports locaux utilisée par le trafic TCP et UDP pour choisir le port local. Composée de deux nombres : Le premier numéro est le premier port local autorisé pour le trafic TCP et UDP sur le nœud de l’agent, le deuxième est le dernier numéro de port local.
net.ipv4.neigh.default.gc_thresh1 128 à 80000 4096 4096 4096 Nombre minimal d’entrées qui peuvent se trouver dans le cache ARP. Le ramasse-miettes n’est pas déclenché si le nombre d’entrées est inférieur à ce réglage.
net.ipv4.neigh.default.gc_thresh2 512 à 90000 8 192 8 192 8 192 Nombre maximum variable d'entrées pouvant se trouver dans le cache ARP. Ce paramètre est sans doute le plus important, car la collecte des déchets ARP se déclenche environ 5 secondes après avoir atteint ce maximum souple.
net.ipv4.neigh.default.gc_thresh3 1024 à 100000 16384 16384 16384 Nombre maximum absolu d’entrées pouvant figurer dans le cache ARP.
net.netfilter.nf_conntrack_max 131072 – 2097152 524288 524288 262144 nf_conntrack est un module qui effectue le suivi des entrées de connexion pour NAT dans Linux. Le module nf_conntrack utilise une table de hachage pour enregistrer la ligne de la connexion établie du protocole TCP. nf_conntrack_max est le nombre maximal de nœuds dans la table de hachage, autrement dit, le nombre maximal de connexions prises en charge par le module nf_conntrack ou la taille de la table de suivi des connexions.
net.netfilter.nf_conntrack_buckets 65536 – 524288 262144 262144 262144 nf_conntrack est un module qui effectue le suivi des entrées de connexion pour NAT dans Linux. Le module nf_conntrack utilise une table de hachage pour enregistrer la ligne de la connexion établie du protocole TCP. nf_conntrack_buckets est la taille de la table de hachage.

Nombre limite de workers Linux

Tout comme les limites de descripteurs de fichiers, le nombre de rôles de travail ou de threads qu’un processus peut créer est limité à la fois par un paramètre de noyau et par des limites utilisateur. La limite utilisateur sur AKS est illimitée. Le tableau suivant répertorie le paramètre de noyau que vous pouvez personnaliser par pool de nœuds :

Paramètre Ubuntu 22.04 par défaut Ubuntu 24.04 par défaut Azure Linux 3.0 par défaut Description
kernel.threads-max 1030425 1030462 256596 Les processus peuvent faire tourner des threads de travail. Le nombre maximal de tous les threads pouvant être créés est défini avec le paramètre de noyau kernel.threads-max.

Mémoire virtuelle Linux

Le tableau suivant répertorie les paramètres du noyau que vous pouvez personnaliser par pool de nœuds pour paramétrer l’opération du sous-système de mémoire virtuelle du noyau Linux et des writeout données sales sur le disque :

Paramètre Valeurs autorisées/intervalle Ubuntu 22.04 par défaut Ubuntu 24.04 par défaut Azure Linux 3.0 par défaut Description
vm.max_map_count 65530 1 048 576 1 048 576 Ce fichier contient le nombre maximal de zones de mappage de mémoire qu’un processus peut avoir. Les zones de carte mémoire sont utilisées comme un effet secondaire de l’appel de malloc, directement par mmap, mprotect et madvise, ainsi que lors du chargement de bibliothèques partagées.
vm.vfs_cache_pressure 1 – 100 100 100 100 Cette valeur de pourcentage contrôle la tendance du noyau à récupérer la mémoire, qui est utilisée pour la mise en cache des objets inodes et du répertoire.
vm.swappiness 0 - 100 60 60 60 Ce contrôle est utilisé pour définir la façon dont le noyau échange de manière agressive les pages de mémoire. Les valeurs plus élevées augmentent l’agressivité, les valeurs inférieures diminuent la quantité d’échange. La valeur 0 indique au noyau de ne pas lancer l’échange tant que le nombre de pages libres et sauvegardées est inférieur à la limite supérieure d’une zone.
swapFileSizeMB 1 Mo : taille du disque temporaire (/dev/sdb) None None None SwapFileSizeMB spécifie la taille en Mo d’un fichier d’échange à créer sur les nœuds de l’agent à partir de ce pool de nœuds.
transparentHugePageEnabled always madvise never always always madvise Transparent Hugepages est une fonctionnalité de noyau Linux destinée à améliorer les performances en utilisant plus efficacement le matériel de mappage de mémoire de votre processeur. Lorsqu'il est activé, le noyau tente d'allouer hugepages chaque fois que possible et tout processus Linux reçoit des pages de 2 Mo si la région mmap est naturellement alignée sur 2 Mo. Dans certains cas, lorsqu’elles hugepages sont activées à l’échelle du système, les applications peuvent finir par allouer davantage de ressources mémoire. Une application peut mmap couvrir une grande région, mais ne toucher qu'un seul octet, auquel cas, une page de 2 Mo pourrait être allouée au lieu d'une page de 4 ko sans raison valable. C’est pourquoi il est possible de désactiver les hugepages à l’échelle du système ou de ne les avoir qu’à l’intérieur des régions MADV_HUGEPAGE madvise.
transparentHugePageDefrag always, defer, , defer+madvise, madvise, never madvise madvise madvise Cette valeur détermine si le noyau doit utiliser de manière intensive la compression de la mémoire pour rendre plus de hugepages disponibles.

Contenu connexe

  • Last updated on