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 Imagecos_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 Imagecos
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 Imageubuntu_containerd
verwendet Containerd als Containerlaufzeit. Weitere Informationen finden Sie unter Containerd-Images verwenden.Ubuntu mit Docker (
ubuntu
): Das Imageubuntu
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 |
---|---|---|
/ |
|
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 |
|
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 |
|
Diese Pfade gehören zu Arbeitsverzeichnissen für Compute Engine-Pakete (z. B. den Account-Manager-Dienst), Docker bzw. Toolbox. |
/var/lib/cloud |
|
Dieser Pfad gehört zum Arbeitsverzeichnis des cloud-init-Pakets. |
/etc |
|
/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 |
|
/tmp wird normalerweise als temporärer Speicherbereich verwendet und sollte nicht zum Speichern von nichtflüchtigen Daten genutzt werden. |
/mnt/disks |
|
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.