Knotenimages

Auf dieser Seite werden die Knoten-Images beschrieben, die für Google Kubernetes Engine-Knoten (GKE) verfügbar sind.

GKE Autopilot-Knoten verwenden immer Container-Optimized OS mit containerd (cos_containerd), dem empfohlenen Knotenbetriebssystem. Wenn Sie GKE Standard verwenden, können Sie während der Erstellung des Clusters oder der Knotenpools das Betriebssystem-Image auswählen, das auf jedem Knoten ausgeführt wird. Sie können auch einen vorhandenen Standardcluster aktualisieren, um ein anderes Knoten-Image zu verwenden. Eine Anleitung zum Festlegen des Knoten-Image finden Sie unter Knoten-Image angeben.

Verfügbare Knoten-Images

GKE bietet je nach Betriebssystem die folgenden Knoten-Image-Optionen für den Cluster:

Betriebssystem Knotenimages
Container-Optimized OS
Ubuntu
Windows Server

Container-Optimized OS

Die Knoten-Images des Container-Optimized OS von Google basieren auf einer aktuellen Version des Linux-Kernels und sind optimiert, um die Knotensicherheit zu verbessern. Für die Images des Container-Optimized OS ist ein Google-Team zuständig, das in Sicherheitsfällen schnell Patches für Images einspielen und Features iterieren kann. Die Images des Container-Optimized OS bieten gegenüber anderen Images einen besseren Support sowie mehr Sicherheit und Stabilität.

Informationen zum Image-Projekt und zur Image-Familie finden Sie unter Knoten-Image-Quellprojekte.

Varianten von Container-Optimized OS

Mit Container-Optimized OS werden zwei Container-Laufzeiten angeboten. Die Images sind bis auf die Auswahl der Container-Laufzeit identisch.

  • Container-Optimized OS mit containerd (cos_containerd): Das Image cos_containerd nutzt containerd als Container-Laufzeit, die direkt in Kubernetes eingebunden ist. GKE Autopilot-Cluster verwenden immer dieses Image. Weitere Informationen finden Sie unter Containerd-Knoten-Images.
  • Container-Optimized OS mit Docker (cos): Das Image cos verwendet die Docker-Containerlaufzeit.

Ubuntu

Die Ubuntu-Knoten-Images wurden hinsichtlich der Anforderungen für Knoten-Images in GKE validiert. Verwenden Sie die Ubuntu-Knoten-Images, wenn die Knoten Unterstützung für XFS-, CephFS- oder Debian-Pakete erfordern.

Weitere Informationen zum Image-Projekt und zur Image-Familie finden Sie unter Featureunterstützung nach Betriebssystem.

Ubuntu-Varianten

Für Ubuntu sind zwei Container-Laufzeiten verfügbar. Die Images sind bis auf die Auswahl der Container-Laufzeit identisch.

  • Ubuntu mit containerd (ubuntu_containerd): Das Image ubuntu_containerd nutzt containerd als Container-Laufzeit. Weitere Informationen finden Sie unter Knoten-Images.

  • Ubuntu mit Docker (ubuntu): Das Image ubuntu verwendet Docker als Containerlaufzeit.

Windows Server

Beim Erstellen eines Clusters mit Windows Server-Knotenpools können Sie ein Knoten-Image für Windows Server Semi-Annual Channel (SAC) oder Windows Server Long-Term Servicing Channel (LTSC) verwenden. Alle Windows-Knoten-Images sind Windows Server Datacenter Core-Images. Ein einzelner Cluster kann mehrere Windows Server-Knotenpools mit unterschiedlichen Windows Server-Versionen haben, aber jeder einzelne Knotenpool darf nur eine einzige Windows Server-Version verwenden. Weitere Informationen finden Sie unter Windows-Knoten-Image auswählen.

