Personnaliser la configuration du système de nœud

Ce document explique comment personnaliser la configuration de vos nœuds Google Kubernetes Engine (GKE) à l'aide d'un fichier de configuration appelé configuration de système de nœuds.

Présentation

Vous pouvez personnaliser la configuration de vos nœuds à l'aide de différentes méthodes. Par exemple, vous pouvez spécifier des paramètres tels que le type de machine et la configuration minimale de la plate-forme du processeur lorsque vous créez un pool de nœuds.

Une configuration de système de nœuds est un fichier de configuration qui permet d'ajuster un ensemble limité de paramètres système. Vous pouvez utiliser une configuration de système de nœuds pour spécifier des paramètres personnalisés pour l'agent de nœud Kubernetes (kubelet) et des configurations de noyau Linux de bas niveau (sysctl) dans vos pools de nœuds.

Vous pouvez également personnaliser votre environnement d'exécution de conteneur containerd sur vos nœuds GKE à l'aide d'un fichier différent appelé fichier de configuration d'exécution. Pour obtenir des instructions, consultez la section Personnaliser la configuration containerd dans les nœuds GKE.

Vous pouvez également utiliser des DaemonSets pour personnaliser les nœuds, comme décrit dans la section Amorçage automatique des nœuds GKE avec DaemonSets.

Utiliser une configuration de système de nœuds

Pour utiliser une configuration de système de nœuds :

  1. Créez un fichier de configuration. Ce fichier contient vos configurations kubelet et sysctl.
  2. Ajoutez la configuration lorsque vous créez un cluster, ou lorsque vous créez ou mettez à jour un pool de nœuds.

Créer un fichier de configuration

Écrivez le fichier de configuration du système de nœud en YAML. L'exemple suivant montre comment ajouter des configurations pour les options kubelet et sysctl :

kubeletConfig:
  cpuManagerPolicy: static
linuxConfig:
 sysctl:
   net.core.somaxconn: '2048'
   net.ipv4.tcp_rmem: '4096 87380 6291456'

Dans cet exemple :

  • cpuManagerPolicy: static configure le kubelet pour utiliser la règle de gestion du processeur statique.
  • net.core.somaxconn: '2048' limite les tâches en attente socket listen() à 2 048 octets.
  • net.ipv4.tcp_rmem: '4096 87380 6291456' définit la valeur minimale, la valeur par défaut et la valeur maximale du tampon de réception de socket TCP sur 4 096 octets, 87 380 octets et 6 291 456 octets, respectivement.

Si vous ne souhaitez ajouter des configurations que pour le kubelet ou sysctl, n'incluez que cette section dans votre fichier de configuration. Par exemple, pour ajouter une configuration kubelet, créez le fichier suivant :

kubeletConfig:
  cpuManagerPolicy: static

Pour obtenir la liste complète des champs que vous pouvez ajouter à votre fichier de configuration, consultez les sections Options de configuration Kubelet et Options de configuration Sysctl.

Ajouter la configuration à un pool de nœuds

Après avoir créé le fichier de configuration, ajoutez l'option --system-config-from-file à l'aide de Google Cloud CLI. Vous pouvez ajouter cette option lorsque vous créez un cluster, ou lorsque vous créez ou mettez à jour un pool de nœuds. Vous ne pouvez pas ajouter de configuration de système de nœuds avec la console Google Cloud.

Pour ajouter une configuration de système de nœuds, exécutez la commande suivante :

Créer un cluster

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Remplacez l'élément suivant :

  • CLUSTER_NAME : nom de votre cluster.
  • LOCATION : zone ou région Compute du cluster.
  • SYSTEM_CONFIG_PATH : chemin d'accès au fichier contenant vos configurations kubelet et sysctl.

Une fois que vous avez appliqué une configuration de système de nœud, le pool de nœuds par défaut du cluster utilise les paramètres que vous avez définis.

Créer un pool de nœuds

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --system-config-from-file=SYSTEM_CONFIG_PATH

Remplacez l'élément suivant :

  • POOL_NAME : nom de votre pool de nœuds.
  • CLUSTER_NAME : nom du cluster auquel vous souhaitez ajouter un pool de nœuds.
  • LOCATION : zone ou région Compute du cluster.
  • SYSTEM_CONFIG_PATH : chemin d'accès au fichier contenant vos configurations kubelet et sysctl.

Mettre à jour le pool de nœuds

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Remplacez l'élément suivant :

  • POOL_NAME : nom du pool de nœuds que vous souhaitez mettre à jour.
  • CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.
  • LOCATION : zone ou région Compute du cluster.
  • SYSTEM_CONFIG_PATH : chemin d'accès au fichier contenant vos configurations kubelet et sysctl.

Modifier une configuration de système de nœuds

Pour modifier une configuration de système de nœuds, vous pouvez créer un pool de nœuds avec la configuration souhaitée ou mettre à jour la configuration du système de nœud d'un pool de nœuds existant.

