Personnaliser la configuration du système de nœud

Standard

Ce document explique comment personnaliser la configuration de vos nœuds Google Kubernetes Engine (GKE) à l'aide d'un fichier de configuration appelé configuration système des 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.

Attention : La modification des paramètres kubelet ou sysctl peut entraîner un comportement inattendu qui pourrait avoir un impact négatif sur l'état de vos charges de travail et de vos nœuds. Testez de manière approfondie toutes les modifications de kubelet ou sysctl avant de les déployer sur des charges de travail de production.

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 système des nœuds 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 d'E/S pour les applications exigeantes telles que l'entraînement ou le service d'IA, les bases de données, les serveurs Web à fort trafic 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 anciennes applications qui nécessitent des paramètres de noyau particuliers.

Autres options de personnalisation des configurations de nœuds

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

• Fichier de configuration d'exécution : pour personnaliser un environnement d'exécution de conteneur containerd sur vos nœuds GKE, vous pouvez utiliser un fichier différent appelé fichier de configuration d'exécution. Pour en savoir plus, consultez Personnaliser la configuration containerd dans les nœuds GKE.
• ComputeClass : vous pouvez spécifier des attributs de nœud dans votre spécification GKE ComputeClass. Vous pouvez utiliser ComputeClasses en mode GKE Autopilot et en mode Standard dans la version 1.32.1-gke.1729000 et ultérieures de GKE. Pour en savoir plus, consultez Personnaliser la configuration du système de nœuds.
• DaemonSets : vous pouvez également utiliser des DaemonSets pour personnaliser les nœuds. Pour en savoir plus, consultez Amorcer automatiquement les nœuds GKE avec DaemonSets.

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

Avant de commencer

Avant de commencer, veillez à 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 interruptions des charges 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, ce qui implique de recréer les nœuds. Planifiez les éventuelles perturbations 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 un environnement de développement avant de les appliquer à la production. Des paramètres incorrects peuvent entraîner l'instabilité des nœuds ou des échecs de charge de travail.
• Examiner les paramètres par défaut de GKE : les images de nœuds GKE sont fournies avec des configurations par défaut optimisées. Ne personnalisez les paramètres que si vous avez un besoin spécifique et que vous comprenez l'impact de vos modifications.

Ajouter une configuration de système de nœuds

Vous pouvez personnaliser la configuration de votre système de nœuds à l'aide d'une ComputeClass ou d'un fichier de configuration.

Utiliser une ComputeClass pour la configuration du système de nœuds

Vous pouvez utiliser une ComputeClass personnalisée pour personnaliser certains paramètres dans kubelet et le noyau Linux. Cette méthode est disponible dans GKE version 1.32.1-gke.1729000 et ultérieure.

Pour utiliser une ComputeClass afin de personnaliser la configuration de votre système de nœuds, procédez comme suit :

1. Créez une ComputeClass qui inclut la paire champ-valeur spec.nodePoolAutoCreation.enabled: true et spécifiez les configurations système dans le champ priorityDefaults.
2. Déployez une charge de travail qui sélectionne la ComputeClass.

Créer la ComputeClass

Écrivez la configuration de votre ComputeClass au format YAML. Utilisez le champ nodeSystemConfig dans la spécification priorityDefaults pour définir les configurations système pour toutes les priorités.

L'exemple ComputeClass suivant configure la stratégie de gestion du processeur statique et les paramètres de noyau personnalisés :

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-sysconfig
spec:
  nodePoolAutoCreation:
    enabled: true
  priorityDefaults:
    nodeSystemConfig:
      kubeletConfig:
        cpuManagerPolicy: static
      linuxNodeConfig:
        sysctls:
          net.core.somaxconn: 2048
  priorities:
  - machineFamily: n4

Appliquez la ComputeClass :

kubectl apply -f custom-sysconfig.yaml

Déployer une charge de travail qui sélectionne la classe de calcul

Dans la spécification de votre pod, ajoutez un sélecteur de nœuds pour le nom ComputeClass :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        cloud.google.com/compute-class: custom-sysconfig
      containers:
      - name: app-container
        image: nginx

Appliquez la charge de travail :

kubectl apply -f my-app.yaml

Pour en savoir plus, consultez Personnaliser la configuration du système de nœuds.

Utiliser un fichier de configuration pour la configuration du système de nœuds

