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.

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. Dans votre pool de nœuds, 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 pour les configurations de noyau Linux de bas niveau sysctl.

Ce document décrit en détail les configurations disponibles pour une configuration de système de nœuds et explique comment les appliquer à vos pools de nœuds GKE Standard. Notez que les options de configuration directe du système de nœuds des clusters GKE Autopilot sont limitées par rapport à celles des pools de nœuds GKE Standard, car les clusters GKE Autopilot disposent d'un environnement de nœuds plus géré.

Pourquoi utiliser des configurations de système de nœuds ?

Les configurations du système de nœud offrent les avantages suivants :

  • Optimisation des performances : optimisez les performances de la pile réseau, la gestion de la mémoire, la planification du processeur ou le comportement des E/S pour les applications exigeantes telles que l'entraînement ou le service d'IA, les bases de données, les serveurs Web à trafic élevé ou les services sensibles à la latence.
  • Renforcement de la sécurité : appliquez des paramètres de sécurité spécifiques au niveau du noyau ou limitez certains comportements du système pour réduire la surface d'attaque.
  • Gestion des ressources : ajustez la façon dont kubelet gère les PID, l'espace disque, la récupération de mémoire des images ou les ressources de processeur et de mémoire.
  • Compatibilité des charges de travail : permet de s'assurer que l'environnement de nœud répond à des prérequis spécifiques pour les logiciels spécialisés ou les applications plus anciennes qui nécessitent des paramètres de noyau particuliers.

Autres options pour personnaliser les configurations de nœuds

Vous pouvez également personnaliser la configuration de vos nœuds à l'aide d'autres méthodes :

Les configurations de système de nœuds ne sont pas compatibles avec les nœuds Windows Server.

Avant de commencer

Avant de commencer, assurez-vous d'effectuer les opérations suivantes :

  • Installez les outils de ligne de commande :
    • Si vous utilisez les exemples de gcloud CLI de ce document, assurez-vous d'installer et de configurer la Google Cloud CLI.
    • Si vous utilisez les exemples Terraform, assurez-vous d'installer et de configurer Terraform.
  • Accorder des autorisations : vous devez disposer des autorisations IAM appropriées pour créer et mettre à jour des clusters et des pools de nœuds GKE, comme container.clusterAdmin ou un autre rôle avec des autorisations équivalentes.
  • Planifiez les éventuelles perturbations de la charge de travail : les configurations de nœuds personnalisées sont appliquées au niveau du pool de nœuds. Les modifications déclenchent généralement une mise à jour progressive des nœuds du pool, qui implique de recréer les nœuds. Planifiez les éventuelles interruptions de charge de travail et utilisez des budgets d'interruption de pod (PDB) le cas échéant.
  • Sauvegardez et testez toutes les modifications : testez toujours les modifications de configuration dans un environnement de préproduction ou de développement avant de les appliquer à la production. Des paramètres incorrects peuvent entraîner l'instabilité des nœuds ou l'échec des charges de travail.
  • Examiner les paramètres par défaut de GKE : les images de nœud GKE sont fournies avec des configurations par défaut optimisées. Ne personnalisez les paramètres que si vous avez des besoins spécifiques et que vous comprenez l'impact de vos modifications.

Utiliser une configuration de système de nœuds en mode GKE Standard

Lorsque vous utilisez une configuration de système de nœud, vous utilisez un fichier YAML contenant les paramètres de configuration pour kubelet et le noyau Linux. Bien que les configurations de système de nœuds soient également disponibles en mode GKE Autopilot, les étapes de ce document vous montrent comment créer et utiliser un fichier de configuration pour le mode GKE Standard.

Pour utiliser une configuration de système de nœuds en mode GKE Standard, procédez comme suit :

  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 la configuration de votre système de nœuds en YAML. L'exemple suivant ajoute des configurations pour les options kubelet et sysctl :

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
    - 'kernel.shm*'
    - 'kernel.msg*'
    - 'kernel.sem'
    - 'fs.mqueue*'
    - 'net.*'
linuxConfig:
  sysctl:
    net.core.somaxconn: '2048'
    net.ipv4.tcp_rmem: '4096 87380 6291456'

Dans cet exemple, les éléments suivants s'appliquent :

  • Le champ cpuManagerPolicy: static configure le kubelet pour utiliser la règle de gestion du processeur statique. + Le champ net.core.somaxconn: '2048' limite le backlog socket listen() à 2 048 octets.
  • Le champ 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 la configuration de votre système de nœuds. 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 à la configuration du système de nœuds, consultez les sections Options de configuration Kubelet et Options de configuration Sysctl.

Ajouter la configuration à un pool de nœuds Standard

Après avoir créé la configuration du système de nœuds, 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 à l'aide de la console Google Cloud .

Créer un cluster avec la configuration du système de nœuds

Vous pouvez ajouter une configuration du système de nœuds lors de la création du cluster à l'aide de gcloud CLI ou de Terraform. Les instructions suivantes appliquent la configuration du système de nœuds au pool de nœuds par défaut :

CLI gcloud 

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

Remplacez les éléments suivants :

  • 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.

