Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Customize OS parameters for a node pool

Dernière mise à jour :Aug 11, 2026

Si les paramètres par défaut du système d'exploitation Linux ne répondent pas aux exigences de votre charge de travail, vous pouvez personnaliser les paramètres au niveau du pool de nœuds afin d'optimiser les performances du système. Après l'application des paramètres personnalisés, le système met à jour les configurations des nœuds par lots. Ces modifications s'appliquent immédiatement aux nœuds existants et sont automatiquement héritées par les nouveaux nœuds ajoutés au pool.

Remarques relatives à l'utilisation

Cette fonctionnalité est prise en charge uniquement sur les clusters ACK managés, les clusters ACK dédiés et les clusters ACK Edge exécutant la version 1.28 ou ultérieure.

La création de nouveaux clusters ACK dédiés n'est plus prise en charge. Pour mettre à niveau votre cluster, consultez la rubrique Mettre à niveau un cluster .
Important
  • La modification dynamique des paramètres du système d'exploitation peut déclencher un redéploiement des pods. Avant de poursuivre, assurez-vous que votre application est configurée pour la haute disponibilité (HA).

  • Un ajustement incorrect des paramètres du système d'exploitation peut modifier le comportement du noyau, entraînant une dégradation des performances ou des pannes de nœuds qui affectent vos services. Comprenez parfaitement l'objectif de chaque paramètre et testez toutes les modifications dans un environnement hors production avant de les appliquer en production.

Configurer les paramètres du système d'exploitation du pool de nœuds

Vous pouvez personnaliser les paramètres sysctl et Transparent Huge Pages (THP) au niveau du pool de nœuds. Bien que tous les paramètres soient configurables via des fichiers, une sélection de paramètres sysctl et tous les paramètres THP peuvent être définis à l'aide de la console ACK ou de l'API OpenAPI.

Configurer à l'aide de la console ou de l'API OpenAPI

Console

L'application de paramètres personnalisés du système d'exploitation modifie la configuration des nœuds existants et peut avoir un impact sur vos services. Nous vous recommandons d'effectuer cette opération pendant les heures creuses.

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, recherchez le cluster à gérer et cliquez sur son nom. Dans le volet de navigation de gauche, choisissez Nodes > Node Pools.

  3. Dans la liste des pools de nœuds, repérez le pool de nœuds cible et choisissez ... > OS Configuration dans la colonne Actions.

  4. Lisez attentivement les remarques affichées à l'écran. Cliquez sur + Custom Parameters, sélectionnez les paramètres et spécifiez les nœuds cibles. Définissez le nombre maximal de nœuds à réparer par lot via le champ Maximum Number of Nodes to Repair per Batch (la valeur maximale est 10), puis cliquez sur Submit.

Après avoir défini le Maximum Number of Nodes to Repair per Batch, la configuration du système d'exploitation est appliquée aux nœuds par lots. Pendant ce processus, vous pouvez surveiller la progression dans la section Event History et contrôler l'exécution avec des actions telles que pause, resume et cancel.

La mise en pause vous permet de valider les nœuds mis à niveau. Si vous mettez la tâche en pause, la configuration des nœuds en cours se termine, mais le processus ne se poursuit pas sur les autres nœuds tant que vous ne l'avez pas reprise.

Important

Terminez la tâche de configuration rapidement. Toute tâche en pause est automatiquement annulée après sept jours, et toutes les informations associées aux événements et aux journaux sont supprimées.

API OpenAPI

En plus de la console, vous pouvez personnaliser les paramètres du système d'exploitation à l'aide de l'opération ModifyNodePoolNodeConfig.

Configurer à l'aide d'un fichier de configuration

ACK vous permet d'écrire des paramètres personnalisés dans le fichier /etc/sysctl.d/99-user-customized.conf. Ce fichier est réservé aux configurations personnalisées appliquées lors de l'initialisation et du redémarrage des nœuds. Les paramètres sysctl de ce fichier ont la priorité lors du redémarrage du nœud, remplaçant à la fois les valeurs par défaut du système d'exploitation et les paramètres appliqués via la fonctionnalité OS Configuration de la console.

Important

L'ajustement des paramètres sysctl modifie le fonctionnement du noyau Linux et peut entraîner une dégradation des performances ou une panne du nœud, ce qui affecte vos services. Évaluez entièrement les risques avant d'effectuer des modifications.

Nœuds existants