Lorsque vous utilisez un fichier de configuration du 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 système des 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 un fichier de configuration du 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 du système de nœuds au format 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 qu'il utilise la stratégie de gestion statique du processeur.
• 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 les valeurs minimale, par défaut et maximale du tampon de réception de socket TCP sur 4 096 octets, 87 380 octets et 6 291 456 octets, respectivement.

Si vous souhaitez ajouter des configurations uniquement pour 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 de Kubelet et Options de configuration de 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 cet indicateur 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 du 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 du système de nœuds

Vous pouvez ajouter une configuration du système de nœuds 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 système de nœud 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 pour un pool de nœuds existant

Vous pouvez définir ou mettre à jour la configuration du système de nœud pour un pool de nœuds existant. Pour en savoir plus sur la mise à jour d'une configuration existante, consultez Modifier en mettant à jour un pool de nœuds existant.

Exécutez la commande suivante pour mettre à jour le pool de nœuds existant :

   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 liées aux mises à jour des nœuds.

Attention : GKE commence immédiatement à recréer les nœuds pour ce changement à l'aide de la stratégie de mise à niveau des nœuds, quelles que soient les règles de maintenance actives. GKE dépend de la disponibilité des ressources pour le changement. La désactivation des mises à niveau automatiques des nœuds n'empêche pas cette modification.

Modifier une configuration de système de nœuds

Vous pouvez modifier la configuration du système d'un nœud selon que vous utilisez des ComputeClasses ou un fichier de configuration.

Pour les ComputeClasses

Pour modifier la configuration du système de nœuds lorsque vous utilisez des ComputeClasses, choisissez l'une des méthodes suivantes :

Méthode 1 : Mettre à jour la ComputeClass existante

Si vous mettez à jour le champ nodeSystemConfig dans une ComputeClass existante, GKE applique la configuration mise à jour aux nœuds nouvellement créés uniquement. Les nœuds existants ne sont pas mis à jour automatiquement.

Pour migrer vos charges de travail vers des nœuds avec la nouvelle configuration, vous pouvez effectuer l'une des opérations suivantes :

• Configurez la migration active dans votre ComputeClass.
• Pour déclencher le scale-up de nouveaux nœuds, redémarrez ou recréez manuellement vos charges de travail.

Pour mettre à jour la ComputeClass, modifiez le fichier YAML et appliquez-le :

kubectl apply -f custom-sysconfig.yaml

Méthode 2 : Créer une ComputeClass

Pour vous assurer que vos charges de travail migrent vers de nouveaux nœuds avec la configuration mise à jour, procédez comme suit :

1. Créez une ComputeClass avec un nom différent et la configuration mise à jour.
2. Mettez à jour le sélecteur de nœud dans les spécifications de votre charge de travail pour référencer la nouvelle ComputeClass.
3. Appliquez les spécifications de charge de travail mises à jour. L'autoscaler de cluster provisionnera de nouveaux nœuds avec la nouvelle configuration et finira par réduire la taille des anciens nœuds.
4. Supprimez l'ancien objet ComputeClass.

Pour les fichiers de configuration

Pour modifier une configuration de système de nœuds lorsque vous utilisez un fichier de configuration, vous pouvez créer un pool de nœuds avec la configuration souhaitée ou mettre à jour la configuration de système de nœuds 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 de système de nœuds existante 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 de 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 respectives.

Obtenir la configuration du système de nœuds existant

