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.

Weitere Informationen zum Image-Projekt und zur Image-Familie finden Sie unter Quellprojekte für Knoten-Images.

Varianten von Container-Optimized OS

Sie können das folgende Container-Optimized OS-Image verwenden:

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

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

Sie können das folgende Ubuntu-Image verwenden:

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

Windows Server

Beim Erstellen eines Clusters mit Windows Server-Knotenpools können Sie ein Knoten-Image für Windows Server Long-Term Servicing Channel (LTSC) verwenden. Dieses Windows-Knoten-Image ist ein Windows Server Datacenter Core-Image. 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.

Sie können das folgende Windows Server-Image verwenden:

  • 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 gcloud CLI-Befehl 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.

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.

Logerfassung

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 Eigenschaften 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
  • 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 Cloudnicht 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

Zeitsynchronisierung

Sowohl Container-Optimized OS- als auch Ubuntu-Knoten-Images verwenden einen internen NTP-Server (Network Time Protocol) als primäre Zeitquelle. Dieser interne NTP-Server wird identisch mit Google Public NTP verteilt.

Wenn der interne NTP-Server nicht verfügbar ist, verwenden sowohl Container-Optimized OS- als auch Ubuntu-Knoten-Images die Echtzeituhr (RTC), also die Hardwareuhr des Hostcomputers, als Backup-Zeitquelle.

Generierung von Zufallszahlen

Auf Container-Optimized OS- und Ubuntu-Knoten haben Pods Zugriff auf die Dateien /dev/random und /dev/urandom. Diese Dateien enthalten Zufallszahlen, die von Virtio RNG aus einem Entropiepool bereitgestellt werden, der von der Compute Engine-Instanz generiert wird.

Ä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 davon abgeraten, kritische Software wie etwa die Kernel- oder Containerlaufzeit zu verwalten, die durch ein Knoten-Image bereitgestellt wird. Knoten-Images werden ausführlich getestet. Änderungen an kritischer Software, die im Knoten-Image bereitgestellt wird, versetzen den Knoten in einen unbekannten und nicht testbaren Zustand. Bei GKE Autopilot-Knoten kann die Knotensoftware nicht geändert werden.

Container-Optimized OS-Knoten-Image-Versionen GKE-Patchversionen zuordnen

GKE veröffentlicht eine JSON-Zuordnung von GKE-Patchversionen zu Container-Optimized OS-Knoten-Image-Versionen:

Mit dieser Zuordnung können Sie auf eine bestimmte Version von GKE aktualisieren, um eine bestimmte Image-Version zu erhalten. Wenn Ihr Cluster beispielsweise ein bestimmtes Feature oder einen bestimmten Fix aus einer Image-Version benötigt, können Sie die Zuordnung finden und Ihren Cluster auf eine bestimmte GKE-Version aktualisieren, um die Container-Optimized OS-Image-Version mit den Änderungen zu erhalten. Details zu Container-Optimized OS-Image-Releases finden Sie in den Versionshinweisen zu Container-Optimized OS.

Diese Liste wird ungefähr wöchentlich aktualisiert. Informationen zur Aktualität der Daten finden Sie im Feld creation_time der JSON-Datei.

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.

Quellprojekte für Knotenimages

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 zur exklusiven Nutzung durch das GKE-Team:

  • ubuntu-os-gke-cloud-private (reserviert für die ausschließliche Verwendung durch das GKE-Team)
  • ubuntu-os-gke-cloud-devel (reserviert für die ausschließliche Verwendung durch das GKE-Team)

Möglicherweise benötigen Sie die Namen der Quellprojekte, wenn Sie hochsichere Cluster einrichten. Die aufgeführten Quellprojekte können sich ändern.

Nächste Schritte