Terraform

Pour créer un cluster régional avec une configuration de système de nœuds personnalisée à l'aide de Terraform, reportez-vous à l'exemple suivant :

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Pour en savoir plus sur l'utilisation de Terraform, consultez la page Compatibilité de Terraform avec GKE.

Créer un pool de nœuds avec la configuration système des nœuds

Vous pouvez ajouter une configuration du système de nœud lorsque vous utilisez gcloud CLI ou Terraform pour créer un pool de nœuds.

Les instructions suivantes appliquent la configuration du système de nœuds à un nouveau pool de nœuds :

CLI gcloud 

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

Remplacez les éléments suivants :

  • 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.

Terraform

Pour créer un pool de nœuds avec une configuration de système de nœuds personnalisée à l'aide de Terraform, reportez-vous à l'exemple suivant :

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Pour en savoir plus sur l'utilisation de Terraform, consultez la page Compatibilité de Terraform avec GKE.

Mettre à jour la configuration du système de nœuds d'un pool de nœuds existant

Vous pouvez mettre à jour la configuration du système de nœuds d'un pool de nœuds existant en exécutant la commande suivante :

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

Remplacez les éléments suivants :

  • 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.

Cette modification nécessite de recréer les nœuds, ce qui peut perturber vos charges de travail en cours d'exécution. Pour en savoir plus sur cette modification spécifique, recherchez la ligne correspondante dans le tableau Modifications manuelles qui recréent les nœuds à l'aide d'une stratégie de mise à niveau des nœuds sans respecter les règles de maintenance.

Pour en savoir plus sur les mises à jour des nœuds, consultez Planifier les interruptions de mise à jour des nœuds.

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 la configuration du système de nœuds d'un pool de nœuds existant, suivez les instructions de l'onglet Mettre à jour un pool de nœuds pour ajouter la configuration à un pool de nœuds. Lorsque vous mettez à jour une configuration de système de nœuds et que la nouvelle configuration remplace la configuration système existante du pool de nœuds, les nœuds doivent être recréés. 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 du système de nœuds, mettez à jour le fichier de configuration avec des valeurs vides pour les champs kubelet et sysctl, par 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 pour kubelet

Les tableaux de cette section décrivent les options kubelet que vous pouvez modifier.

Gestion du processeur

Le tableau suivant décrit les options de gestion du processeur pour kubelet.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
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 peut être avantageux 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 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.

Gestion de la mémoire et éviction

Le tableau suivant décrit les options modifiables pour la gestion de la mémoire et l'éviction. Cette section contient également un tableau distinct décrivant les options modifiables pour le flag evictionSoft.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
evictionSoft Mappage des noms de signaux. Pour connaître les restrictions de valeur, consultez le tableau suivant. none Ce paramètre mappe les noms de signaux à une quantité ou un pourcentage qui définit les seuils d'éviction souple. Un seuil d'éviction souple doit comporter un délai de grâce. Le kubelet n'expulse pas les pods tant que le délai de grâce n'est pas dépassé.
evictionSoftGracePeriod Mappage des noms de signaux. Pour chaque nom de signal, la valeur doit être une durée positive inférieure à 5m. Les unités de temps valides sont ns, us (ou µs), ms, s ou m. none Ce paramètre mappe les noms de signaux aux durées qui définissent les périodes de grâce pour les seuils d'éviction progressive. Chaque seuil d'éviction temporaire doit être associé à un délai de grâce.
evictionMinimumReclaim Mappage des noms de signaux. Pour chaque nom de signal, la valeur doit être un pourcentage positif inférieur à 10%. none Ce paramètre mappe les noms de signaux à des pourcentages qui définissent la quantité minimale d'une ressource donnée que le kubelet récupère lorsqu'il effectue une éviction de pod.
evictionMaxPodGracePeriodSeconds La valeur doit être un entier compris entre 0 et 300. 0 Ce paramètre définit, en secondes, le délai de grâce maximal pour l'arrêt du pod lors de l'éviction.

Le tableau suivant présente les options modifiables pour l'indicateur evictionSoft. Les mêmes options s'appliquent également aux indicateurs evictionSoftGracePeriod et evictionMinimumReclaim, avec des restrictions différentes.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
memoryAvailable La valeur doit être une quantité supérieure à 100Mi et inférieure à 50% de la mémoire du nœud. none Ce paramètre représente la quantité de mémoire disponible avant l'éviction logicielle. Définit la quantité de signal memory.available dans kubelet .
nodefsAvailable La valeur doit être comprise entre 10% et 50%. none Ce paramètre représente les nœuds disponibles avant l'éviction logicielle. Définit la quantité de signal nodefs.available dans kubelet .
nodefsInodesFree La valeur doit être comprise entre 5% et 50%. none Ce paramètre représente les inodes nodefs qui sont libres avant l'éviction logicielle. Définit la quantité de signal nodefs.inodesFree dans kubelet .
imagefsAvailable La valeur doit être comprise entre 15% et 50%. none Ce paramètre représente l'imagefs disponible avant l'éviction logicielle. Définit la quantité de signal imagefs.available dans kubelet .
imagefsInodesFree La valeur doit être comprise entre 5% et 50%. none Ce paramètre représente les inodes imagefs qui sont libres avant l'éviction logicielle. Définit la quantité de signal imagefs.inodesFree dans kubelet.
pidAvailable La valeur doit être comprise entre 10% et 50%. none Ce paramètre représente les PID disponibles avant l'éviction logicielle. Définit la quantité de signal pid.available dans kubelet.
singleProcessOOMKill La valeur doit être true ou false. true pour les nœuds cgroupv1, false pour les nœuds cgroupv2. Ce paramètre définit si les processus du conteneur sont arrêtés individuellement ou en groupe en cas de manque de mémoire.

