Knotensystemkonfiguration anpassen

Standard

In diesem Dokument wird beschrieben, wie Sie die Knotenkonfiguration Ihrer Google Kubernetes Engine (GKE) mithilfe einer Konfigurationsdatei, der sogenannten Knotensystemkonfiguration, anpassen.

Eine Knotensystemkonfiguration ist eine Konfigurationsdatei, mit der Sie eine begrenzte Anzahl von Systemeinstellungen anpassen können. In Ihrem Knotenpool können Sie eine Knotensystemkonfiguration verwenden, um benutzerdefinierte Einstellungen für den Kubernetes-Knoten-Agent kubelet und für Linux-Kernel-Konfigurationen auf niedriger Ebene (sysctl) anzugeben.

Achtung: Wenn Sie die Einstellungen kubelet oder sysctl ändern, kann dies zu unerwünschtem Verhalten führen, was sich negativ auf den Zustand Ihrer Arbeitslasten und Knoten auswirken kann. Testen Sie alle kubelet- oder sysctl-Änderungen gründlich, bevor Sie sie auf Produktionsarbeitslasten bereitstellen.

In diesem Dokument werden die verfügbaren Konfigurationen für eine Knotensystemkonfiguration und die Anwendung auf Ihre GKE Standard-Knotenpools beschrieben. Da GKE Autopilot-Cluster eine stärker verwaltete Knotenumgebung haben, sind die Optionen für die direkte Knotenkonfiguration im Vergleich zu GKE Standard-Knotenpools eingeschränkt.

Vorteile von Knotensystemkonfigurationen

Knotensystemkonfigurationen bieten folgende Vorteile:

• Leistungsoptimierung:Optimieren Sie die Leistung des Netzwerkstacks, die Speicherverwaltung, die CPU-Planung oder das E/A-Verhalten für anspruchsvolle Anwendungen wie KI-Training oder ‑Bereitstellung, Datenbanken, Webserver mit hohem Traffic oder latenzempfindliche Dienste.
• Sicherheitshärtung: Wenden Sie bestimmte Sicherheitseinstellungen auf Kernelebene an oder schränken Sie bestimmte Systemverhaltensweisen ein, um die Angriffsfläche zu verringern.
• Ressourcenverwaltung:Sie können genau festlegen, wie kubelet PIDs, Speicherplatz, die Bereinigung von Image-Müll oder CPU- und Arbeitsspeicherressourcen verwaltet.
• Arbeitslastkompatibilität: Sie können dafür sorgen, dass die Knotenumgebung bestimmte Voraussetzungen für spezialisierte Software oder ältere Anwendungen erfüllt, die bestimmte Kerneleinstellungen erfordern.

Weitere Optionen zum Anpassen von Knotenkonfigurationen

Sie können die Knotenkonfiguration auch mit anderen Methoden anpassen:

• Laufzeitkonfigurationsdatei: Wenn Sie eine containerd-Containerlaufzeit auf Ihren GKE-Knoten anpassen möchten, können Sie eine andere Datei verwenden, die als Laufzeitkonfigurationsdatei bezeichnet wird. Weitere Informationen finden Sie unter containerd-Konfiguration in GKE-Knoten anpassen.
• ComputeClass: Sie können Knotenattribute in der GKE-Spezifikation für ComputeClass angeben. Sie können ComputeClasses sowohl im GKE Autopilot-Modus als auch im Standardmodus in GKE-Version 1.32.1-gke.1729000 und höher verwenden. Weitere Informationen finden Sie unter Knotensystemkonfiguration anpassen.
• DaemonSets: Sie können DaemonSets auch verwenden, um Knoten anzupassen. Weitere Informationen finden Sie unter GKE-Knoten automatisch mit DaemonSets booten.

Knotensystemkonfigurationen werden in Windows Server-Knoten nicht unterstützt.

Hinweis

Bevor Sie beginnen, müssen Sie Folgendes tun:

• Befehlszeilentools installieren:
  • Wenn Sie die gcloud CLI-Beispiele in diesem Dokument verwenden, müssen Sie die Google Cloud CLI installieren und konfigurieren.
  • Wenn Sie die Terraform-Beispiele verwenden, müssen Sie Terraform installieren und konfigurieren.
• Berechtigungen erteilen: Sie benötigen die entsprechenden IAM-Berechtigungen zum Erstellen und Aktualisieren von GKE-Clustern und ‑Knotenpools, z. B. container.clusterAdmin oder eine andere Rolle mit entsprechenden Berechtigungen.
• Mögliche Arbeitslastunterbrechungen einplanen: Benutzerdefinierte Knotenkonfigurationen werden auf Knotenpoolebene angewendet. Änderungen lösen in der Regel ein Rolling Update der Knoten im Pool aus, bei dem die Knoten neu erstellt werden. Planen Sie potenzielle Arbeitslastunterbrechungen ein und verwenden Sie gegebenenfalls Budgets für Pod-Störungen (Pod Disruption Budgets, PDBs).
• Alle Änderungen sichern und testen: Testen Sie Konfigurationsänderungen immer in einer Staging- oder Entwicklungsumgebung, bevor Sie sie in der Produktion anwenden. Falsche Einstellungen können zu Knoteninstabilität oder Arbeitslastfehlern führen.
• GKE-Standardeinstellungen prüfen: GKE-Knoten-Images werden mit optimierten Standardkonfigurationen geliefert. Passen Sie Parameter nur an, wenn Sie einen bestimmten Bedarf haben und die Auswirkungen Ihrer Änderungen verstehen.

Knotensystemkonfiguration hinzufügen

Sie können die Knotensystemkonfiguration entweder mit einer ComputeClass oder einer Konfigurationsdatei anpassen.

ComputeClass für die Knotensystemkonfiguration verwenden

Mit einer benutzerdefinierten ComputeClass können Sie bestimmte Parameter in der kubelet und im Linux-Kernel anpassen. Diese Methode ist in GKE-Version 1.32.1-gke.1729000 und höher verfügbar.

So verwenden Sie eine ComputeClass, um Ihre Knotensystemkonfiguration anzupassen:

1. Erstellen Sie eine ComputeClass, die das Feld-Wert-Paar spec.nodePoolAutoCreation.enabled: true enthält, und geben Sie die Systemkonfigurationen im Feld priorityDefaults an.
2. Stellen Sie eine Arbeitslast bereit, die die ComputeClass auswählt.

ComputeClass erstellen

Schreiben Sie die ComputeClass-Konfiguration in YAML. Verwenden Sie das Feld nodeSystemConfig in der priorityDefaults-Spezifikation, um Systemkonfigurationen für alle Prioritäten festzulegen.

Im folgenden Beispiel für ComputeClass werden die statische CPU-Manager-Richtlinie und benutzerdefinierte Kernel-Parameter konfiguriert:

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

Wenden Sie die ComputeClass an:

kubectl apply -f custom-sysconfig.yaml

Arbeitslast bereitstellen, die die ComputeClass auswählt

Fügen Sie in Ihrer Pod-Spezifikation eine Knotenauswahl für den ComputeClass-Namen hinzu:

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

Wenden Sie die Arbeitslast an:

kubectl apply -f my-app.yaml

Weitere Informationen finden Sie unter Knotensystemkonfiguration anpassen.

Konfigurationsdatei für die Knotensystemkonfiguration verwenden

Wenn Sie eine Konfigurationsdatei für das Knotensystem verwenden, verwenden Sie eine YAML-Datei, die die Konfigurationsparameter für kubelet und den Linux-Kernel enthält. Knotensystemkonfigurationen sind zwar auch im GKE Autopilot-Modus verfügbar, die Schritte in diesem Dokument zeigen jedoch, wie Sie eine Konfigurationsdatei für den GKE Standard-Modus erstellen und verwenden.

So verwenden Sie eine Knotenkonfigurationsdatei im GKE-Standardmodus:

1. Erstellen Sie eine Konfigurationsdatei. Diese Datei enthält Ihre kubelet- und sysctl-Konfigurationen.
2. Fügen Sie die Konfiguration hinzu, wenn Sie einen Cluster erstellen oder einen Knotenpool erstellen oder aktualisieren.

Konfigurationsdatei erstellen

Schreiben Sie die Konfiguration Ihres Knotensystems in YAML. Im folgenden Beispiel werden Konfigurationen für die Optionen kubelet und sysctl hinzugefügt:

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'

In diesem Beispiel gilt Folgendes:

• Mit dem Feld cpuManagerPolicy: static wird die kubelet für die Verwendung der statischen CPU-Verwaltungsrichtlinie konfiguriert.
• Das Feld net.core.somaxconn: '2048' begrenzt den socket listen()-Rückstand auf 2.048 Byte.
• Im Feld net.ipv4.tcp_rmem: '4096 87380 6291456' werden der Mindest-, Standard- und Höchstwert des TCP-Socket-Empfangspuffers auf 4.096 Byte, 87.380 Byte bzw. 6.291.456 Byte festgelegt.

Wenn Sie nur Konfigurationen für kubelet oder sysctl hinzufügen möchten, fügen Sie nur diesen Abschnitt in Ihre Knotensystemkonfiguration ein. Wenn Sie beispielsweise eine kubelet-Konfiguration hinzufügen möchten, erstellen Sie die folgende Datei:

kubeletConfig:
  cpuManagerPolicy: static

Eine vollständige Liste der Felder, die Sie Ihrer Knotensystemkonfiguration hinzufügen können, finden Sie in den Abschnitten Kubelet-Konfigurationsoptionen und Sysctl-Konfigurationsoptionen.

Konfiguration einem Standardknotenpool hinzufügen