Mit Windows Server LTSC- und SAC-Knoten-Images werden zwei Container-Laufzeiten angeboten: Docker und containerd. Die Images sind bis auf die Auswahl der Container-Laufzeit identisch.

  • Containerd-Laufzeit-Images (verfügbar in GKE-Version 1.21 und höher):

    • Windows Server LTSC mit containerd (windows_ltsc_containerd): Das Image windows_ltsc_containerd verwendet containerd als Container-Laufzeit. Derzeit ist dieser Image-Typ zwei Knoten-Images zugeordnet: Windows Server 2022 und Windows Server 2019. Sie können Windows LTSC2022-Knotenpools über den Befehlszeilenbefehl mit dem Flag windows-os-version erstellen.

      Weitere Informationen zum Erstellen von Windows Server 2022-Knotenpools finden Sie unter Windows-Knotenpools erstellen.

      Weitere Informationen zu containerd-Knoten-Images finden Sie unter Containerd-Knoten-Images.

    • Windows Server SAC mit containerd (windows_sac_containerd): Das Image windows_sac_containerd verwendet containerd als Container-Laufzeit.

      Weitere Informationen finden Sie unter Containerd-Knoten-Images.

  • Docker-Laufzeit-Images (verfügbar in GKE-Version 1.16 und höher):

    • Windows Server LTSC mit Docker (windows_ltsc): Das Image windows_ltsc verwendet Docker als Containerlaufzeit.
    • Windows Server SAC mit Docker (windows_sac): Das Image windows_sac verwendet Docker als Containerlaufzeit.

Weitere Informationen zum Image-Projekt und zur Image-Familie finden Sie unter Featureunterstützung nach Betriebssystem.

Linux-Knoten-Images im Vergleich

In den nächsten Abschnitten werden die folgenden betrieblichen Aspekte der Knoten-Images für Container-Optimized OS und Ubuntu verglichen:

  • Softwarepaketmanagement
  • Systeminitialisierung
  • Logerfassung
  • Dateisystemlayout
  • Unterstützung für Speichertreiber

Softwarepaketmanager

Die Knoten-Images cos und cos_containerd verwenden ein minimales Root-Dateisystem mit integrierter Unterstützung für die Docker-Containerlaufzeit (containerd). Dieses dient gleichzeitig als Softwarepaketmanager, mit dem Sie Software auf dem Host installieren können. Für das Ubuntu-Image wird der APT-Paketmanager verwendet.

Software auf Container-Optimized OS verwalten

Das Container-Optimized OS-Image bietet keine Paketverwaltungssoftware wie apt-get. Sie können über herkömmliche Mechanismen keine beliebige Software auf den Knoten installieren. Erstellen Sie stattdessen ein Container-Image, das die benötigte Software enthält.

Container-Optimized OS umfasst auf Standardclustern zu Debugging-Zwecken die CoreOS Toolbox, mit der gängige Debugging-Tools wie ping, psmisc oder pstree installiert und ausgeführt werden können. Weitere Informationen zum Debugging von Container-Optimized OS-Knoten finden Sie unter Anleitungen zu Container-Optimized OS.

Software auf Ubuntu verwalten

Für das Ubuntu-Image wird der APT-Paketmanager verwendet. Mit dem Befehl apt-get können Sie Pakete auf diesen Images installieren. Beispielsweise können Sie so ceph-Pakete installieren:

sudo apt-get update
sudo apt-get install ceph

Systeminitialisierung

Sowohl das Container-Optimized OS- als auch das Ubuntu-Knoten-Image nutzen systemd, um während der Systeminitialisierung Systemressourcen und Services zu verwalten.

Beide Knoten-Images verwenden Servicedateien vom Typ "systemd", um mit services Services auf dem Knoten zu definieren und mit systemd.targets Bootziele nach Abhängigkeiten zu gruppieren.

Logs erfassen

Die Container-Optimized OS- und Ubuntu-Knoten-Images verwenden zum Erfassen systemweiter Logs systemd-journald.

Logs auf Container-Optimized OS und Ubuntu ansehen

Mit dem Befehl journalctl können Sie Logs auf einem Knoten mit dem Knoten-Image für Container-Optimized OS oder Ubuntu aufrufen. So rufen Sie beispielsweise containerd-Daemon-Logs auf:

sudo journalctl -u containerd

So zeigen Sie kubelet-Logs an:

sudo journalctl -u kubelet

Dateisystemlayout

Das Ubuntu-Knoten-Image verwendet das Standardlayout des Linux-Dateisystems.