Disponible sur les versions 1.32.4-gke.1132000, 1.33.0-gke.1748000 ou ultérieures de GKE.

Gestion des PID

Le tableau suivant décrit les options modifiables pour la gestion des PID.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
podPidsLimit La valeur doit être comprise entre 1024 et 4194304. none Ce paramètre définit le nombre maximal d'ID de processus (PID) que chaque pod peut utiliser.

Journalisation

Le tableau suivant décrit les options de journalisation modifiables.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
containerLogMaxSize La valeur doit être un nombre positif et un suffixe d'unité compris entre 10Mi et 500Mi inclus. 10Mi Ce paramètre contrôle le paramètre containerLogMaxSize de la stratégie de rotation des journaux de conteneur, qui vous permet de configurer la taille maximale de chaque fichier journal. La valeur par défaut est 10Mi. Les unités valides sont Ki, Mi et Gi.
containerLogMaxFiles La valeur doit être un entier compris entre 2 et 10, inclus. 5 Ce paramètre contrôle le paramètre containerLogMaxFiles de la règle de rotation des fichiers journaux de conteneur, qui vous permet de configurer le nombre maximal de fichiers autorisés pour chaque conteneur, respectivement. La valeur par défaut est 5. La taille totale des journaux (container_log_max_size*container_log_max_files) par conteneur ne peut pas dépasser 1 % du stockage total du nœud.

Récupération de mémoire des images

Le tableau suivant décrit les options modifiables pour la récupération des déchets d'image.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
imageGCHighThresholdPercent La valeur doit être un entier compris entre 10 et 85 (inclus), et supérieur à imageGcLowThresholdPercent. 85 Ce paramètre définit le pourcentage d'utilisation du disque au-delà duquel la récupération de mémoire des images est exécutée. Il s'agit de l'utilisation maximale du disque pour la récupération de mémoire. Le pourcentage est calculé en divisant la valeur de ce champ par 100.
imageGCLowThresholdPercent La valeur doit être un entier compris entre 10 et 85 (inclus), et inférieur à imageGcHighThresholdPercent. 80 Ce paramètre définit le pourcentage d'utilisation du disque en dessous duquel la récupération d'espace inutilisé des images n'est jamais exécutée. Il représente l'utilisation de disque la plus faible pour la récupération de mémoire. Le pourcentage est calculé en divisant la valeur de ce champ par 100.
imageMinimumGcAge La valeur doit être une durée inférieure ou égale à 2m. Les unités de temps valides sont ns, us (ou µs), ms, s, m ou h. 2m Ce paramètre définit l'âge minimal d'une image inutilisée avant qu'elle ne soit supprimée.
imageMaximumGcAge La valeur doit être une durée. 0s

Ce paramètre définit l'âge maximal d'une image inutilisée avant qu'elle ne soit supprimée. La valeur par défaut de ce champ est 0s, ce qui le désactive. Par conséquent, les images ne seront pas supprimées en fonction de leur inutilisation. Si cette valeur est spécifiée, elle doit être supérieure à celle du champ imageMinimumGcAge.

Disponible sur les versions 1.30.7-gke.1076000, 1.31.3-gke.1023000 ou ultérieures de GKE.

Extraction d'images

Le tableau suivant décrit les options modifiables pour l'extraction d'images.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
maxParallelImagePulls La valeur doit être un entier compris entre 2 et 5 (inclus). 2 ou 3 selon le type de disque. Ce paramètre définit le nombre maximal d'extractions d'images en parallèle. La valeur par défaut est déterminée par le type de disque de démarrage.

Sécurité et opérations dangereuses

Le tableau suivant décrit les options modifiables pour configurer la sécurité et gérer les opérations dangereuses.

Paramètres de configuration kubelet Restrictions Paramètre par défaut Description
allowedUnsafeSysctls

Liste des noms ou groupes sysctl. Les groupes sysctl autorisés sont les suivants :

  • kernel.shm*
  • kernel.msg*
  • kernel.sem
  • fs.mqueue.*
  • net.*.
 none Ce paramètre définit une liste d'autorisation séparée par des virgules de noms ou de groupes sysctl non sécurisés qui peuvent être définis sur les pods.sysctl
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é kubelet 10255 sur chaque nouveau pool de nœuds de votre cluster. Si vous configurez ce paramètre dans ce fichier, vous ne pourrez pas utiliser de client d'API GKE pour le modifier au niveau du cluster.