Nachdem Sie die Knotensystemkonfiguration erstellt haben, fügen Sie das Flag --system-config-from-file über die Google Cloud CLI hinzu. Sie können dieses Flag hinzufügen, wenn Sie einen Cluster erstellen oder einen Knotenpool erstellen oder aktualisieren. Sie können keine Knotensystemkonfiguration über die Google Cloud Console hinzufügen.

Cluster mit der Knotensystemkonfiguration erstellen

Sie können eine Knotenkonfiguration während der Clustererstellung mit der gcloud CLI oder Terraform hinzufügen. In der folgenden Anleitung wird die Knotensystemkonfiguration auf den Standardknotenpool angewendet:

gcloud-CLI

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

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des Clusters
• LOCATION: die Compute-Zone oder ‑Region des Clusters.
• SYSTEM_CONFIG_PATH: der Pfad zur Datei, die Ihre kubelet- und sysctl-Konfigurationen enthält

Nachdem Sie eine Knotensystemkonfiguration angewendet haben, verwendet der Standardknotenpool des Clusters die von Ihnen definierten Einstellungen.

Terraform

Informationen zum Erstellen eines regionalen Clusters mit einer benutzerdefinierten Knotensystemkonfiguration mit Terraform finden Sie im folgenden Beispiel:

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"
      }
    }
  }
}

Weitere Informationen zur Verwendung von Terraform finden Sie unter Terraform-Unterstützung für GKE.

Neuen Knotenpool mit der Knotensystemkonfiguration erstellen

Sie können eine Knotensystemkonfiguration hinzufügen, wenn Sie mit der gcloud CLI oder Terraform einen neuen Knotenpool erstellen.

In der folgenden Anleitung wird die Knotensystemkonfiguration auf einen neuen Knotenpool angewendet:

gcloud-CLI

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

Ersetzen Sie Folgendes:

• POOL_NAME ist der Name des Knotenpools
• CLUSTER_NAME ist der Name des Clusters, dem Sie einen Knotenpool hinzufügen möchten
• LOCATION: die Compute-Zone oder ‑Region des Clusters.
• SYSTEM_CONFIG_PATH: der Pfad zur Datei, die Ihre kubelet- und sysctl-Konfigurationen enthält

Terraform

Informationen zum Erstellen eines Knotenpools mit einer benutzerdefinierten Knotensystemkonfiguration mithilfe von Terraform finden Sie im folgenden Beispiel:

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"
      }
    }
  }
}

Weitere Informationen zur Verwendung von Terraform finden Sie unter Terraform-Unterstützung für GKE.

Knotensystemkonfiguration für einen vorhandenen Knotenpool aktualisieren

Sie können die Knotensystemkonfiguration für einen vorhandenen Knotenpool festlegen oder aktualisieren. Weitere Informationen zum Aktualisieren einer vorhandenen Konfiguration finden Sie unter Bearbeitung durch Aktualisieren eines vorhandenen Knotenpools.

Führen Sie den folgenden Befehl aus, um den vorhandenen Knotenpool zu aktualisieren:

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

Ersetzen Sie Folgendes:

• POOL_NAME ist der Name des Knotenpools, den Sie aktualisieren möchten
• CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren möchten
• LOCATION: die Compute-Zone oder ‑Region des Clusters.
• SYSTEM_CONFIG_PATH: der Pfad zur Datei, die Ihre kubelet- und sysctl-Konfigurationen enthält

Für diese Änderung müssen die Knoten neu erstellt werden, was zu Unterbrechungen der laufenden Arbeitslasten führen kann. Weitere Informationen zu dieser speziellen Änderung finden Sie in der entsprechenden Zeile in der Tabelle Manuelle Änderungen, bei denen die Knoten mit einer Knotenupgrade-Strategie neu erstellt werden, ohne die Wartungsrichtlinien zu berücksichtigen.

Weitere Informationen zu Knotenupdates finden Sie unter Unterbrechungen bei Knotenupdates planen.

Achtung: GKE beginnt sofort mit der Neuerstellung der Knoten für diese Änderung. Dazu wird die Knoten-Upgradestrategie verwendet, unabhängig von aktiven Wartungsrichtlinien. GKE hängt von der Ressourcenverfügbarkeit für die Änderung ab. Durch das Deaktivieren automatischer Knotenupgrades wird diese Änderung nicht verhindert.

Knotensystemkonfiguration bearbeiten

Sie können eine Knotensystemkonfiguration bearbeiten, je nachdem, ob Sie ComputeClasses oder eine Konfigurationsdatei verwenden.

Für ComputeClasses

Wählen Sie eine der folgenden Methoden aus, um die Knotensystemkonfiguration bei Verwendung von ComputeClasses zu bearbeiten:

Methode 1: Vorhandene ComputeClass aktualisieren

Wenn Sie die nodeSystemConfig in einer vorhandenen ComputeClass aktualisieren, wendet GKE die aktualisierte Konfiguration nur auf neu erstellte Knoten an. Vorhandene Knoten werden nicht automatisch aktualisiert.

Wenn Sie Ihre Arbeitslasten zu Knoten mit der neuen Konfiguration migrieren möchten, haben Sie folgende Möglichkeiten:

• Konfigurieren Sie die aktive Migration in Ihrer Compute-Klasse.
• Wenn Sie eine Hochskalierung neuer Knoten auslösen möchten, starten Sie Ihre Arbeitslasten manuell neu oder erstellen Sie sie neu.

Wenn Sie die ComputeClass aktualisieren möchten, bearbeiten Sie die YAML-Datei und wenden Sie sie an:

kubectl apply -f custom-sysconfig.yaml

Methode 2: Neue ComputeClass erstellen

Damit Ihre Arbeitslasten auf neue Knoten mit der aktualisierten Konfiguration migriert werden, gehen Sie so vor:

1. Erstellen Sie eine neue ComputeClass mit einem anderen Namen und der aktualisierten Konfiguration.
2. Aktualisieren Sie die Knotenauswahl in Ihren Arbeitslastspezifikationen, um auf die neue ComputeClass zu verweisen.
3. Wenden Sie die aktualisierten Arbeitslastspezifikationen an. Der Cluster Autoscaler stellt neue Knoten mit der neuen Konfiguration bereit und skaliert die alten Knoten schließlich herunter.
4. Löschen Sie das alte ComputeClass-Objekt.

Für Konfigurationsdateien

Wenn Sie eine Knotensystemkonfiguration mit einer Konfigurationsdatei bearbeiten möchten, können Sie einen neuen Knotenpool mit der gewünschten Konfiguration erstellen oder die Knotensystemkonfiguration eines vorhandenen Knotenpools aktualisieren.

Durch Erstellen eines Knotenpools bearbeiten

So bearbeiten Sie eine Knotensystemkonfiguration, indem Sie einen Knotenpool erstellen:

1. Erstellen Sie eine Konfigurationsdatei mit der gewünschten Konfiguration.
2. Fügen Sie die Konfiguration einem neuen Knotenpool hinzu.
3. Migrieren Sie Ihre Arbeitslasten zum neuen Knotenpool.
4. Löschen Sie den alten Knotenpool.

Bearbeitung durch Aktualisieren eines vorhandenen Knotenpools

Wenn Sie die vorhandene Knotensystemkonfiguration eines vorhandenen Knotenpools bearbeiten möchten, folgen Sie der Anleitung auf dem Tab Knotenpool aktualisieren, um die Konfiguration einem Knotenpool hinzuzufügen. Wenn Sie eine Knotensystemkonfiguration aktualisieren und die neue Konfiguration die vorhandene Systemkonfiguration des Knotenpools überschreibt, müssen die Knoten neu erstellt werden. Wenn Sie bei einer Aktualisierung Parameter weglassen, werden die Parameter auf die jeweiligen Standardwerte gesetzt.

Vorhandene Knotensystemkonfiguration abrufen

Wenn Sie die vorhandene Knotensystemkonfiguration Ihres Knotenpools abrufen möchten, z. B. wenn Sie die Konfiguration bereits angepasst haben und sie erweitern möchten, verwenden Sie den Befehl gcloud container node-pools describe. In der Ausgabe des Befehls werden alle vorhandenen Konfigurationen unter kubeletConfig und linuxNodeConfig aufgeführt.

Achtung: Wenn Sie die Linux-Knotenkonfiguration anhand dieser Ausgabe aktualisieren, müssen Sie die Parameter im Feld linuxConfig im Aktualisierungsbefehl angeben. Der Befehl describe zeigt diese Einstellungen unter linuxNodeConfig an. Für Aktualisierungen ist jedoch das Feld linuxConfig das richtige. Wenn Sie das Ausgabefeld linuxNodeConfig in einer Aktualisierungsanfrage verwenden, werden die Änderungen nicht übernommen.

Das folgende Snippet zeigt beispielsweise das Ausgabeformat des Befehls 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

Wenn Sie noch keine Knotensystemkonfiguration festgelegt haben, werden in der Ausgabe weder kubeletConfig noch linuxNodeConfig aufgeführt.

Vorhandene Knotensystemkonfiguration zurücksetzen

Wenn Sie die Knotensystemkonfiguration auf die Standardeinstellungen zurücksetzen möchten, aktualisieren Sie die Konfigurationsdatei mit leeren Werten für die Felder kubelet und sysctl, z. B.:

kubeletConfig: {}
linuxConfig:
  sysctl: {}

Knotensystemkonfiguration löschen

Wenn Sie eine Knotensystemkonfiguration entfernen möchten, folgen Sie der Anleitung für ComputeClasses oder für eine Konfigurationsdatei.

Für ComputeClasses

So entfernen Sie die benutzerdefinierte Knotensystemkonfiguration:

1. Entfernen Sie die Knotenauswahl cloud.google.com/compute-class aus den Arbeitslastspezifikationen.
2. Wenden Sie die aktualisierten Arbeitslastspezifikationen an. Die Arbeitslasten werden von GKE auf Standardknoten neu erstellt. Der Cluster Autoscaler skaliert die für die ComputeClass bereitgestellten Knoten schließlich herunter und löscht sie.

3. Löschen Sie das ComputeClass-Objekt aus dem Cluster:

   kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
   

Für Konfigurationsdateien

So entfernen Sie eine Knotensystemkonfiguration, die mit einer Konfigurationsdatei angewendet wurde:

1. Erstellen Sie einen neuen Knotenpool ohne die Konfigurationsdatei.
2. Migrieren Sie Ihre Arbeitslasten zum neuen Knotenpool.
3. Löschen Sie den Knotenpool mit der alten Knotensystemkonfiguration.

Konfigurationsoptionen für kubelet

In den Tabellen in diesem Abschnitt werden die kubelet-Optionen beschrieben, die Sie ändern können.

CPU-Verwaltung

In der folgenden Tabelle werden die CPU-Verwaltungsoptionen für kubelet beschrieben.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
cpuCFSQuota	Muss true oder false sein.	true	Mit dieser Einstellung wird das CPU-Limit des Pods erzwungen. Wenn Sie diesen Wert auf false festlegen, werden die CPU-Limits für Pods ignoriert. Das Ignorieren von CPU-Limits kann in bestimmten Szenarien von Vorteil sein, in denen Pods empfindlich auf CPU-Limits reagieren. Das Risiko beim Deaktivieren von cpuCFSQuota besteht darin, dass ein nicht autorisierter Pod mehr CPU-Ressourcen verbrauchen kann als vorgesehen.
cpuCFSQuotaPeriod	Muss eine Zeitdauer sein.	"100ms"	Mit dieser Einstellung wird der Wert für den CPU-CFS-Kontingentzeitraum (cpu.cfs_period_us) festgelegt. Dieser gibt an, wie oft der Zugriff einer cgroup auf CPU-Ressourcen neu zugewiesen werden soll. Mit dieser Option können Sie das CPU-Drosselungsverhalten anpassen.
reservedSystemCPUs (Vorschau)	Muss eine Liste bestimmter CPU-Kerne sein, die reserviert werden sollen (z. B. 0-1 oder 0,1, um die Kerne 0 und 1 zu reservieren). Da Kerne nullbasiert indexiert werden, müssen die Werte kleiner als die Anzahl der vCPUs für den Maschinentyp sein.	none	Reserviert explizit bestimmte CPU-Kerne für Hostsystemdienste wie Betriebssystem-Daemons und den kubelet-Dienst. Standardmäßig können diese Dienste auf jedem CPU-Kern ausgeführt werden, was bei CPU-sensitiven Arbeitslasten zu Leistungsproblemen führen kann. Mit der Einstellung cpuManagerPolicy: static werden zwar dedizierte Kerne für Guaranteed-Pods mit CPU-Anfragen für Ganzzahlen zugewiesen, aber Hostsystemdienste können diese Kerne trotzdem verwenden. Durch Hinzufügen der Einstellung reservedSystemCPUs werden Hostsystemdienste auf ihre eigenen reservierten Kerne beschränkt. So wird verhindert, dass sie die exklusiven Kerne Ihrer Arbeitslasten unterbrechen. Dazu pinnt GKE beim Start des Knotens automatisch die system.slice-Cgroup an die reservierten Kerne. Durch das Reservieren von System-CPUs wird die insgesamt zuweisbare Kapazität Ihrer Knoten reduziert. Burstable- und BestEffort-Pods können zwar weiterhin auf diesen reservierten Kernen ausgeführt werden, ihre CPU-Anfragen, einschließlich unvollständiger Anfragen von GKE-DaemonSets, werden jedoch weiterhin auf die zuweisbare Kapazität des Knotens angerechnet. Da exklusive Guaranteed-Arbeitslasten ganze Kerne erfordern, reduzieren selbst kleine Bruchteile von Anfragen die Anzahl der verfügbaren exklusiven Kerne. Achten Sie darauf, dass Sie in reservedSystemCPUs genügend CPU-Kerne reservieren. Wenn Sie zu wenige Kerne reservieren, können Hostsystem-Daemons und Betriebssystemprozesse bei hoher Last CPU-beschränkt werden, was zu Instabilität oder verworfenen Netzwerkpaketen führen kann.

Speicherverwaltung und Entfernung

In der folgenden Tabelle werden die änderbaren Optionen für die Speicherverwaltung und das Entfernen von Daten beschrieben. Dieser Abschnitt enthält auch eine separate Tabelle, in der die änderbaren Optionen für das Flag evictionSoft beschrieben werden.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
evictionSoft	Zuordnung von Signalnamen. Informationen zu Wertebeschränkungen finden Sie in der folgenden Tabelle.	none	Mit dieser Einstellung werden Signalnamen einer Menge oder einem Prozentsatz zugeordnet, die die Grenzwerte für den sanften Ausschluss definieren. Für einen Schwellenwert für das vorläufige Entfernen muss es einen Kulanzzeitraum geben. Der kubelet entfernt Pods erst, wenn der Kulanzzeitraum überschritten ist.
evictionSoftGracePeriod	Zuordnung von Signalnamen. Für jeden Signalnamen muss der Wert eine positive Dauer von weniger als 5m sein. Gültige Zeiteinheiten sind ns, us (oder µs), ms, s oder m.	none	Mit dieser Einstellung werden Signalnamen Zeiträumen zugeordnet, die Kulanzzeiträume für Grenzwerte für das vorläufige Entfernen definieren. Für jeden Schwellenwert für die weiche Bereinigung muss ein entsprechender Kulanzzeitraum festgelegt werden.
evictionMinimumReclaim	Zuordnung von Signalnamen. Der Wert für jeden Signalnamen muss ein positiver Prozentsatz kleiner als 10% sein.	none	Mit dieser Einstellung werden Signalnamen Prozentwerten zugeordnet, die den Mindestbetrag einer bestimmten Ressource definieren, die von kubelet zurückgefordert wird, wenn ein Pod-Ausschluss erfolgt.
evictionMaxPodGracePeriodSeconds	Der Wert muss eine Ganzzahl zwischen 0 und 300 sein.	0	Diese Einstellung definiert in Sekunden den maximalen Kulanzzeitraum für die Pod-Beendigung während der Bereinigung.
singleProcessOOMKill	Der Wert muss true oder false sein.	true für cgroupv1-Knoten, false für cgroupv2-Knoten.	Mit dieser Einstellung wird festgelegt, ob die Prozesse im Container einzeln oder als Gruppe beendet werden, wenn der Arbeitsspeicher nicht ausreicht. Verfügbar in den GKE-Versionen 1.32.4-gke.1132000, 1.33.0-gke.1748000 oder höher.

In der folgenden Tabelle sind die änderbaren Optionen für das Flag evictionSoft aufgeführt. Dieselben Optionen gelten auch für die Flags evictionSoftGracePeriod und evictionMinimumReclaim mit unterschiedlichen Einschränkungen.

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
memoryAvailable	Der Wert muss eine Menge sein, die größer als 100Mi und kleiner als 50% des Knotenspeichers ist.	none	Diese Einstellung gibt die Menge an Arbeitsspeicher an, die vor dem Soft Eviction verfügbar ist. Definiert die Menge des memory.available-Signals im kubelet .
nodefsAvailable	Wert muss zwischen 10% und 50% liegen	none	Diese Einstellung gibt den verfügbaren Node-Speicherplatz vor dem Soft Eviction an. Definiert die Menge des nodefs.available-Signals im kubelet .
nodefsInodesFree	Wert muss zwischen 5% und 50% liegen	none	Diese Einstellung stellt die nodefs-Inodes dar, die vor der weichen Bereinigung verfügbar sind. Definiert die Menge des nodefs.inodesFree-Signals im kubelet .
imagefsAvailable	Wert muss zwischen 15% und 50% liegen	none	Diese Einstellung gibt das verfügbare Image-Dateisystem vor dem Soft Eviction an. Definiert die Stärke des imagefs.available-Signals im kubelet .
imagefsInodesFree	Wert muss zwischen 5% und 50% liegen	none	Diese Einstellung stellt die imagefs-Inodes dar, die vor der weichen Bereinigung verfügbar sind. Definiert den Anteil des imagefs.inodesFree-Signals im kubelet.
pidAvailable	Wert muss zwischen 10% und 50% liegen	none	Diese Einstellung stellt die PIDs dar, die vor dem Soft Eviction verfügbar sind. Definiert den Anteil des pid.available-Signals im kubelet.

PID-Verwaltung

In der folgenden Tabelle werden die änderbaren Optionen für die PID-Verwaltung beschrieben.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
podPidsLimit	Wert muss zwischen 1024 und 4194304 liegen	none	Mit dieser Einstellung wird die maximale Anzahl von Prozess-IDs (PIDs) festgelegt, die jeder Pod verwenden kann.

Logging

In der folgenden Tabelle werden die änderbaren Optionen für die Protokollierung beschrieben.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
containerLogMaxSize	Der Wert muss eine positive Zahl und ein Einheitssuffix zwischen 10Mi und 500Mi (einschließlich) sein.	10Mi	Mit dieser Einstellung wird die Einstellung containerLogMaxSize der Richtlinie für den Container-Protokollwechsel gesteuert, mit der Sie die maximale Größe für jede Protokolldatei konfigurieren können. Der Standardwert ist 10Mi. Gültige Einheiten sind Ki, Mi und Gi.
containerLogMaxFiles	Der Wert muss eine Ganzzahl zwischen 2 und 10 (einschließlich) sein.	5	Mit dieser Einstellung wird die Einstellung containerLogMaxFiles der Rotationsrichtlinie für Container-Logdateien gesteuert. Damit können Sie die maximal zulässige Anzahl von Dateien für jeden Container konfigurieren. Der Standardwert ist 5. Die Gesamtgröße der Logs (container_log_max_size*container_log_max_files) pro Container darf 1% des Gesamtspeichers des Knotens nicht überschreiten.

