Personnaliser les paramètres du système d'exploitation (OS) pour un pool de nœuds - Container Service for Kubernetes

Notes d'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 le redéploiement des pods. Avant de procéder, 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 de non-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.

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
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.
Dans la liste des pools de nœuds, recherchez le pool de nœuds cible et choisissez ... > OS Configuration dans la colonne Actions.
Lisez attentivement les notes affichées à l'écran. Cliquez sur + Custom Parameters, sélectionnez les paramètres et spécifiez les nœuds cibles. Définissez le 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 vers d'autres nœuds tant que vous ne reprenez pas l'opération.

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.

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 /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'apporter des modifications.

Nœuds existants

Pour les nœuds existants dans le 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 via la mise à l'échelle horizontale (scale-out), ajoutez 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é des paramètres personnalisés du système d'exploitation, vérifiez que les modifications ont bien été appliquées à vos nœuds.

Connectez-vous à un nœud du pool de nœuds. Pour plus d'informations, consultez la rubrique Se connecter à une instance ECS.
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
```
Pour les paramètres THP, lisez le fichier sysfs correspondant. Par exemple :
```
   cat /sys/kernel/mm/transparent_hugepage/enabled
```
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 est 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 pour ces paramètres, consultez la documentation 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 Configurer à l'aide d'un fichier de configuration.

Paramètres du système de fichiers

Ces paramètres contrôlent les limites des descripteurs 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.

Field name	Description	Default value	Console or OpenAPI
`fs.aio-max-nr`	Le nombre maximal d'opérations d'E/S asynchrones.	65536	Oui
`fs.file-max`	Le nombre maximal de descripteurs 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 accédé par un processus, empêchant ainsi le verrouillage de l'ensemble 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 à forte concurrence.

Field name	Description	Default value	Console or 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 pour le 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 pour le 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 rentre de nouveau dans 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 système	Oui
`net.ipv4.neigh.default.gc_thresh2`	La limite souple pour le 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 pour le 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 ponté 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 de la 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 ajuster le comportement du noyau pour la stabilité.

Field name	Description	Default value	Console or 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 si un soft lockup se produit, 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 CPU lorsqu'un soft lockup est détecté, aidant ainsi au diagnostic.	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 regroupe 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 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 Paramètres THP du noyau Linux.

Field name	Description	Possible values
`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 de pages et améliore les performances.	- `always` : Si une huge page ne peut pas être allouée, le système interrompt 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 est équivalent à `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 regroupe les huge pages pour réduire la fragmentation de la mémoire et améliorer les performances. Il recherche les huge pages dispersées et les fusionne en blocs contigus, améliorant ainsi l'utilisation de la mémoire. Étant donné que 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 temps 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 empêche les échecs d'allocation répétés sur une courte période.	Pour plus d'informations, consultez 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.