Gestionnaires de ressources

Kubernetes propose une suite de gestionnaires de ressources. Vous pouvez configurer ces gestionnaires de ressources pour coordonner et optimiser l'alignement des ressources de nœuds pour les pods configurés avec des exigences spécifiques pour les ressources de processeurs, d'appareils et de mémoire (pages énormes).

Le tableau suivant décrit les options modifiables pour les gestionnaires de ressources.

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 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 qui appartiennent à la classe QoS Guaranteed et qui ont des requêtes de processeurs entières se voient attribuer des processeurs exclusifs.
memoryManager.policy La valeur doit être None ou Static. None

Ce paramètre contrôle la règle du gestionnaire de mémoire kubelet. Avec la valeur par défaut None, Kubernetes se comporte comme si le gestionnaire de mémoire n'était pas présent.

Si vous définissez cette valeur sur Static, la règle Memory Manager envoie des indications de topologie qui dépendent du type de pod. Pour en savoir plus, consultez Règles statiques.

Ce paramètre est compatible avec les clusters dont le plan de contrôle exécute la version 1.32.3-gke.1785000 ou ultérieure de GKE.
topologyManager

La valeur doit correspondre à l'un des paramètres acceptés pour chacun des champs concernés.

Vous ne pouvez pas définir le champ topologyManager lorsque vous utilisez les instructions Terraform pour ajouter la configuration à un pool de nœuds standard.
  • policy : none
  • scope : container

Ces paramètres contrôlent la configuration du gestionnaire de topologie kubelet à l'aide des sous-champs policy et scope. Le gestionnaire de topologie coordonne l'ensemble des composants responsables des optimisations de performances liées à l'isolation du processeur, à la mémoire et à la localité des appareils.

Vous pouvez définir les paramètres de règle et de portée indépendamment les uns des autres. Pour en savoir plus sur ces paramètres, consultez Scopes et règles du gestionnaire de topologie.

Les ressources GKE suivantes sont compatibles avec ce paramètre :

  • Clusters dont le plan de contrôle exécute GKE version 1.32.3-gke.1785000 ou ultérieure. Pour les clusters dont le plan de contrôle et les nœuds exécutent la version 1.33.0-gke.1712000 ou ultérieure, le gestionnaire de topologie reçoit également des informations sur la topologie des GPU.
  • Nœuds avec les types de machines suivants : A2, A3, A4, C3, C4, C4A, G2, G4, M3, N4

Options de configuration Sysctl

Pour ajuster les performances de votre système, vous pouvez modifier les paramètres du noyau Linux. Les tableaux de cette section décrivent les différents paramètres du noyau que vous pouvez configurer.

Paramètres du système de fichiers (fs.*)

Le tableau suivant décrit les paramètres modifiables pour le système de fichiers Linux. Ces paramètres contrôlent le comportement du système de fichiers Linux, comme les limites de gestion des fichiers et la surveillance des événements.

Paramètre Sysctl Restrictions Description
fs.aio-max-nr Doit être compris entre [65536, 4194304]. Ce paramètre définit le nombre maximal de requêtes d'E/S asynchrones à l'échelle du système.
fs.file-max La valeur doit être comprise entre 104 857 et 67 108 864. Ce paramètre définit le nombre maximal de descripteurs de fichiers que le noyau Linux peut allouer.
fs.inotify.max_user_instances Doit être compris entre [8192, 1048576]. Ce paramètre définit le nombre maximal d'instances inotify qu'un utilisateur peut créer.
fs.inotify.max_user_watches Doit être compris entre [8192, 1048576]. Ce paramètre définit le nombre maximal de surveillances inotify qu'un utilisateur peut créer.
fs.nr_open La valeur doit être comprise entre [1048576, 2147483584]. Ce paramètre définit le nombre maximal de descripteurs de fichiers qu'un processus peut ouvrir.

Paramètres du noyau (kernel.*)

Le tableau suivant décrit les paramètres modifiables pour le noyau Linux. Ces paramètres configurent les fonctionnalités de base du noyau, y compris l'allocation de mémoire partagée.

Paramètre Sysctl Restrictions Description
kernel.shmmni Doit être compris entre 4 096 et 32 768. Ce paramètre définit le nombre maximal de segments de mémoire partagée à l'échelle du système. Si cette valeur n'est pas définie, la valeur par défaut est 4096.
kernel.shmmax La valeur doit être comprise entre 0 et 18446744073692774399. Ce paramètre définit la taille maximale, en octets, d'un segment de mémoire partagée unique autorisé par le noyau. Cette valeur est ignorée si elle est supérieure à la quantité réelle de RAM, ce qui signifie que toute la RAM disponible peut être partagée.
kernel.shmall La valeur doit être comprise entre 0 et 18446744073692774399. Ce paramètre définit la quantité totale de pages de mémoire partagée pouvant être utilisées sur le système en même temps. Une page fait 4 096 octets sur l'architecture AMD64 et Intel 64.
kernel.perf_event_paranoid Doit être compris entre -1 et 3. Ce paramètre contrôle l'utilisation du système d'événements de performances par les utilisateurs non privilégiés sans CAP_PERFMON. La valeur par défaut est 2 dans le noyau.
kernel.sched_rt_runtime_us Doit être compris entre -1 et 1 000 000. Ce paramètre définit une limite globale sur le temps que la planification en temps réel peut utiliser.
kernel.softlockup_panic Facultatif (booléen). Ce paramètre contrôle si le noyau panique lorsqu'un blocage logiciel est détecté.
kernel.yama.ptrace_scope Doit être compris entre 0 et 3.

