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

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étaille 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, comme les clusters GKE Autopilot disposent d'un environnement de nœuds plus géré, leurs options de configuration directe du système de nœuds sont limitées par rapport aux pools de nœuds GKE Standard.

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

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

• Réglage 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 la diffusion de l'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 : assurez-vous que l'environnement de nœud répond aux conditions préalables spécifiques pour les logiciels spécialisés ou les applications plus anciennes 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 vos nœuds à 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 ComputeClass GKE. Vous pouvez utiliser ComputeClasses, en mode Autopilot et mode Standard GKE, dans GKE version 1.32.1-gke.1729000 et ultérieures. 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 des 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, veillez à installer et à configurer Google Cloud CLI.
  • Si vous utilisez les exemples Terraform, veillez à installer et à 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, telles que container.clusterAdmin ou un autre rôle avec des autorisations équivalentes.
• Planifiez les perturbations potentielles 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, ce qui implique de recréer les nœuds. Planifiez les interruptions potentielles des charges 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 en production. Des paramètres incorrects peuvent entraîner une instabilité des nœuds ou des échecs de charge de travail.
• Vérifiez 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 1.32.1-gke.1729000 et versions ultérieures.

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 votre configuration ComputeClass en YAML. Utilisez le champ nodeSystemConfig dans la spécification priorityDefaults pour définir les configurations système pour toutes les priorités.

L'exemple de ComputeClass suivant configure la règle de gestionnaire de processeur statique et les paramètres de kernel 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 ComputeClass

Dans la spécification de votre pod, ajoutez un sélecteur de nœud pour le nom de la 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 de kubelet et du noyau Linux. Bien que les configurations système des nœuds soient également disponibles en mode GKE Autopilot, les étapes de ce document vous expliquent 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 un pool de nœuds, ou mettez à jour un pool de nœuds existant.

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'
  kernelOverrides:
    kernelCommandlineOverrides:
      specRstackOverflow: 'SPEC_RSTACK_OVERFLOW_OFF'
      initOnAlloc: 'INIT_ON_ALLOC_OFF'

Dans cet exemple, les conditions suivantes s'appliquent :

• Le champ cpuManagerPolicy: static configure le kubelet pour qu'il utilise la règle 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.
• Le bloc kernelCommandlineOverrides désactive la correction du dépassement de pile de retour spéculatif (SRSO) et le paramètre de noyau init_on_alloc.

Si vous souhaitez ajouter des configurations uniquement pour kubelet ou sysctl, n'incluez que cette section dans votre configuration de 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 de votre 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 cette option lorsque vous créez un cluster ou un pool de nœuds, ou lorsque vous mettez à jour un pool de nœuds existant. 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 système de nœud lors de la création du cluster à l'aide de la 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 :

gcloud CLI

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œuds, 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 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 système de nœud lorsque vous utilisez la 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 :

gcloud CLI

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 Compatibilité de Terraform avec GKE.

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

Si vous utilisez un fichier de configuration pour gérer la configuration du système de nœuds, vous pouvez mettre à jour un pool de nœuds existant de l'une des manières suivantes :

• Mise à jour en direct sans interruption : applique les paramètres sysctl et kubelet mis à jour directement aux nœuds en cours d'exécution sans recréer les VM ni expulser les pods. Utilisez cette méthode lorsque vous ne modifiez que les paramètres sysctl ou kubelet et que vous souhaitez minimiser les perturbations.
• Stratégie de mise à niveau standard : recrée les nœuds avec la nouvelle configuration. Utilisez cette méthode lorsque vous modifiez des paramètres qui ne sont pas compatibles avec les mises à jour en temps réel, lorsque votre cluster ou votre pool de nœuds exécute une version de GKE antérieure à la version 1.37.1-gke.1954000, ou lorsque vous souhaitez que GKE draine et replanifie vos pods sur de nouveaux nœuds.

Pour modifier la configuration des nœuds qui utilisent une ComputeClass, consultez plutôt Modifier une configuration de système de nœud pour les ComputeClasses.

Attention : Quelle que soit la méthode, l'inclusion de la section kubeletConfig ou linuxConfig dans votre fichier remplace l'intégralité de cette section de la configuration existante du pool de nœuds. Tout paramètre que vous omettez dans une section incluse est réinitialisé à sa valeur par défaut. Lors d'une mise à jour en direct, l'omission d'un paramètre précédemment configuré qui n'est pas compatible avec les mises à jour en direct (comme cpuManagerPolicy ou cgroupMode) entraîne le rejet de la mise à jour par GKE. Avant de procéder à la mise à jour, obtenez la configuration système des nœuds existants et incluez tous les paramètres que vous souhaitez conserver.

Mettre à jour à l'aide d'une mise à jour en direct sans interruption

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.

Vous pouvez appliquer les paramètres sysctl et kubelet mis à jour de votre fichier de configuration directement aux nœuds en cours d'exécution. Comme ce processus met à jour les paramètres sans recréer ni redémarrer les VM sous-jacentes, il réduit les perturbations et accélère la mise à jour. Les options linuxConfig suivantes nécessitent toujours la stratégie de mise à niveau standard :