Automatische Speicherbereinigung für Images

In der folgenden Tabelle werden die modifizierbaren Optionen für die automatische Löschung von Bildern beschrieben.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
imageGcHighThresholdPercent	Der Wert muss eine Ganzzahl zwischen 10 und 85 (einschließlich) und größer als imageGcLowThresholdPercent sein.	85	Mit dieser Einstellung wird der Prozentsatz der Laufwerknutzung festgelegt, oberhalb dessen die automatische Speicherbereinigung für Images ausgeführt wird. Sie stellt die höchste Laufwerknutzung dar, bis zu der die automatische Speicherbereinigung durchgeführt wird. Der Prozentsatz wird berechnet, indem der Wert dieses Felds durch 100 geteilt wird.
imageGcLowThresholdPercent	Der Wert muss eine Ganzzahl zwischen 10 und 85 (einschließlich) und kleiner als imageGcHighThresholdPercent sein.	80	Diese Einstellung definiert den Prozentsatz der Laufwerknutzung, unterhalb dessen die automatische Speicherbereinigung von Images nie ausgeführt wird. Er stellt die niedrigste Laufwerknutzung dar, bis zu der die automatische Speicherbereinigung ausgeführt wird. Der Prozentsatz wird berechnet, indem der Wert dieses Felds durch 100 geteilt wird.
imageMinimumGcAge	Der Wert muss eine Zeitdauer sein, die nicht länger als 2m ist. Gültige Zeiteinheiten sind ns, us (oder µs), ms, s, m oder h.	2m	Mit dieser Einstellung wird das Mindestalter für ein ungenutztes Bild festgelegt, bevor es automatisch gelöscht wird.
imageMaximumGcAge	Der Wert muss eine Zeitdauer sein.	0s	Mit dieser Einstellung wird das maximale Alter festgelegt, das ein Bild haben darf, bevor es gelöscht wird. Der Standardwert dieses Felds ist 0s, wodurch es deaktiviert wird. Daher werden Images nicht automatisch bereinigt, weil sie nicht verwendet werden. Wenn dieser Wert angegeben wird, muss er größer als der Wert des Felds imageMinimumGcAge sein. Verfügbar ab GKE-Version 1.30.7-gke.1076000, 1.31.3-gke.1023000 oder höher.

Abrufen von Bildern

In der folgenden Tabelle werden die änderbaren Optionen für das Pullen von Images beschrieben.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
maxParallelImagePulls	Der Wert muss eine Ganzzahl zwischen 2 und 5 (einschließlich) sein.	2 oder 3, je nach Laufwerkstyp.	Mit dieser Einstellung wird die maximale Anzahl paralleler Image-Abrufe definiert. Der Standardwert wird durch den Typ des Bootlaufwerks bestimmt.

Sicherheit und unsichere Vorgänge

In der folgenden Tabelle werden die änderbaren Optionen zum Konfigurieren der Sicherheit und zum Verarbeiten unsicherer Vorgänge beschrieben.

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
allowedUnsafeSysctls	Liste mit sysctl Namen oder Gruppen. Die zulässigen sysctl-Gruppen sind: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	none	Mit dieser Einstellung wird eine kommagetrennte Zulassungsliste mit unsicheren sysctl-Namen oder sysctl-Gruppen definiert, die für die Pods festgelegt werden können.
insecureKubeletReadonlyPortEnabled	Der Wert muss ein boolescher Wert sein, entweder true oder false.	false	Mit dieser Einstellung wird der unsichere kubelet schreibgeschützte Port 10255 für jeden neuen Knotenpool in Ihrem Cluster deaktiviert. Wenn Sie diese Einstellung in dieser Datei konfigurieren, können Sie die Einstellung nicht mit einem GKE API-Client auf Clusterebene ändern.

Ressourcenmanager

Kubernetes bietet eine Reihe von Ressourcenmanagern. Sie können diese ResourceManagers so konfigurieren, dass sie die Ausrichtung von Knotenressourcen für Pods koordinieren und optimieren, die mit bestimmten Anforderungen für CPU-, Geräte- und Arbeitsspeicherressourcen (Huge Pages) konfiguriert sind.

In der folgenden Tabelle werden die änderbaren Optionen für Resource Manager beschrieben.

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
cpuManagerPolicy	Der Wert muss none oder static sein.	none	Mit dieser Einstellung wird die CPU-Manager-Richtlinie von kubelet gesteuert. Der Standardwert ist none. Dies ist das Standard-CPU-Affinitätsschema, das keine Affinität über das hinaus bietet, was der Betriebssystem-Scheduler automatisch tut. Wenn Sie diesen Wert auf static setzen, können Pods, die sich in der QoS-Klasse Guaranteed befinden und ganzzahlige CPU-Anfragen haben, exklusive CPUs zugewiesen werden.
memoryManager.policy	Der Wert muss None oder Static sein.	None	Mit dieser Einstellung wird die Memory Manager-Richtlinie von kubelet gesteuert. Beim Standardwert None verhält sich Kubernetes so, als wäre der Memory Manager nicht vorhanden. Wenn Sie diesen Wert auf Static setzen, sendet die Memory Manager-Richtlinie Topologiehinweise, die vom Pod-Typ abhängen. Weitere Informationen finden Sie unter Statische Richtlinie. Diese Einstellung wird für Cluster unterstützt, deren Steuerungsebene die GKE-Version 1.32.3-gke.1785000 oder höher ausführt.
topologyManager	Der Wert muss eine der unterstützten Einstellungen für die jeweiligen Felder sein. Sie können das Feld topologyManager nicht festlegen, wenn Sie die Terraform-Anleitung verwenden, um die Konfiguration einem Standardknotenpool hinzuzufügen.	policy: none scope: container	Mit diesen Einstellungen wird die kubelet-Konfiguration des Topology Managers über die Unterfelder policy und scope gesteuert. Der Topology Manager koordiniert die Komponenten, die für Leistungsoptimierungen in Bezug auf CPU-Isolation, Arbeitsspeicher und Geräteortung zuständig sind. Sie können die Richtlinien- und Bereichseinstellungen unabhängig voneinander festlegen. Weitere Informationen zu diesen Einstellungen finden Sie unter Topology Manager-Bereiche und ‑Richtlinien. Die folgenden GKE-Ressourcen unterstützen diese Einstellung: Cluster mit der Steuerungsebene, auf der GKE-Version 1.32.3-gke.1785000 oder höher ausgeführt wird. Bei Clustern mit der Steuerungsebene und Knoten, auf denen 1.33.0-gke.1712000 oder höher ausgeführt wird, erhält der Topology Manager auch Informationen zur GPU-Topologie. Knoten mit den folgenden Maschinentypen: A2, A3, A4, C3, C4, C4A, C4N, G2, G4, M3, N4

Verzögerung beim Containerneustart

Mit dieser Einstellung wird die maximale Wartezeit zwischen Container-Neustartversuchen festgelegt, wenn sich ein Container im Status CrashLoopBackOff befindet. Sie können diese Einstellung für Standard-Knotenpools mit GKE-Version 1.35 oder höher konfigurieren.

Achtung: Eine sehr kurze Verzögerung bei einem dauerhaft fehlerhaften Container kann zu einem hohen CPU- und Ressourcenverbrauch auf dem Knoten führen, was sich aufgrund von Ressourcenmangel auf andere Arbeitslasten auswirken kann. Sie sollten den Wert nur dann verringern, wenn die Vorteile schnellerer Wiederholungsversuche die Risiken einer erhöhten Ressourcennutzung überwiegen.

In der folgenden Tabelle werden die änderbaren Optionen für crashLoopBackOff beschrieben.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
crashLoopBackOff.maxContainerRestartPeriod	Der Wert muss eine positive Dauer von maximal 5 Minuten (5m) sein. Gültige Zeiteinheiten sind ns, us (oder µs), ms, s oder m.	none	Die maximale Dauer, die die Backoff-Verzögerung für Containerneustarts erreichen kann. Die Verzögerung zwischen Neustarts erhöht sich exponentiell von einem Anfangswert bis zu diesem Höchstwert. Das standardmäßige maximale Zeitlimit für einen Kubernetes-Cluster beträgt 5 Minuten. Weitere Informationen finden Sie unter Konfigurierbare Verzögerung beim Neustart von Containern.

Ordnungsgemäßes Beenden von Spot-VMs in GKE

In der folgenden Tabelle werden die änderbaren Optionen für die Beendigung und den Zeitraum für das ordnungsgemäße Herunterfahren von Spot-VMs in GKE beschrieben. Damit Sie diese Optionen verwenden können, muss auf der Steuerungsebene Ihres Clusters die GKE-Version 1.35.0-gke.1171000 oder höher ausgeführt werden. Weitere Informationen finden Sie unter Funktionsweise von Spot-VMs in GKE.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
shutdownGracePeriodSeconds	Der Wert muss eine Ganzzahl sein, die die Dauer in Sekunden darstellt. Zulässige Werte sind 0, 30 oder 120.	30	Gibt die Gesamtdauer in Sekunden an, um die der Knoten das Herunterfahren verzögert, damit Pods ordnungsgemäß beendet werden können.
shutdownGracePeriodCriticalPodsSeconds	Der Wert muss eine Ganzzahl zwischen 0 und 120 (einschließlich) und kleiner als shutdownGracePeriodSeconds sein. Nur gültig, wenn shutdownGracePeriodSeconds ebenfalls festgelegt ist.	15	Gibt die Dauer in Sekunden an, die zum Beenden kritischer Pods während des Herunterfahrens eines Knotens verwendet wird.

