Knotensystemkonfiguration anpassen

Standard

In diesem Dokument erfahren Sie, wie Sie Ihre GKE-Knotenkonfiguration (Google Kubernetes Engine) mithilfe einer Konfigurationsdatei anpassen, die als Knotensystemkonfiguration bezeichnet wird.

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-Agenten 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 beschrieben und es wird erläutert, wie Sie sie auf Ihre GKE Standard-Knotenpools anwenden. 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 Arbeitsspeicherverwaltung, 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 Systemverhalten ein, um die Angriffsfläche zu verringern.
• Ressourcenverwaltung:Hier können Sie genau festlegen, wie kubelet PIDs, Speicherplatz, die Bereinigung von Image-Restmüll oder CPU- und Arbeitsspeicherressourcen verwaltet.
• Kompatibilität von Arbeitslasten:Damit wird sichergestellt, dass die Knotenumgebung bestimmte Voraussetzungen für spezielle 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 die 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 auch DaemonSets verwenden, um Knoten anzupassen. Weitere Informationen finden Sie unter Automatisches Bootstrapping von GKE-Knoten mit DaemonSets.

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

Hinweise

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 Unterbrechungen von Arbeitslasten 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 Produktionsumgebung anwenden. Falsche Einstellungen können zu Knoteninstabilität oder Arbeitslastfehlern führen.
• GKE-Standardeinstellungen prüfen:GKE-Knoten-Images enthalten optimierte Standardkonfigurationen. Passen Sie Parameter nur an, wenn Sie einen bestimmten Bedarf haben und sich der Auswirkungen Ihrer Änderungen bewusst sind.

Knotensystemkonfiguration im GKE-Standardmodus verwenden

Wenn Sie eine Knotensystemkonfiguration verwenden, nutzen Sie eine YAML-Datei, die die Konfigurationsparameter für kubelet und den Linux-Kernel enthält. Knotensystemkonfigurationen sind auch im GKE-Autopilot-Modus verfügbar. In diesem Dokument wird jedoch beschrieben, wie Sie eine Konfigurationsdatei für den GKE-Standardmodus erstellen und verwenden.

So verwenden Sie eine Knotensystemkonfiguration im GKE Standard-Modus:

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

Konfigurationsdatei erstellen

Schreiben Sie die Konfiguration des 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 kubelet so konfiguriert, dass die statische CPU-Verwaltungsrichtlinie verwendet wird. + Das Feld net.core.somaxconn: '2048' begrenzt den Rückstand socket listen() auf 2.048 Byte.
• Das Feld net.ipv4.tcp_rmem: '4096 87380 6291456' legt den Mindest-, Standard- und Höchstwert für den TCP-Socket-Empfang-Zwischenspeicher auf 4.096 Byte, 87.380 Byte bzw. 6.291.456 Byte fest.

Wenn Sie Konfigurationen nur für kubelet oder sysctl hinzufügen möchten, fügen Sie nur diesen Abschnitt in die Konfiguration Ihres Knotensystems 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 der Konfiguration Ihres Knotensystems hinzufügen können, finden Sie in den Abschnitten Kubelet-Konfigurationsoptionen und Sysctl-Konfigurationsoptionen.

Konfiguration einem Standard-Knotenpool hinzufügen

Nachdem Sie die Knotenkonfiguration 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. Mit der Google Cloud Console können Sie keine Knotensystemkonfiguration 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 Knotenkonfiguration hinzufügen, wenn Sie einen neuen Knotenpool mit der gcloud CLI oder Terraform 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 mit 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 eines vorhandenen Knotenpools aktualisieren

Sie können die Knotensystemkonfiguration eines vorhandenen Knotenpools mit dem folgenden Befehl 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 ist 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 Ihrer 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 Knoten-Updates finden Sie unter Unterbrechungen durch Knoten-Updates planen.

Achtung: GKE beginnt sofort mit dem Neuerstellen der Knoten für diese Änderung. Dabei wird die Knoten-Upgrade-Strategie verwendet, unabhängig von aktiven Wartungsrichtlinien. GKE ist von der Ressourcenverfügbarkeit für die Änderung abhängig. Das Deaktivieren automatischer Knotenupgrades verhindert diese Änderung nicht.

Knotensystemkonfiguration bearbeiten

Zum Bearbeiten einer Konfiguration für ein Knotensystem können Sie einen neuen Knotenpool mit der gewünschten Konfiguration erstellen oder die Knotensystemkonfiguration eines vorhandenen Knotenpools aktualisieren.