Ce paramètre définit le champ d'application et les restrictions de l'appel système ptrace(), ce qui a un impact sur le débogage et le traçage des processus. Les valeurs autorisées incluent les suivantes :

  • 0 : autorisations ptrace classiques.
  • 1 : ptrace restreint, qui est la valeur par défaut dans de nombreuses distributions. Seuls les processus enfants ou CAP_SYS_PTRACE.
  • 2 : ptrace réservé aux administrateurs. Uniquement les processus avec CAP_SYS_PTRACE.
  • 3 : pas de ptrace. Les appels ptrace ne sont pas autorisés.
kernel.kptr_restrict Doit être compris entre 0 et 2. Ce paramètre indique si des restrictions sont imposées à l'exposition des adresses du noyau via /proc et d'autres interfaces.
kernel.dmesg_restrict Facultatif (booléen). Ce paramètre indique si les utilisateurs non privilégiés sont empêchés d'utiliser dmesg(8) pour afficher les messages du tampon de journalisation du noyau.
kernel.sysrq La valeur doit être comprise entre 0 et 511.

Ce paramètre contrôle les fonctions qui peuvent être appelées à l'aide de la touche SysRq. Les valeurs possibles sont les suivantes :

  • 0 : désactive complètement SysRq.
  • 1 : active toutes les fonctions SysRq.
  • >1 : masque de bits des fonctions sysrq autorisées. Pour en savoir plus, consultez Linux Magic System Request Key Hacks.

Paramètres réseau (net.*)

Le tableau suivant décrit les paramètres réseau modifiables. Ces paramètres ajustent les performances et le comportement de la pile réseau, des tampons de socket au suivi des connexions.

Paramètre Sysctl Restrictions Description
net.core.busy_poll Tout entier positif inférieur à 2147483647. Ce paramètre définit le délai d'inactivité de l'interrogation occupée à faible latence pour l'interrogation et la sélection. Il représente le temps approximatif en µs pour la boucle d'attente des événements.
net.core.busy_read Tout entier positif inférieur à 2147483647. Ce paramètre définit le délai d'expiration de l'interrogation d'occupation à faible latence pour les lectures de socket. Il représente le temps approximatif en µs pour la boucle d'attente occupée pour les paquets dans la file d'attente de l'appareil.
net.core.netdev_max_backlog Tout entier positif inférieur à 2147483647. Ce paramètre définit le nombre maximal de paquets mis en file d'attente côté INPUT lorsque l'interface reçoit des paquets plus rapidement que le noyau ne peut les traiter.
net.core.rmem_default Tout entier positif inférieur à 2147483647. Ce paramètre définit la taille par défaut du tampon de réception de socket, en octets.
net.core.rmem_max Tout entier positif inférieur à 2147483647. Ce paramètre définit la taille maximale de la mémoire tampon du socket de réception, en octets.
net.core.wmem_default Tout entier positif inférieur à 2147483647. Ce paramètre définit la taille par défaut, en octets, du tampon d'envoi du socket.
net.core.wmem_max Tout entier positif inférieur à 2147483647. Ce paramètre définit la taille maximale de la mémoire tampon du socket d'envoi, en octets.
net.core.optmem_max Tout entier positif inférieur à 2147483647. Ce paramètre définit la taille maximale de la mémoire tampon auxiliaire autorisée par socket.
net.core.somaxconn Doit être compris entre [128, 2147483647]. Ce paramètre définit la limite du backlog socket listen(), qui est connu dans l'espace utilisateur sous le nom SOMAXCONN. Ce paramètre est défini par défaut sur 128.
net.ipv4.tcp_rmem {min, default, max} (chaque valeur est > 0, mémoire en octets). Ce paramètre définit la taille minimale, en octets, de la mémoire tampon de réception utilisée par les sockets UDP lors de la modération. Le paramètre par défaut est de 1 page.
net.ipv4.tcp_wmem {min, default, max} (chaque valeur est > 0, mémoire en octets). Ce paramètre définit la taille minimale, en octets, de la mémoire tampon d'envoi utilisée par les sockets UDP en modération. Le paramètre par défaut est de 1 page.
net.ipv4.tcp_tw_reuse La valeur doit être comprise entre 0 et 1. Ce paramètre définit s'il faut autoriser la réutilisation des sockets à l'état TIME_WAIT pour les nouvelles connexions lorsque cela est sûr du point de vue du protocole. La valeur par défaut est 0.
net.ipv4.tcp_max_orphans Doit être compris entre 16 384 et 262 144. Ce paramètre définit le nombre maximal de sockets TCP qui ne sont associés à aucun descripteur de fichier utilisateur.
net.ipv4.tcp_max_tw_buckets La valeur doit être comprise entre 4 096 et 2 147 483 647. Ce paramètre définit le nombre maximal de sockets timewait détenus simultanément par le système. Si ce nombre est dépassé, le socket d'attente est immédiatement détruit et un avertissement s'affiche.
net.ipv4.tcp_syn_retries La valeur doit être comprise entre 1 et 127. Ce paramètre définit le nombre de fois où les SYN initiaux d'une tentative de connexion TCP active sont retransmis.
net.ipv4.tcp_ecn Doit être compris entre 0 et 2. Ce paramètre contrôle l'utilisation de la notification explicite de congestion (ECN) par TCP. ECN n'est utilisé que lorsque les deux extrémités de la connexion TCP indiquent qu'elles le prennent en charge.
net.ipv4.tcp_mtu_probing Doit être compris entre 0 et 2.