Reservierungen von Systemressourcen

Vorschau

Dieses Produkt oder Feature unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Für Standardknotenpools, auf denen Linux und GKE 1.37 oder höher ausgeführt wird, können Sie die Menge an Arbeitsspeicher und CPU anpassen, die für Systemkomponenten reserviert ist. So können Sie die zuweisbare Kapazität für bestimmte Szenarien optimieren, z. B. für die Verarbeitung von Image-Abrufen mit hohem Volumen oder für die Ausführung benutzerdefinierter Knoten-DaemonSets. Weitere Informationen zu den Standardreservierungen finden Sie unter GKE-Knotengröße.

In der folgenden Tabelle werden die änderbaren Optionen für Systemressourcenreservierungen beschrieben.

kubelet Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
reservedResourcesConfig.memoryReservedMib	Der Wert muss eine ganze Zahl sein. Muss größer oder gleich der Standard-Speicherreservierung für Knotenpools sein, die mit Version 1.37 oder höher erstellt wurden, und kleiner als 50% der Gesamtspeicherkapazität des Knotens.	Siehe Speicherreservierungen.	Die Menge an Arbeitsspeicher, die für Systemkomponenten reserviert werden soll, in Mebibyte (MiB).
reservedResourcesConfig.cpuReservedMillicore	Der Wert muss eine ganze Zahl sein. Muss mindestens der standardmäßigen CPU-Reservierung für Knotenpools entsprechen, die mit Version 1.37 oder höher erstellt wurden, und weniger als 50% der gesamten CPU-Kapazität des Knotens betragen.	Siehe CPU-Reservierungen.	Die Menge an CPU, die für Systemkomponenten reserviert werden soll, in Millicore.

Effektive Reservierungen prüfen

Prüfen Sie die Ausgabefelder effectiveMemoryReservedMib und effectiveCpuReservedMillicore, um die aktiven Reservierungen für Ihren Knotenpool zu sehen:

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

Sysctl-Konfigurationsoptionen

Zur Optimierung der Leistung Ihres Systems können Sie Linux-Kernel-Parameter ändern. In den Tabellen in diesem Abschnitt werden die verschiedenen Kernelparameter beschrieben, die Sie konfigurieren können.

Dateisystemparameter (fs.*)

In der folgenden Tabelle werden die änderbaren Parameter für das Linux-Dateisystem beschrieben. Mit diesen Einstellungen wird das Verhalten des Linux-Dateisystems gesteuert, z. B. Dateihandle-Limits und Ereignisüberwachung.

Sysctl Parameter	Beschränkungen	Beschreibung
fs.aio-max-nr	Muss zwischen [65536, 4194304] liegen.	Mit dieser Einstellung wird die maximale systemweite Anzahl asynchroner E/A-Anfragen definiert.
fs.file-max	Muss zwischen [104857, 67108864] liegen.	Diese Einstellung definiert die maximale Anzahl von Datei-Handles, die der Linux-Kernel zuweisen kann.
fs.inotify.max_user_instances	Muss zwischen [8192, 1048576] liegen.	Mit dieser Einstellung wird die maximale Anzahl von inotify-Instanzen definiert, die ein Nutzer erstellen kann.
fs.inotify.max_user_watches	Muss zwischen [8192, 1048576] liegen.	Mit dieser Einstellung wird die maximale Anzahl von inotify-Watches definiert, die ein Nutzer erstellen kann.
fs.nr_open	Muss zwischen [1048576, 2147483584] liegen.	Diese Einstellung definiert die maximale Anzahl von Dateideskriptoren, die von einem Prozess geöffnet werden können.

Kernel-Parameter (kernel.*)

In der folgenden Tabelle werden die änderbaren Parameter für den Linux-Kernel beschrieben. Mit diesen Einstellungen werden wichtige Kernel-Funktionen konfiguriert, einschließlich der Zuweisung von gemeinsam genutztem Speicher.

Sysctl-Parameter	Beschränkungen	Beschreibung
kernel.shmmni	Muss zwischen [4096, 32768] liegen.	Diese Einstellung definiert die systemweite maximale Anzahl von gemeinsam genutzten Speichersegmenten. Wenn dieser Wert nicht festgelegt ist, wird standardmäßig 4096 verwendet.
kernel.shmmax	Muss zwischen [0, 18446744073692774399] liegen.	Diese Einstellung definiert die maximale Größe eines einzelnen Shared-Memory-Segments in Byte, das vom Kernel zugelassen wird. Dieser Wert wird ignoriert, wenn er größer als die tatsächliche Menge an RAM ist. Das bedeutet, dass der gesamte verfügbare RAM freigegeben werden kann.
kernel.shmall	Muss zwischen [0, 18446744073692774399] liegen.	Mit dieser Einstellung wird die Gesamtzahl der gemeinsam genutzten Speicherseiten definiert, die gleichzeitig auf dem System verwendet werden können. Eine Seite umfasst 4.096 Byte in der AMD64- und Intel 64-Architektur.
kernel.perf_event_paranoid	Muss zwischen [-1, 3] liegen.	Mit dieser Einstellung wird die Verwendung des Systems für Leistungsereignisse durch nicht privilegierte Nutzer ohne CAP_PERFMON gesteuert. Der Standardwert im Kernel ist 2.
kernel.sched_rt_runtime_us	Muss zwischen [-1, 1000000] liegen.	Mit dieser Einstellung wird ein globales Limit für die Zeit festgelegt, die für die Echtzeitplanung verwendet werden kann.
kernel.softlockup_panic	Optional (boolesch).	Mit dieser Einstellung wird gesteuert, ob der Kernel abstürzt, wenn ein Soft Lockup erkannt wird.
kernel.yama.ptrace_scope	Muss zwischen [0, 3] liegen.	Mit dieser Einstellung werden der Umfang und die Einschränkungen für den Systemaufruf ptrace() definiert, was sich auf das Debugging und Tracing von Prozessen auswirkt. Unterstützte Werte: 0: Klassische ptrace-Berechtigungen. 1: eingeschränktes ptrace, das in vielen Distributionen die Standardeinstellung ist. Nur untergeordnete Prozesse oder CAP_SYS_PTRACE. 2: ptrace nur für Administratoren. Nur Prozesse mit CAP_SYS_PTRACE. 3: Kein ptrace. ptrace-Aufrufe sind nicht zulässig.
kernel.kptr_restrict	Muss zwischen [0, 2] liegen.	Diese Einstellung gibt an, ob die Offenlegung von Kerneladressen über /proc und andere Schnittstellen eingeschränkt wird.
kernel.dmesg_restrict	Optional (boolesch).	Diese Einstellung gibt an, ob Nutzer ohne Berechtigungen daran gehindert werden, mit dmesg(8) Nachrichten aus dem Logpuffer des Kernels aufzurufen.
kernel.sysrq	Muss zwischen 0 und 511 liegen.	Mit dieser Einstellung wird festgelegt, welche Funktionen über die SysRq-Taste aufgerufen werden dürfen. Mögliche Werte: 0: deaktiviert sysrq vollständig. 1: aktiviert alle SysRq-Funktionen. >1: Bitmaske der zulässigen sysrq-Funktionen. Weitere Informationen finden Sie unter Linux Magic System Request Key Hacks.
kernel.keys.maxbytes	Muss zwischen [20000, 2097152] liegen.	Mit dieser Einstellung wird die maximale Anzahl von Byte festgelegt, die ein Nicht-Root-Nutzer im Nutzlastbereich aller seiner Schlüssel speichern kann.
kernel.keys.maxkeys	Muss zwischen [200, 1048576] liegen.	Mit dieser Einstellung wird die maximale Anzahl von Schlüsseln definiert, die ein Nicht-Root-Nutzer besitzen kann.

Netzwerkparameter (net.*)

In der folgenden Tabelle werden die änderbaren Parameter für die Netzwerkfunktionen beschrieben. Mit diesen Einstellungen werden die Leistung und das Verhalten des Netzwerkstacks optimiert, von Socket-Zwischenspeichern bis hin zur Verbindungsverfolgung.