Pour récupérer la configuration existante du système de nœuds de votre pool de nœuds (par exemple, si vous avez déjà personnalisé la configuration et que vous souhaitez l'enrichir), utilisez la commande gcloud container node-pools describe. Le résultat de la commande liste toutes les configurations existantes sous kubeletConfig et linuxNodeConfig.

Attention : Lorsque vous mettez à jour la configuration du nœud Linux en fonction de cette sortie, vous devez spécifier les paramètres sous le champ linuxConfig dans la commande de mise à jour. La commande describe affiche ces paramètres sous linuxNodeConfig, mais pour les mises à jour, le champ correct est linuxConfig. L'utilisation du champ de sortie linuxNodeConfig dans une requête de mise à jour n'appliquera pas les modifications.

Par exemple, consultez l'extrait suivant qui montre le format de la sortie de la commande describe :

  kubeletConfig:
    allowedUnsafeSysctls:
    - kernel.shm*
    - kernel.msg*
    - kernel.sem
    - fs.mqueue.*
    - net.*
    cpuManagerPolicy: static
    insecureKubeletReadonlyPortEnabled: false
    maxParallelImagePulls: 2
  linuxNodeConfig: # IMPORTANT: Use linuxConfig when updating these settings
    sysctl:
      net.core.somaxconn: '2048'
      net.ipv4.tcp_rmem: 4096 87380 6291456

Si vous n'avez pas encore défini de configuration du système de nœuds, la sortie ne liste pas kubeletConfig ni linuxNodeConfig.

Réinitialiser la configuration existante du système de nœuds

Si vous souhaitez rétablir la configuration par défaut du système de nœuds, mettez à jour votre 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 du système de nœud, suivez les étapes en fonction de l'utilisation de ComputeClasses ou d'un fichier de configuration.

Pour les ComputeClasses

Pour supprimer la configuration personnalisée du système de nœuds, procédez comme suit :

1. Supprimez le sélecteur de nœud cloud.google.com/compute-class des spécifications de vos charges de travail.
2. Appliquez les spécifications de charge de travail mises à jour. GKE recrée les charges de travail sur les nœuds par défaut. L'autoscaler de cluster finira par réduire la capacité et supprimer les nœuds provisionnés pour la ComputeClass.

3. Supprimez l'objet ComputeClass du cluster :

   kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
   

Pour les fichiers de configuration

Pour supprimer une configuration de système de nœuds appliquée à l'aide d'un fichier de configuration, procédez comme suit :

1. Créez un pool de nœuds sans fichier de configuration.
2. Migrez vos charges de travail vers le nouveau pool de nœuds.
3. Supprimez le pool de nœuds qui contient l'ancienne configuration du 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. Si vous définissez cette valeur sur false, les limites de processeur pour les pods sont ignorées. Ignorer les limites de processeur peut être utile dans certains cas où les pods sont sensibles à ces limites. Le risque lié à la désactivation de cpuCFSQuota est qu'un pod malveillant 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 la période du quota CFS du processeur, cpu.cfs_period_us, qui spécifie la fréquence à laquelle l'accès d'un cgroup 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 qui décrit les options modifiables pour l'indicateur 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 réversible 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 à des durées qui définissent les périodes de grâce pour les seuils d'éviction souple. Chaque seuil d'éviction flexible 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.
singleProcessOOMKill	La valeur doit être true ou false.	true pour les nœuds cgroupv1, false pour les nœuds cgroupv2.	Ce paramètre indique 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.

Le tableau suivant indique 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 les imagefs disponibles 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.

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 règle 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. 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 nombre 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 de mémoire des images n'est jamais exécutée. Il représente l'utilisation de disque la plus faible pour la récupération d'espace. 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. Lorsque 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.

Récupération 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 de récupérations 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 de noms sysctl ou de groupes sysctl non sécurisés, séparés par une virgule, qui peuvent être définis sur les pods.
insecureKubeletReadonlyPortEnabled	La valeur doit être une valeur booléenne (true ou false).	false	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 pouvez pas utiliser un client 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œud 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, qui correspond au schéma d'affinité du processeur par défaut. Elle ne fournit aucune affinité au-delà de ce que le planificateur de l'OS fait automatiquement. Si vous définissez cette valeur sur static, les pods qui appartiennent à la classe QoS Guaranteed et qui ont des demandes de processeur entières peuvent se voir 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, le règlement du gestionnaire de mémoire envoie des indications de topologie qui dépendent du type de pod. Pour en savoir plus, consultez Règle statique. 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 des 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 champ d'application indépendamment les uns des autres. Pour en savoir plus sur ces paramètres, consultez Champs d'application 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, C4N, G2, G4, M3, N4

Délai de redémarrage du conteneur

Ce paramètre contrôle le délai maximal d'attente entre les tentatives de redémarrage d'un conteneur lorsqu'il est à l'état CrashLoopBackOff. Vous pouvez configurer ce paramètre pour les pools de nœuds standards exécutant la version 1.35 ou ultérieure de GKE.

Attention : Un délai très court sur un conteneur qui échoue de manière persistante peut entraîner une forte consommation de processeur et de ressources sur le nœud, ce qui peut avoir un impact sur d'autres charges de travail en raison de l'épuisement des ressources. Envisagez de le réduire uniquement lorsque les avantages de nouvelles tentatives plus rapides l'emportent sur les risques d'augmentation de l'utilisation des ressources.

Le tableau suivant décrit les options modifiables pour crashLoopBackOff.

Paramètres de configuration kubelet	Restrictions	Paramètre par défaut	Description
crashLoopBackOff.maxContainerRestartPeriod	La valeur doit être une durée positive inférieure ou égale à 5 minutes (5m). Les unités de temps valides sont ns, us (ou µs), ms, s ou m.	none	Durée maximale pendant laquelle le délai d'intervalle entre les tentatives peut s'accumuler pour les redémarrages de conteneurs. Le délai entre les redémarrages augmente de manière exponentielle à partir d'une valeur initiale jusqu'à cette limite maximale. La limite maximale par défaut pour un cluster Kubernetes est de 5 minutes. Pour en savoir plus, consultez Délai de redémarrage configurable des conteneurs.

Arrêt progressif des VM Spot dans GKE

Le tableau suivant décrit les options modifiables pour la période de fin et d'arrêt progressif des VM spot dans GKE. Pour utiliser ces options, le plan de contrôle de votre cluster doit exécuter GKE version 1.35.0-gke.1171000 ou ultérieure. Pour en savoir plus, consultez Fonctionnement des VM Spot dans GKE.

Paramètres de configuration kubelet	Restrictions	Paramètre par défaut	Description
shutdownGracePeriodSeconds	La valeur doit être un nombre entier représentant la durée en secondes. Les valeurs autorisées sont 0, 30 ou 120.	30	Spécifie la durée totale, en secondes, pendant laquelle le nœud retarde son arrêt afin de mettre fin aux pods de manière progressive.
shutdownGracePeriodCriticalPodsSeconds	La valeur doit être un entier compris entre 0 et 120 (inclus), et doit être inférieure à shutdownGracePeriodSeconds. Valide uniquement si shutdownGracePeriodSeconds est également défini.	15	Indique la durée en secondes utilisée pour arrêter les pods critiques lors de la mise hors ligne d'un nœud.

Réservations de ressources système

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour les pools de nœuds Standard qui exécutent Linux et GKE 1.37 ou version ultérieure, vous pouvez personnaliser la quantité de mémoire et de processeur réservée aux composants système. Cela vous permet d'ajuster la capacité allouable pour des scénarios spécifiques, comme la gestion des extractions d'images à volume élevé ou l'exécution de DaemonSets de nœuds personnalisés. Pour en savoir plus sur les réservations par défaut, consultez À propos du dimensionnement des nœuds GKE.

Le tableau suivant décrit les options modifiables pour les réservations de ressources système.

Paramètres de configuration kubelet	Restrictions	Paramètre par défaut	Description
reservedResourcesConfig.memoryReservedMib	La valeur doit être un nombre entier. La valeur doit être supérieure ou égale à la réservation de mémoire par défaut pour les pools de nœuds créés avec la version 1.37 ou ultérieure, et inférieure à 50% de la capacité de mémoire totale du nœud.	Consultez Réservations de mémoire.	Quantité de mémoire à réserver pour les composants système, en mébioctets (Mio).
reservedResourcesConfig.cpuReservedMillicore	La valeur doit être un nombre entier. Doit être supérieur ou égal à la réservation de processeur par défaut pour les pools de nœuds créés avec la version 1.37 ou ultérieure, et inférieur à 50% de la capacité totale du processeur du nœud.	Consultez Réservations de processeur.	Quantité de ressources processeur à réserver pour les composants système, en millicores.

Vérifier les réservations effectives

Pour vérifier les réservations actives appliquées à votre pool de nœuds, inspectez les champs de sortie effectiveMemoryReservedMib et effectiveCpuReservedMillicore :

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig.reservedResourcesConfig)"

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 [104857, 67108864].	Ce paramètre définit le nombre maximal de descripteurs de fichiers que le noyau Linux peut allouer.
fs.inotify.max_user_instances	La valeur doit être comprise entre 8 192 et 1 048 576.	Ce paramètre définit le nombre maximal d'instances inotify qu'un utilisateur peut créer.
fs.inotify.max_user_watches	La valeur doit être comprise entre 8 192 et 1 048 576.	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 du 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 correspond à 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 accepté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.
kernel.keys.maxbytes	Doit être compris entre [20000, 2097152].	Ce paramètre définit le nombre maximal d'octets qu'un utilisateur non racine peut stocker dans la section de charge utile de toutes ses clés.
kernel.keys.maxkeys	Doit être compris entre [200, 1048576].	Ce paramètre définit le nombre maximal de clés qu'un utilisateur non root peut posséder.

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é pour l'interrogation d'occupation à faible latence pour l'interrogation et la sélection. Il représente le temps approximatif en µs pour la boucle d'attente occupée pour les é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 occupée à faible latence pour les lectures de socket. Il représente le temps approximatif en µs pour la boucle d'occupation en attente de 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	La valeur doit être comprise entre 128 et 2147483647.	Ce paramètre définit la limite du backlog socket listen(), qui est connu dans l'espace utilisateur sous le nom de SOMAXCONN. Ce paramètre est défini par défaut sur 128.
net.ipv4.tcp_rmem	{min, default, max} (chaque valeur doit être supérieure à 0, mémoire en octets).	Ce paramètre définit la taille minimale, en octets, du tampon de réception utilisé 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 doit être supérieure à 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	La valeur doit être comprise 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 4096 et 2147483647.	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écouverte de l'unité de transmission maximale (MTU) du 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 : Container-Optimized OS : reno, cubic, bbr, lp, htcp (disponible sur les versions GKE 1.34.1-gke.3355001 ou ultérieures) 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 permet 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 les versions GKE 1.32.0-gke.1448000 ou ultérieures.
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 les versions GKE 1.32.0-gke.1448000 ou ultérieures.
net.netfilter.nf_conntrack_buckets	La valeur doit être comprise entre 65 536 et 524 288.	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 les versions GKE 1.32.0-gke.1448000 ou ultérieures.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Doit être compris entre [60, 3600].	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 les versions GKE 1.32.0-gke.1448000 ou ultérieures.
net.netfilter.nf_conntrack_tcp_timeout_established	La valeur doit être comprise entre 600 et 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 les versions GKE 1.32.0-gke.1448000 ou ultérieures.
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 les versions GKE 1.32.0-gke.1448000 ou ultérieures.
net.ipv4.neigh.default.gc_thresh1	La valeur doit être comprise entre 0 et 262 144.	Ce paramètre définit le nombre minimal d'entrées à conserver dans le cache ARP. Le collecteur de déchets ne s'exécute pas si le nombre d'entrées est inférieur à ce paramètre. Si vous définissez cette valeur sur 0, cela peut entraîner un thrashing du cache et une dégradation des performances.
net.ipv4.neigh.default.gc_thresh2	La valeur doit être comprise entre 512 et 524 288.	Ce paramètre définit le nombre maximal d'entrées à conserver dans le cache ARP. Le collecteur de déchets permet au nombre d'entrées de dépasser cette valeur pendant cinq secondes avant de lancer la récupération de mémoire soft.
net.ipv4.neigh.default.gc_thresh3	Doit être compris entre [1024, 1048576].	Ce paramètre définit le nombre maximal d'entrées à conserver dans le cache ARP. Le collecteur de déchets est conçu pour s'exécuter systématiquement si le nombre d'entrées dépasse ce paramètre.