Das Dateisystemlayout für das Container-Optimized OS-Knoten-Image wurde optimiert, um die Knotensicherheit zu verbessern. Der Boot-Speicherplatz ist in drei Arten von Partitionen aufgeteilt:

  • Root-Partition, die schreibgeschützt bereitgestellt wird
  • Zustandsorientierte Partitionen, die bearbeitbar und zustandsorientiert sind
  • Zustandslose Partitionen, die zwar bearbeitbar sind, deren Inhalte jedoch bei einem Neustart nicht erhalten bleiben

Wenn Sie Container-Optimized OS nutzen, beachten Sie die Partitionierung, wenn Sie eigene Dienste ausführen, die bestimmte "Erwartungen" an das Dateisystemlayout außerhalb von Containern haben.

Mit dem Container-Optimized OS-Dateisystem arbeiten

Im Folgenden finden Sie eine Liste der Pfade im Dateisystem des Container-Optimized OS-Knoten-Images sowie deren Attribute und empfohlene Verwendung:

Pfad Attribute Zweck
/
  • Schreibgeschützt
  • Ausführbar
 Das Root-Dateisystem wird zur Wahrung der Integrität schreibgeschützt zur Verfügung gestellt. Der Kernel überprüft die Integrität des Root-Dateisystems beim Starten und verweigert den Start, wenn Fehler vorliegen.
/home
/var
  • Bearbeitbar
  • Nicht ausführbar
  • Zustandsorientiert
 Diese Pfade dienen zum Speichern von Daten, die für die Lebensdauer des Startdatenträgers bestehen bleiben. Sie werden über /mnt/stateful_partition bereitgestellt.
/var/lib/google
/var/lib/docker
/var/lib/toolbox
  • Bearbeitbar
  • Ausführbar
  • Zustandsorientiert
 Diese Pfade gehören zu Arbeitsverzeichnissen für Compute Engine-Pakete (z. B. den Account-Manager-Dienst), Docker bzw. Toolbox.
/var/lib/cloud
  • Bearbeitbar
  • Ausführbar
  • Zustandslos
  • tmpfs
 Dieser Pfad ist das Arbeitsverzeichnis des Pakets cloud-init.
/etc
  • Bearbeitbar
  • Nicht ausführbar
  • Zustandslos
  • tmpfs
 Enthält normalerweise Ihre Konfiguration. Beispiel: über cloud-init definierte Services vom Typ systemd. Es empfiehlt sich, den gewünschten Status Ihrer Instanzen in cloud-init zu erfassen, da cloud-init zur Anwendung kommt, wenn eine Instanz neu erstellt und wenn eine Instanz neu gestartet wird.
/tmp
  • Bearbeitbar
  • Nicht ausführbar
  • Zustandslos
  • tmpfs
 Wird normalerweise als temporärer Speicherbereich verwendet und sollte nicht zum Speichern von nichtflüchtigen Daten verwendet werden.
/mnt/disks
  • Bearbeitbar
  • Ausführbar
  • Zustandslos
  • tmpfs
 Sie können nichtflüchtige Speicher in Verzeichnissen unter /mnt/disks bereitstellen.

Unterstützung für Speichertreiber

Die Knoten-Images unterscheiden sich in Bezug auf die unterstützten Speicher-Plug-ins. Die folgenden Regelungen gelten bei der Beschreibung der Unterstützung eines Knoten-Images für einen bestimmten Speichertreiber:

  • Ja – Vollständig getestet/unterstützt: Dieses Speicher-Plug-in wird komplett unterstützt und wurde mit dem spezifischen Knoten-Image getestet.
  • Ja – Eingeschränkte Tests: Dieses Speicher-Plug-in arbeitet mit dem angegebenen Knoten-Image, wurde jedoch nur eingeschränkt getestet. Es können unerwartete Probleme auftreten. Für Container-Optimized OS werden diese Plug-ins noch vollständig getestet und unterstützt.
  • Nicht unterstützt: Dieses Speicher-Plug-in wurde mit dem angegebenen Knoten-Image weder getestet noch verwendet. GKE übernimmt keine Garantie für die Funktionsfähigkeit. Es ist nicht geplant, dieses Speicher-Plug-in zu testen.
  • Nein: Dieses Speicher-Plug-in funktioniert aufgrund von Beschränkungen in Bezug auf das Knotenbetriebssystem oder Google Cloud nicht mit dem angegebenen Knoten-Image.

