Knotensystemkonfiguration anpassen

Standard

In diesem Dokument wird beschrieben, wie Sie die Knotenkonfiguration Ihrer Google Kubernetes Engine (GKE) mithilfe einer Konfigurationsdatei namens 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 umfassend, 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 Knotensystemkonfiguration 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 Systemverhalten ein, um die Angriffsfläche zu verringern.
• Ressourcenverwaltung: Sie können genau festlegen, wie kubelet PIDs, Speicherplatz, Image-automatische Speicherbereinigung 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 Ihrer GKE-ComputeClass-Spezifikation 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 gewähren: Sie benötigen die entsprechenden IAM-Berechtigungen, um GKE-Cluster und -Knotenpools zu erstellen und zu aktualisieren, 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 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 Ihre ComputeClass-Konfiguration in YAML. Verwenden Sie das Feld nodeSystemConfig in der Spezifikation priorityDefaults, 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 Konfigurationsdatei für das Knotensystem 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 oder einen Knotenpool erstellen, oder aktualisieren Sie einen vorhandenen Knotenpool.

Konfigurationsdatei erstellen

Schreiben Sie die Knotensystemkonfiguration 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 so konfiguriert, dass die statische CPU-Verwaltungsrichtlinie verwendet wird.
• Das Feld net.core.somaxconn: '2048' begrenzt den socket listen()-Backlog 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 oder einen Knotenpool erstellen oder wenn Sie einen vorhandenen Knotenpool aktualisieren. Sie können keine Knotensystemkonfiguration über die Google Cloud Console hinzufügen.

Cluster mit der Knotensystemkonfiguration erstellen

Sie können eine Knotensystemkonfiguration 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 ist 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 ist 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 für einen vorhandenen Knotenpool aktualisieren

Wenn Sie die Knotensystemkonfiguration mit einer Konfigurationsdatei verwalten, können Sie einen vorhandenen Knotenpool auf eine der folgenden Arten aktualisieren:

• Unterbrechungsfreies Live-Update: Wendet aktualisierte sysctl- und kubelet-Einstellungen direkt auf laufende Knoten an, ohne die VMs neu zu erstellen oder Pods zu entfernen. Verwenden Sie diese Methode, wenn Sie nur sysctl- oder kubelet-Einstellungen ändern und Unterbrechungen minimieren möchten.
• Standard-Upgradestrategie: Die Knoten werden mit der neuen Konfiguration neu erstellt. Verwenden Sie diese Methode, wenn Sie Einstellungen ändern, die keine Live-Updates unterstützen, wenn Ihr Cluster oder Knotenpool eine GKE-Version vor 1.37.1-gke.1954000 ausführt oder wenn Sie möchten, dass GKE Ihre Pods leert und auf neuen Knoten neu plant.

Informationen zum Ändern der Konfiguration von Knoten, die eine ComputeClass verwenden, finden Sie unter Knotensystemkonfiguration für ComputeClasses bearbeiten.

Achtung: Bei beiden Methoden wird durch das Einfügen des Abschnitts kubeletConfig oder linuxConfig in Ihre Datei der gesamte Abschnitt der vorhandenen Konfiguration des Knotenpools ersetzt. Alle Parameter, die Sie in einem enthaltenen Abschnitt weglassen, werden auf ihren Standardwert zurückgesetzt. Wenn Sie während eines Live-Updates einen zuvor konfigurierten Parameter weglassen, der keine Live-Updates unterstützt (z. B. cpuManagerPolicy oder cgroupMode), lehnt die GKE das Update ab. Rufen Sie vor dem Aktualisieren die vorhandene Knotensystemkonfiguration ab und fügen Sie alle Einstellungen hinzu, die Sie beibehalten möchten.

Aktualisierung mit einem unterbrechungsfreien Live-Update

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ 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.

Sie können aktualisierte sysctl- und kubelet-Einstellungen aus Ihrer Konfigurationsdatei direkt auf laufende Knoten anwenden. Da bei diesem Vorgang die Parameter aktualisiert werden, ohne dass die zugrunde liegenden VMs neu erstellt oder neu gestartet werden müssen, werden Unterbrechungen reduziert und die Aktualisierung beschleunigt. Für die folgenden linuxConfig-Optionen ist weiterhin die Standard-Upgradestrategie erforderlich:

• Linux-cgroup-Modus
• Linux-Hugepages
• Genaue Zeitsynchronisierung unter Linux
• Linux VFIO
• Linux-Laufwerk-E/A-Planer

So funktionieren Livemeldungen

Livemeldungen funktionieren für jede unterstützte Konfiguration so:

• sysctl-Konfigurationen: GKE startet den systemd-Dienst sysctl auf jedem Knoten neu, um die Kernel-Parameter im Feld linuxConfig.sysctl anzuwenden. Wenn Sie einen Namespace-bezogenen sysctl-Parameter aktualisieren, startet die GKE auch den kubelet-Dienst neu, um die sysctl-Konfiguration auf Pod-Ebene zu aktualisieren. Informationen zu unterstützten Parametern finden Sie unter Sysctl-Konfigurationsoptionen.
• kubelet-Konfigurationen: GKE startet den kubelet-Dienst auf jedem Knoten neu, um die Parameter im Feld kubeletConfig anzuwenden. Die meisten kubelet-Konfigurationsoptionen unterstützen Live-Updates. Für die Optionen cpuManagerPolicy, shutdownGracePeriodSeconds und shutdownGracePeriodCriticalPodsSeconds ist jedoch die Standard-Upgradestrategie erforderlich.

In beiden Fällen wendet GKE die Änderung direkt auf den laufenden Knoten an, ohne die VMs neu zu erstellen, Ihre Pods zu entfernen oder temporäre Surge-VMs zu erstellen. GKE verwendet die Summe der Einstellungen --max-surge-upgrade und --max-unavailable-upgrade Ihres Knotenpools als Nebenläufigkeitslimit, um zu bestimmen, wie viele vorhandene Knoten parallel aktualisiert werden.

Voraussetzungen für Livemeldungen

Damit Sie Live-Updates verwenden können, müssen Ihr Cluster und Ihr Knotenpool die folgenden Voraussetzungen erfüllen:

• GKE-Version 1.37.1-gke.1954000 oder höher ausführen.
• Aktivieren Sie das Add-on NodeReadinessController im Cluster. Während eines Live-Updates wendet dieser Controller vorübergehend die Markierung readiness.k8s.io/gke-node-live-update-reconciling:NoSchedule auf jeden aktualisierten Knoten an, damit GKE erst dann neue Pods auf dem Knoten plant, wenn das Update abgeschlossen ist:
  • Fügen Sie bei neuen Clustern das Add-on NodeReadinessController während der Clustererstellung im Flag --addons hinzu. Mit diesem Flag werden nur die von Ihnen angegebenen Add-ons aktiviert und alle anderen deaktiviert. Geben Sie daher auch alle Standard-Add-ons an, die Sie beibehalten möchten.
  • Übergeben Sie bei vorhandenen Clustern das Flag --update-addons=NodeReadinessController=ENABLED während einer Clusteraktualisierung.

Live-Update anwenden

So wenden Sie ein Live-Update an:

1. Erstellen oder ändern Sie die YAML-Datei für die Knotensystemkonfiguration, sodass sie die vollständige Konfiguration des Knotenpools enthält, einschließlich der Einstellungen kubelet oder sysctl, die Sie ändern möchten. Um zu vermeiden, dass Einstellungen zurückgesetzt werden, die Sie nicht ändern möchten, beginnen Sie mit der vorhandenen Konfiguration des Knotenpools.

2. Aktualisieren Sie den Knotenpool mit Ihrer Konfigurationsdatei und setzen Sie den Wert des Flags --node-config-update-mode auf LIVE_UPDATE_WITHOUT_DRAIN:

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

   Ersetzen Sie Folgendes:

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

3. Prüfen Sie, ob die aktualisierten Einstellungen von GKE auf den Knotenpool angewendet wurden:

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

   In der Befehlsausgabe werden die aktiven Einstellungen für den Knotenpool in den Feldern config.kubeletConfig und config.linuxNodeConfig angezeigt.