Bearbeitung durch Erstellen eines Knotenpools

So bearbeiten Sie eine Knotensystemkonfiguration durch Erstellen eines Knotenpools:

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 Knotensystemkonfiguration eines vorhandenen Knotenpools bearbeiten möchten, folgen Sie der Anleitung auf dem Tab Knotenpool aktualisieren unter Konfiguration einem Knotenpool hinzufü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 Parameter während einer Aktualisierung weglassen, werden sie auf die entsprechenden Standardwerte zurückgesetzt.

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

kubeletConfig: {}
linuxConfig:
  sysctl: {}

Knotensystemkonfiguration löschen

So entfernen Sie eine Knotensystemkonfiguration:

1. Erstellen Sie einen Knotenpool.
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 Optionen für die CPU-Verwaltung für kubelet beschrieben.

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
cpuCFSQuota	Muss true oder false sein.	true	Diese Einstellung erzwingt das CPU-Limit des Pods. Wenn Sie diesen Wert auf false setzen, werden die CPU-Limits für Pods ignoriert. Das Ignorieren von CPU-Limits kann in bestimmten Szenarien, in denen Pods empfindlich auf CPU-Limits reagieren, wünschenswert sein. Das Risiko, cpuCFSQuota zu deaktivieren, besteht darin, dass ein nicht autorisierter Pod mehr CPU-Ressourcen verbrauchen kann als beabsichtigt.
cpuCFSQuotaPeriod	Muss eine Zeitdauer sein.	"100ms"	Mit dieser Einstellung wird der Wert des CPU-CFS-Kontingentbereichs cpu.cfs_period_us festgelegt, der angibt, wie oft der Zugriff einer Gruppe auf CPU-Ressourcen verteilt werden soll. Mit dieser Option können Sie das CPU-Drosselungsverhalten anpassen.

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 mit den änderbaren Optionen für das evictionSoft-Flag.

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
evictionSoft	Zuordnung von Signalnamen. Informationen zu Wertbeschränkungen finden Sie in der folgenden Tabelle.	none	Mit dieser Einstellung werden Signalnamen einer Menge oder einem Prozentsatz zugeordnet, der die Grenzwerte für das vorläufige Entfernen definiert. Für einen Schwellenwert für den vorläufigen Ausschluss muss es eine Kulanzfrist geben. Der kubelet entfernt Pods erst, wenn der Kulanzzeitraum überschritten wurde.
evictionSoftGracePeriod	Zuordnung von Signalnamen. Der Wert muss für jeden Signalnamen eine positive Dauer sein, die kleiner als 5m ist. Gültige Zeiteinheiten sind ns, us (oder µs), ms, s oder m.	none	Mit dieser Einstellung werden Signalnamen Zeiträumen zugeordnet, die Kulanzzeiten für Soft-Eviction-Schwellenwerte definieren. Für jeden Schwellenwert für den sanften Ausschluss muss ein entsprechender Kulanzzeitraum angegeben werden.
evictionMinimumReclaim	Zuordnung von Signalnamen. Der Wert muss für jeden Signalnamen ein positiver Prozentsatz unter 10% sein.	none	Mit dieser Einstellung werden Signalnamen Prozentwerten zugeordnet, die den Mindestbetrag einer bestimmten Ressource definieren, die kubelet zurückfordert, wenn ein Pod entfernt wird.
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 des Entfernens.

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, allerdings mit anderen 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 Arbeitsspeichers des Knotens 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 in der kubelet .
nodefsAvailable	Wert muss zwischen 10% und 50% liegen	none	Diese Einstellung gibt den verfügbaren nodefs vor dem Soft Eviction an. Definiert die Menge des nodefs.available-Signals in der kubelet .
nodefsInodesFree	Wert muss zwischen 5% und 50% liegen	none	Diese Einstellung gibt die Anzahl der nodefs-Inodes an, die vor dem Soft-Eviction frei sind. Definiert die Menge des nodefs.inodesFree-Signals in der 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 Menge des imagefs.available-Signals im kubelet .
imagefsInodesFree	Wert muss zwischen 5% und 50% liegen	none	Diese Einstellung gibt die Imagefs-Inodes an, die vor dem Soft Eviction frei sind. Definiert die Menge des imagefs.inodesFree-Signals im kubelet.
pidAvailable	Wert muss zwischen 10% und 50% liegen	none	Diese Einstellung gibt die PIDs an, die vor dem Soft Eviction verfügbar sind. Definiert die Menge des pid.available-Signals im kubelet.
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. Verfügbar in GKE-Versionen 1.32.4-gke.1132000, 1.33.0-gke.1748000 oder höher.

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 zur Container-Logrotation gesteuert. Damit können Sie die maximale Größe für jede Logdatei konfigurieren. 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 Gesamtprotokollgröße (container_log_max_size*container_log_max_files) pro Container darf 1% des Gesamtspeichers des Knotens nicht überschreiten.

