Customize node pool kubelet configurations - Container Service for Kubernetes

Limitations

Seuls les clusters ACK exécutant Kubernetes 1.20 ou une version ultérieure prennent en charge les paramètres kubelet personnalisés. Pour mettre à jour un cluster, consultez la rubrique Mettre à jour manuellement un cluster.
Seuls les clusters ACK Lingjun exécutant Kubernetes 1.22 ou une version ultérieure prennent en charge les paramètres kubelet personnalisés. Pour mettre à jour un cluster, consultez la rubrique Mettre à jour un cluster.

Si la version de votre cluster ne satisfait pas ces conditions, un comportement inattendu peut se produire.

Notes d'utilisation

Les paramètres kubelet personnalisés sont appliqués aux nœuds par lots. Les modifications prennent effet immédiatement sur les nœuds existants du pool de nœuds et sont automatiquement appliquées aux nouveaux nœuds. L'application de la configuration redémarre le processus kubelet, ce qui peut affecter les nœuds et les charges de travail en cours d'exécution. Nous vous recommandons d'effectuer cette opération pendant les heures creuses.
Si evictionHard, kubeReserved ou systemReserved n'est pas configuré, le système utilise des valeurs par défaut pour la réservation de ressources. Pour plus d'informations sur le calcul des valeurs par défaut, consultez la rubrique Politique de réservation des ressources des nœuds.
Les modifications apportées à la configuration de réservation des ressources peuvent réduire les ressources allouables d'un nœud. Pour les nœuds dont l'utilisation des ressources est élevée, cela peut déclencher une éviction des pods.
Nous vous déconseillons fortement d'utiliser la ligne de commande pour définir des paramètres kubelet non pris en charge dans la console. L'utilisation de la ligne de commande présente des risques importants pour la stabilité. Vous êtes responsable de l'exactitude et de la compatibilité du contenu du fichier de données utilisateur. Des paramètres incorrects ou obsolètes peuvent rendre les nœuds indisponibles.
Au démarrage, le kubelet fusionne les configurations provenant de différentes sources en fonction de leur priorité. Si un même élément de configuration est défini de plusieurs manières, le paramètre ayant la priorité la plus élevée écrase celui ayant la priorité la plus basse.
Ordre de fusion des configurations
Les configurations suivantes sont classées par ordre de priorité croissante :
1. Les portes de fonctionnalités (feature gates) spécifiées par l'indicateur --feature-gates dans la ligne de commande.
2. Le fichier de configuration kubelet, qui contient les paramètres personnalisés via la console ACK ou l'OpenAPI.
3. Les configurations des plugins, chargées par ordre alphabétique depuis le répertoire de configuration kubelet.
4. Les paramètres de ligne de commande autres que les portes de fonctionnalités, spécifiés directement via la ligne de commande.

Personnaliser les paramètres kubelet dans la console

L'application de paramètres kubelet personnalisés redémarre le processus kubelet, ce qui peut affecter vos services. Nous vous recommandons d'effectuer cette opération pendant les heures creuses.

Sur la page Clusters ACK, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Nodes > Node Pools.
Sur la page Node Pools, localisez le pool de nœuds cible et choisissez > Kubelet Configuration dans la colonne Actions.
Lisez les notes affichées sur la page. Cliquez sur Custom Parameters, sélectionnez les paramètres à configurer, spécifiez les nœuds à mettre à jour et définissez la politique de mise à jour par lots. Ensuite, suivez les instructions pour terminer l'opération.

La politique de mise à jour par lots est décrite ci-dessous :
- Maximum Parallel Nodes per Batch : nombre de nœuds à mettre à jour simultanément dans chaque lot. Vous pouvez surveiller et gérer le processus de mise à jour dans la liste des événements.
- Interval Between Batches : temps d'attente entre les lots de mise à jour consécutifs.
Vous pouvez suspendre la mise à jour pour vérifier les nœuds mis à jour. En cas de suspension, toutes les mises à jour de nœuds en cours se termineront, mais aucune nouvelle mise à jour ne démarrera tant que vous n'aurez pas repris la tâche.

