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
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 Featureunterstützung nach Betriebssystem.

Varianten von Container-Optimized OS

Zwei Containerlaufzeiten werden mit Container-Optimized OS angeboten. Die Images sind bis auf die Auswahl der Containerlaufzeit identisch.

  • Container-Optimized OS mit Containerd (cos_containerd): Das Image cos_containerd verwendet Containerd als Containerlaufzeit, die direkt in Kubernetes eingebunden ist. Weitere Informationen finden Sie unter Containerd-Images verwenden.
  • 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 Containerlaufzeiten verfügbar. Die Images sind identisch, abgesehen von der Auswahl der Containerlaufzeit.

  • Ubuntu mit Containerd (ubuntu_containerd): Das Image ubuntu_containerd verwendet Containerd als Containerlaufzeit. Weitere Informationen finden Sie unter Containerd-Images verwenden.

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

Windows Server LTSC und Windows Server SAC

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.

Diese Images sind nur für Cluster mit Versionen ab 1.16.8-gke.9 verfügbar.

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 gehört zum Arbeitsverzeichnis des cloud-init-Pakets.
/etc
  • Bearbeitbar
  • Nicht ausführbar
  • Zustandslos
  • tmpfs
 /etc 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
 /tmp wird normalerweise als temporärer Speicherbereich verwendet und sollte nicht zum Speichern von nichtflüchtigen Daten genutzt 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?
Google Compute Engine
Nichtflüchtiger Speicher (EXT4 oder XFS)		 Ja – Vollständig getestet/unterstützt
(XFS wird nicht unterstützt.)		 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.

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.

Weitere Informationen