Sysctl-Parameter	Beschränkungen	Beschreibung
net.core.busy_poll	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	Mit dieser Einstellung wird das Zeitlimit für die Abfrage und Auswahl bei hoher Auslastung mit niedriger Latenz definiert. Sie stellt die ungefähre Zeit in µs dar, die für das Warten auf Ereignisse in einer Busy-Loop aufgewendet wird.
net.core.busy_read	Beliebige positive Ganzzahl, kleiner als 2.147.483.647.	Diese Einstellung definiert das Busy-Poll-Zeitlimit für Socket-Lesevorgänge mit niedriger Latenz. Sie stellt die ungefähre Zeit in µs dar, die für das Warten auf Pakete in der Gerätewarteschlange benötigt wird.
net.core.netdev_max_backlog	Beliebige positive Ganzzahl, kleiner als 2.147.483.647.	Mit dieser Einstellung wird die maximale Anzahl von Paketen definiert, die auf der INPUT-Seite in die Warteschlange gestellt werden, wenn die Schnittstelle Pakete schneller empfängt, als der Kernel sie verarbeiten kann.
net.core.rmem_default	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	Diese Einstellung definiert die Standardgröße des Empfangs-Socket-Zwischenspeichers in Byte.
net.core.rmem_max	Beliebige positive Ganzzahl, kleiner als 2.147.483.647.	Diese Einstellung definiert die maximale Größe des Empfangs-Socket-Zwischenspeichers in Byte.
net.core.wmem_default	Beliebige positive Ganzzahl, kleiner als 2147483647.	Diese Einstellung definiert die Standardeinstellung für den Socket-Sende-Puffer in Byte.
net.core.wmem_max	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	Diese Einstellung definiert die maximale Größe des Sendesocket-Puffers in Byte.
net.core.optmem_max	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	Mit dieser Einstellung wird die maximal zulässige Puffergröße für Zusatzdaten pro Socket definiert.
net.core.somaxconn	Muss zwischen [128, 2147483647] liegen.	Mit dieser Einstellung wird das Limit für den socket listen()-Backlog definiert, der im Nutzerbereich als SOMAXCONN bekannt ist. Die Standardeinstellung ist 128.
net.ipv4.tcp_rmem	{min, default, max} (jeweils > 0, Arbeitsspeicher in Byte).	Mit dieser Einstellung wird die Mindestgröße des Empfangspuffers in Byte definiert, der von UDP-Sockets in moderatem Umfang verwendet wird. Die Standardeinstellung ist 1 Seite.
net.ipv4.tcp_wmem	{min, default, max} (jeweils > 0, Arbeitsspeicher in Byte).	Mit dieser Einstellung wird die Mindestgröße des Sendepuffers in Byte definiert, der von UDP-Sockets in der Moderation verwendet wird. Die Standardeinstellung ist 1 Seite.
net.ipv4.tcp_tw_reuse	Muss zwischen 0 und 1 liegen.	Mit dieser Einstellung wird festgelegt, ob Sockets im Status TIME_WAIT für neue Verbindungen wiederverwendet werden dürfen, wenn dies aus Protokollsicht sicher ist. Der Standardwert ist 0.
net.ipv4.tcp_max_orphans	Muss zwischen [16384, 262144] liegen.	Diese Einstellung definiert die maximale Anzahl von TCP-Sockets, die keinem Nutzerdatei-Handle zugeordnet sind.
net.ipv4.tcp_max_tw_buckets	Muss zwischen [4096, 2147483647] liegen.	Diese Einstellung definiert die maximale Anzahl von TIME_WAIT-Sockets, die das System gleichzeitig belegt. Wenn diese Zahl überschritten wird, wird der Socket mit Zeitüberschreitung sofort zerstört und eine Warnung ausgegeben.
net.ipv4.tcp_syn_retries	Muss zwischen [1, 127] liegen.	Diese Einstellung definiert, wie oft die ersten SYN-Pakete für einen aktiven TCP-Verbindungsversuch erneut übertragen werden.
net.ipv4.tcp_ecn	Muss zwischen 0 und 2 liegen.	Mit dieser Einstellung wird die Verwendung von Explicit Congestion Notification (ECN) durch TCP gesteuert. ECN wird nur verwendet, wenn beide Enden der TCP-Verbindung Unterstützung dafür angeben.
net.ipv4.tcp_mtu_probing	Muss zwischen [0, 2] liegen.	Mit dieser Einstellung wird die TCP Packetization-Layer Path MTU Discovery gesteuert. Folgende Werte werden unterstützt: 0: deaktiviert. 1: Standardmäßig deaktiviert, aktiviert, wenn ein ICMP-Blackhole erkannt wird. 2: immer aktiviert. Verwenden Sie die anfängliche MSS von tcp_base_mss.
net.ipv4.tcp_congestion_control	Muss einer der unterstützten Werte aus der Spalte Beschreibung sein.	Diese Einstellung wird nicht unterstützt, wenn GKE Dataplane V2 im Cluster aktiviert ist. Die folgenden unterstützten Werte hängen vom Image-Typ ab: Container-Optimized OS: reno, cubic, bbr, lp, htcp (verfügbar in GKE-Versionen ab 1.34.1-gke.3355001) Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6	Boolescher Wert.	Wenn Sie diesen Wert ändern, entspricht das dem Ändern der Einstellung conf/default/disable_ipv6 und aller disable_ipv6-Einstellungen pro Schnittstelle auf denselben Wert.
net.ipv6.conf.default.disable_ipv6	Boolescher Wert.	Durch diese Einstellung wird die Verwendung von IPv6 deaktiviert.
net.netfilter.nf_conntrack_acct	Muss zwischen {0, 1} liegen.	Mit dieser Einstellung wird die Abrechnung des Verbindungs-Tracking-Ablaufs aktiviert. Der Standardwert ist 0. Das bedeutet, dass die Einstellung deaktiviert ist. Verfügbar in GKE-Versionen 1.32.0-gke.1448000 oder höher.
net.netfilter.nf_conntrack_max	Muss zwischen [65536, 4194304] liegen.	Diese Einstellung definiert die Größe der Tabelle für das Verbindungs-Tracking. Wenn der Höchstwert erreicht ist, schlägt die neue Verbindung fehl. Verfügbar ab GKE-Version 1.32.0-gke.1448000.
net.netfilter.nf_conntrack_buckets	Muss zwischen [65536, 524288] liegen.	Diese Einstellung definiert die Größe der Hash-Tabelle. Die empfohlene Einstellung ist das Ergebnis von Folgendem: nf_conntrack_max = nf_conntrack_buckets * 4. Verfügbar ab GKE-Version 1.32.0-gke.1448000.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Muss zwischen [60, 3600] liegen.	Mit dieser Einstellung wird der Zeitraum in Sekunden definiert, für den die TCP-Verbindungen im Status CLOSE_WAIT verbleiben können. Der Standardwert ist 3600. Verfügbar in GKE-Versionen 1.32.0-gke.1448000 oder höher.
net.netfilter.nf_conntrack_tcp_timeout_established	Muss zwischen [600, 86400] liegen.	Mit dieser Einstellung wird die Dauer in Sekunden für inaktive Verbindungen festgelegt, bevor sie automatisch aus der Tabelle für das Verbindungstracking gelöscht werden. Verfügbar ab GKE-Version 1.32.0-gke.1448000.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	Muss zwischen 1 und 600 liegen.	Mit dieser Einstellung wird der Zeitraum in Sekunden definiert, für den die TCP-Verbindungen im Status TIME_WAIT verbleiben können. Der Standardwert ist 120. Verfügbar ab GKE-Version 1.32.0-gke.1448000.
net.ipv4.neigh.default.gc_thresh1	Muss zwischen [0, 262144] liegen.	Diese Einstellung definiert die Mindestanzahl von Einträgen, die im ARP-Cache aufbewahrt werden sollen. Der Garbage Collector wird nicht ausgeführt, wenn die Anzahl der Einträge unter dieser Einstellung liegt. Wenn Sie diesen Wert auf 0 setzen, kann dies zu Cache-Thrashing und Leistungseinbußen führen.
net.ipv4.neigh.default.gc_thresh2	Muss zwischen [512, 524288] liegen.	Diese Einstellung definiert die maximale Anzahl von Einträgen, die im ARP-Cache aufbewahrt werden sollen. Die automatische Speicherbereinigung lässt zu, dass die Anzahl der Einträge diesen Wert für 5 Sekunden überschreitet, bevor die einfache automatische Speicherbereinigung gestartet wird.
net.ipv4.neigh.default.gc_thresh3	Muss zwischen [1024, 1048576] liegen.	Diese Einstellung definiert die maximale Anzahl von Einträgen, die im ARP-Cache gespeichert werden. Der Garbage Collector wird immer ausgeführt, wenn die Anzahl der Einträge diese Einstellung überschreitet.

Parameter für den virtuellen Arbeitsspeicher (vm.*)

In der folgenden Tabelle werden die änderbaren Parameter für das Subsystem „Virtueller Speicher“ beschrieben. Mit diesen Einstellungen wird das Subsystem für virtuellen Speicher verwaltet, das steuert, wie der Kernel Arbeitsspeicher, Swapping und Festplatten-Caching verarbeitet.