Terminez la tâche de configuration personnalisée dès que possible. Une tâche suspendue est automatiquement annulée après sept jours, et les événements et journaux associés sont supprimés.

Outre la console, vous pouvez également appeler l'opération API ModifyNodePoolNodeConfig pour personnaliser les paramètres kubelet. La section suivante décrit les paramètres kubelet personnalisables pris en charge par ACK.

Paramètres kubelet personnalisables

Paramètre	Description	Valeur par défaut	Valeurs
allowedUnsafeSysctls	Spécifiez les sysctls non sécurisés autorisés ou les caractères génériques sysctl (motifs se terminant par ``). Séparez-les par une virgule (,). Important* Avant d'utiliser ce paramètre, évaluez soigneusement les risques et assurez-vous de la disponibilité.	S/O	Prend en charge les configurations sysctl avec les préfixes suivants : kernel.shm kernel.msg kernel.sem fs.mqueue. net.
containerLogMaxFiles	Nombre maximal de fichiers journaux pour un conteneur. La valeur doit être supérieure ou égale à 2. Le runtime de conteneur doit être containerd.	10	[2, 10]
containerLogMaxSize	Taille maximale d'un fichier journal de conteneur avant sa rotation. Le runtime de conteneur doit être containerd.	100Mi	S/O
cpuCFSQuota	Active l'application du quota CPU CFS pour les conteneurs disposant de limites CPU.	true	Valeurs valides : true false
cpuCFSQuotaPeriod	Définit la valeur de la période de quota CPU CFS. La porte de fonctionnalité CustomCPUCFSQuotaPeriod doit être activée.	100ms	Une valeur comprise entre 1 milliseconde et 1 seconde, inclus.
cpuManagerPolicy	Stratégie du gestionnaire de CPU.	none	Valeurs valides : none static
eventBurst	Nombre maximal d'enregistrements d'événements lors d'une rafale.	10	La valeur doit être un entier compris entre 1 et 100, et supérieur ou égal à la valeur de `eventRecordQPS`.
eventRecordQPS	Nombre d'événements pouvant être générés par seconde.	5	[1, 50]
evictionHard	Ensemble de seuils d'éviction stricts qui déclenchent l'éviction des pods.	imagefs.available<15%,memory.available<300Mi,nodefs.available<10%,nodefs.inodesFree<5%	Aucun
evictionSoft	Ensemble de seuils d'éviction souples.	Aucun	Aucun
evictionSoftGracePeriod	Ensemble de périodes de grâce d'éviction. Remarque `evictionSoft` doit être défini.	Aucun	Aucun
featureGates	Ensemble de portes de fonctionnalités pour les fonctionnalités expérimentales. Chaque porte est représentée sous la forme `key=value`. Pour plus d'informations, consultez la documentation Feature Gates. Dans le formulaire de configuration, sélectionnez une clé (par exemple `featureGates`) dans la liste déroulante de gauche, saisissez la valeur correspondante dans la zone de texte de droite, puis cochez la case à droite pour activer la porte de fonctionnalité. Important Avant d'utiliser ce paramètre, évaluez soigneusement les risques et assurez-vous de la disponibilité. Les portes de fonctionnalités supprimées n'ont aucun effet. Mettez-les à jour rapidement. Pour plus d'informations, consultez la documentation Feature Gates (removed).	S/O	S/O
imageGCHighThresholdPercent	Pourcentage d'utilisation du disque qui déclenche le nettoyage des images. Le nettoyage des images s'exécute en continu lorsque l'utilisation du disque dépasse ce seuil. Cette valeur doit être supérieure à la valeur de imageGCLowThresholdPercent.	85	[60, 95]
imageGCLowThresholdPercent	Pourcentage d'utilisation du disque en dessous duquel le nettoyage des images ne s'exécute pas. Cette valeur doit être inférieure à la valeur de imageGCHighThresholdPercent.	80	[30, 90]
kubeAPIBurst	Nombre maximal de requêtes en rafale envoyées au serveur API par seconde.	10	[1, 100], et doit être supérieur ou égal à `kubeAPIQPS`
kubeAPIQPS	Nombre de requêtes par seconde (QPS) vers le serveur API.	5	[1, 50]
kubeReserved	Configuration des ressources réservées pour les daemons système Kubernetes.	La valeur est calculée automatiquement par défaut. Pour plus d'informations, consultez la rubrique Politique de réservation des ressources des nœuds.	S/O
maxPods	Nombre maximal de pods pouvant s'exécuter sur un nœud. Important La modification de la valeur de `maxPods` n'affecte pas le nombre d'adresses IP pouvant être allouées au nœud. Si la valeur de `maxPods` est trop élevée, les pods n'utilisant pas le mode HostNetwork peuvent échouer au démarrage en raison de l'impossibilité d'obtenir une adresse IP.	S/O. La valeur dépend des configurations des ressources physiques, telles que les spécifications de la machine et la planification du réseau de conteneurs.	S/O
memoryManagerPolicy	Stratégie du gestionnaire de mémoire.	None	Valeurs valides : None Static Avant d'utiliser cette stratégie, effectuez les opérations suivantes : La porte de fonctionnalité MemoryManager est activée. Si vous gérez manuellement les réservations de ressources mémoire (systemReserved, kubeReserved, evictionHard et reservedMemory), vous devez vous assurer que la configuration est correcte. La configuration doit suivre la formule `kube-reserved + system-reserved + eviction-hard = sum(reserved-memory)` pour éviter que les nœuds ne deviennent indisponibles. Par exemple, dans le panneau de paramètres personnalisés, définissez memoryManagerPolicy sur Static et configurez les paramètres suivants selon la formule `evictionHard.memory.available + systemReserved.memory + kubeReserved.memory = sum(reservedMemory.limits.memory)` : définissez memory.available de evictionHard sur `100Mi`, memory de kubeReserved sur `100Mi`, numaNode de reservedMemory sur `0`, limits.memory de reservedMemory sur `300Mi` et memory de systemReserved sur `100Mi`. Pour plus d'informations, consultez la documentation Reserved memory flag.
podPidsLimit	Nombre maximal d'identifiants de processus (PID) utilisables dans chaque pod. Un entier positif : définit la limite supérieure du nombre de PID. -1 : aucune limite n'est définie pour le nombre de PID.	16384	Aucun
readOnlyPort	Port en lecture seule pour le kubelet ne nécessitant pas d'authentification.	Pour les clusters exécutant Kubernetes 1.26 ou une version ultérieure, la valeur par défaut est 0. Pour les clusters exécutant une version de Kubernetes antérieure à 1.26, la valeur par défaut est 10255.	0 Pour connaître les risques liés à l'ouverture du port en lecture seule (10255) pour la surveillance des conteneurs kubelet, consultez la rubrique [Modification du produit] Migrer le port de surveillance des clusters ACK de versions antérieures vers un port authentifié.
registryBurst	Nombre maximal de pulls d'images en rafale.	10	La valeur doit être comprise dans la plage [1, 100] et doit être supérieure ou égale à la valeur de `registryPullQPS`.
registryPullQPS	QPS maximal pour le registre d'images.	5	[1, 50]
reservedMemory	Liste des réservations de mémoire pour les nœuds NUMA.	Aucun	Aucun
serializeImagePulls	Indique si les images doivent être extraites de manière sérielle.	False	Valeurs valides : False : il s'agit de la valeur recommandée. Elle permet d'extraire les images en parallèle pour accélérer le démarrage des pods. True : extrait les images de manière sérielle.
systemReserved	Configuration des ressources réservées pour les daemons système.	La valeur est calculée automatiquement par défaut. Pour plus d'informations, consultez la rubrique Politique de réservation des ressources des nœuds.	S/O
topologyManagerPolicy	Stratégie du gestionnaire de topologie. Avec une architecture NUMA, l'allocation des données sur le même nœud NUMA réduit les accès inter-nœuds et améliore les performances. Le gestionnaire de topologie prend des décisions d'allocation de ressources alignées sur la topologie. Pour plus d'informations, consultez la documentation Control Topology Management Policies on a node.	none	`none` (par défaut) : n'applique pas de stratégie de gestion de la topologie. `restricted` : le kubelet rejette un pod si ses demandes de ressources ne peuvent pas être satisfaites par un seul nœud NUMA. `best-effort` : le kubelet tente d'allouer les ressources sur un seul nœud NUMA, mais autorise les allocations provenant de plusieurs nœuds NUMA si une allocation sur un seul nœud n'est pas possible. `single-numa-node` : le kubelet n'autorise l'allocation des ressources CPU et périphériques que depuis un seul nœud NUMA pour un pod.
containerLogMonitorInterval	Le cluster doit exécuter Kubernetes 1.30 ou une version ultérieure. Intervalle de vérification des journaux de conteneur pour la rotation.	10s	[3s, 60s]
containerLogMaxWorkers	Le cluster doit exécuter Kubernetes 1.30 ou une version ultérieure. Nombre maximal de workers simultanés pour la rotation des journaux.	1	[1, 20]
tracing	Active le traçage pour les composants du plan de contrôle ou du plan de données du cluster. Pour plus d'informations, consultez la rubrique Gestion du traçage.	Aucun	endpoint : le paramètre recommandé est `localhost:4317`. `samplingRatePerMillion` : [0, 1000000]
singleProcessOOMKill	Contrôle le comportement OOM Kill des conteneurs dans un environnement cgroup v2. Lorsqu'il est défini sur `true`, ce paramètre désactive l'indicateur `memory.oom.group` pour le cgroup du conteneur, ce qui entraîne l'arrêt individuel des processus à l'intérieur du conteneur en cas de manque de mémoire (OOM), plutôt qu'en groupe. Ce comportement est cohérent avec cgroup v1. Si ce paramètre n'est pas explicitement configuré, le système détermine automatiquement la valeur par défaut en fonction de l'environnement actuel : `true` : déclenche un arrêt OOM individuellement. `false` : déclenche un arrêt OOM par groupe (comportement par défaut pour cgroup v2).	Dans un environnement cgroup v2, la valeur par défaut est `false`	Non-Linux : seule la valeur `true` est prise en charge. cgroup v1 Linux : seule la valeur `true` est prise en charge. cgroup v2 Linux : prend en charge les valeurs `true` et `false`
configMapAndSecretChangeDetectionStrategy	Mode de fonctionnement du gestionnaire ConfigMap et Secret.	`Watch`	`Get` : le kubelet récupère directement les objets requis depuis le serveur API. `Cache` : le kubelet utilise un TTL pour mettre en cache les objets récupérés depuis le serveur API. `Watch` : le kubelet utilise le mécanisme Watch pour surveiller les modifications des objets pertinents.
serverTLSBootstrap	Seuls les clusters ACK Managed Pro sont pris en charge. Assurez-vous que la porte de fonctionnalité `RotateKubeletServerCertificate` est activée. Activez le bootstrap du certificat serveur Kubelet. Lorsque cette fonctionnalité est activée, Kubelet demande des certificats serveur au cluster via l'API `certificates.k8s.io` au lieu d'utiliser des certificats auto-signés. Le cluster approuve automatiquement ces demandes de signature de certificat (CSR).	Pour les clusters 1.34 ou ultérieurs : `true` Pour les clusters de version 1.33 et inférieures : `false`	Valeurs valides : `true` `false`