Automatische Speicherbereinigung von Bildern

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

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
imageGCHighThresholdPercent	Der Wert muss eine ganze Zahl zwischen 10 und 85 (einschließlich) und höher als imageGcLowThresholdPercent sein.	85	Mit dieser Einstellung wird der Prozentsatz der Laufwerknutzung angegeben, oberhalb dessen die automatische Speicherbereinigung für Images ausgeführt wird. Sie stellt die höchste Laufwerknutzung dar, die für die automatische Speicherbereinigung erreicht werden soll. 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. Sie stellt die niedrigste Laufwerknutzung dar, die für die automatische Speicherbereinigung erreicht werden soll. 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 nicht verwendetes Bild festgelegt, bevor es automatisch bereinigt 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. Dadurch wird das Feld deaktiviert. Bilder werden also nicht gelöscht, weil sie nicht verwendet werden. Wenn dieser Wert angegeben wird, muss er größer als der Wert des Felds imageMinimumGcAge sein. Verfügbar in GKE-Versionen 1.30.7-gke.1076000, 1.31.3-gke.1023000 oder höher.

Image-Abruf

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 sein.	2 oder 3, je nach Laufwerkstyp.	Diese Einstellung definiert die maximale Anzahl paralleler Image-Pulls. 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 der Namen oder Gruppen von sysctl. Die zulässigen sysctl-Gruppen sind: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	none	Mit dieser Einstellung wird eine durch Kommas getrennte 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.	true	Mit dieser Einstellung wird der unsichere schreibgeschützte Port kubelet 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.

Resource Manager

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

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

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
cpuManagerPolicy	Der Wert muss none oder static sein.	none	Diese Einstellung steuert die CPU-Manager-Richtlinie von kubelet. Der Standardwert ist none. Dies ist das Standard-CPU-Affinitätsschema und bietet keine Affinität, die über den Autoscaling-Planer hinaus automatisch erfolgt. Wenn Sie diesen Wert auf static setzen, kann Pods, die sowohl in der QoS-Klasse Guaranteed sind als auch ganzzahlige CPU-Anfragen haben, die exklusive Verwendung von CPUs zugewiesen werden.
memoryManager.policy	Der Wert muss None oder Static sein.	None	Mit dieser Einstellung wird die kubelet-Memory Manager-Richtlinie festgelegt. Mit dem 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 Topologie-Hinweise, 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 zum Hinzufügen der Konfiguration zu einem Standardknotenpool verwenden.	policy: none scope: container	Mit diesen Einstellungen wird die kubelet-Konfiguration des Topology Manager mithilfe der Unterfelder policy und scope gesteuert. Der Topology Manager koordiniert die Gruppe von 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, auf deren Steuerungsebene die GKE-Version 1.32.3-gke.1785000 oder höher ausgeführt wird. Bei Clustern mit der Steuerungsebene und den 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, G2, G4, M3, N4

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.	Diese Einstellung definiert die maximale systemweite Anzahl asynchroner E/A-Anfragen.
fs.file-max	Muss zwischen [104857, 67108864] liegen.	Diese Einstellung definiert die maximale Anzahl von Dateihandles, 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 festgelegt, 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 festgelegt, die ein Nutzer erstellen kann.
fs.nr_open	Muss zwischen [1048576, 2147483584] liegen.	Mit dieser Einstellung wird die maximale Anzahl von Dateideskriptoren definiert, die von einem Prozess geöffnet werden können.

Kernelparameter (kernel.*)