• Mode cgroup de Linux
• Hugepages Linux
• Synchronisation précise de l'heure sous Linux
• VFIO Linux
• Planificateur d'E/S de disque Linux

Fonctionnement des infos en direct

Les infos en direct fonctionnent comme suit pour chaque configuration compatible :

• Configurations sysctl : GKE redémarre le service systemd sysctl sur chaque nœud pour appliquer les paramètres du noyau dans le champ linuxConfig.sysctl. Si vous mettez à jour un paramètre sysctl associé à un espace de noms, GKE redémarre également le service kubelet pour mettre à jour la configuration sysctl au niveau du pod. Pour connaître les paramètres compatibles, consultez Options de configuration Sysctl.
• Configurations kubelet : GKE redémarre le service kubelet sur chaque nœud pour appliquer les paramètres du champ kubeletConfig. La plupart des options de configuration kubelet sont compatibles avec les mises à jour en direct. Toutefois, les options cpuManagerPolicy, shutdownGracePeriodSeconds et shutdownGracePeriodCriticalPodsSeconds nécessitent la stratégie de mise à niveau standard.

Dans les deux cas, GKE applique la modification sur les nœuds en cours d'exécution sans recréer les VM, sans supprimer vos pods ni créer de VM de surutilisation temporaires. GKE utilise la somme des paramètres --max-surge-upgrade et --max-unavailable-upgrade de votre pool de nœuds comme limite de simultanéité pour déterminer le nombre de nœuds existants mis à jour en parallèle.

Prérequis pour les infos en direct

Pour utiliser les mises à jour en direct, votre cluster et votre pool de nœuds doivent remplir les conditions préalables suivantes :

• Exécutez GKE version 1.37.1-gke.1954000 ou ultérieure.
• Activez le module complémentaire NodeReadinessController sur le cluster. Lors d'une mise à jour en direct, ce contrôleur applique temporairement le rejet readiness.k8s.io/gke-node-live-update-reconciling:NoSchedule à chaque nœud en cours de mise à jour afin que GKE ne planifie pas de nouveaux pods sur le nœud tant que la mise à jour n'est pas terminée :
  • Pour les nouveaux clusters, incluez le module complémentaire NodeReadinessController dans l'option --addons lors de la création du cluster. Cette option n'active que les modules complémentaires que vous spécifiez et désactive tous les autres. Incluez donc également les modules complémentaires par défaut que vous souhaitez conserver.
  • Pour les clusters existants, transmettez l'option --update-addons=NodeReadinessController=ENABLED lors d'une mise à jour du cluster.

Appliquer une mise à jour en direct

Pour appliquer une mise à jour en direct, procédez comme suit :

1. Créez ou modifiez votre fichier YAML de configuration du système de nœuds afin qu'il contienne la configuration complète du pool de nœuds, y compris les paramètres kubelet ou sysctl que vous souhaitez modifier. Pour éviter de réinitialiser des paramètres que vous ne souhaitez pas modifier, commencez par la configuration existante du pool de nœuds.

2. Mettez à jour le pool de nœuds avec votre fichier de configuration et définissez la valeur de l'option --node-config-update-mode sur LIVE_UPDATE_WITHOUT_DRAIN :

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

   Remplacez les éléments suivants :

   • POOL_NAME : nom du pool de nœuds que vous souhaitez mettre à jour.
   • CLUSTER_NAME : nom du cluster contenant le pool de nœuds.
   • LOCATION : zone ou région Compute du cluster.
   • SYSTEM_CONFIG_PATH : chemin d'accès au fichier YAML contenant la configuration de votre système de nœuds.

3. Vérifiez que GKE a appliqué les paramètres mis à jour à votre pool de nœuds :

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

   Le résultat de la commande affiche les paramètres actifs sur le pool de nœuds dans les champs config.kubeletConfig et config.linuxNodeConfig.

4. Facultatif : redémarrez vos pods existants. La mise à jour en direct n'interrompt pas les pods en cours d'exécution. GKE n'applique donc les paramètres mis à jour qu'aux pods qui démarrent une fois la mise à jour terminée. Pour appliquer les paramètres à une charge de travail déjà en cours d'exécution, redémarrez ses pods, par exemple en exécutant kubectl rollout restart sur le déploiement.

Si une mise à jour en direct ne se déroule pas comme prévu, le chemin de récupération dépend de la fin de l'opération de mise à jour :

• Si l'opération de mise à jour en direct échoue, consultez Récupérer après l'échec d'une mise à jour en direct.
• Si l'opération de mise à jour en direct réussit, mais que les nouveaux paramètres entraînent un comportement de charge de travail involontaire, consultez la section Annuler une mise à jour en direct terminée.

Récupération après un échec de mise à jour en direct

Si une mise à jour en direct échoue sur un nœud, GKE arrête immédiatement le déploiement et laisse le pool de nœuds dans un état partiellement mis à jour. Pour inspecter les détails de l'échec, effectuez l'une des opérations suivantes :