FAQ

Les configurations personnalisées seront-elles obsolètes ?

À mesure que Kubernetes évolue, certains paramètres et portes de fonctionnalités peuvent devenir obsolètes ou être supprimés. Si un paramètre personnalisé géré par ACK devient obsolète dans une nouvelle version de Kubernetes, ACK supprime la configuration correspondante lors de la mise à niveau du cluster.

Gestion de kubelet avec un fichier de configuration

Container Service for Kubernetes adapte la gestion des configurations kubelet en fonction des meilleures pratiques de la communauté. Pour les clusters exécutant Kubernetes 1.20 ou une version ultérieure, les indicateurs de ligne de commande kubelet obsolètes sont progressivement remplacés par un fichier de configuration. Pour plus d'informations, consultez la documentation Kubelet Configuration (v1beta1).

Les nouveaux nœuds utilisent à la fois le fichier de configuration et la méthode de configuration d'origine. Les nœuds existants ne sont pas affectés. Pour gérer les configurations de tous les nœuds d'un pool de nœuds uniquement à l'aide du fichier de configuration, vous pouvez appliquer une configuration personnalisée comme décrit dans la section Paramètres kubelet personnalisables afin d'uniformiser les configurations de tous les nœuds du pool.

Modification des paramètres kubelet non pris en charge