Paramètres de 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 comporter.
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 pouvant être rempli par des pages modifiées 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 modifiée à 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 qui peut être rempli de 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 du vidangeur de 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 (valeur par défaut) 2 : empêche l'engagement au-delà de la mémoire d'échange et du ratio de RAM Ce paramètre n'est pas compatible avec les machines disposant de moins de 15 Go de mémoire.
vm.overcommit_ratio	Doit être compris entre 0 et 100.	Ce paramètre définit le pourcentage de RAM physique autorisé pour le sur-engagement lorsque la valeur du champ vm.overcommit_memory est définie sur 2.
vm.vfs_cache_pressure	Doit être compris 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 le sysctl est appliqué de manière globale sur le nœud et dans chaque espace de noms, de sorte que chaque pod ait des valeurs sysctl identiques dans chaque espace de noms Linux.

Options de configuration du mode cgroup de Linux

Attention : GKE abandonne cgroupv1 à partir de la version mineure 1.31 et supprime la prise en charge de cgroupv1 à partir de la version 1.35. Pour en savoir plus sur la transition de GKE vers cgroupv2 et sur la préparation de vos clusters à cette transition, consultez Migrer des nœuds vers Linux cgroupv2.

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 sur les 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 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 d'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 l'image de nœud Container-Optimized OS avec containerd ou Ubuntu avec 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.
• 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 des huge pages préallouées manuellement ou des huge pages transparentes attribuées automatiquement.