4. Optional: Starten Sie Ihre vorhandenen Pods neu. Das Live-Update unterbricht keine laufenden Pods. Daher wendet GKE die aktualisierten Einstellungen nur auf Pods an, die nach Abschluss des Updates gestartet werden. Wenn Sie die Einstellungen auf eine bereits ausgeführte Arbeitslast anwenden möchten, starten Sie die Pods neu, z. B. durch Ausführen von kubectl rollout restart für das Deployment.

Wenn ein Live-Update nicht wie erwartet verläuft, hängt der Wiederherstellungspfad davon ab, ob der Updatevorgang abgeschlossen wurde:

• Wenn das Live-Update fehlschlägt, finden Sie weitere Informationen unter Nach einem fehlgeschlagenen Live-Update wiederherstellen.
• Wenn der Live-Update-Vorgang erfolgreich ist, die neuen Einstellungen jedoch zu unbeabsichtigtem Arbeitslastverhalten führen, lesen Sie den Abschnitt Abgeschlossenes Live-Update rückgängig machen.

Nach einem fehlgeschlagenen Live-Update wiederherstellen

Wenn ein Live-Update auf einem Knoten fehlschlägt, beendet GKE den Roll-out sofort und belässt den Knotenpool in einem teilweise aktualisierten Zustand. So prüfen Sie die Fehlerdetails:

• Führen Sie den Befehl gcloud container operations describe aus. In der Ausgabe gibt das Feld statusMessage den Knoten an, auf dem das Live-Update fehlgeschlagen ist, und den Fehler, den der Knoten gemeldet hat, z. B.:

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

• Suchen Sie im Log-Explorer nach Fehlern der Komponente gke-node-live-update-reconciler auf den betroffenen Knoten.

Da ein fehlgeschlagenes Live-Update die gespeicherte Konfiguration des Knotenpools nicht ändert, wird durch das erneute Anwenden der vorherigen Konfiguration mit dem Befehl gcloud container node-pools update kein Update ausgelöst. Wählen Sie nach der Prüfung des Fehlers eine der folgenden Wiederherstellungsoptionen aus:

• Problem beheben und Live-Update abschließen (empfohlen): Beheben Sie das Problem, das den Fehler verursacht hat, und führen Sie dann den Befehl gcloud container node-pools update aus dem vorherigen Verfahren mit Ihrer Zielkonfiguration noch einmal aus.
• Zur vorherigen Konfiguration zurückkehren: Wenn Sie das Problem nicht beheben können, führen Sie den Befehl gcloud container node-pools rollback aus, um den Knotenpool auf die vorherige Konfiguration zurückzusetzen. Im Gegensatz zu einem Live-Update werden mit diesem Befehl alle Knoten im Knotenpool neu erstellt, was die darauf ausgeführten Arbeitslasten unterbricht.

Abgeschlossenes Live-Update rückgängig machen

Wenn ein Live-Update-Vorgang erfolgreich ist, eine neu angewendete Einstellung jedoch zu unbeabsichtigtem Verhalten der Arbeitslast führt, können Sie die Änderung rückgängig machen, indem Sie ein weiteres Live-Update mit Ihrer vorherigen Konfiguration anwenden. Durch dieses Live-Update wird die vorherige Konfiguration wiederhergestellt, ohne dass Pods entfernt oder Knoten neu gestartet werden. Der Befehl gcloud container node-pools rollback ist nach einem erfolgreichen Vorgang nicht verfügbar. Er funktioniert nur, wenn der Vorgang fehlschlägt.

So machen Sie ein abgeschlossenes Live-Update rückgängig:

1. Aktualisieren Sie die YAML-Datei für die Knotensystemkonfiguration, sodass sie die vollständige vorherige Konfiguration des Knotenpools enthält. Wenn eine Einstellung zuvor nicht konfiguriert wurde, legen Sie sie explizit auf ihren Standardwert fest, anstatt sie wegzulassen oder den Abschnitt leer zu lassen. Die Standardwerte finden Sie unter Kubelet-Konfigurationsoptionen und Sysctl-Konfigurationsoptionen.