• Exécutez la commande gcloud container operations describe. Dans le résultat, le champ statusMessage identifie le nœud sur lequel la mise à jour en direct a échoué et l'erreur signalée par le nœud, par exemple :

  statusMessage: 'Failed precondition: live update failed on node gke-my-cluster-default-pool-ae3770ee-2kk0:
    Live update fails with error: failed to write new kubelet config: ...'
  

• Dans l'explorateur de journaux, recherchez les erreurs du composant gke-node-live-update-reconciler sur les nœuds concernés.

Étant donné qu'une mise à jour en direct ayant échoué ne modifie pas la configuration stockée du pool de nœuds, l'application de votre configuration précédente à l'aide de la commande gcloud container node-pools update ne déclenche pas de mise à jour. Après avoir inspecté l'échec, choisissez l'une des options de récupération suivantes :

• Corrigez le problème et effectuez la mise à jour en direct (recommandé) : résolvez le problème à l'origine de l'échec, puis réexécutez la commande gcloud container node-pools update de la procédure précédente avec votre configuration cible.
• Revenir à la configuration précédente : si vous ne parvenez pas à résoudre le problème, exécutez la commande gcloud container node-pools rollback pour rétablir la configuration précédente du pool de nœuds. Contrairement à une mise à jour en direct, cette commande recrée tous les nœuds du pool de nœuds, ce qui perturbe les charges de travail qui s'y exécutent.

Annuler une mise à jour en direct terminée

Si une opération de mise à jour en direct réussit, mais qu'un paramètre nouvellement appliqué entraîne un comportement de charge de travail involontaire, annulez la modification en place en appliquant une autre mise à jour en direct avec votre configuration précédente. Cette mise à jour en direct restaure la configuration précédente sans supprimer les pods ni redémarrer les nœuds. La commande gcloud container node-pools rollback n'est pas disponible après une opération réussie. Elle ne fonctionne que lorsque l'opération échoue.

Pour annuler une mise à jour en direct terminée, procédez comme suit :

1. Mettez à jour le fichier YAML de configuration du système de nœuds afin qu'il contienne la configuration précédente complète du pool de nœuds. Si un paramètre n'a pas été configuré précédemment, définissez-le explicitement sur sa valeur par défaut plutôt que de l'omettre ou de laisser la section vide. Pour connaître les valeurs par défaut, consultez Options de configuration de Kubelet et Options de configuration de Sysctl.

2. Appliquez la configuration précédente à votre pool de nœuds :

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

Mettre à jour à l'aide de la stratégie de mise à niveau standard

Utilisez la stratégie de mise à niveau standard si vous mettez à jour des options de configuration qui ne sont pas compatibles avec les mises à jour en temps réel, si votre cluster ou votre pool de nœuds exécute une version de GKE antérieure à la version 1.37.1-gke.1954000, ou si vous souhaitez que GKE draine et replanifie automatiquement vos pods sur les nœuds nouvellement créés.

Pour mettre à jour un pool de nœuds existant à l'aide de la stratégie de mise à niveau standard, exécutez 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 contenant le pool de nœuds.
• LOCATION : zone ou région Compute du cluster.
• SYSTEM_CONFIG_PATH : chemin d'accès au fichier YAML contenant la configuration de votre système de nœuds.

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 cette modification à 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 la modification. La désactivation des mises à niveau automatiques des nœuds n'empêche pas ce changement.

Modifier une configuration de système de nœuds

Vous pouvez modifier la configuration d'un système de nœuds 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 nodeSystemConfig dans une ComputeClass existante, GKE applique la configuration mise à jour uniquement aux nœuds nouvellement créés. Les nœuds existants ne sont pas mis à jour automatiquement.

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

• Configurez la migration active dans votre ComputeClass.
• Pour déclencher un scaling à la hausse 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 classe 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 classe ComputeClass avec un nom différent et la configuration mise à jour.
2. Mettez à jour le sélecteur de nœuds 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 capacité 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 de votre choix 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 du système de nœuds d'un pool de nœuds existant, consultez Mettre à jour la configuration du système de nœuds d'un pool de nœuds existant.

Obtenir la configuration du système de nœud existante