sysctl Parameter	Beschränkungen	Beschreibung
vm.max_map_count	Muss zwischen [65536, 2147483647] liegen.	In dieser Datei wird die maximale Anzahl von Memory-Map-Bereichen definiert, die ein Prozess haben kann.
vm.dirty_background_ratio	Muss zwischen 1 und 100 liegen.	Diese Einstellung definiert den Prozentsatz des Systemspeichers, der mit Dirty Pages gefüllt werden kann, bevor die Kernel-Flusher-Threads im Hintergrund mit dem Zurückschreiben beginnen. Der Wert muss kleiner als der Wert des Felds vm.dirty_ratio sein.
vm.dirty_background_bytes	Muss zwischen [0, 68719476736] liegen.	Diese Einstellung definiert die Menge an Dirty Memory, bei der die Hintergrund-Kernel-Flusher-Threads mit dem Zurückschreiben beginnen. vm.dirty_background_bytes ist das Gegenstück zu vm.dirty_background_ratio. Es kann nur eine dieser Einstellungen angegeben werden.
vm.dirty_expire_centisecs	Muss zwischen [0, 6000] liegen.	Mit dieser Einstellung wird das maximale Alter in Hundertstelsekunden festgelegt, das schmutzige Daten im Arbeitsspeicher haben können, bevor Kernel-Flusher-Threads sie auf die Festplatte schreiben.
vm.dirty_ratio	Muss zwischen 1 und 100 liegen.	Mit dieser Einstellung wird der Prozentsatz des Systemspeichers definiert, der mit „dirty pages“ gefüllt werden kann, bevor Prozesse, die Schreibvorgänge ausführen, zum Blockieren und synchronen Schreiben von „dirty data“ gezwungen werden.
vm.dirty_bytes	Muss zwischen [0, 68719476736] liegen.	Diese Einstellung definiert die Menge an Dirty Memory, bei der ein Prozess, der Laufwerksschreibvorgänge generiert, selbst mit dem Zurückschreiben beginnt. Der zulässige Mindestwert für vm.dirty_bytes beträgt zwei Seiten in Byte. Alle Werte, die unter diesem Limit liegen, werden ignoriert und die alte Konfiguration wird beibehalten. vm.dirty_bytes ist das Gegenstück zu vm.dirty_ratio. Es kann nur eine dieser Einstellungen angegeben werden.
vm.dirty_writeback_centisecs	Muss zwischen [0, 1000] liegen.	Diese Einstellung definiert das Intervall in Hundertstelsekunden, in dem Kernel-Flusher-Threads aktiviert werden, um alte schmutzige Daten auf das Laufwerk zu schreiben.
vm.overcommit_memory	Muss zwischen {0, 1, 2} liegen.	Mit dieser Einstellung wird die Strategie des Kernels für den Umgang mit einer Überbelegung des Arbeitsspeichers festgelegt. Die Werte sind: 0: Große Zuweisungen ablehnen 1: immer zulassen (Standardwert) 2: Commit über Swap + RAM-Verhältnis verhindern Diese Einstellung wird auf Maschinen mit weniger als 15 GB Arbeitsspeicher nicht unterstützt.
vm.overcommit_ratio	Muss zwischen [0, 100] liegen.	Mit dieser Einstellung wird der Prozentsatz des physischen RAM definiert, der für Overcommit zulässig ist, wenn der Wert des Felds vm.overcommit_memory auf 2 festgelegt ist.
vm.vfs_cache_pressure	Muss zwischen [0, 100] liegen.	Mit dieser Einstellung wird die Präferenz des Kernels für das Freigeben von Arbeitsspeicher angepasst, der für Dentry- (Verzeichnis-) und Inode-Caches verwendet wird.
vm.swappiness	Muss zwischen [0, 200] liegen.	Diese Einstellung steuert die Tendenz des Kernels, Prozesse aus dem physischen Speicher auf das Auslagerungslaufwerk zu verschieben. Der Standardwert ist 60.
vm.watermark_scale_factor	Muss zwischen [10, 3000] liegen.	Mit dieser Einstellung wird die Aggressivität von kswapd gesteuert. Er definiert den verbleibenden Speicher, bevor kswapd aktiviert wird, und den Speicher, der freigegeben werden muss, bevor kswapd in den Ruhemodus wechselt. Der Standardwert ist 10.
vm.min_free_kbytes	Muss zwischen [67584, 1048576] liegen.	Diese Einstellung definiert den minimalen verfügbaren Speicher vor OOM. Der Standardwert ist 67584.

Weitere Informationen zu den unterstützten Werten für die einzelnen sysctl-Flags finden Sie in der gcloud CLI-Dokumentation zu --system-config-from-file.

Unterschiedliche Linux-Namespaces können eindeutige Werte für ein bestimmtes sysctl-Flag haben, während andere global für den gesamten Knoten gelten. Durch das Aktualisieren der sysctl-Optionen mithilfe einer Knotensystemkonfiguration wird sichergestellt, dass sysctl global auf den Knoten und in jedem Namespace angewendet wird. Dadurch hat jeder Pod identische sysctl-Werte in jedem Linux-Namespace.

Konfigurationsoptionen für den Linux-cgroup-Modus

Achtung: cgroupv1 wird in GKE mit der Nebenversion 1.31 eingestellt und für cgroupv1 ab Version 1.35 nicht mehr unterstützt. Weitere Informationen zur Umstellung von GKE auf cgroupv2 und zur Vorbereitung Ihrer Cluster auf diese Umstellung finden Sie unter Knoten zu Linux cgroup v2 migrieren.

Die Containerlaufzeit und kubelet verwenden Linux-Kernel-cgroups für die Ressourcenverwaltung, z. B. wie viel CPU oder Arbeitsspeicher auf jeden Container in einem Pod zugreifen kann. Es gibt zwei Versionen des cgroup-Subsystems im Kernel: cgroupv1 und cgroupv2. Die Kubernetes-Unterstützung für cgroupv2 wurde in Kubernetes-Version 1.18 als Alphaversion, in Version 1.22 als Betaversion und in Version 1.25 als allgemein verfügbar eingeführt. Weitere Informationen finden Sie in der Dokumentation zu Kubernetes cgroups v2.

Mit der Knotensystemkonfiguration können Sie die cgroup-Konfiguration Ihrer Knotenpools anpassen. Sie können cgroupv1 oder cgroupv2 verwenden. In GKE wird cgroupv2 für neue Standardknotenpools mit Version 1.26 und höher und cgroupv1 für Knotenpools mit Versionen vor 1.26 verwendet. Bei Knotenpools, die mit der automatischen Knotenbereitstellung erstellt wurden, hängt die cgroup-Konfiguration von der ursprünglichen Clusterversion ab, nicht von der Knotenpoolversion. cgroupv1 wird auf Arm-Maschinen nicht unterstützt.

Mit der Knotensystemkonfiguration können Sie die Einstellung für einen Knotenpool so ändern, dass cgroupv1 oder cgroupv2 explizit verwendet wird. Durch das Upgrade eines vorhandenen Knotenpools, der cgroupv1 verwendet, auf Version 1.26 wird die Einstellung nicht in cgroupv2 geändert. Vorhandene Knotenpools, die eine frühere Version als 1.26 ausführen und keine benutzerdefinierte cgroup-Konfiguration enthalten, verwenden weiterhin cgroupv1. Wenn Sie die Einstellung ändern möchten, müssen Sie cgroupv2 explizit für den vorhandenen Knotenpool angeben.

Wenn Sie Ihren Knotenpool beispielsweise für die Verwendung von cgroupv2 konfigurieren möchten, verwenden Sie eine Knotensystemkonfigurationsdatei wie diese:

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

Die unterstützten cgroupMode-Optionen sind:

• CGROUP_MODE_V1: cgroupv1 für den Knotenpool verwenden.
• CGROUP_MODE_V2: cgroupv2 für den Knotenpool verwenden.
• CGROUP_MODE_UNSPECIFIED: Verwende die standardmäßige GKE-cgroup-Konfiguration.

Für die Verwendung von cgroupv2 gelten die folgenden Anforderungen und Einschränkungen:

• Für einen Knotenpool, auf dem eine Version vor 1.26 ausgeführt wird, müssen Sie die gcloud CLI-Version 408.0.0 oder höher verwenden. Alternativ können Sie gcloud beta mit Version 395.0.0 oder höher verwenden.
• Ihre Cluster und Ihre Knotenpools müssen die GKE-Version 1.24.2-gke.300 oder höher ausführen.
• Sie müssen entweder das Container-Optimized OS mit containerd oder das Ubuntu mit containerd-Knoten-Image verwenden.
• Wenn eine Ihrer Arbeitslasten vom Lesen des cgroup-Dateisystems (/sys/fs/cgroup/...) abhängt, sorgen Sie dafür, dass sie mit der cgroupv2 API kompatibel sind.
• Wenn Sie Monitoring-Tools oder Drittanbieter-Tools verwenden, prüfen Sie, ob diese mit cgroupv2 kompatibel sind.
• Wenn Sie Java-Arbeitslasten (JDK) nutzen, empfehlen wir Ihnen, Versionen zu verwenden, die cgroupv2 vollständig unterstützen, einschließlich JDK 8u372, JDK 11.0.16 oder höher oder JDK 15 oder höher.

Cgroup-Konfiguration prüfen

Wenn Sie eine Knotensystemkonfiguration hinzufügen, müssen die Knoten in GKE neu erstellt werden, um die Änderungen zu implementieren. Nachdem Sie die Konfiguration einem Knotenpool hinzugefügt und die Knoten neu erstellt haben, können Sie die neue Konfiguration überprüfen.

Sie können die cgroup-Konfiguration für Knoten in einem Knotenpool mit der gcloud CLI oder dem kubectl-Befehlszeilentool prüfen:

gcloud-CLI

Prüfen Sie die cgroup-Konfiguration für einen Knotenpool:

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

Ersetzen Sie dabei POOL_NAME durch den Namen Ihres Knotenpools.

Die mögliche Ausgabe ist eine der folgenden:

• EFFECTIVE_CGROUP_MODE_V1: Die Knoten verwenden cgroupv1.
• EFFECTIVE_CGROUP_MODE_V2: Die Knoten verwenden cgroupv2.

Die Ausgabe zeigt erst dann die neue cgroup-Konfiguration an, wenn die Knoten im Knotenpool neu erstellt wurden. Die Ausgabe ist für Windows Server-Knotenpools leer, die cgroup nicht unterstützen.

kubectl

Wenn Sie die cgroup-Konfiguration für Knoten in diesem Knotenpool mit kubectl prüfen möchten, wählen Sie einen Knoten aus und stellen Sie so eine Verbindung zu ihm her:

1. Erstellen Sie eine interaktive Shell mit einem beliebigen Knoten im Knotenpool. Ersetzen Sie im Befehl mynode durch den Namen eines beliebigen Knotens im Knotenpool.
2. Cgroup-Version auf Linux-Knoten ermitteln.

Konfigurationsoptionen für Linux-Huge-Pages

Sie können manuell vorab zugewiesene Hugepages oder automatisch zugewiesene transparente Hugepages verwenden.

Vorab zugewiesene Hugepages

Sie können eine Knotensystem-Konfigurationsdatei verwenden, um Huge Pages vorab zuzuweisen. Kubernetes unterstützt vorab zugewiesene Hugepages als Ressourcentyp, ähnlich wie CPU oder Arbeitsspeicher.

Für die Verwendung von Huge Pages gelten die folgenden Einschränkungen und Anforderungen:

• Damit der Knoten nicht vollständig von Huge Pages belegt wird, darf die Gesamtgröße der zugewiesenen Huge Pages nicht mehr als einer der folgenden Werte betragen:
  • Auf Maschinen mit weniger als 30 GB Arbeitsspeicher: 60% des gesamten Arbeitsspeichers. Bei einem e2-standard-2-Rechner mit 8 GB Arbeitsspeicher können Sie beispielsweise nicht mehr als 4,8 GB für Huge Pages zuweisen.
  • Auf Maschinen mit mehr als 30 GB Arbeitsspeicher: 80% des gesamten Arbeitsspeichers. Auf c4a-standard-8-Maschinen mit 32 GB Arbeitsspeicher dürfen Huge Pages beispielsweise nicht größer als 25,6 GB sein.
• Große Seiten mit 1 GB sind nur auf den Maschinentypen A3, C2D, C3, C3D, C4, C4A, C4D, C4N, CT5E, CT5LP, CT6E, H3, M2, M3, M4, Z3 oder Z4D verfügbar.

In der folgenden Tabelle werden die änderbaren Einstellungen für Linux-Hugepages beschrieben.

Config-Parameter	Beschränkungen	Standardwert	Beschreibung
hugepage_size2m	Ganzzahl. Unterliegt den zuvor beschriebenen Limits für die Arbeitsspeicherzuweisung.	0	Mit dieser Einstellung wird eine bestimmte Anzahl von 2 MB-Hugepages vorab zugewiesen.
hugepage_size1g	Ganzzahl. Unterliegt den zuvor beschriebenen Einschränkungen für Arbeitsspeicher und Maschinentyp.	0	Mit dieser Einstellung wird eine bestimmte Anzahl von 1-GB-Hugepages vorab zugewiesen.

Transparent Huge Pages (THP)

Sie können eine Knotensystemkonfigurationsdatei verwenden, um die Unterstützung für transparente Huge Pages des Linux-Kernels zu aktivieren. Mit THP weist der Kernel Prozessen automatisch Huge Pages zu, ohne dass eine manuelle Vorabzuweisung erforderlich ist.

In der folgenden Tabelle werden die änderbaren Parameter für THP beschrieben.

Konfigurationsparameter	Unterstützte Werte	Standardwert	Beschreibung
transparentHugepageEnabled	TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: Transparent Hugepage ist systemweit aktiviert. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: Transparent Hugepage ist in MADV_HUGEPAGE-Regionen aktiviert. Das ist die Standardkonfiguration des Kernels. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: Transparent Hugepage ist deaktiviert. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: Der Standardwert. Die Kernelkonfiguration wird von GKE nicht geändert.	UNSPECIFIED	Mit dieser Einstellung wird festgelegt, ob THP für anonymen Speicher aktiviert ist.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: Eine Anwendung, die bei einem Zuteilungsfehler THP anfordert, gibt Seiten direkt zurück und komprimiert den Arbeitsspeicher, um sofort eine THP zuzuteilen. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: Eine Anwendung weckt kswapd im Hintergrund, um Seiten zurückzufordern, und weckt kcompactd, um den Speicher zu komprimieren, damit THP in naher Zukunft verfügbar ist. Es liegt in der Verantwortung von khugepaged, die THP-Seiten später zu installieren. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: Eine Anwendung wechselt wie gewohnt in die direkte Rückgewinnung und Komprimierung, aber nur für Regionen, die madvise(MADV_HUGEPAGE) verwendet haben. In allen anderen Regionen wird kswapd im Hintergrund aktiviert, um Seiten freizugeben, und kcompactd, um den Speicher zu komprimieren, damit THP in naher Zukunft verfügbar ist. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: Eine Anwendung wechselt wie gewohnt in die direkte Freigabe und Komprimierung, aber nur für Regionen, die madvise(MADV_HUGEPAGE) verwendet haben. In allen anderen Regionen wird „kswapd“ im Hintergrund aktiviert, um Seiten freizugeben, und „kcompactd“, um den Speicher zu komprimieren, damit THP in naher Zukunft verfügbar ist. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: Eine Anwendung wird nie direkt freigegeben oder komprimiert. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: Der Standardwert. GKE ändert die Kernelkonfiguration nicht.	UNSPECIFIED	Mit dieser Einstellung wird die Defragmentierungskonfiguration für THP definiert.

THP ist in GKE-Version 1.33.2-gke.4655000 oder höher verfügbar. In der GKE-Version 1.33.2-gke.4655000 oder höher ist sie auch standardmäßig für neue TPU-Knotenpools aktiviert. THP wird nicht aktiviert, wenn Sie vorhandene Knotenpools auf eine unterstützte Version oder höher aktualisieren.

Option für die genaue Zeitsynchronisierung unter Linux

Wenn eine genaue Zeitsynchronisierung und die Überwachung der Genauigkeit Ihrer Zeitsynchronisierung für Ihre Arbeitslasten wichtig sind, können Sie genaue Zeit konfigurieren, um die Uhr Ihrer VM mit der Hostuhr über chrony und ptp_kvm zu synchronisieren. Die genaue Zeitsynchronisierung ist in GKE-Version 1.36.0-gke.3241000 und höher verfügbar. Diese Konfiguration ist so konzipiert, dass bei unterstützten Setups eine Genauigkeit von 1 ms erreicht wird. Weitere Informationen zu unterstützten Maschinentypen, unterstützten Betriebssystemen und unterstützten Zonen finden Sie unter Genaue Zeit für Compute Engine-VMs konfigurieren.

In der folgenden Tabelle wird der Parameter beschrieben, mit dem Sie die genaue Zeitsynchronisierung mit GKE konfigurieren können:

Config-Parameter	Unterstützte Werte	Standardwert	Beschreibung
Konfigurationsdatei: accurateTimeConfig.enablePtpKvmTimeSync Terraform: accurate_time_config.enable_ptp_kvm_time_sync	true oder false	false	Diese Einstellung ermöglicht eine genaue Zeitsynchronisierung. Diese Funktion wird nur für bestimmte Maschinentypen, Betriebssysteme und Zonen unterstützt.

Nachdem Sie die genaue Zeitsynchronisierung aktiviert haben, erhebt und exportiert GKE die folgenden Informationen:

• Der Messwert compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy gibt die Genauigkeit der VM-Hostuhr im Vergleich zu UTC an.
• Das projects/PROJECT_ID/logs/chrony.tracking-Log, das die Tracking-Logs von chrony enthält. Diese Logs enthalten Informationen wie die Abweichungsrate der Systemuhr.

Anhand dieser Informationen können Sie in Cloud Monitoring logbasierte Messwerte und Dashboards erstellen, um die Leistung und Zuverlässigkeit der Zeitsynchronisierung zu analysieren.

Die folgende gke-clock-metric.json-Konfiguration definiert beispielsweise eine logbasierte Messwert für den maximalen Host-Taktfehler:

{
  "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
      ]
    }
  }
}

Die folgende gke-metrics-dashboard.json-Konfiguration definiert ein Monitoring-Dashboard, in dem die Fehlerdaten aus dem logbasierten Messwert und dem UTC-Genauigkeitsmesswert zusammengefasst werden:

{
  "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"
            }
          }
        }
      }
    ]
  }
}

Linux-VFIO-Konfigurationsoptionen

In der folgenden Tabelle wird der Parameter zum Konfigurieren von VFIO (Virtual Function I/O) auf einem Knoten beschrieben. VFIO ermöglicht sicheren, nicht privilegierten Userspace-Treibern den Zugriff auf E/A-Geräte.

Konfigurationsparameter	Beschränkungen	Standardwert	Beschreibung
nodeVfioConfig.dmaEntryLimit	Muss eine Ganzzahl zwischen 65535 und 4194304 sein.	65535	Gibt die maximale Anzahl von DMA-Einträgen (Seiten) an, die vom VFIO-IOMMU-Typ-1-Treiber für einen Container zugeordnet werden können. Dieses Limit wirkt sich auf die Gesamtmenge des Hostspeichers aus, die für den direkten Gerätezugriff angepinnt werden kann. Dies ist oft entscheidend für Hochleistungsgeräte wie TPUs und GPUs. Diese Einstellung entspricht dem folgenden Kernel-Parameter: /sys/module/vfio_iommu_type1/parameters/dma_entry_limit. Für Arbeitslasten, die große Speicherbereiche zuordnen, sind möglicherweise höhere Werte erforderlich. Verfügbar in GKE-Versionen 1.36.0-gke.3009000 oder höher.

Konfigurationsoptionen für den Linux-Laufwerk-E/A-Planer

In der folgenden Tabelle werden die Parameter zum Konfigurieren des Festplatten-I/O-Schedulers für Knotenpools beschrieben.

Konfigurationsparameter	Unterstützte Werte	Standardwert	Beschreibung
diskIoScheduler.nodeSystemIoScheduler	mq-deadline, bfq, kyber, none	bfq für Container-Optimized OS-Image, none für Ubuntu-Image	Konfiguriert den E/A-Planer für das Bootlaufwerk oder die sitzungsspezifische lokale SSD, auf der Knotensystemarbeitslasten ausgeführt werden. Verfügbar in GKE-Versionen 1.36.0-gke.3009000 oder höher.
diskIoScheduler.nodeAttachedDiskIoScheduler	mq-deadline, bfq, kyber, none	none	Konfiguriert den I/O-Scheduler für die angehängten Laufwerke. Verfügbar in GKE-Versionen 1.36.0-gke.3009000 oder höher.

Nächste Schritte

• Knoten zu Linux cgroupv2 migrieren
• Knotenpools hinzufügen und verwalten
• containerd-Konfiguration in GKE-Knoten anpassen
• GKE-Knoten automatisch mit DaemonSets booten