Knotensystemkonfiguration anpassen

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

Übersicht

Sie können die Knotenkonfiguration mit verschiedenen Methoden anpassen. Sie können beispielsweise beim Erstellen eines Knotenpools Parameter wie den Maschinentyp und die Mindest-CPU-Plattform angeben.

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

Sie können die containerd-Containerlaufzeit auf Ihren GKE-Knoten auch anpassen, indem Sie eine andere Datei verwenden, die als Laufzeitkonfigurationsdatei bezeichnet wird. Eine Anleitung finden Sie unter containerd-Konfiguration in GKE-Knoten anpassen.

Sie können DaemonSets auch verwenden, um Knoten anzupassen, z. B. Automatisches Bootstrapping von GKE-Knoten mit DaemonSets.

Knotensystemkonfiguration verwenden

Sie können die Knotensystemkonfiguration mit einer der folgenden Methoden anpassen:

  • Konfigurationsdatei: Im Standardmodus verfügbar. Sie verwenden eine YAML-Datei, die die kubelet- und Linux-Kernel-Konfigurationsparameter enthält. Auf dieser Seite wird beschrieben, wie Sie eine Konfigurationsdatei erstellen und verwenden.
  • ComputeClass: Im Autopilot- und Standardmodus verfügbar. Sie geben die Konfiguration des Knotensystems in der GKE ComputeClass-Spezifikation an. Mit Compute-Klassen können Sie Gruppen von Knotenattributen definieren, die GKE beim Hochskalieren Ihres Clusters verwenden soll. Verfügbar in GKE-Version 1.32.1-gke.1729000 und höher. Weitere Informationen finden Sie unter Compute-Klassen in GKE.

So verwenden Sie eine Knotensystemkonfigurationsdatei:

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

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Konfigurationsdatei erstellen

Schreiben Sie die Konfigurationsdatei des Knotensystems in YAML. Das folgende Beispiel zeigt, wie Sie Konfigurationen für die Optionen kubelet und sysctl hinzufügen:

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:

  • cpuManagerPolicy: static konfiguriert kubelet so, dass die statische CPU-Verwaltungsrichtlinie verwendet wird.
  • net.core.somaxconn: '2048' begrenzt den Rückstand socket listen() auf 2.048 Byte.
  • 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 ausschließlich für kubelet oder sysctl hinzufügen möchten, fügen Sie nur diesen Abschnitt in die Konfigurationsdatei 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 Konfigurationsdatei hinzufügen können, finden Sie in den Abschnitten zu den Kubelet-Konfigurationsoptionen und Sysctl-Konfigurationsoptionen.

Konfiguration einem Knotenpool hinzufügen

Nachdem Sie die Konfigurationsdatei erstellt haben, fügen Sie das Flag --system-config-from-file über die Google Cloud CLI hinzu.

Sie können die gcloud CLI oder Terraform verwenden, um eine Knotenkonfiguration anzuwenden, wenn Sie einen neuen Standardcluster oder einen neuen Knotenpool erstellen. Wenn Sie die Konfiguration während der Clustererstellung anwenden, wendet GKE die Konfiguration auf den Standardknotenpool des Clusters an. Sie können auch die Knotensystemkonfiguration eines vorhandenen Knotenpools aktualisieren. Mit der Google Cloud Console können Sie keine Knotensystemkonfiguration hinzufügen.

Neuen Knotenpool mit der Knotensystemkonfiguration 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