Pour récupérer la configuration du système de nœuds existante de votre pool de nœuds (par exemple, si vous avez déjà personnalisé la configuration et que vous souhaitez l'ajouter), 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 ce résultat, 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, l'extrait suivant montre le format de 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 système de nœud, la sortie n'affiche pas kubeletConfig ni linuxNodeConfig.

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

Si vous souhaitez rétablir les valeurs par défaut de la configuration du système de nœuds, mettez à jour votre fichier de configuration avec des valeurs vides pour les champs kubelet et sysctl, par exemple :

```yaml
kubeletConfig: {}
linuxConfig:
  sysctl: {}
```

Supprimer une configuration de système de nœuds

Pour supprimer une configuration de système de nœud, suivez les étapes selon que vous utilisez des ComputeClasses ou 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 de vos spécifications de charge 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 le fichier de configuration.
2. Migrez vos charges de travail vers le nouveau pool de nœuds.
3. Supprimez le pool de nœuds qui possède 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.

kubelet paramètre de configuration	Restrictions	Paramètre par défaut	Description
cpuCFSQuota	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 scénarios où les pods sont sensibles aux limites de processeur. Si vous désactivez cpuCFSQuota, un pod non autorisé risque de 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 de 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éalloué. Cette option vous permet d'ajuster le comportement de limitation du processeur.
reservedSystemCPUs (Preview)	Il doit s'agir d'une liste de cœurs de processeur spécifiques à réserver (par exemple, 0-1 ou 0,1 pour réserver les cœurs 0 et 1). Étant donné que les cœurs sont indexés à partir de zéro, les valeurs doivent être inférieures au nombre de processeurs virtuels sur le type de machine.	none	Réserve explicitement des cœurs de processeur spécifiques pour les services du système hôte, tels que les daemons de l'OS et le service kubelet. Par défaut, ces services peuvent s'exécuter sur n'importe quel cœur de processeur, ce qui peut entraîner des problèmes de performances pour les charges de travail sensibles au processeur. Bien que le paramètre cpuManagerPolicy: static attribue des cœurs dédiés aux pods Guaranteed avec des requêtes de processeur entières, il n'empêche pas les services du système hôte d'utiliser ces cœurs. L'ajout du paramètre reservedSystemCPUs limite les services du système hôte à leurs propres cœurs réservés, ce qui les empêche d'interrompre les cœurs exclusifs de vos charges de travail. Pour ce faire, GKE associe automatiquement le cgroup system.slice aux cœurs réservés au démarrage du nœud. La réservation de processeurs système réduit la capacité globale pouvant être allouée de vos nœuds. Bien que les pods Burstable et BestEffort puissent toujours s'exécuter sur ces cœurs réservés, leurs demandes de processeur, y compris les demandes fractionnaires des DaemonSets GKE, sont toujours comptabilisées dans la capacité allouable du nœud. Étant donné que les charges de travail Guaranteed exclusives nécessitent des cœurs entiers, même de petites requêtes fractionnaires réduisent le nombre de cœurs exclusifs disponibles. Assurez-vous de réserver suffisamment de cœurs de processeur dans reservedSystemCPUs. Si vous réservez trop peu de cœurs, les démons du système hôte et les processus de l'OS peuvent être limités par le processeur en cas de charge élevée, ce qui peut entraîner une instabilité ou une perte de paquets réseau.

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'option evictionSoft.

kubelet paramètre de configuration	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 des signaux à une quantité ou à un pourcentage qui définit les seuils d'éviction logicielle. Un seuil d'éviction souple doit être associé à 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 des signaux aux durées qui définissent les délais de grâce pour les seuils d'éviction logicielle. Chaque seuil d'éviction souple 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 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 des pods 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 détermine si les processus du conteneur sont arrêtés par OOM individually ou en groupe. Disponible sur GKE 1.32.4-gke.1132000, 1.33.0-gke.1748000 ou version ultérieure.

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

kubelet paramètre de configuration	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 le kubelet .
nodefsAvailable	La valeur doit être comprise entre 10% et 50%.	none	Ce paramètre représente les nodefs disponibles avant l'éviction logicielle. Définit la quantité de signal nodefs.available dans le 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 le kubelet .
imagefsAvailable	La valeur doit être comprise entre 15% et 50%.	none	Ce paramètre représente l'espace imagefs disponible avant l'éviction logicielle. Définit la quantité de signal imagefs.available dans le 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 le 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 le kubelet.

Gestion des PID

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

kubelet paramètre de configuration	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 modifiables pour la journalisation.

kubelet paramètre de configuration	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 du 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 % de l'espace de 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 de mémoire des images.

kubelet paramètre de configuration	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-dessus duquel le nettoyage d'image est exécuté. Il représente 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 minimale du disque 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 récupérée par le garbage collector.
imageMaximumGcAge	La valeur doit être une durée.	0s	Ce paramètre définit la durée maximale pendant laquelle une image peut rester inutilisée avant d'être 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 récupérées par le garbage collector si elles ne sont pas utilisées. Lorsque cette valeur est spécifiée, elle doit être supérieure à la valeur du champ imageMinimumGcAge. Disponible sur GKE 1.30.7-gke.1076000, 1.31.3-gke.1023000 ou version ultérieure.

Extraction d'image

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

kubelet paramètre de configuration	Restrictions	Paramètre par défaut	Description
maxParallelImagePulls	La valeur doit être un entier compris entre 2 et 5 inclus.	2 ou 3 en fonction du 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 non sécurisées

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

kubelet paramètre de configuration	Restrictions	Paramètre par défaut	Description
allowedUnsafeSysctls	Liste de noms ou de 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é 10255 du kubelet 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 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 processeur, d'appareil et de mémoire (hugepages).

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

kubelet paramètre de configuration	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 de kubelet. La valeur par défaut est none, qui correspond au schéma d'affinité de processeur par défaut, ne fournissant aucune affinité au-delà de ce que le planificateur d'OS fait automatiquement. Définir cette valeur sur static permet aux pods qui se trouvent à la fois dans la classe QoS Guaranteed et qui ont des requêtes de processeur entières de se voir attribuer des processeurs exclusifs.
memoryManager.policy	La valeur doit être None ou Static.	None	Ce paramètre contrôle la règle MemoryManager de 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 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 GKE version 1.32.3-gke.1785000 ou ultérieure.
topologyManager	La valeur doit correspondre à l'un des paramètres acceptés pour chacun des champs respectifs. 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 localisation 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 lorsque celui-ci est à l'état CrashLoopBackOff. Vous pouvez configurer ce paramètre pour les pools de nœuds standards exécutant GKE 1.35 ou une version ultérieure.

Attention : Un délai très court sur un conteneur qui échoue de manière persistante peut entraîner une consommation élevée 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 la réduire uniquement lorsque les avantages de nouvelles tentatives plus rapides l'emportent sur les risques d'une utilisation accrue des ressources.

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

kubelet paramètre de configuration	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 du délai d'intervalle entre les tentatives pour les redémarrages de conteneurs. Le délai entre les redémarrages augmente de manière exponentielle, d'une valeur initiale jusqu'à cette limite maximale. La limite maximale par défaut pour un cluster Kubernetes est de cinq minutes. Pour en savoir plus, consultez Délai de redémarrage du conteneur configurable.

Arrêt progressif des VM Spot dans GKE

Le tableau suivant décrit les options modifiables pour la période d'arrêt 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.

kubelet paramètre de configuration	Restrictions	Paramètre par défaut	Description
shutdownGracePeriodSeconds	La valeur doit être un 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 l'arrêt pour permettre l'arrêt progressif des pods.
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	Spécifie la durée en secondes utilisée pour arrêter les pods critiques lors de l'arrêt 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, tels que la gestion d'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.

kubelet paramètre de configuration	Restrictions	Paramètre par défaut	Description
reservedResourcesConfig.memoryReservedMib	La valeur doit être un nombre entier. Doit être supérieur ou égal à 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érieur à 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 exécutant 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 de kernel 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	Doit être compris entre 104857 et 67108864.	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	Doit être compris entre [1048576, 2147483584].	Ce paramètre définit le nombre maximal de descripteurs de fichiers pouvant être ouverts par un processus.

Paramètres du kernel (kernel.*)

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

Paramètre sysctl	Restrictions	Description
kernel.shmmni	La valeur doit être comprise entre 4096 et 32768.	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, elle est définie par défaut sur 4096.
kernel.shmmax	Doit être compris entre [0, 18446744073692774399].	Ce paramètre définit la taille maximale, en octets, d'un seul segment de mémoire partagée 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	Doit être compris entre [0, 18446744073692774399].	Ce paramètre définit la quantité totale de pages de mémoire partagée pouvant être utilisées simultanément sur le système. Une page correspond à 4 096 octets sur l'architecture AMD64 et Intel 64.
kernel.perf_event_paranoid	La valeur doit être comprise 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 du temps que la planification en temps réel peut utiliser.
kernel.softlockup_panic	Facultatif (booléen).	Ce paramètre détermine si le kernel panique lorsqu'un blocage logiciel est détecté.
kernel.yama.ptrace_scope	Doit être compris entre [0, 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 sont les suivantes : 0 : autorisations ptrace classiques. 1 : ptrace restreint, qui est la valeur par défaut dans de nombreuses distributions. Uniquement 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 appliqué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 ne peuvent pas utiliser dmesg(8) pour afficher les messages du tampon de journal du noyau.
kernel.sysrq	Doit être compris entre 0 et 511.	Ce paramètre contrôle les fonctions pouvant être appelées via 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	La valeur doit être comprise entre 20 000 et 2 097 152.	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 et 1 048 576.	Ce paramètre définit le nombre maximal de clés qu'un utilisateur non racine peut posséder.

Paramètres réseau (net.*)

Le tableau suivant décrit les paramètres modifiables pour la mise en réseau. Ces paramètres permettent d'ajuster 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 à 2 147 483 647.	Ce paramètre définit le délai d'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 active des événements.
net.core.busy_read	Tout entier positif inférieur à 2 147 483 647.	Ce paramètre définit le délai avant expiration de l'interrogation d'activité à faible latence pour les lectures de sockets. Il représente le temps approximatif en µs d'attente de paquets dans la file d'attente de l'appareil.
net.core.netdev_max_backlog	Tout entier positif inférieur à 2 147 483 647.	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 à 2 147 483 647.	Ce paramètre définit la taille par défaut du tampon de socket de réception, en octets.
net.core.rmem_max	Tout entier positif inférieur à 2 147 483 647.	Ce paramètre définit la taille maximale de la mémoire tampon de socket de réception, en octets.
net.core.wmem_default	Tout entier positif inférieur à 2 147 483 647.	Ce paramètre définit le paramètre par défaut, en octets, du tampon d'envoi du socket.
net.core.wmem_max	Tout entier positif inférieur à 2 147 483 647.	Ce paramètre définit la taille maximale de la mémoire tampon de socket d'envoi, en octets.
net.core.optmem_max	Tout entier positif inférieur à 2 147 483 647.	Ce paramètre définit la taille maximale autorisée de la mémoire tampon auxiliaire par socket.
net.core.somaxconn	La valeur doit être comprise entre 128 et 2 147 483 647.	Ce paramètre définit la limite du backlog socket listen(), connu dans l'espace utilisateur sous le nom de SOMAXCONN. Ce paramètre est défini sur 128 par défaut.
net.ipv4.tcp_rmem	{min, default, max} (chaque valeur > 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 en modération. Le paramètre par défaut est "1 page".
net.ipv4.tcp_wmem	{min, default, max} (chaque valeur > 0, mémoire en octets).	Ce paramètre définit la taille minimale, en octets, du tampon d'envoi utilisé par les sockets UDP dans la modération. Le paramètre par défaut est "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	Doit être compris entre [4096, 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 en 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 l'ECN (Explicit Congestion Notification) par TCP. L'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 d'accès de la couche de paquets 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 la valeur MSS initiale 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 GKE 1.34.1-gke.3355001 ou version ultérieure) 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 pour leur attribuer 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 des 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 1.32.0-gke.1448000 ou version 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 1.32.0-gke.1448000 ou version 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 l'opération suivante : nf_conntrack_max = nf_conntrack_buckets * 4. Disponible sur GKE 1.32.0-gke.1448000 ou version 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 1.32.0-gke.1448000 ou version ultérieure.
net.netfilter.nf_conntrack_tcp_timeout_established	Doit être compris entre [600, 86400].	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 1.32.0-gke.1448000 ou version ultérieure.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	La valeur doit être comprise 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 1.32.0-gke.1448000 ou version ultérieure.
net.ipv4.neigh.default.gc_thresh1	La valeur doit être comprise entre 0 et 262144.	Ce paramètre définit le nombre minimal d'entrées à conserver dans le cache ARP. Le récupérateur de mémoire ne s'exécute pas si le nombre d'entrées est inférieur à ce paramètre. Définir cette valeur sur 0 peut entraîner un écrasement 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 récupérateur de mémoire permet au nombre d'entrées de dépasser cette valeur pendant cinq secondes avant de lancer la récupération de mémoire logicielle.
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 récupérateur de mémoire est conçu pour toujours s'exécuter 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 du 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 du disque.

Paramètre sysctl	Restrictions	Description
vm.max_map_count	La valeur doit être comprise entre 65536 et 2147483647.	Ce fichier définit le nombre maximal de zones de mappage de 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 pouvant être rempli de pages modifiées avant que les threads de vidage du noyau en arrière-plan ne commencent l'écriture différée. 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 à laquelle les threads de vidage du noyau en arrière-plan démarrent la réécriture. 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	La valeur doit être comprise entre 0 et 6 000.	Ce paramètre définit l'âge maximal, en centièmes de seconde, pendant lequel les données sales 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 de pages sales avant que les processus qui effectuent des écritures ne soient forcés de bloquer et d'écrire des données sales 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 démarre lui-même la réécriture. 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	La valeur doit être comprise 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 sales sur le disque.
vm.overcommit_memory	Doit être compris entre {0, 1, 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 volumineuses 1 : toujours autoriser (valeur par défaut) 2 : empêche l'allocation au-delà de la mémoire d'échange + le 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	La valeur doit être comprise entre [0, 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	La valeur doit être comprise entre [0, 100].	Ce paramètre ajuste la préférence du noyau pour récupérer la mémoire utilisée pour les caches dentry (répertoire) et inode.
vm.swappiness	La valeur doit être comprise 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 67 584 et 1 048 576.	Ce paramètre définit la mémoire libre minimale avant l'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 flag sysctl donné, tandis que d'autres sont globaux pour l'ensemble du nœud. La mise à jour des options sysctl à l'aide d'une configuration de système de nœuds 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

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 consacrée aux cgroups Kubernetes en v2.

La configuration du système de nœud vous permet de personnaliser la configuration cgroup de vos pools de nœuds. Vous pouvez utiliser cgroupv1 ou cgroupv2. GKE utilise cgroupv2 pour les nouveaux pools de nœuds standard exécutant les versions 1.26 ou ultérieures, et cgroupv1 pour les 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 :

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

Les options cgroupMode acceptées sont les suivantes :

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

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

• Pour un pool de nœuds exécutant une version antérieure à 1.26, vous devez utiliser gcloud CLI 408.0.0 ou une version ultérieure. Vous pouvez également utiliser gcloud beta avec la version 395.0.0 ou une version ultérieure.
• Votre cluster et vos pools de nœuds doivent exécuter GKE version 1.24.2-gke.300 ou ultérieure.
• Vous devez utiliser Container-Optimized OS avec containerd ou Ubuntu avec une image de nœud containerd.
• Si l'une de vos charges de travail dépend de la lecture du système de fichiers cgroup (/sys/fs/cgroup/...), assurez-vous qu'elles sont compatibles avec l'API cgroupv2.
• 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 :

gcloud CLI

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 HugePages sur Linux

Vous pouvez utiliser des pages volumineuses pré-allouées manuellement ou des pages volumineuses 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 accepte les pages "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 pages HugePages, la taille globale des pages HugePages allouées ne peut pas dépasser les 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 pages Huge Pages.
  • 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 pages Huge Pages ne peuvent pas dépasser 25,6 Go.
• Les pages Huge Pages 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 pages volumineuses 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. Sous réserve des 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 pages géantes de 1 Go.

Hugepages transparentes (THP)

Vous pouvez utiliser un fichier de configuration du système de nœud pour activer la compatibilité avec Transparent HugePage du noyau Linux. Avec THP, le noyau attribue automatiquement des pages volumineuses aux processus sans préallocation manuelle.

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

Paramètre de configuration	Valeurs acceptées	Valeur par défaut	Description
transparentHugepageEnabled	TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS : la fonctionnalité Transparent Hugepage est activée à l'échelle du système. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE : les pages volumineuses 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 : la fonctionnalité Transparent Hugepage est désactivée. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED : valeur par défaut. GKE ne modifie pas la configuration du noyau.	UNSPECIFIED	Ce paramètre contrôle si les THP sont activées pour la mémoire anonyme.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS : une application demandant des THP se bloque en cas d'échec d'allocation, et récupère directement les pages et compacte la mémoire afin d'allouer immédiatement une 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 à khugepaged d'installer les pages THP ultérieurement. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE : une application entre en récupération directe et en compactage 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 entre en récupération directe et en compactage 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 en récupération directe ni en compactage. 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. Il est également activé par défaut sur les nouveaux pools de nœuds TPU dans GKE version 1.33.2-gke.4655000 ou ultérieure. Les THP ne sont pas activées 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

Si la synchronisation précise de l'heure et la surveillance de la précision de la 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. La synchronisation précise de l'heure est disponible dans GKE 1.36.0-gke.3241000 et versions ultérieures. 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 l'heure exacte 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
Fichier de configuration : accurateTimeConfig.enablePtpKvmTimeSync Terraform : accurate_time_config.enable_ptp_kvm_time_sync	true ou false	false	Ce paramètre permet une synchronisation précise de l'heure. Cette fonctionnalité n'est compatible qu'avec des types de machines, des systèmes d'exploitation et des zones spécifiques.

Une fois que vous avez activé la synchronisation précise de l'heure, GKE collecte et exporte les informations suivantes :

• La métrique compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy, qui indique la précision de l'horloge de l'hôte de la VM par rapport à l'heure UTC.
• Le journal projects/PROJECT_ID/logs/chrony.tracking, qui contient les journaux de suivi de chrony. Ces journaux fournissent des informations telles que le taux de gain ou de perte de l'horloge système.

Vous pouvez utiliser ces informations pour créer des métriques basées sur les journaux et des tableaux de bord dans Cloud Monitoring afin d'analyser les performances et la fiabilité de la synchronisation de l'heure.

Par exemple, la configuration gke-clock-metric.json suivante définit une métrique basée sur les journaux de l'erreur d'horloge maximale de l'hôte :

{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "resource.type=\"k8s_node\" AND log_id(\"chrony.tracking\")",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": []
  },
  "valueExtractor": "REGEXP_EXTRACT(textPayload, \"^.*PHC0.* ([-\\\\d\\\\.eE]+)$\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 5.0E-7, 1.0E-6, 2.0E-6, 4.0E-6, 5.0E-6, 8.0E-6, 1.0E-5, 2.0E-5,
        1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  }
}

La configuration gke-metrics-dashboard.json suivante définit un tableau de bord Monitoring qui regroupe les données d'erreur de la métrique basée sur les journaux et de la métrique de précision UTC :

{
  "displayName": "Overall Clock Accuracy",
  "dashboardFilters": [],
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "width": 28,
        "height": 28,
        "widget": {
          "xyChart": {
            "dataSets": [
              {
                "plotType": "LINE",
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "prometheusQuery": "(\n  histogram_quantile(1, sum by (le, node_name) (\n    increase(logging_googleapis_com:user_phc_clock_max_error_bucket{monitored_resource=\"k8s_node\"}[1m])\n  )) * 1000000000\n)\n+ on(node_name) group_left()\nlabel_replace(\n  compute_googleapis_com:instance_clock_accuracy_ptp_kvm_nanosecond_accuracy{monitored_resource=\"gce_instance\"},\n  \"node_name\", \"$1\", \"instance_name\", \"(.*)\"\n)\n",
                  "unitOverride": "ns"
                }
              }
            ],
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR"
            },
            "thresholds": [],
            "yAxis": {
              "label": "Clock Accuracy",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}

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 pouvant être épinglée pour un accès direct aux appareils, ce qui est souvent essentiel pour les appareils hautes performances tels que les TPU et les GPU. Ce paramètre correspond au paramètre de kernel 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 GKE 1.36.0-gke.3009000 ou version ultérieure.

Options de configuration du programmeur d'E/S de 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 disque SSD local éphémère qui exécute les charges de travail du système de nœuds. Disponible sur GKE 1.36.0-gke.3009000 ou version ultérieure.
diskIoScheduler.nodeAttachedDiskIoScheduler	mq-deadline, bfq, kyber, none	none	Configure le planificateur d'E/S pour les disques associés. Disponible sur GKE 1.36.0-gke.3009000 ou version ultérieure.

Options de remplacement du noyau Linux

Vous pouvez utiliser un fichier de configuration du système de nœud pour remplacer des paramètres spécifiques du noyau Linux, y compris la ligne de commande du noyau et les paramètres LRU multigénérationnels. Ces paramètres sont compatibles avec les clusters exécutant GKE 1.35.0-gke.1018000 ou version ultérieure.

Options de ligne de commande du noyau Linux

Le tableau suivant décrit les options de ligne de commande du noyau modifiables.

Paramètre de configuration	Valeurs acceptées	Description
specRstackOverflow	SPEC_RSTACK_OVERFLOW_OFF	Modifie la correction du dépassement de la pile de retour spéculatif (SRSO). La seule valeur acceptée est SPEC_RSTACK_OVERFLOW_OFF.
initOnAlloc	INIT_ON_ALLOC_OFF	Modifie le paramètre init_on_alloc dans la ligne de commande du noyau. La seule valeur acceptée est INIT_ON_ALLOC_OFF.

Options de configuration de Multi-Gen LRU

Le tableau suivant décrit les options LRU multigénérationnelles modifiables.

Paramètre de configuration	Valeurs acceptées	Description
enabled	true, false	Active ou désactive le LRU multigénérationnel. Ce paramètre configure le dispositif d'arrêt d'urgence.
minTtlMs	Nombre entier positif	Facultatif. Configure la valeur de prévention du thrashing min_ttl_ms pour le LRU multigénérationnel.

Options de configuration des fichiers de l'OS

Vous pouvez utiliser un fichier de configuration du système de nœud pour ajouter des entrées à des fichiers de configuration d'OS spécifiques sur vos nœuds. Ces paramètres sont compatibles avec les clusters exécutant GKE 1.35.0-gke.1018000 ou version ultérieure.

Entrées /etc/hosts supplémentaires

Ce champ ajoute des entrées de fichier /etc/hosts, comme dans l'exemple suivant :

linuxConfig:
  additionalEtcHosts:
    - ip: 1.2.3.4
      host: myownpersonaldomain.com
    - ip: 5.6.7.8
      host: otherpersonaldomain.com

Entrées /etc/systemd/resolved.conf supplémentaires

Ce champ ajoute /etc/systemd/resolved.conf entrées de fichier. Ce champ accepte un tableau de paires clé-valeur. Les clés suivantes sont acceptées :

• DNS
• FallbackDNS
• Domains
• LLMNR
• MulticastDNS
• DNSSEC
• DNSOverTLS
• Cache
• CacheFromLocalhost
• DNSStubListener
• DNSStubListenerExtra
• ReadEtcHosts
• ResolveUnicastSingleLabel
• StaleRetentionSec

L'exemple suivant ajoute deux valeurs de serveur DNS (8.8.8.8 et 8.8.4.4) à la clé DNS et une valeur de domaine (myownpersonaldomain.com) à la clé Domains :

linuxConfig:
  additionalEtcSystemdResolvedConf:
    - key: DNS
      value:
        - 8.8.8.8
        - 8.8.4.4
    - key: Domains
      value:
        - myownpersonaldomain.com

Entrées /etc/resolv.conf supplémentaires

Ce champ ajoute /etc/resolv.conf entrées de fichier. Ce champ accepte un tableau de paires clé-valeur. Les clés suivantes sont acceptées :

• nameserver
• search
• sortlist
• options

L'exemple suivant ajoute une valeur de serveur DNS (1.1.1.1) à la clé nameserver et une valeur de domaine (myownpersonaldomain.com) à la clé search :

linuxConfig:
  additionalEtcResolvConf:
    - key: nameserver
      value:
        - 1.1.1.1
    - key: search
      value:
        - myownpersonaldomain.com

Configuration du fuseau horaire

Le champ timeZone définit le fuseau horaire sur le nœud, par exemple America/Los_Angeles. Ce paramètre est compatible avec les clusters exécutant GKE 1.35.0-gke.1018000 ou une version ultérieure.

L'exemple suivant définit le champ timeZone sur America/Los_Angeles :

linuxConfig:
  timeZone: America/Los_Angeles

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