Pour les nœuds existants du pool de nœuds, connectez-vous au nœud et modifiez le fichier de configuration. Ensuite, exécutez la commande suivante pour appliquer immédiatement les modifications :

sysctl -p /etc/sysctl.d/99-user-customized.conf

Exemple de fichier de configuration (/etc/sysctl.d/99-user-customized.conf) :

# Filesystem settings
fs.file-max = 2097152
fs.nr_open = 1048576

# Networking settings
net.core.somaxconn = 32768
net.ipv4.tcp_max_syn_backlog = 8096

# Memory / kernel settings
vm.max_map_count = 262144

Remplacez les noms et les valeurs des paramètres par ceux dont vous avez besoin pour votre charge de travail.

Nouveaux nœuds (mise à l'échelle horizontale)

Pour les nouveaux nœuds ajoutés au pool de nœuds par mise à l'échelle horizontale, vous pouvez ajouter un script au champ User Data du pool de nœuds. Cela garantit que les nouveaux nœuds utilisent automatiquement les valeurs de paramètres personnalisées.

Dans le champ User Data de la configuration de votre pool de nœuds, ajoutez un script pour écrire la configuration personnalisée dans un fichier du répertoire /etc/sysctl.d/. Remplacez ${sysctl_key} et ${sysctl_value} par le paramètre et la valeur réels.

#!/bin/bash
echo "${sysctl_key} = ${sysctl_value}" >> /etc/sysctl.d/99-user-customized.conf
sysctl -p /etc/sysctl.d/99-user-customized.conf
Pour plus d'informations, consultez la rubrique Créer et gérer des pools de nœuds .

Vérifier que les modifications ont pris effet

Après avoir appliqué les paramètres personnalisés du système d'exploitation, vérifiez que les modifications ont bien été appliquées à vos nœuds.

  1. Connectez-vous à un nœud du pool de nœuds. Pour plus d'informations, consultez la rubrique Se connecter à une instance ECS.

  2. Exécutez la commande sysctl pour vérifier la valeur actuelle d'un paramètre. Par exemple : Sortie attendue :

       sysctl fs.file-max
       fs.file-max = 2097152
  3. Pour les paramètres THP, lisez le fichier sysfs correspondant. Par exemple :

       cat /sys/kernel/mm/transparent_hugepage/enabled
  4. Dans la console ACK, vérifiez l'état de la tâche de configuration dans la section Event History du pool de nœuds.

Liste des paramètres sysctl

Remarque
  • Dans les tableaux suivants, la Default Value correspond à la valeur définie par défaut par ACK lors de l'initialisation d'un pool de nœuds.

  • Pour connaître la plage de valeurs valides de ces paramètres, consultez la documentation relative aux paramètres sysctl du noyau Linux.

  • Pour les paramètres non répertoriés ici ou non encore pris en charge dans la console ou l'API OpenAPI, vous pouvez les modifier en suivant les étapes décrites dans la section Configurer à l'aide d'un fichier de configuration.

Paramètres du système de fichiers

Ces paramètres contrôlent les limites des handles de fichiers, les watches inotify et le comportement du système de fichiers. Ajustez ces paramètres pour les charges de travail intensives en E/S ou les applications qui ouvrent un grand nombre de fichiers.

Nom du champ Description Valeur par défaut Console ou API OpenAPI
fs.aio-max-nr Le nombre maximal d'opérations d'E/S asynchrones. 65536 Oui
fs.file-max Le nombre maximal de handles de fichiers que le système peut ouvrir. 2097152 Oui
fs.inotify.max_user_watches Le nombre maximal de watches inotify qu'un seul utilisateur peut créer. 524288 Oui
fs.inotify.max_user_instances Le nombre maximal d'instances inotify qu'un seul utilisateur peut créer. Limite l'utilisation des ressources par utilisateur. 16384 Non
fs.inotify.max_queued_events Le nombre maximal d'événements du système de fichiers pouvant être mis en file d'attente dans le noyau. 16384 Non
fs.nr_open Le nombre maximal de descripteurs de fichiers qu'un seul processus peut ouvrir. Cette valeur doit être inférieure à fs.file-max. 1048576 Oui
fs.may_detach_mounts Permet au noyau de détacher en toute sécurité un point de montage d'un namespace même s'il est toujours utilisé par un processus, empêchant ainsi le verrouillage de l'intégralité du namespace. 1 Non

Paramètres réseau

Ces paramètres régissent les tampons de socket, la mise en file d'attente des connexions, la mémoire TCP et le comportement du cache ARP. Ajustez ces paramètres pour les charges de travail à fort trafic ou à haute concurrence.

Nom du champ Description Valeur par défaut Console ou API OpenAPI
net.core.netdev_max_backlog Le nombre maximal de paquets de données pouvant être mis en file d'attente pour traitement lorsqu'une interface réseau reçoit des paquets plus rapidement que le noyau ne peut les traiter. 16384 Oui
net.core.optmem_max La taille maximale du tampon auxiliaire pour chaque socket réseau, en octets. 20480 Oui
net.core.rmem_max La taille maximale du tampon de réception pour chaque socket réseau, en octets. 16777216 Oui
net.core.wmem_max La taille maximale du tampon d'envoi pour chaque socket réseau, en octets. 16777216 Oui
net.core.wmem_default La taille par défaut du tampon d'envoi pour chaque socket réseau, en octets. 212992 Oui
net.core.somaxconn Le nombre maximal de connexions pouvant être mises en file d'attente pour un socket en écoute, contrôlant la capacité de gestion des connexions simultanées. 32768 Non
net.ipv4.tcp_mem La quantité de mémoire disponible pour la pile TCP, mesurée en pages mémoire (généralement 4 Ko). Ce paramètre se compose de trois valeurs entières : le seuil bas, le seuil de pression et le seuil haut. Vous devez définir ces valeurs dans l'ordre. Calculé dynamiquement en fonction de la mémoire totale du système. Oui
net.ipv4.tcp_wmem Les tailles minimale, par défaut et maximale du tampon d'envoi TCP, en octets. Ce paramètre affecte directement le débit réseau et la consommation de mémoire des connexions TCP. 4096 12582912 16777216 Non
net.ipv4.tcp_rmem Les tailles minimale, par défaut et maximale du tampon de réception TCP, en octets. Ce paramètre affecte directement le débit réseau et la consommation de mémoire des connexions TCP. 4096 12582912 16777216 Non
net.ipv4.tcp_max_syn_backlog Le nombre maximal de demandes de connexion avec une poignée de main en trois temps incomplète dans la file d'attente SYN. 8096 Non
net.ipv4.tcp_slow_start_after_idle Contrôle si une connexion TCP réintègre l'algorithme de démarrage lent après une longue période d'inactivité. 0 Non
net.ipv4.ip_forward Active le transfert de paquets IPv4, permettant au système d'agir comme un routeur. 1 Non
net.ipv4.neigh.default.gc_thresh1 Le nombre minimal d'entrées à conserver dans le cache ARP. Le système n'effectue pas de garbage collection si le nombre d'entrées est inférieur à cette valeur. Préréglage du système Oui
net.ipv4.neigh.default.gc_thresh2 La limite souple du nombre maximal d'entrées dans le cache ARP. Lorsque le nombre d'entrées atteint cette valeur, le système planifie l'exécution du garbage collection après un délai de cinq secondes. 1024 Oui
net.ipv4.neigh.default.gc_thresh3 La limite stricte du nombre maximal d'entrées dans le cache ARP. Le système effectue immédiatement le garbage collection lorsque le nombre d'entrées atteint cette valeur. Si le nombre d'entrées dépasse constamment cette limite, le processus de garbage collection s'exécute en continu. 8192 Oui
net.bridge.bridge-nf-call-iptables Permet au trafic bridgé d'être traité par les règles iptables, garantissant l'application des politiques de sécurité réseau. 1 Non

Paramètres de mémoire et du noyau

Ces paramètres contrôlent les limites des processus, le nombre de threads, le mappage mémoire et les diagnostics du noyau. Ajustez ces paramètres lorsque vos charges de travail nécessitent un grand nombre de processus ou de threads, ou lorsque vous devez adapter le comportement du noyau pour la stabilité.

Nom du champ Description Valeur par défaut Console ou API OpenAPI
kernel.pid_max L'identifiant de processus (PID) maximal que le système peut attribuer. 4194303 Oui
kernel.threads-max Le nombre maximal de threads que le système peut créer. 504581 Oui
kernel.softlockup_panic Lorsqu'il est activé, le noyau déclenche un panic et redémarre le système en cas de soft lockup, permettant au système de restaurer rapidement son état. 1 Non
kernel.softlockup_all_cpu_backtrace Lorsqu'il est activé, capture les informations de débogage de tous les processeurs lorsqu'un soft lockup est détecté, facilitant ainsi les diagnostics. 1 Non
vm.max_map_count Le nombre maximal de zones de mappage mémoire qu'un seul processus peut avoir. Limite l'utilisation excessive de la mémoire. 262144 Non
user.max_user_namespaces Le nombre maximal de namespaces utilisateur qu'un seul utilisateur peut créer. 0 Oui

Liste des paramètres THP

Transparent Huge Pages (THP) est une fonctionnalité du noyau Linux qui fusionne automatiquement les petites pages mémoire (généralement 4 Ko) en pages plus grandes (généralement 2 Mo ou plus). Ce processus réduit la surcharge des entrées de table de pages (PTE) et le nombre d'accès mémoire, diminuant ainsi la pression sur le Translation Lookaside Buffer (TLB) et améliorant l'efficacité des accès mémoire.

Remarque
  • Tous les paramètres suivants peuvent être configurés via la console ACK ou l'API OpenAPI.

  • Les valeurs par défaut de ces paramètres varient selon le système d'exploitation et la version du noyau. Pour plus d'informations, consultez la documentation relative aux paramètres THP du noyau Linux.

Nom du champ Description Valeurs possibles
transparent_enabled Contrôle si THP est activé globalement.

- always : active THP à l'échelle du système.

- never : désactive THP à l'échelle du système.

- madvise : active THP uniquement pour les régions mémoire marquées avec l'indicateur MADV_HUGEPAGE via l'appel système madvise().

transparent_defrag Contrôle si le noyau effectue une défragmentation de la mémoire pour créer des huge pages. Lorsqu'il est activé, le système peut fusionner de petites pages en une seule huge page, ce qui réduit la taille de la table des pages et améliore les performances.

- always : si une huge page ne peut pas être allouée, le système met en pause le processus d'allocation et tente immédiatement de récupérer et de défragmenter la mémoire. Si suffisamment de mémoire libre contiguë devient disponible, l'allocation de la huge page se poursuit.

- defer : si une huge page ne peut pas être allouée, le système alloue plutôt une page standard de 4 Ko. Les threads du noyau kswapd et kcompactd sont réveillés pour récupérer et défragmenter la mémoire en arrière-plan. Plus tard, le thread du noyau khugepaged peut fusionner ces pages de 4 Ko en une huge page de 2 Mo si suffisamment de mémoire contiguë est disponible.

- madvise : l'allocation se comporte comme always uniquement pour les régions mémoire marquées avec l'indicateur MADV_HUGEPAGE via l'appel système madvise(). Pour toutes les autres régions mémoire, une faute de page entraîne l'allocation d'une page standard de 4 Ko.

- defer+madvise : l'allocation se comporte comme always pour les régions mémoire marquées avec MADV_HUGEPAGE. Pour toutes les autres régions mémoire, le comportement d'allocation équivaut à defer.

- never : interdit tous les efforts de défragmentation pour les huge pages.

khugepaged_defrag khugepaged est un thread du noyau qui gère et fusionne les huge pages pour réduire la fragmentation de la mémoire et améliorer les performances. Il recherche des huge pages dispersées et les fusionne en blocs contigus, améliorant ainsi l'utilisation de la mémoire. Comme ce processus implique des opérations de verrouillage dans le chemin d'accès à la mémoire et que le thread du noyau khugepaged peut scanner et convertir des pages à des moments inopportuns, il peut potentiellement affecter les performances des applications.

- 0 : désactive la défragmentation khugepaged.

- 1 : le thread du noyau khugepaged se réveille périodiquement pendant les périodes d'inactivité du système pour fusionner les pages contiguës de 4 Ko en huge pages de 2 Mo.

khugepaged_alloc_sleep_millisecs Le temps, en millisecondes, pendant lequel le thread du noyau khugepaged attend avant la prochaine tentative d'allocation de huge page après un échec. Cela évite les échecs d'allocation répétés sur une courte période. Pour plus d'informations, consultez la rubrique Défragmentation khugepaged.
khugepaged_scan_sleep_millisecs L'intervalle, en millisecondes, entre chaque réveil du thread du noyau khugepaged pour scanner la mémoire.
khugepaged_pages_to_scan Le nombre de pages mémoire que le thread du noyau khugepaged scanne à chaque réveil.