Nachfolgend wird beschrieben, welche gängigen Speicher-Plug-ins von den GKE-Knoten-Images unterstützt werden:

Volume-Typ Funktionsfähig auf Container-Optimized OS (cos)? Funktionsfähig auf Ubuntu?
Compute Engine
Persistent Disk (EXT4 oder XFS)		 Ja – Vollständig getestet/unterstützt
(XFS wird nur in cos-85 und höher unterstützt.) Siehe GKE-Versionshinweise 		Ja – Vollständig getestet/unterstützt
NFSv3 Ja – Vollständig getestet/unterstützt Ja – Vollständig getestet/unterstützt
NFSv4 Ja – Vollständig getestet/unterstützt Ja – Vollständig getestet/unterstützt
CephFS Nein. Ja – Eingeschränkte Tests
(Der Treiber ist standardmäßig nicht installiert. Sie müssen den ceph-Client installieren, vorzugsweise über DaemonSet.)
Cinder Nein. Nein.
Fibre Channel Nein. Nein.
Flocker Nicht unterstützt Nicht unterstützt
iSCSI Nein. Nein.
RBD Nein. Nein

Änderungen der Knoten-VMs

Änderungen am Bootlaufwerk einer Knoten-VM gehen bei der Neuerstellung von Knoten verloren. Knoten werden bei manuellen Upgrades und automatischen Upgrades sowie bei automatischen Reparaturen und beim Autoscaling neu erstellt. Außerdem werden Knoten neu erstellt, wenn Sie ein Feature aktivieren, das ein erneutes Erstellen der Knoten erfordert, z. B. GKE Sandbox, knoteninterne Sichtbarkeit und Shielded-Knoten.

Verwenden Sie ein DaemonSet, um Änderungen beizubehalten, wenn Knoten neu erstellt werden.

Es wird nicht empfohlen, kritische Software zu verwenden, die von einem Knoten-Image bereitgestellt wird, z. B. die Kernel- oder Container-Laufzeit (containerd oder docker). Knoten-Images werden umfassend getestet. Durch Änderungen an kritischer Software im Knoten-Image wird der Knoten in einen unbekannten und nicht testbaren Zustand versetzt. GKE Autopilot-Knoten lassen keine Änderungen der Knotensoftware zu.

Versionshinweise für Knoten-Images

Container-Optimized OS

Google bietet eine umfassende Dokumentation zu Container-Optimized OS:

Ubuntu

Die auf Ihren Clusterknoten verfügbaren Ubuntu-Images werden regelmäßig von Google aktualisiert. Informationen zu diesen Aktualisierungen finden Sie in den Versionshinweisen von GKE. Über einen Link gelangen Sie zu einem Manifest mit einer Liste der standardmäßig installierten Pakete.

Bekannte Probleme

Zufälliges Zurücksetzen von Verbindungen auf GKE-Knoten unter Verwendung von Container-Optimized OS mit Docker-Laufzeit

Auf GKE-Knoten, die Container-Optimized OS mit Docker (cos) verwenden, werden TCP-Verbindungen möglicherweise zufällig zurückgesetzt, wenn zwei Pods auf demselben Knoten über einen Kubernetes-ClusterIP-Service kommunizieren.

Die folgenden GKE-Versionen sind betroffen:

  • 1.20.5-gke.100 oder höher

Verwenden Sie eine der folgenden Optionen, um das Problem zu umgehen:

Knotenimage-Quellprojekte

Die verfügbaren Knoten-Images für GKE-Cluster sind in den folgenden Quellprojekten enthalten:

  • Container-Optimized OS-Images: gke-node-images
  • Ubuntu-Images: ubuntu-os-gke-cloud
  • Windows Server-Images: gke-windows-node-images

Zusätzlich zu den oben aufgeführten Quellprojekten verwendet GKE auch die folgenden Quellprojekte für die exklusive Nutzung durch das GKE-Team:

  • ubuntu-os-gke-cloud-private (reserviert für die exklusive Nutzung des GKE-Teams)
  • ubuntu-os-gke-cloud-devel (reserviert für die exklusive Nutzung des GKE-Teams)

Möglicherweise müssen Sie die Namen des Quellprojekts kennen, wenn Sie hochsichere Cluster einrichten. Die aufgeführten Quellprojekte können sich ändern.

Nächste Schritte