Hugepages préallouées

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, C4N, CT5E, CT5LP, CT6E, H3, M2, M3, M4, Z3 ou Z4D.

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. Soumis aux limites d'allocation de mémoire décrites précédemment.	0	Ce paramètre préalloue un nombre spécifique de pages "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 kernel 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 pages énormes 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 un THP. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER : une application réveille kswapd en arrière-plan pour récupérer des pages et réveille kcompactd pour compacter la mémoire afin que THP soit disponible dans un avenir proche. Il incombe ensuite à khugepaged d'installer les pages THP. 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). Dans toutes les autres régions, kswapd est réveillé en arrière-plan pour récupérer des pages et kcompactd est réveillé 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). Dans toutes les autres régions, kswapd est réveillé en arrière-plan pour récupérer des pages et kcompactd est réveillé 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 sur GKE version 1.33.2-gke.4655000 ou ultérieure. THP n'est pas activé lorsque vous mettez à niveau des pools de nœuds existants vers une version compatible ou ultérieure.

Option de synchronisation horaire précise pour Linux

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Si la synchronisation précise de l'heure et la surveillance de la précision de votre synchronisation de l'heure sont importantes pour vos charges de travail, vous pouvez configurer l'heure précise pour synchroniser l'horloge de votre VM avec l'horloge de l'hôte à l'aide de chrony et ptp_kvm. Cette configuration est conçue pour atteindre une précision de 1 ms pour les configurations compatibles. Pour en savoir plus sur les types de machines, les systèmes d'exploitation et les zones compatibles, consultez Configurer une heure précise pour les VM Compute Engine.