ACK vous permet d'écrire des paramètres personnalisés dans le fichier /etc/kubernetes/kubelet-customized-args.conf. Ce fichier stocke les paramètres de démarrage personnalisés et les options de configuration pour le kubelet. Les paramètres de ce fichier ont priorité sur les valeurs définies via la fonctionnalité de configuration kubelet personnalisée du pool de nœuds lors du redémarrage du nœud.

Important

L'ajustement des paramètres kubelet peut entraîner des problèmes tels que des échecs d'enregistrement des nœuds et des échecs de planification des pods, ce qui affecte vos services. Avant de procéder, évaluez pleinement les risques liés à la modification.

(Recommandé) Pour les nœuds qui seront ajoutés au pool de nœuds à l'avenir, vous pouvez ajouter un script qui écrit dans le fichier de configuration des paramètres personnalisés à la section User Data du pool de nœuds. Cela garantit que les nouveaux nœuds utilisent ces valeurs de paramètres personnalisés par défaut.

Configurez le contenu suivant dans la section User Data de la configuration du pool de nœuds, et remplacez ${kubelet_key} et ${kubelet_value} par les valeurs réelles.

Vous ne pouvez écrire dans le fichier kubelet-customized-args.conf qu'en utilisant la commande > /etc/kubernetes/kubelet-customized-args.conf ou > kubelet-customized-args.conf dans la section User Data . Si vous modifiez le fichier par toute autre méthode dans Pre-defined Custom Data , le fichier /etc/kubernetes/kubelet-customized-args.conf sera écrasé pendant le processus d'initialisation d'ACK.
```
mkdir -p /etc/kubernetes  
echo 'KUBELET_CUSTOMIZED_ARGS="--${kubelet_key}=${kubelet_value}"' > /etc/kubernetes/kubelet-customized-args.conf
systemctl daemon-reload
systemctl restart kubelet
```
Pour accéder à la page de configuration, consultez la rubrique Créer et gérer des pools de nœuds .
Pour les nœuds existants dans le pool de nœuds, connectez-vous au nœud pour modifier le fichier de configuration des paramètres personnalisés. Ensuite, exécutez les commandes suivantes pour appliquer la configuration.
```
systemctl daemon-reload
systemctl restart kubelet
```

Références

Pour plus d'informations sur les éléments de configuration d'un pool de nœuds, consultez la rubrique Créer et gérer des pools de nœuds.
Si vous rencontrez des erreurs ou un comportement anormal avec vos nœuds, pods ou le kubelet, consultez les rubriques Résoudre les anomalies des nœuds, Dépannage des pods et FAQ sur les nœuds et les pools de nœuds pour résoudre les problèmes.