Ce paramètre contrôle la détection de MTU de chemin de la couche de paquetisation TCP. Les valeurs acceptées sont les suivantes :

  • 0 : désactivé.
  • 1 : désactivé par défaut, activé lorsqu'un trou noir ICMP est détecté.
  • 2 : toujours activé. Utilisez le MSS initial de tcp_base_mss.
net.ipv4.tcp_congestion_control Doit correspondre à l'une des valeurs acceptées de la colonne Description.

Ce paramètre n'est pas compatible lorsque GKE Dataplane V2 est activé sur le cluster.

Les valeurs acceptées suivantes dépendent du type d'image :

  • COS : reno, cubic, bbr, lp
  • Ubuntu : reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6 Valeur booléenne. Modifier cette valeur revient à modifier le paramètre conf/default/disable_ipv6 et tous les paramètres disable_ipv6 par interface sur la même valeur.
net.ipv6.conf.default.disable_ipv6 Valeur booléenne. Ce paramètre désactive le fonctionnement d'IPv6.
net.netfilter.nf_conntrack_acct La valeur doit être comprise entre 0 et 1. Ce paramètre active la comptabilisation du flux de suivi des connexions. La valeur par défaut est 0, ce qui signifie que le paramètre est désactivé. Disponible sur GKE version 1.32.0-gke.1448000 ou ultérieure.
net.netfilter.nf_conntrack_max Doit être compris entre [65536, 4194304]. Ce paramètre définit la taille de la table de suivi des connexions. Si la valeur maximale est atteinte, la nouvelle connexion échouera. Disponible sur GKE version 1.32.0-gke.1448000 ou ultérieure.
net.netfilter.nf_conntrack_buckets Doit être compris entre [65536, 524288].

Ce paramètre définit la taille de la table de hachage. Le paramètre recommandé est le résultat de ce qui suit : nf_conntrack_max = nf_conntrack_buckets * 4.

Disponible sur GKE version 1.32.0-gke.1448000 ou ultérieure.
net.netfilter.nf_conntrack_tcp_timeout_close_wait Doit être compris entre 60 et 3 600.

Ce paramètre définit la période, en secondes, pendant laquelle les connexions TCP peuvent rester à l'état CLOSE_WAIT. La valeur par défaut est 3600.

Disponible sur GKE version 1.32.0-gke.1448000 ou ultérieure.
net.netfilter.nf_conntrack_tcp_timeout_established Doit être compris entre [600, 86 400].

Ce paramètre définit la durée, en secondes, des connexions inactives avant qu'elles ne soient automatiquement supprimées de la table de suivi des connexions.

Disponible sur GKE version 1.32.0-gke.1448000 ou ultérieure.
net.netfilter.nf_conntrack_tcp_timeout_time_wait Doit être compris entre 1 et 600.

Ce paramètre définit la période, en secondes, pendant laquelle les connexions TCP peuvent rester à l'état TIME_WAIT. La valeur par défaut est 120.

Disponible sur GKE version 1.32.0-gke.1448000 ou ultérieure.

Paramètres de la mémoire virtuelle (vm.*)

Le tableau suivant décrit les paramètres modifiables pour le sous-système de mémoire virtuelle. Ces paramètres gèrent le sous-système de mémoire virtuelle, qui contrôle la façon dont le noyau gère la mémoire, l'échange et la mise en cache sur disque.

Paramètre sysctl Restrictions Description
vm.max_map_count La valeur doit être comprise entre [65536, 2147483647]. Ce fichier définit le nombre maximal de zones de mappage mémoire qu'un processus peut avoir.
vm.dirty_background_ratio La valeur doit être comprise entre 1 et 100. Ce paramètre définit le pourcentage de mémoire système qui peut être rempli de pages sales avant que les threads de vidage du noyau en arrière-plan ne commencent à réécrire les données. La valeur doit être inférieure à celle du champ vm.dirty_ratio.
vm.dirty_background_bytes La valeur doit être comprise entre 0 et 68719476736.

Ce paramètre définit la quantité de mémoire sale à partir de laquelle les threads de vidage du noyau en arrière-plan commencent à écrire les données.