Le tableau suivant décrit le paramètre permettant de configurer une synchronisation temporelle précise avec GKE :

Paramètre de configuration	Valeurs acceptées	Valeur par défaut	Description
accurateTimeConfig.enablePtpKvmTimeSync	true ou false	false	Ce paramètre permet une synchronisation horaire précise. Cette fonctionnalité n'est compatible qu'avec certains types de machines, systèmes d'exploitation et zones.

Options de configuration VFIO Linux

Le tableau suivant décrit le paramètre permettant de configurer VFIO (Virtual Function I/O) sur un nœud. VFIO permet aux pilotes d'espace utilisateur sécurisés et non privilégiés d'accéder aux périphériques d'E/S.

Paramètre de configuration	Restrictions	Valeur par défaut	Description
nodeVfioConfig.dmaEntryLimit	Veuillez saisir un nombre entier compris entre 65535 et 4194304.	65535	Spécifie le nombre maximal d'entrées DMA (pages) pouvant être mappées par le pilote VFIO IOMMU de type 1 pour un conteneur. Cette limite affecte la quantité totale de mémoire hôte qui peut être épinglée pour un accès direct aux appareils, ce qui est souvent essentiel pour les appareils hautes performances comme les TPU et les GPU. Ce paramètre correspond au paramètre de noyau suivant : /sys/module/vfio_iommu_type1/parameters/dma_entry_limit. Des valeurs plus élevées peuvent être nécessaires pour les charges de travail mappant de grandes régions de mémoire. Disponible sur les versions GKE 1.36.0-gke.3009000 ou ultérieures.

Options de configuration du programmeur d'E/S disque Linux

Le tableau suivant décrit les paramètres permettant de configurer le planificateur d'E/S de disque pour les pools de nœuds.

Paramètre de configuration	Valeurs acceptées	Valeur par défaut	Description
diskIoScheduler.nodeSystemIoScheduler	mq-deadline, bfq, kyber, none	bfq pour l'image Container-Optimized OS, none pour l'image Ubuntu	Configure le planificateur d'E/S pour le disque de démarrage ou le SSD local éphémère qui exécute les charges de travail du système de nœuds. Disponible sur les versions 1.36.0-gke.3009000 ou ultérieures de GKE.
diskIoScheduler.nodeAttachedDiskIoScheduler	mq-deadline, bfq, kyber, none	none	Configure le planificateur d'E/S pour les disques associés. Disponible sur les versions 1.36.0-gke.3009000 ou ultérieures de GKE.

Étapes suivantes

• Découvrez comment migrer des nœuds vers Linux cgroupv2.
• Découvrez comment ajouter et gérer des pools de nœuds.
• Découvrez comment personnaliser la configuration containerd dans les nœuds GKE.
• Découvrez comment amorcer automatiquement les nœuds GKE avec les objets DaemonSet.