Knotenimages

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

Sie können beim Erstellen eines GKE-Clusters oder -Knotenpools das auf jedem Knoten auszuführende Betriebssystem-Image auswählen. Sie können auch einen vorhandenen Cluster aktualisieren, um einen anderen Knoten-Image-Typ zu verwenden. Eine Anleitung zum Festlegen des Knoten-Images 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	Container-Optimized OS mit containerd (cos_containerd) Container-Optimized OS mit Docker (cos)
Ubuntu	Ubuntu mit containerd (ubuntu_containerd) Ubuntu mit Docker (ubuntu)
Windows Server	Windows Server LTSC mit containerd (windows_ltsc_containerd) Windows Server SAC mit containerd (windows_sac_containerd) Windows Server LTSC mit Docker (windows_ltsc) Windows Server SAC mit Docker (windows_sac)

Hinweis: GKE Autopilot-Cluster verwenden nur das Knoten-Image cos_containerd.

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.

Hinweis: Für GKE-Knoten ist die automatische Aktualisierung von Container-Optimized OS deaktiviert. GKE hat eine eigene automatische Upgradefunktion, die stattdessen verwendet werden kann.

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

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. Weitere Informationen finden Sie unter Containerd-Knoten-Images.
• Container-Optimized OS mit Docker (cos): Das Image cos verwendet die Docker-Containerlaufzeit.

Warnung: Seit der GKE-Knotenversion 1.19 ist die Docker-Container-Laufzeit verworfen. Statt die Variante Container-Optimized OS mit Docker (cos) zu verwenden, migrieren Sie zur Variante von Container-Optimized OS mit containerd (cos_containerd), die jetzt das Standard-GKE-Knoten-Image ist.

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.

Warnung: Seit der GKE-Knotenversion 1.19 ist die Docker-Container-Laufzeit verworfen. Statt Ubuntu mit Docker (ubuntu) zu verwenden, migrieren Sie zur Variante Ubuntu mit containerd (ubuntu_containerd).

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.

• Docker-Laufzeit-Images (verfügbar in GKE-Knotenversion 1.16.8-gke.9 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.
• Containerd-Laufzeit-Images (verfügbar in GKE-Knotenversion 1.21.1-gke.2200 und höher):
  • Windows Server LTSC mit containerd (windows_ltsc_containerd): Das Image windows_ltsc_containerd verwendet containerd als Container-Laufzeit. Weitere Informationen 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.

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 enthält 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 zeigen Sie beispielsweise Docker-Daemon-Logs an:

sudo journalctl -u docker

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, wie z. B. über cloud-init definierte Dienste 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 oder 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 die Google Cloud Platform 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

Hinweis: Mithilfe von Container Storage Interface (Beta) können Sie in Ihrem Cluster auf einfache Weise Volume-Plug-ins verwenden. Sie sind somit nicht auf vorinstallierte OS-Pakete angewiesen.

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

Versionshinweise für Knoten-Images

Container-Optimized OS

Google bietet eine umfassende Dokumentation zu Container-Optimized OS:

• Dokumentation zu Container-Optimized OS
• Versionshinweise

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.

Weitere Informationen

• Knoten-Image angeben
• Knotenpools