2. Wenden Sie die vorherige Konfiguration auf Ihren Knotenpool an:

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

Mit der Standard-Upgradestrategie aktualisieren

Verwenden Sie die Standard-Upgradestrategie, wenn Sie Konfigurationsoptionen aktualisieren, die keine Live-Updates unterstützen, wenn auf Ihrem Cluster oder Knotenpool eine GKE-Version vor 1.37.1-gke.1954000 ausgeführt wird oder wenn Sie möchten, dass GKE Ihre Pods automatisch per Drain beendet und auf neu erstellten Knoten neu plant.

Führen Sie den folgenden Befehl aus, um einen vorhandenen Knotenpool mit der Standard-Upgradestrategie 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, der den Knotenpool enthält.
• LOCATION: die Compute-Zone oder ‑Region des Clusters.
• SYSTEM_CONFIG_PATH: der Pfad zur YAML-Datei, die Ihre Knotensystemkonfiguration enthält

Für diese Änderung müssen die Knoten neu erstellt werden, was zu einer Unterbrechung der ausgeführten Arbeitslasten führen kann. Weitere Informationen zu dieser spezifischen Änderung finden Sie in der entsprechenden Zeile der Tabelle Manuelle Änderungen, bei denen die Knoten mithilfe einer Knotenupgradestrategie neu erstellt werden, ohne 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. Dabei wird die Knoten-Upgrade-Strategie verwendet, unabhängig von aktiven Wartungsrichtlinien. GKE ist von der Ressourcenverfügbarkeit für die Änderung abhängig. Durch das Deaktivieren von automatischen 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 die 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 ComputeClass.
• 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

So sorgen Sie dafür, dass Ihre Arbeitslasten auf neue Knoten mit der aktualisierten Konfiguration migriert werden:

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

Informationen zum Ändern der Knotensystemkonfiguration eines vorhandenen Knotenpools finden Sie unter Knotensystemkonfiguration für einen vorhandenen Knotenpool aktualisieren.

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 kubeletConfig oder linuxNodeConfig nicht in der Ausgabe aufgeführt.

Vorhandene Knotensystemkonfiguration zurücksetzen

Wenn Sie die Knotensystemkonfiguration auf die Standardwerte zurücksetzen möchten, aktualisieren Sie Ihre Konfigurationsdatei mit leeren Werten für die Felder kubelet und sysctl, zum Beispiel:

```yaml
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 Ihren Arbeitslastspezifikationen.
2. Wenden Sie die aktualisierten Arbeitslastspezifikationen an. Die Arbeitslasten werden von GKE auf Standardknoten neu erstellt. 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 setzen, 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 bei der Deaktivierung von cpuCFSQuota besteht darin, dass ein bösartiger Pod mehr CPU-Ressourcen als beabsichtigt verbrauchen kann.
cpuCFSQuotaPeriod	Muss eine Zeitdauer sein.	"100ms"	Mit dieser Einstellung wird der Wert für den CPU-CFS-Kontingentzeitraum (cpu.cfs_period_us) festgelegt. Er 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 (Vorabversion)	Muss eine Liste der zu reservierenden CPU-Kerne sein (z. B. 0-1 oder 0,1, um die Kerne 0 und 1 zu reservieren). Da Kerne nullindexiert sind, müssen die Werte kleiner als die Anzahl der vCPUs des Maschinentyps 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 Guaranteed-Pods mit ganzzahligen CPU-Anfragen dedizierte Kerne zugewiesen. Es wird jedoch nicht verhindert, dass Hostsystemdienste diese Kerne verwenden. Wenn Sie die Einstellung reservedSystemCPUs hinzufügen, werden Hostsystemdienste auf ihre eigenen reservierten Kerne beschränkt, sodass sie die exklusiven Kerne Ihrer Arbeitslasten nicht unterbrechen. Dazu pinnt GKE die system.slice-cgroup beim Knotenstart automatisch 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 auch 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, kann es bei hoher Last zu CPU-Einschränkungen bei Hostsystem-Daemons und Betriebssystemprozessen kommen, was zu Instabilität oder verworfenen Netzwerkpaketen führen kann.

Speicherverwaltung und -bereinigung

In der folgenden Tabelle werden die änderbaren Optionen für die Speicherverwaltung und die Bereinigung 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 bzw. der Schwellenwerte für die weiche Bereinigung definiert. Ein Schwellenwert für die weiche Bereinigung muss einen Kulanzzeitraum haben. 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 Schwellenwerte für die weiche Bereinigung 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 unter 10% sein.	none	Mit dieser Einstellung werden Signalnamen Prozentsätzen zugeordnet, die die Mindestmenge einer bestimmten Ressource definieren, die der kubelet beim Entfernen eines Pods zurückfordert.
evictionMaxPodGracePeriodSeconds	Der Wert muss eine Ganzzahl zwischen 0 und 300 sein.	0	Diese Einstellung definiert in Sekunden den maximalen Kulanzzeitraum für die Beendigung von Pods 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 ab GKE-Version 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 der weichen Bereinigung verfügbar ist. Definiert die Stärke des memory.available-Signals im kubelet .
nodefsAvailable	Wert muss zwischen 10% und 50% liegen	none	Diese Einstellung stellt die verfügbaren Knoten dar, bevor die weiche Bereinigung erfolgt. Definiert die Stärke 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 Stärke des nodefs.inodesFree-Signals im kubelet .
imagefsAvailable	Wert muss zwischen 15% und 50% liegen	none	Diese Einstellung stellt das imagefs dar, das vor der weichen Bereinigung verfügbar ist. Definiert die Menge 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 die Menge des imagefs.inodesFree-Signals im kubelet.
pidAvailable	Wert muss zwischen 10% und 50% liegen	none	Diese Einstellung stellt die PIDs dar, die vor der weichen Bereinigung verfügbar sind. Definiert die Menge 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 das Logging 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 die Container-Logrotation gesteuert, mit der Sie die maximale Größe für jede Logdatei 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 änderbaren Optionen für die Image-automatische Speicherbereinigung 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. Er stellt die höchste Laufwerknutzung dar, bis zu der die automatische Speicherbereinigung ausgefü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 Dauer sein, die nicht größer als 2m ist. Gültige Zeiteinheiten sind ns, us (oder µs), ms, s, m oder h.	2m	Diese Einstellung definiert das Mindestalter für ein nicht verwendetes Image, bevor es durch die automatische Speicherbereinigung gelöscht wird.
imageMaximumGcAge	Der Wert muss eine Zeitdauer sein.	0s	Diese Einstellung definiert das maximale Alter, das ein Image ungenutzt bleiben kann, bevor es durch die automatische Speicherbereinigung entfernt wird. Der Standardwert dieses Felds ist 0s, wodurch das Feld deaktiviert wird. Daher werden Images nicht aufgrund von Nichtverwendung gelöscht. Wenn dieser Wert angegeben wird, muss er größer als der Wert des Felds imageMinimumGcAge sein. Verfügbar in den 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 Abrufen 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 Umgang mit unsicheren Vorgängen beschrieben.

kubelet-Konfigurationseinstellungen	Beschränkungen	Standardeinstellung	Beschreibung
allowedUnsafeSysctls	Liste mit sysctl Namen oder Gruppen. Die folgenden sysctl-Gruppen sind zulässig: 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 schreibgeschützte kubelet-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.

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 für CPUs, Geräte und Arbeitsspeicherressourcen (Hugepages) 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 festgelegt. 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, auf deren Steuerungsebene die GKE-Version 1.32.3-gke.1785000 oder höher ausgeführt wird.
topologyManager	Der Wert muss eine der unterstützten Einstellungen für jedes der 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 im Zusammenhang mit CPU-Isolation, Arbeitsspeicher und Gerätelokalität verantwortlich sind. Sie können die Richtlinien- und Bereichseinstellungen unabhängig voneinander festlegen. Weitere Informationen zu diesen Einstellungen finden Sie unter Bereiche und Richtlinien des Topologiemanagers. 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 Standardknotenpools 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 ihn nur reduzieren, 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 Standardlimit für einen Kubernetes-Cluster beträgt 5 Minuten. Weitere Informationen finden Sie unter Konfigurierbare Verzögerung beim Neustart von Containern.

Ordnungsgemäße Beendigung 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. Wenn Sie diese Optionen verwenden möchten, 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 auch shutdownGracePeriodSeconds 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 diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ 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 das Abrufen großer Mengen von Images oder das Ausführen benutzerdefinierter DaemonSets für Knoten. 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-Arbeitsspeicherreservierung für Knotenpools sein, die mit Version 1.37 oder höher erstellt wurden, und kleiner als 50 % der gesamten Arbeitsspeicherkapazität des Knotens.	Siehe Arbeitsspeicherreservierungen.	Die Menge an Arbeitsspeicher, die für Systemkomponenten reserviert werden soll, in Mebibyte (MiB).
reservedResourcesConfig.cpuReservedMillicore	Der Wert muss eine ganze Zahl sein. Muss größer oder gleich der Standard-CPU-Reservierung für Knotenpools sein, 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 CPU-Kapazität, 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.	Diese Einstellung definiert die maximale systemweite Anzahl asynchroner E/A-Anfragen.
fs.file-max	Muss zwischen [104857, 67108864] liegen.	Mit dieser Einstellung wird die maximale Anzahl von Datei-Handles definiert, 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.	Diese Einstellung definiert die maximale Anzahl von inotify-Watches, 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 Kernelfunktionen konfiguriert, einschließlich der Zuweisung von gemeinsam genutztem Arbeitsspeicher.

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 gemeinsam genutzten Speichersegments in Byte, die vom Kernel zugelassen wird. Dieser Wert wird ignoriert, wenn er größer als die tatsächliche RAM-Größe ist. Das bedeutet, dass der gesamte verfügbare RAM gemeinsam genutzt werden kann.
kernel.shmall	Muss zwischen [0, 18446744073692774399] liegen.	Diese Einstellung definiert die Gesamtzahl der gemeinsam genutzten Speicherseiten, 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).	Diese Einstellung steuert, ob der Kernel in den Panic-Modus wechselt, 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 sind: 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 Kernel-Adressen über /proc und andere Schnittstellen eingeschränkt ist.
kernel.dmesg_restrict	Optional (boolesch).	Diese Einstellung gibt an, ob nicht privilegierte Nutzer daran gehindert werden, mit dmesg(8) Nachrichten aus dem Logpuffer des Kernels anzusehen.
kernel.sysrq	Muss zwischen [0, 511] liegen.	Mit dieser Einstellung werden die Funktionen gesteuert, die über die S-Abf-Taste aufgerufen werden können. 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 das Netzwerk beschrieben. Mit diesen Einstellungen werden die Leistung und das Verhalten des Netzwerkstacks optimiert, von Socket-Zwischenspeichern bis hin zum Connection Tracking.

Sysctl-Parameter	Beschränkungen	Beschreibung
net.core.busy_poll	Beliebige positive Ganzzahl, kleiner als 2147483647.	Mit dieser Einstellung wird das Zeitlimit für die Abfrage und Auswahl bei niedriger Latenz definiert. Sie stellt die ungefähre Zeit in µs dar, die für das Warten auf Ereignisse in einer Busy-Loop benötigt wird.
net.core.busy_read	Beliebige positive Ganzzahl, kleiner als 2147483647.	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 aufgewendet wird.
net.core.netdev_max_backlog	Beliebige positive Ganzzahl, kleiner als 2147483647.	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, kleiner als 2147483647.	Diese Einstellung definiert die Standardgröße des Empfangs-Socket-Zwischenspeichers in Byte.
net.core.rmem_max	Beliebige positive Ganzzahl, kleiner als 2147483647.	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 des Socket-Sendepuffers in Byte.
net.core.wmem_max	Beliebige positive Ganzzahl, kleiner als 2147483647.	Diese Einstellung definiert die maximale Größe des Sendesocket-Zwischenspeichers in Byte.
net.core.optmem_max	Beliebige positive Ganzzahl, kleiner als 2147483647.	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 des socket listen()-Backlogs definiert, das im Userspace als SOMAXCONN bezeichnet wird. Die Standardeinstellung ist 128.
net.ipv4.tcp_rmem	{min, default, max} (jeweils > 0, Arbeitsspeicher in Byte).	Diese Einstellung definiert die Mindestgröße des Empfangspuffers in Byte, 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).	Diese Einstellung definiert die Mindestgröße des Sendepuffers in Byte, der von UDP-Sockets in der Moderation verwendet wird. Die Standardeinstellung ist 1 Seite.
net.ipv4.tcp_tw_reuse	Muss zwischen {0, 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 Timewait-Sockets, die das System gleichzeitig halten kann. Wenn diese Anzahl überschritten wird, wird der Socket im Status TIME_WAIT sofort gelöscht und eine Warnung ausgegeben.
net.ipv4.tcp_syn_retries	Muss zwischen [1, 127] liegen.	Diese Einstellung definiert, wie oft die ersten SYNs für einen aktiven TCP-Verbindungsversuch erneut übertragen werden.
net.ipv4.tcp_ecn	Muss zwischen [0, 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.	Das Ändern dieses Werts entspricht dem Ändern der Einstellung conf/default/disable_ipv6 und aller schnittstellenspezifischen disable_ipv6-Einstellungen auf denselben Wert.
net.ipv6.conf.default.disable_ipv6	Boolescher Wert.	Mit dieser Einstellung wird der Betrieb von IPv6 deaktiviert.
net.netfilter.nf_conntrack_acct	Muss zwischen {0, 1} liegen.	Mit dieser Einstellung wird die Abrechnung des Verbindungs-Tracking-Flusses aktiviert. Der Standardwert ist 0, d. h., die Einstellung ist deaktiviert. Verfügbar ab GKE-Version 1.32.0-gke.1448000.
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 und 3.600 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 ab GKE-Version 1.32.0-gke.1448000.
net.netfilter.nf_conntrack_tcp_timeout_established	Muss zwischen [600, 86400] liegen.	Mit dieser Einstellung wird die Dauer in Sekunden festgelegt, die inaktive Verbindungen bestehen, 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, 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.	Mit dieser Einstellung wird die Mindestanzahl von Einträgen im ARP-Cache festgelegt. 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 weiche maximale Anzahl von Einträgen, die im ARP-Cache aufbewahrt werden sollen. Der Garbage Collector lässt zu, dass die Anzahl der Einträge diesen Wert für 5 Sekunden überschreitet, bevor er mit der Soft-Garbage-Collection beginnt.
net.ipv4.neigh.default.gc_thresh3	Muss zwischen [1024, 1048576] liegen.	Mit dieser Einstellung wird die maximale Anzahl von Einträgen festgelegt, die im ARP-Cache gespeichert werden sollen. Der Garbage Collector wird immer ausgeführt, wenn die Anzahl der Einträge diese Einstellung überschreitet.

Parameter für virtuellen Arbeitsspeicher (vm.*)

In der folgenden Tabelle werden die änderbaren Parameter für das Subsystem „Virtueller Speicher“ beschrieben. Mit diesen Einstellungen wird das virtuelle Speichersubsystem verwaltet, das steuert, wie der Kernel mit Arbeitsspeicher, Auslagerung und Datenträger-Caching umgeht.

sysctl Parameter	Beschränkungen	Beschreibung
vm.max_map_count	Muss zwischen [65536, 2147483647] liegen.	Diese Datei definiert die maximale Anzahl von Speicherzuordnungsbereichen, die ein Prozess haben kann.
vm.dirty_background_ratio	Muss zwischen [1, 100] liegen.	Diese Einstellung definiert den Prozentsatz des Systemspeichers, der mit Dirty Pages gefüllt werden kann, bevor Hintergrund-Kernel-Flusher-Threads 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.	Diese Einstellung definiert das maximale Alter in Hundertstelsekunden, das schmutzige Daten im Arbeitsspeicher verbleiben können, bevor sie von Kernel-Flusher-Threads auf das Laufwerk geschrieben werden.
vm.dirty_ratio	Muss zwischen [1, 100] liegen.	Diese Einstellung definiert den Prozentsatz des Systemspeichers, der mit Dirty Pages gefüllt werden kann, bevor Prozesse, die Schreibvorgänge ausführen, gezwungen werden, schmutzige Daten synchron zu blockieren und zu schreiben.
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 Writeback 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.	Diese Einstellung bestimmt die Strategie des Kernels für den Umgang mit Speicher-Overcommitment. Die Werte sind: 0: Große Zuweisungen ablehnen 1: Immer zulassen (Standardwert) 2: Commit über Swap + RAM-Verhältnis hinaus verhindern Diese Einstellung wird auf Computern 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 die Freigabe 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 Swap-Laufwerk zu verschieben. Der Standardwert ist 60.
vm.watermark_scale_factor	Muss zwischen [10, 3000] liegen.	Diese Einstellung steuert die Aggressivität von kswapd. Sie 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 Dokumentation zur gcloud CLI für „--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 auf 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: Verwenden Sie 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 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 Konfigurationsdatei für das Knotensystem 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 Folgendes nicht überschreiten:
  • 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 Gesamtarbeitsspeichers. Auf c4a-standard-8-Maschinen mit 32 GB Arbeitsspeicher dürfen Huge Pages beispielsweise 25,6 GB nicht überschreiten.
• 1 GB große Seiten 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 beiden zuvor beschriebenen Einschränkungen für Arbeitsspeicher und Maschinentyp.	0	Mit dieser Einstellung wird eine bestimmte Anzahl von 1-GB-Hugepages vorab zugewiesen.

Transparent Hugepages (THP)

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

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

Config-Parameter	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. Diese Einstellung ist die Standard-Kernel-Konfiguration. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: Transparent Hugepage ist deaktiviert. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: Der Standardwert. GKE ändert die Kernelkonfiguration nicht.	UNSPECIFIED	Mit dieser Einstellung wird festgelegt, ob THP für anonymen Speicher aktiviert ist.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: Eine Anwendung, die THP anfordert, wird bei einem Zuordnungsfehler blockiert und gibt Seiten und kompakten Speicher direkt frei, um sofort eine THP zuzuweisen. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: Eine Anwendung weckt kswapd im Hintergrund, um Seiten freizugeben, und kcompactd, um den Speicher zu komprimieren, damit THP in naher Zukunft verfügbar ist. Es liegt dann 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 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 wird aktiviert, um den Speicher zu komprimieren, sodass 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 wird aktiviert, um den Speicher zu komprimieren, sodass THP in naher Zukunft verfügbar ist. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: Eine Anwendung wird nie direkt zurückgefordert oder komprimiert. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: Der Standardwert. Die Kernelkonfiguration wird von GKE nicht geändert.	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 standardmäßig in neuen TPU-Knotenpools in GKE-Version 1.33.2-gke.4655000 oder höher 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 die genaue Zeit konfigurieren, um die Uhr Ihrer VM mit der Hostuhr zu synchronisieren. Verwenden Sie dazu chrony und ptp_kvm. 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 zum Konfigurieren der genauen Zeitsynchronisierung mit GKE beschrieben:

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, erfasst und exportiert GKE die folgenden Informationen:

• Der Messwert compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy, der die Genauigkeit der VM-Hostuhr im Vergleich zur UTC angibt.
• 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 logbasierte Messwerte und Dashboards in Cloud Monitoring erstellen, um die Leistung und Zuverlässigkeit der Zeitsynchronisierung zu analysieren.

In der folgenden gke-clock-metric.json-Konfiguration wird beispielsweise ein logbasierter Messwert für den maximalen Hostuhrfehler definiert:

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

In der folgenden gke-metrics-dashboard.json-Konfiguration wird ein Monitoring-Dashboard definiert, das die Fehlerdaten aus dem logbasierten Messwert und dem UTC-Genauigkeitsmesswert zusammenfasst:

{
  "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.

Config-Parameter	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 Hostarbeitsspeichers 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 Laufwerk-E/A-Schedulers für Knotenpools beschrieben.

Config-Parameter	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 E/A-Planer 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