``` Replace the following:
  • 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

Führen Sie dazu diesen Befehl aus:

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

Ersetzen Sie Folgendes:

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

Für diese Änderung müssen die Knoten neu erstellt werden, was zu Unterbrechungen Ihrer laufenden Arbeitslasten führen kann. Details zu dieser spezifischen Ä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 Knotenaktualisierungen finden Sie unter Unterbrechungen bei Knotenaktualisierungen planen.

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. Durch das Aktualisieren einer Knotensystemkonfiguration wird die Systemkonfiguration des Knotenpools mit der neuen Konfiguration überschrieben. Dazu 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 kubelet und sysctl. Beispiel:

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.

Kubelet-Konfigurationsoptionen

In der folgenden Tabelle sind die kubelet-Optionen aufgeführt, die Sie ändern können.

Kubelet-Konfigurationseinstellungen Beschränkungen Standardeinstellung Beschreibung
allowedUnsafeSysctls Liste der Namen oder Gruppen von sysctl. Zulässige sysctl-Gruppen: kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.* und net.*. Beispiel: [kernel.msg*, net.ipv4.route.min_pmtu]. 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.

Verfügbar in GKE-Versionen 1.32.0-gke.1448000 oder höher.
containerLogMaxSize Der Wert muss eine positive Zahl und ein Einheitssuffix zwischen 10Mi und 500Mi sein. Gültige Einheiten sind Ki, Mi, Gi. 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.
containerLogMaxFiles Der Wert muss eine Ganzzahl zwischen 2 und 10 (einschließlich) sein. 5 Mit dieser Einstellung wird die Einstellung containerLogMaxFiles der Richtlinie zur Rotation von Containerlogdateien 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 Protokolle (container_log_max_size*container_log_max_files) pro Container darf 1 % des Gesamtspeichers des Knotens nicht überschreiten.
cpuCFSQuota Der Wert 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, bedeutet, dass ein zustandsorientierter Pod mehr CPU-Ressourcen verbrauchen kann als beabsichtigt.
cpuCFSQuotaPeriod Der Wert muss eine Zeitdauer zwischen 1 Millisekunde und 1 Sekunde (einschließlich) 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.
imageGcLowThresholdPercent Der Wert muss eine ganze Zahl 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. Niedrigste Laufwerksnutzung, die für die automatische Speicherbereinigung erreicht werden soll. Der Prozentsatz wird berechnet, indem dieser Feldwert durch 100 geteilt wird. Falls angegeben, muss der Wert kleiner als imageGcHighThresholdPercent sein.
imageGcHighThresholdPercent Der Wert muss eine Ganzzahl zwischen 10 und 85 (einschließlich) und höher als imageGcLowThresholdPercent sein. 85 Mit dieser Einstellung wird der Prozentsatz der Laufwerknutzung definiert, oberhalb dessen die automatische Speicherbereinigung für Images ausgeführt wird. Höchste Laufwerksnutzung, die für die automatische Speicherbereinigung verwendet werden soll. Der Prozentsatz wird berechnet, indem dieser Feldwert durch 100 geteilt wird. Falls der Wert angegeben wird, muss er größer als imageGcLowThresholdPercent sein.
imageMinimumGcAge Der Wert muss eine Zeitdauer von höchstens 2 Minuten sein. Gültige Zeiteinheiten sind "ns", "us" (or "µs"), "ms", "s", "m", "h". 2m imageMinimumGcAge ist das Mindestalter für ein nicht verwendetes Bild, bevor es automatisch gelöscht wird.
imageMaximumGcAge Der Wert muss eine Zeitdauer sein 0s imageMaximumGcAge ist das maximale Alter, das ein Bild haben kann, bevor es automatisch gelöscht wird. Der Standardwert dieses Felds ist „0 s“. Dadurch wird das Feld deaktiviert. Das bedeutet, dass Bilder nicht automatisch gelöscht werden, weil sie zu lange nicht verwendet wurden. Falls der Wert angegeben wird, muss er größer als imageMinimumGcAge sein.

Verfügbar in GKE-Versionen 1.30.7-gke.1076000, 1.31.3-gke.1023000 oder höher.
insecureKubeletReadonlyPortEnabled Der Wert muss ein boolescher Wert (true oder false) sein. true 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.
podPidsLimit Der 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.
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:

  • Standardwert 3: pd-balanced, pd-ssd oder temporäre lokale SSD sind vorhanden.
  • Standard-2: pd-standard oder andere Arten von Bootlaufwerken.

    • Verfügbar in GKE-Versionen 1.33.1-gke.1918000 oder höher.
    evictionSoft Zuordnung von Signalnamen. Informationen zu Wertbeschränkungen finden Sie in der folgenden Tabelle. none Mit dieser Einstellung werden Signalnamen Mengen oder Prozentsätzen zugeordnet, die die Grenzwerte für den sanften Ausschluss definieren. Für einen Schwellenwert für den sanften Ausschluss muss es eine Kulanzfrist geben. Das Kubelet entfernt Pods erst, wenn der Kulanzzeitraum überschritten wurde.
    evictionSoftGracePeriod Eine Zuordnung von Signalnamen, die dieselben Optionen wie evictionSoft, aber andere Einschränkungen hat. Für jeden Signalnamen muss der Wert eine positive Dauer sein, die kleiner als 5m ist, z. B. 30s oder 1m. Gültige Zeiteinheiten sind "ns", "us" (oder "µs"), "ms", "s", "m" oder "h". 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 Eine Zuordnung von Signalnamen, die dieselben Optionen wie evictionSoft, aber andere Einschränkungen hat. Der Wert muss für jeden Signalnamen ein positiver Prozentsatz unter 10% sein, z. B. 5%. none Mit dieser Einstellung werden Signalnamen Prozentwerten zugeordnet, die den Mindestbetrag einer bestimmten Ressource definieren, die das Kubelet zurückfordert, wenn es einen Pod entfernt.
    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 Optionen für das evictionSoft-Flag aufgeführt, die Sie ändern können. 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. Beispiel: 100Mi, 1Gi. none Gibt die Menge an Arbeitsspeicher an, die vor dem vorläufigen Entfernen verfügbar war. Definiert die Menge des memory.available-Signals im Kubelet.
    nodefsAvailable Wert muss zwischen 10% und 50% liegen none Stellt das verfügbare nodefs vor dem vorläufigen Entfernen dar. Definiert die Menge des nodefs.available-Signals im Kubelet.
    nodefsInodesFree Wert muss zwischen 5% und 50% liegen none Stellt die Nodefs-Inodes dar, die vor dem vorläufigen Entfernen frei sind. Definiert die Menge des nodefs.inodesFree-Signals im Kubelet.
    imagefsAvailable Wert muss zwischen 15% und 50% liegen none Stellt das Image-Dateisystem dar, das vor dem vorläufigen Entfernen verfügbar war. Definiert die Menge des imagefs.available-Signals im Kubelet.
    imagefsInodesFree Wert muss zwischen 5% und 50% liegen none Stellt die Imagefs-Inodes dar, die vor dem vorläufigen Entfernen frei sind. Definiert die Menge des imagefs.inodesFree-Signals im Kubelet.
    pidAvailable Wert muss zwischen 10% und 50% liegen none Stellt die PIDs dar, die vor dem vorläufigen Entfernen verfügbar waren. 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.

    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 Speicherressourcen (Huge Pages) konfiguriert sind. Weitere Informationen finden Sie unter Node Resource Managers.

    Mit GKE können Sie die folgenden Einstellungen für diese Ressourcenmanager konfigurieren. Sie können diese Einstellungen unabhängig voneinander konfigurieren. Wir empfehlen jedoch, sie gemeinsam zu verwenden, um die Ressourcenverwaltung aufeinander abzustimmen. Sie können die Topology Manager-Einstellungen zusammen mit den CPU Manager- und Memory Manager-Einstellungen verwenden, um CPU und Speicher mit anderen angeforderten Ressourcen in der Pod-Spezifikation abzustimmen.

    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

    Diese Einstellung steuert die Memory Manager-Richtlinie von Kubelet. Mit dem Standardwert None verhält sich Kubernetes so, als wäre der Memory Manager nicht vorhanden. Weitere Informationen finden Sie unter „None“-Richtlinie.

    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:
        policy:
        scope:
    		Der Wert muss eine der unterstützten Einstellungen für die jeweiligen Felder sein.
    • Der Standardwert für „topologyManager.policy“ ist none.
    • Der Standardwert für „topoloyManager.scope“ ist container.

    Diese Einstellungen steuern die Topology Manager-Richtlinie von Kubelet, die die Gruppe von Komponenten koordiniert, 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, M3, N4

    Das folgende Beispiel zeigt eine Knotensystemkonfiguration, in der alle drei Resource Manager-Richtlinien konfiguriert sind:

    cpuManagerPolicy: static
memoryManager:
  policy: Static
topologyManager:
  policy: best-effort
  scope: pod

    Sysctl-Konfigurationsoptionen

    Zur Optimierung der Leistung Ihres Systems können Sie die folgenden Kernel-Attribute ändern:

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

    Das Kubelet und die Containerlaufzeit 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 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 auf 1.26 wird die Einstellung nicht auf cgroupv2 geändert, da vorhandene Knotenpools, die mit einer früheren Version als 1.26 erstellt wurden - ohne benutzerdefinierte cgroup-Konfiguration - weiterhin cgroupv1 vewenden, sofern Sie nichts anderes 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 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.
      • Prüfen Sie, ob alle Monitoring-Tools oder Drittanbieter-Tools mit cgroupv2 kompatibel sind.
    • Wenn Sie JDK (Java-Arbeitslast) 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

    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 mynode im Befehl durch den Namen eines beliebigen Knotens im Knotenpool.
    2. Cgroup-Version auf Linux-Knoten ermitteln.

    Konfigurationsoptionen für Linux-Huge-Pages

    Sie können die Konfigurationsdatei des Knotensystems verwenden, um die Linux-Kernelfunktion Huge Pages zu nutzen.

    Kubernetes unterstützt Huge Pages auf Knoten als eine Art von Ressource, ähnlich wie CPU oder Arbeitsspeicher. Mit den folgenden Parametern können Sie Ihre Kubernetes-Knoten anweisen, Huge Pages für die Verwendung durch Pods vorab zuzuweisen. Informationen zum Verwalten des Verbrauchs von Huge Pages durch Ihre Pods finden Sie unter HugePages verwalten.

    Wenn Sie Huge Pages für Ihre Knoten vorab zuweisen möchten, geben Sie die Anzahl und Größe an. Wenn Sie Ihre Knoten beispielsweise so konfigurieren möchten, dass drei Huge Pages mit einer Größe von 1 Gigabyte und 1.024 Huge Pages mit einer Größe von 2 Megabyte zugewiesen werden, verwenden Sie eine Knotensystemkonfiguration wie die folgende:

    linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

    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 60% des gesamten Arbeitsspeichers auf Maschinen mit weniger als 30 GB Arbeitsspeicher und 80% auf Maschinen mit mehr als 30 GB Arbeitsspeicher nicht überschreiten. Auf 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 einer c4a-standard-8-Instanz mit 32 GB Arbeitsspeicher dürfen Huge Pages nicht mehr als 25, 6 GB belegen.
    • 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.

    Unterstützung von Transparent Huge Pages

    Sie können die Konfigurationsdatei des Knotensystems verwenden, um die Linux-Kernelfunktion Transparent HugePage Support zu aktivieren. Die Unterstützung von Transparent Huge Pages (THP) ist eine alternative Lösung zur statischen Huge Page. Bei THP weist der Kernel Prozessen automatisch Huge Pages zu. Huge Pages müssen also nicht manuell reserviert werden. Die folgenden Felder werden unterstützt:

    linuxConfig:
  transparentHugepageEnabled: TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS
  transparentHugepageDefrag: TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS

    • Mit transparentHugepageEnabled wird die Unterstützung von transparenten Huge Pages für anonymen Speicher gesteuert. Folgende Werte werden unterstützt:

      • 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 Standardkonfiguration des Kernels.
      • TRANSPARENT_HUGEPAGE_ENABLED_NEVER: Transparent Hugepage ist deaktiviert.
      • TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: Standardwert. GKE ändert die Kernelkonfiguration nicht.

    • transparentHugepageDefrag definiert die Defrag-Konfiguration für Transparent Huge Page auf dem Knoten. Folgende Werte werden unterstützt:

      • TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: Eine Anwendung, die THP anfordert, wird bei einem Zuweisungsfehler angehalten und versucht, Seiten direkt zurückzufordern und den Speicher zu komprimieren, 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 immer 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 zurückzufordern, und kcompactd wird aktiviert, um den Speicher zu komprimieren, damit THP in naher Zukunft verfügbar ist.
      • TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: Eine Anwendung führt wie immer Direct Reclaim und Verdichtung aus, aber 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 verdichten, damit THP in naher Zukunft verfügbar ist.
      • TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: Eine Anwendung wird nie direkt zurückgefordert oder komprimiert.
      • TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: Standardwert. GKE ändert die Kernelkonfiguration nicht.

    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