Notez que vm.dirty_background_bytes est l'équivalent de vm.dirty_background_ratio. Vous ne pouvez spécifier qu'un seul de ces paramètres.
vm.dirty_expire_centisecs Doit être compris entre 0 et 6 000. Ce paramètre définit l'âge maximal, en centièmes de seconde, pendant lequel les données modifiées peuvent rester en mémoire avant que les threads de vidage du noyau ne les écrivent sur le disque.
vm.dirty_ratio La valeur doit être comprise entre 1 et 100. Ce paramètre définit le pourcentage de mémoire système pouvant être rempli par des pages modifiées avant que les processus qui effectuent des écritures ne soient forcés de bloquer et d'écrire les données modifiées de manière synchrone.
vm.dirty_bytes La valeur doit être comprise entre 0 et 68719476736.

Ce paramètre définit la quantité de mémoire sale à partir de laquelle un processus qui génère des écritures sur disque commence lui-même à écrire en différé. La valeur minimale autorisée pour vm.dirty_bytes est de deux pages en octets. Toute valeur inférieure à cette limite sera ignorée et l'ancienne configuration sera conservée.

Notez que vm.dirty_bytes est l'équivalent de vm.dirty_ratio. Vous ne pouvez spécifier qu'un seul de ces paramètres.
vm.dirty_writeback_centisecs Doit être compris entre 0 et 1 000. Ce paramètre définit l'intervalle, en centièmes de seconde, auquel les threads de vidage du noyau se réveillent pour écrire les anciennes données modifiées sur le disque.
vm.overcommit_memory La valeur doit être comprise entre 0, 1 et 2.

Ce paramètre détermine la stratégie du noyau pour gérer le sur-engagement de mémoire. Les valeurs sont les suivantes :

  • 0 : rejeter les allocations importantes
  • 1 : toujours autoriser
  • 2 : empêche l'opération de validation au-delà de la mémoire d'échange et du ratio de RAM
vm.overcommit_ratio La valeur doit être comprise entre 0 et 100. Ce paramètre définit le pourcentage de RAM physique autorisé pour le surdimensionnement lorsque la valeur du champ vm.overcommit_memory est définie sur 2.
vm.vfs_cache_pressure La valeur doit être comprise entre 0 et 100. Ce paramètre ajuste la préférence du noyau pour la récupération de la mémoire utilisée pour les caches dentry (répertoire) et inode.
vm.swappiness Doit être compris entre 0 et 200. Ce paramètre contrôle la tendance du noyau à déplacer les processus de la mémoire physique vers le disque d'échange. La valeur par défaut est 60.
vm.watermark_scale_factor Doit être compris entre 10 et 3 000. Ce paramètre contrôle l'agressivité de kswapd. Il définit la mémoire restante avant que kswapd ne se réveille et la mémoire à libérer avant qu'il ne se mette en veille. La valeur par défaut est 10.
vm.min_free_kbytes La valeur doit être comprise entre [67584, 1048576]. Ce paramètre définit la mémoire libre minimale avant l'erreur OOM. La valeur par défaut est 67584.

Pour en savoir plus sur les valeurs acceptées pour chaque option sysctl, consultez la documentation de gcloud CLI sur --system-config-from-file.

Différents espaces de noms Linux peuvent avoir des valeurs uniques pour un indicateur sysctl donné, tandis que d'autres peuvent être globaux pour l'ensemble du nœud. La mise à jour des options sysctl à l'aide d'une configuration de système de nœuds permet de s'assurer 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

L'environnement d'exécution du conteneur et kubelet 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 en savoir plus, consultez la documentation Kubernetes sur les cgroups 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 pools de nœuds exécutant 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 du cgroup dépend de la version initiale du cluster, et non de la version du pool de nœuds. cgroupv1 n'est pas compatible avec les machines Arm.

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 qui utilise cgroupv1 vers la version 1.26 ne remplace pas le paramètre par cgroupv2. Les pools de nœuds existants qui exécutent une version antérieure à la version 1.26 et qui n'incluent pas de configuration cgroup personnalisée continueront à utiliser cgroupv1. Pour modifier le paramètre, vous devez spécifier explicitement cgroupv2 pour le pool de nœuds existant.

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 le suivant :

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 version 408.0.0 ou 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 containerd ou Ubuntu avec containerd comme image de nœud.
  • 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.
  • Si vous utilisez des outils de surveillance ou tiers, assurez-vous qu'ils sont compatibles avec cgroupv2.
  • Si vous utilisez des charges de travail Java (JDK), 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.

Vous pouvez vérifier la configuration cgroup des nœuds d'un pool de nœuds à l'aide de gcloud CLI ou de l'outil de ligne de commande kubectl :

CLI gcloud

Vérifiez la configuration cgroup d'un pool de nœuds:

gcloud container node-pools describe POOL_NAME \
  --format='value(Config.effectiveCgroupMode)'

Remplacez POOL_NAME par le nom de votre pool de nœuds.

La sortie potentielle est l'une des suivantes:

  • EFFECTIVE_CGROUP_MODE_V1: les nœuds utilisent cgroupv1
  • EFFECTIVE_CGROUP_MODE_V2: les nœuds utilisent cgroupv2