In der folgenden Tabelle werden die änderbaren Parameter für den Linux-Kernel beschrieben. Mit diesen Einstellungen werden wichtige Kernelfunktionen 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 Segmenten für gemeinsam genutzten Speicher. 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 im System verwendet werden können. Eine Seite hat auf der AMD64- und Intel 64-Architektur eine Größe von 4.096 Byte.
kernel.perf_event_paranoid	Muss zwischen [-1, 3] liegen.	Mit dieser Einstellung wird die Verwendung des Systems für Leistungsereignisse durch Nutzer ohne Berechtigungen 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 und 3 liegen.	Mit dieser Einstellung werden der Umfang und die Einschränkungen für den Systemaufruf ptrace() definiert, was sich auf das Debugging und die Ablaufverfolgung 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 und 2 liegen.	Diese Einstellung gibt an, ob Einschränkungen für die Offenlegung von Kerneladressen über /proc und andere Schnittstellen gelten.
kernel.dmesg_restrict	Optional (boolesch).	Mit dieser Einstellung wird angegeben, ob Nutzer ohne Berechtigungen daran gehindert werden, mit dmesg(8) Nachrichten aus dem Logpuffer des Kernels aufzurufen.
kernel.sysrq	Muss zwischen [0, 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.

Netzwerkparameter (net.*)

In der folgenden Tabelle werden die änderbaren Parameter für die Netzwerkfunktionen beschrieben. Mit diesen Einstellungen wird die Leistung und das Verhalten des Netzwerk-Stacks optimiert, von Socket-Puffern bis 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 Busy-Abfrage mit niedriger Latenz für „Poll and Select“ definiert. Sie gibt die ungefähre Zeit in Mikrosekunden an, die mit dem Warten auf Ereignisse verbracht wird.
net.core.busy_read	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	Mit dieser Einstellung wird das Zeitlimit für das Busy-Polling mit niedriger Latenz für Socket-Lesevorgänge definiert. Sie gibt die ungefähre Zeit in Mikrosekunden an, die für das Busy-Loop-Warten auf Pakete in der Geräte-Warteschlange benötigt wird.
net.core.netdev_max_backlog	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	Diese Einstellung definiert die maximale Anzahl von Paketen, 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.	Mit dieser Einstellung wird die Standardgröße des Empfangssocket-Puffers in Byte definiert.
net.core.rmem_max	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	Diese Einstellung definiert die maximale Größe des Socket-Zwischenspeichers für eingehende Daten in Byte.
net.core.wmem_default	Beliebige positive Ganzzahl, die kleiner als 2.147.483.647 ist.	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 Socket-Zwischenspeichers für ausgehende Daten 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 Größe des Hilfspuffers 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 Userspace als SOMAXCONN bekannt ist. Die Standardeinstellung ist 128.
net.ipv4.tcp_rmem	{min, default, max} (jeweils > 0, Arbeitsspeicher in Byte).	Diese Einstellung definiert die Mindestgröße des Zwischenspeichers für eingehende Daten, der von UDP-Sockets bei der Moderation verwendet wird. Die Standardeinstellung ist 1 Seite.
net.ipv4.tcp_wmem	{min, default, max} (jeweils > 0, Arbeitsspeicher in Byte).	Diese Einstellung definiert die Mindestgröße des Sendepuffers, der von UDP-Sockets in der Moderation verwendet wird, in Byte. Die Standardeinstellung ist 1 Seite.
net.ipv4.tcp_tw_reuse	Muss zwischen 0 und 1 liegen.	Mit dieser Einstellung wird festgelegt, ob die Wiederverwendung von Sockets im Status TIME_WAIT für neue Verbindungen zulässig ist, wenn dies aus Protokollsicht sicher ist. Der Standardwert ist 0.
net.ipv4.tcp_max_orphans	Muss zwischen [16384, 262144] liegen.	Mit dieser Einstellung wird die maximale Anzahl von TCP-Sockets definiert, die keinem Nutzer-Datei-Handle zugeordnet sind.
net.ipv4.tcp_max_tw_buckets	Muss zwischen [4096, 2147483647] liegen.	Diese Einstellung definiert die maximale Anzahl von Timewait-Sockets, die gleichzeitig vom System gehalten werden. Wenn diese Zahl überschritten wird, wird der Time-Wait-Socket sofort zerstört und eine Warnung ausgegeben.
net.ipv4.tcp_syn_retries	Muss zwischen [1, 127] liegen.	Mit dieser Einstellung wird die Anzahl der Wiederholungen für die Übertragung von anfänglichen SYNs für einen aktiven TCP-Verbindungsversuch festgelegt.
net.ipv4.tcp_ecn	Muss zwischen 0 und 2 liegen.	Mit dieser Einstellung wird die Verwendung von ECN (Explicit Congestion Notification) durch TCP gesteuert. ECN wird nur verwendet, wenn beide Enden der TCP-Verbindung die Unterstützung dafür angeben.
net.ipv4.tcp_mtu_probing	Muss zwischen 0 und 2 liegen.	Mit dieser Einstellung wird die TCP-Paketierungsschicht-Path MTU Discovery gesteuert. Folgende Werte werden unterstützt: 0: deaktiviert. 1: Standardmäßig deaktiviert, wird aktiviert, wenn ein ICMP-Blackhole erkannt wird. 2: immer aktiviert. Verwenden Sie die ursprü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 sind vom Bildtyp abhängig: COS: reno, cubic, bbr, lp Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6	Boolescher Wert.	Wenn Sie diesen Wert ändern, ändern Sie auch die Einstellung conf/default/disable_ipv6 und alle disable_ipv6-Einstellungen pro Schnittstelle in denselben Wert.
net.ipv6.conf.default.disable_ipv6	Boolescher Wert.	Durch diese Einstellung wird der Betrieb von IPv6 deaktiviert.
net.netfilter.nf_conntrack_acct	Muss zwischen 0 und 1 liegen.	Mit dieser Einstellung wird die Abrechnung des Connection-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 Maximalwert erreicht ist, schlägt die neue Verbindung fehl. Verfügbar in GKE-Versionen 1.32.0-gke.1448000 oder höher.
net.netfilter.nf_conntrack_buckets	Muss zwischen [65536, 524288] liegen.	Mit dieser Einstellung wird die Größe der Hashtabelle definiert. Die empfohlene Einstellung ist das Ergebnis von: nf_conntrack_max = nf_conntrack_buckets * 4. Verfügbar in GKE-Versionen 1.32.0-gke.1448000 oder höher.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Muss zwischen [60, 3600] liegen.	Mit dieser Einstellung wird der Zeitraum in Sekunden definiert, in dem 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 Verbindungstabelle gelöscht werden. Verfügbar in GKE-Versionen 1.32.0-gke.1448000 oder höher.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	Muss zwischen 1 und 600 liegen.	Mit dieser Einstellung wird der Zeitraum in Sekunden definiert, in dem die TCP-Verbindungen im Status TIME_WAIT verbleiben können. Der Standardwert ist 120. Verfügbar in GKE-Versionen 1.32.0-gke.1448000 oder höher.

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

In der folgenden Tabelle werden die änderbaren Parameter für das Subsystem für virtuellen Speicher beschrieben. Mit diesen Einstellungen wird das Subsystem für virtuellen Speicher verwaltet, das steuert, wie der Kernel Speicher, 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.	Mit dieser Einstellung wird der Prozentsatz des Systemspeichers definiert, der mit „dirty pages“ gefüllt werden kann, bevor Hintergrund-Kernel-Flusher-Threads mit dem Writeback beginnen. Der Wert muss kleiner als der Wert des Felds vm.dirty_ratio sein.
vm.dirty_background_bytes	Muss zwischen [0, 68719476736] liegen.	Mit dieser Einstellung wird die Menge an nicht bereinigtem Arbeitsspeicher definiert, bei der die Hintergrund-Kernel-Flusher-Threads mit dem Writeback 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.	Diese Einstellung definiert das maximale Alter in Hundertstelsekunden, 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.	Mit dieser Einstellung wird die Menge an nicht bereinigtem Arbeitsspeicher definiert, ab der ein Prozess, der Festplattenzugriffe generiert, selbst mit dem Writeback beginnt. Der zulässige Mindestwert für vm.dirty_bytes beträgt zwei Seiten in Byte. Alle Werte, die unter diesem Grenzwert 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 und 1.000 liegen.	Mit dieser Einstellung wird das Intervall in Hundertstelsekunden definiert, in dem Kernel-Flusher-Threads aktiviert werden, um alte, nicht gespeicherte Daten auf die Festplatte zu schreiben.
vm.overcommit_memory	Muss zwischen {0, 1, 2} liegen.	Mit dieser Einstellung wird die Strategie des Kernels für den Umgang mit Memory Overcommitment festgelegt. Die Werte sind folgende: 0: große Zuweisungen ablehnen 1: Immer zulassen 2: Commit über Swap + RAM-Verhältnis verhindern
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.	Mit dieser Einstellung wird die Tendenz des Kernels gesteuert, Prozesse aus dem physischen Arbeitsspeicher auf die Swap-Festplatte 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. Sie definiert den verbleibenden Speicher, bevor kswapd aktiviert wird, und den Speicher, der freigegeben werden muss, bevor kswapd in den Ruhezustand wechselt. Der Standardwert ist 10.
vm.min_free_kbytes	Muss zwischen [67584, 1048576] liegen.	Mit dieser Einstellung wird der minimale freie Speicher vor OOM definiert. 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-Computern 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 auf cgroupv2 geändert. Vorhandene Knotenpools, auf denen eine Version vor 1.26 ausgeführt wird und die keine benutzerdefinierte cgroup-Konfiguration enthalten, verwenden weiterhin cgroupv1. Wenn Sie die Einstellung ändern möchten, müssen Sie cgroupv2 für den vorhandenen Knotenpool explizit 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, achten Sie darauf, dass sie mit cgroupv2 kompatibel sind.
• Wenn Sie Java-Arbeitslasten (JDK) verwenden, 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

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

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 eine Konfigurationsdatei des Knotensystems verwenden, um Huge Pages vorab zuzuweisen. Kubernetes unterstützt vorab zugewiesene Huge Pages 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 Geräten mit weniger als 30 GB Arbeitsspeicher: 60% des gesamten Arbeitsspeichers. Auf einer e2-standard-2-Maschine 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 für die Maschinentypen A3, C2D, C3, C3D, C4, C4A, C4D, CT5E, CT5LP, CT6E, H3, M2, M3, M4 oder Z3 verfügbar.

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

Konfigurationsparameter	Beschränkungen	Standardwert	Beschreibung
hugepage_size2m	Ganzzahlanzahl. Vorbehaltlich der zuvor beschriebenen Speicherzuweisungslimits.	0	Mit dieser Einstellung wird eine bestimmte Anzahl von 2 MB-Hugepages vorab zugewiesen.
hugepage_size1g	Ganzzahlanzahl. Unterliegt sowohl den zuvor beschriebenen Arbeitsspeicher- als auch den Maschinentypbeschränkungen.	0	Mit dieser Einstellung wird eine bestimmte Anzahl von 1-GB-Hugepages vorab zugewiesen.

Transparent Huge Pages (THP)

Sie können eine Konfigurationsdatei des Knotensystems verwenden, um die Unterstützung für transparente Huge Pages des Linux-Kernels zu aktivieren. Bei 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 Huge Pages sind systemweit aktiviert. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: Transparent Huge Pages sind in MADV_HUGEPAGE-Regionen aktiviert. Dies ist die Standardeinstellung für die Kernelkonfiguration. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: Transparent Hugepage ist deaktiviert. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: Der Standardwert. GKE ändert die Kernelkonfiguration nicht.	UNSPECIFIED	Mit dieser Einstellung wird gesteuert, ob THP für anonymen Speicher aktiviert ist.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: Eine Anwendung, die THP anfordert, wird bei einem Zuweisungsfehler angehalten und gibt Seiten direkt frei und komprimiert den Arbeitsspeicher, um sofort eine THP zuzuweisen. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: Eine Anwendung aktiviert kswapd im Hintergrund, um Seiten freizugeben, und 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 den Modus für die direkte Rückforderung und Komprimierung, jedoch nur für Regionen, in denen madvise(MADV_HUGEPAGE) verwendet wurde. In allen anderen Regionen wird „kswapd“ im Hintergrund aktiviert, um Seiten freizugeben, und „kcompactd“, um den Arbeitsspeicher zu komprimieren, damit THP in naher Zukunft verfügbar ist. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: Eine Anwendung wechselt wie gewohnt in den Modus für die direkte Rückforderung und Komprimierung, jedoch nur für Regionen, in denen madvise(MADV_HUGEPAGE) verwendet wurde. In allen anderen Regionen wird „kswapd“ im Hintergrund aktiviert, um Seiten freizugeben, und „kcompactd“, um den Arbeitsspeicher zu komprimieren, damit THP in naher Zukunft verfügbar ist. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: Eine Anwendung geht nie in die direkte Rückforderung oder Komprimierung über. 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. Sie ist auch für neue TPU-Knotenpools in GKE-Version 1.33.2-gke.4655000 oder höher standardmäßig aktiviert. THP wird nicht aktiviert, wenn Sie vorhandene Knotenpools auf eine unterstützte Version oder höher aktualisieren.

Nächste Schritte

• Knotenpools
• Knotenpools erstellen