Modifier en créant un pool de nœuds

Pour modifier une configuration de système de nœuds en créant un pool de nœuds, procédez comme suit :

  1. Créez un fichier de configuration avec la configuration de votre choix.
  2. Ajoutez la configuration à un nouveau pool de nœuds.
  3. Migrez vos charges de travail vers le nouveau pool de nœuds.
  4. Supprimez l'ancien pool de nœuds.

Modifier en mettant à jour un pool de nœuds existant

Pour modifier une configuration de système de nœuds en mettant à jour un pool de nœuds existant, mettez à jour la configuration du système de nœuds avec les valeurs souhaitées. La mise à jour d'une configuration de système de nœuds remplace la configuration système du pool de nœuds par la nouvelle configuration. Si vous omettez des paramètres lors d'une mise à jour, ils sont définis sur leurs valeurs par défaut.

Si vous souhaitez réinitialiser la configuration de système de nœuds, mettez à jour le fichier de configuration avec des valeurs vides pour le kubelet et sysctl. Exemple :

kubeletConfig: {}
linuxConfig:
  sysctl: {}

Supprimer une configuration de système de nœuds

Pour supprimer une configuration de système de nœuds, procédez comme suit :

  1. Créez un pool de nœuds.
  2. Migrez vos charges de travail vers le nouveau pool de nœuds.
  3. Supprimez le pool de nœuds contenant l'ancienne configuration de système de nœuds.

Options de configuration Kubelet

Le tableau suivant présente les options de kubelet que vous pouvez modifier.

Paramètres de configuration Kubelet Restrictions Paramètre par défaut Description
cpuManagerPolicy La valeur doit être none ou static. none Ce paramètre contrôle la règle du gestionnaire de processeur du kubelet. La valeur par défaut est none, ce qui correspond au schéma d'affinité de processeur par défaut, qui ne fournit aucune affinité au-delà de celle qui est fournie automatiquement par le programmeur du système d'exploitation.

Si vous définissez cette valeur sur static, les pods de la classe QoS garantie ayant des requêtes de processeurs entières se voient attribuer une utilisation exclusive des processeurs.
cpuCFSQuota La valeur doit être true ou false. true Ce paramètre applique la limite de processeur du pod. Définir cette valeur sur false signifie que les limites du processeur pour les pods sont ignorées.

Il est préférable d'ignorer les limites du processeur dans certains scénarios où les pods sont sensibles aux limites du processeur. Le risque lié à la désactivation de cpuCFSQuota est qu'un pod non autorisé peut consommer plus de ressources de processeur que prévu.
cpuCFSQuotaPeriod La valeur doit être une durée. "100ms" Ce paramètre définit la valeur de période de quota du CFS du processeur (cpu.cfs_period_us) qui spécifie la période à laquelle l'accès d'un groupe aux ressources du processeur doit être réattribué. Cette option vous permet d'ajuster le comportement de limitation du processeur.
insecureKubeletReadonlyPortEnabled La valeur doit être une valeur booléenne (true ou false). true Ce paramètre désactive le port accessible en lecture seule et non sécurisé du kubelet 10255 sur chaque nouveau pool de nœuds de votre cluster. Si vous configurez ce paramètre dans ce fichier, vous ne pouvez pas utiliser un client API GKE pour modifier le paramètre au niveau du cluster.
podPidsLimit La valeur doit être comprise entre 1 024 et 4 194 304 none Ce paramètre définit le nombre maximal d'ID de processus (PID) que chaque pod peut utiliser.

Options de configuration Sysctl

Pour ajuster les performances de votre système, vous pouvez modifier les attributs de noyau suivants :

Différents espaces de noms Linux peuvent avoir des valeurs uniques pour un sysctl donné, tandis que d'autres sont globaux pour l'ensemble du nœud. La mise à jour des options sysctl à l'aide d'une configuration de système de nœuds garantit que sysctl est appliqué de manière globale sur le nœud et dans chaque espace de noms. Ainsi, chaque pod a des valeurs sysctl identiques dans chaque espace de noms Linux.

Options de configuration du mode cgroup de Linux

Le kubelet et l'environnement d'exécution du conteneur utilisent des cgroups du noyau Linux pour la gestion des ressources, par exemple pour limiter la quantité de ressources processeur ou mémoire auxquelles chaque conteneur d'un pod peut accéder. Il existe deux versions du sous-système cgroup dans le noyau : cgroupv1 et cgroupv2. La compatibilité de Kubernetes avec cgroupv2 a été introduite en version alpha dans la version 1.18 de Kubernetes, en version bêta dans la version 1.22 et en disponibilité générale dans la version 1.25. Pour plus de détails, consultez la documentation consacrée aux cgroups Kubernetes en v2.