La sortie n'affiche la nouvelle configuration de cgroup qu'après la recréation des nœuds du pool de nœuds. La sortie est vide pour les pools de nœuds Windows Server, qui ne sont pas compatibles avec cgroup.

kubectl

Pour utiliser kubectl afin de vérifier la configuration cgroup des nœuds de ce pool de nœuds, sélectionnez 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 des hugepages Linux

Vous pouvez utiliser un fichier de configuration du système de nœud pour préallouer des hugepages. Kubernetes prend en charge les hugepages préallouées en tant que type de ressource, comme le processeur ou la mémoire.

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

  • Pour garantir que le nœud n'est pas entièrement occupé par les hugepages, la taille globale des hugepages allouées ne peut pas dépasser l'une des valeurs suivantes :
    • Sur les machines disposant de moins de 30 Go de mémoire : 60 % de la mémoire totale. Par exemple, sur une machine e2-standard-2 dotée de 8 Go de mémoire, vous ne pouvez pas allouer plus de 4,8 Go aux HugePages.
    • Sur les machines disposant de plus de 30 Go de mémoire : 80 % de la mémoire totale. Par exemple, sur les machines c4a-standard-8 dotées de 32 Go de mémoire, les hugepages ne peuvent pas dépasser 25,6 Go.
  • Les HugePages de 1 Go ne sont disponibles que sur les types de machines A3, C2D, C3, C3D, C4, C4A, C4D, CT5E, CT5LP, CT6E, H3, M2, M3, M4 ou Z3.

Le tableau suivant décrit les paramètres modifiables pour les hugepages Linux.

Paramètre de configuration Restrictions Valeur par défaut Description
hugepage_size2m Nombre entier. Sous réserve des limites d'allocation de mémoire décrites précédemment. 0 Ce paramètre préalloue un nombre spécifique de hugepages de 2 Mo.
hugepage_size1g Nombre entier. Soumis aux limites de mémoire et de type de machine décrites précédemment. 0 Ce paramètre préalloue un nombre spécifique de hugepages de 1 Go.

Pages énormes transparentes (THP)

Vous pouvez utiliser un fichier de configuration du système de nœud pour activer la prise en charge des pages énormes transparentes du noyau Linux. Avec THP, le noyau attribue automatiquement des hugepages aux processus sans pré-allocation manuelle.

Le tableau suivant décrit les paramètres modifiables pour THP.

Paramètre de configuration Valeurs acceptées Valeur par défaut Description
transparentHugepageEnabled
  • TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS : les huge pages transparentes sont activées à l'échelle du système.
  • TRANSPARENT_HUGEPAGE_ENABLED_MADVISE : les pages énormes transparentes sont activées dans les régions MADV_HUGEPAGE. Il s'agit de la configuration du noyau par défaut.
  • TRANSPARENT_HUGEPAGE_ENABLED_NEVER : les hugepages transparentes sont désactivées.
  • TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED : valeur par défaut. GKE ne modifie pas la configuration du noyau.
 UNSPECIFIED Ce paramètre permet de contrôler si THP est activé pour la mémoire anonyme.
transparentHugepageDefrag
  • TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS : une application qui demande des THP s'arrête en cas d'échec de l'allocation et récupère directement les pages et la mémoire compacte afin d'allouer immédiatement une THP.
  • TRANSPARENT_HUGEPAGE_DEFRAG_DEFER : une application réactive kswapd en arrière-plan pour récupérer des pages et réactive kcompactd pour compacter la mémoire afin que THP soit disponible dans un avenir proche. Il incombe à khugepaged d'installer les pages THP ultérieurement.
  • TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE : une application effectue la récupération et la compaction directes comme d'habitude, mais uniquement pour les régions qui ont utilisé madvise(MADV_HUGEPAGE). Toutes les autres régions réveillent kswapd en arrière-plan pour récupérer des pages et réveillent kcompactd pour compacter la mémoire afin que THP soit disponible dans un avenir proche.
  • TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE : une application effectue la récupération et la compaction directes comme d'habitude, mais uniquement pour les régions qui ont utilisé madvise(MADV_HUGEPAGE). Toutes les autres régions réveillent kswapd en arrière-plan pour récupérer des pages et réveillent kcompactd pour compacter la mémoire afin que THP soit disponible dans un avenir proche.
  • TRANSPARENT_HUGEPAGE_DEFRAG_NEVER : une application n'entre jamais dans la récupération directe ni dans la compaction.
  • TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED : valeur par défaut. GKE ne modifie pas la configuration du noyau.
 UNSPECIFIED Ce paramètre définit la configuration de défragmentation pour THP.

THP est disponible sur GKE version 1.33.2-gke.4655000 ou ultérieure. Elle est également activée par défaut sur les nouveaux pools de nœuds TPU dans la version 1.33.2-gke.4655000 ou ultérieure de GKE. THP n'est pas activé lorsque vous mettez à niveau des pools de nœuds existants vers une version compatible ou ultérieure.

Étapes suivantes