La configuration du système de nœud vous permet de personnaliser la configuration cgroup de vos pools de nœuds. Vous pouvez utiliser cgroupv1 ou cgroupv2. GKE utilise cgroupv2 pour les nouveaux pools de nœuds Standard exécutant les versions 1.26 ou ultérieures, et cgroupv1 pour les versions antérieures à la version 1.26. Pour les pools de nœuds créés avec le provisionnement automatique des nœuds, la configuration cgroup dépend de la version initiale du cluster, et non de la version du pool de nœuds.

Vous pouvez utiliser la configuration du système de nœud pour modifier le paramètre d'un pool de nœuds afin d'utiliser explicitement cgroupv1 ou cgroupv2. La mise à niveau d'un pool de nœuds existant vers la version 1.26 ne remplace pas le paramètre par cgroupv2, car les pools de nœuds existants créés exécutant une version antérieure à la version 1.26 (sans configuration de cgroup personnalisée) continuent à utiliser. cgroupv1, sauf indication contraire explicite de votre part.

Par exemple, pour configurer votre pool de nœuds afin d'utiliser cgroupv2, utilisez un fichier de configuration du système de nœud tel que :

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

Les options cgroupMode acceptées sont les suivantes :

  • CGROUP_MODE_V1: utilisez cgroupv1 sur le pool de nœuds.
  • CGROUP_MODE_V2: utilisez cgroupv2 sur le pool de nœuds.
  • CGROUP_MODE_UNSPECIFIED : utilisez la configuration cgroup par défaut de GKE.

Pour utiliser cgroupv2, les exigences et limites suivantes s'appliquent:

  • Pour un pool de nœuds exécutant une version antérieure à 1.26, vous devez utiliser gcloud CLI 408.0.0 ou une version ultérieure. Vous pouvez également utiliser gcloud beta avec la version 395.0.0 ou une version ultérieure.
  • Votre cluster et vos pools de nœuds doivent exécuter GKE version 1.24.2-gke.300 ou ultérieure.
  • Vous devez utiliser Container-Optimized OS avec une image de nœud containerd.
  • Si l'une de vos charges de travail dépend de la lecture du système de fichiers cgroup (/sys/fs/cgroup/...), assurez-vous qu'elles sont compatibles avec l'API cgroupv2.
    • Assurez-vous que les outils de surveillance ou tiers sont compatibles avec cgroupv2.
  • Si vous utilisez le JDK (charge de travail Java), nous vous recommandons d'utiliser des versions entièrement compatibles avec cgroupv2, y compris JDK 8u372, JDK 11.0.16 ou version ultérieure, ou JDK 15 ou version ultérieure.

Vérifier la configuration cgroup

Lorsque vous ajoutez une configuration de système de nœud, GKE doit recréer les nœuds pour mettre en œuvre les modifications. Une fois que vous avez ajouté la configuration à un pool de nœuds et que les nœuds ont été recréés, vous pouvez vérifier la nouvelle configuration.

Pour vérifier la configuration cgroup des nœuds de ce pool, choisissez un nœud et connectez-vous à celui-ci en suivant les instructions suivantes :

  1. Créez un shell interactif avec n'importe quel nœud du pool de nœuds. Dans la commande, remplacez mynode par le nom d'un nœud quelconque du pool de nœuds.
  2. Identifiez la version cgroup sur les nœuds Linux.

Options de configuration Huge Pages sur Linux

Vous pouvez utiliser le fichier de configuration du système de nœud pour utiliser la fonctionnalité de noyau Linux Huge Pages.

Kubernetes prend en charge Huge Pages sur les nœuds en tant que type de ressource, comme le processeur ou la mémoire. Utilisez les paramètres suivants pour indiquer à vos nœuds Kubernetes de pré-allouer des Huge Pages à consommer par les pods. Pour gérer la consommation de Huge Pages par vos pods, consultez la page Gérer les pages HugePages.

Pour pré-allouer des pages Huge Pages pour vos nœuds, spécifiez les quantités et les tailles. Par exemple, pour configurer vos nœuds afin d'allouer trois pages Huge Pages de 1 gigaoctet et 1 024 pages Huge Pages de 2 mégaoctets, utilisez une configuration de système de nœud telle que la suivante :

linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

Pour utiliser Huge Pages, les limitations et exigences suivantes s'appliquent :

  • Pour garantir que le nœud n'est pas entièrement occupé par les pages Huge Pages, la taille globale des pages Huge Pages allouées ne peut pas dépasser 60 % de la mémoire totale. Par exemple, avec une machine e2-standard-2 dotée de 8 Go de mémoire, vous ne pouvez pas allouer plus de 4,8 Go aux pages Huge Pages.
  • Les pages Huge Pages d'un gigaoctet ne sont disponibles que sur les types de machines A3, C2D, C3, C3A, C3D, C4, CT5E, CT5L, CT5LP, CT6E, H3, M2, M3 ou Z3.

Étapes suivantes