Standardclusterarchitektur


Ein Cluster ist die Grundlage von Google Kubernetes Engine (GKE): Die Kubernetes-Objekte, die Ihre Containeranwendungen darstellen, werden alle auf einem Cluster ausgeführt.

In GKE besteht ein Cluster aus mindestens einer Steuerungsebene und mehreren Worker-Maschinen, die Knoten genannt werden. Auf diesen Maschinen der Steuerungsebenen und Knotenmaschinen wird das Cluster-Orchestrierungssystem Kubernetes ausgeführt.

Das folgende Diagramm bietet einen Überblick über die Architektur eines zonalen Clusters in GKE.

GKE übernimmt die Bereitstellung, Verwaltung und Ausführung für alles auf der zonalen Steuerungsebene und stellt nur die Knoten bereit.

Steuerungsebene

Auf der Steuerungsebene werden die Prozesse der Steuerungsebene ausgeführt, darunter der Kubernetes API-Server, der Planer und die Kernressourcen-Controller. Wenn Sie einen Cluster erstellen oder löschen, übernimmt GKE die Verwaltung des Lebenszyklus der Steuerungsebene. Hierzu gehören Upgrades der Kubernetes-Version, die auf der Steuerungsebene ausgeführt wird. Diese Upgrades werden von Kubernetes Engine entweder automatisch durchgeführt oder von Ihnen manuell gesteuert, falls Sie Upgrades vor dem automatisch geplanten Termin ausführen möchten.

Steuerungsebene und die Kubernetes API

Die Steuerungsebene ist der einheitliche Endpunkt für Ihren Cluster. Sie interagieren mit dem Cluster über Kubernetes API-Aufrufe und die Steuerungsebene führt den Kubernetes API-Serverprozess aus, um diese Anfragen zu verarbeiten. Sie können Kubernetes API-Aufrufe direkt über HTTP/gRPC oder indirekt ausführen. Dazu verwenden Sie die Befehle im Kubernetes-Befehlszeilenclient (kubectl) oder interagieren mit der UI in der Cloud Console.

Der API-Serverprozess ist der Hub für sämtliche Kommunikation, die sich an den Cluster richtet. Alle internen Clusterprozesse (wie Clusterknoten, System und Komponenten, Anwendungscontroller) fungieren als Clients des API-Servers; der API-Server ist für den gesamten Cluster die zentrale „Quelle der Wahrheit“.

Interaktion zwischen Steuerungsebene und Knoten

Die Steuerungsebene entscheidet darüber, was auf allen Knoten des Clusters ausgeführt wird. Die Steuerungsebene plant Arbeitslasten wie containerisierte Anwendungen und verwaltet den Lebenszyklus, die Skalierung und Upgrades der Arbeitslasten. Die Steuerungsebene verwaltet außerdem die Netzwerk- und Speicherressourcen für diese Arbeitslasten.

Die Steuerungsebene und die Knoten kommunizieren ebenfalls über die Kubernetes-APIs.

Interaktionen der Steuerungsebene mit Artifact Registry und Container Registry

Wenn Sie einen Cluster erstellen oder aktualisieren, werden Container-Images für auf der Steuerungsebene (und Knoten) ausgeführte Kubernetes-Software aus der Artifact Registry pkg.dev oder der Container Registry gcr.io abgerufen. Ein Ausfall, der diese Registries betrifft, kann zu folgenden Fehlern führen:

  • Während des Ausfalls können keine neuen Cluster erstellt werden.
  • Während des Ausfalls können keine Clusterupgrades durchgeführt werden.
  • Je nach Art und Dauer des Ausfalls können trotz Nutzereingriff Arbeitslasten unterbrochen werden.

Bei einem regionalen Ausfall der Artifact Registry pkg.dev oder der Container Registry gcr.io kann Google Anfragen an eine Zone oder Region weiterleiten, die nicht vom Ausfall betroffen ist.

Den aktuellen Status der Google Cloud-Dienste können Sie auf dem Google Cloud-Status-Dashboard prüfen.

Knoten

Ein Cluster besteht in der Regel aus einem oder mehreren Knoten, die als Worker-Maschinen fungieren und Containeranwendungen und andere Arbeitslasten ausführen. Die einzelnen Maschinen sind Compute Engine-VM-Instanzen, die beim Erstellen eines Clusters von GKE für Sie erstellt werden.

Jeder Knoten wird von der Steuerungsebene verwaltet, die von den Knoten selbst Statusaktualisierungen erhält. Sie können den Knotenlebenszyklus in gewissem Umfang manuell steuern oder in GKE automatische Reparaturen und automatische Upgrades der Clusterknoten ausführen lassen.

Ein Knoten führt die Dienste aus, die zur Unterstützung der Container erforderlich sind, aus denen die Arbeitslasten Ihres Clusters bestehen. Hierzu gehören der Laufzeit- und der Kubernetes-Knoten-Agent (kubelet), der mit der Steuerungsebene kommuniziert und dafür verantwortlich ist, die auf dem betreffenden Knoten geplanten Container zu starten und auszuführen.

In GKE gibt es ferner eine Reihe von Spezialcontainern, die als Pro-Knoten-Agents ausgeführt werden und Funktionen wie Logerfassung und Netzwerkverbindungen innerhalb von Clustern bieten.

Knoten-Maschinentyp

Jeder Knoten hat den standardmäßigen Maschinentyp von Compute Engine. Der Standardtyp ist e2-medium. Beim Erstellen des Clusters können Sie einen anderen Maschinentyp auswählen.

Betriebssystemimages von Knoten

Jeder Knoten verwendet ein spezielles Betriebssystemimage zum Ausführen Ihrer Container. Sie können angeben, welches Betriebssystemimage Ihre Cluster und Knotenpools verwenden sollen.

Mindest-CPU-Plattform

Beim Erstellen eines Clusters oder Knotenpools können Sie eine Mindest-CPU-Plattform für die zugehörigen Knoten angeben. Die Auswahl einer bestimmten CPU-Plattform hat Vorteile bei komplexen oder rechenintensiven Arbeitslasten. Weitere Informationen finden Sie unter Mindest-CPU-Plattform.

Für Knoten zuweisbare Ressourcen

Einige Ressourcen des Knotens werden zum Ausführen der GKE- und Kubernetes-Knotenkomponenten benötigt, die diesen Knoten als Teil des Clusters fungieren lassen. Deshalb kann es zu Abweichungen zwischen der Gesamtzahl der Ressourcen (wie in der Maschinentyp-Dokumentation festgelegt) und den zuweisbaren Ressourcen des Knotens in GKE kommen.

Auf größeren Maschinentypen werden in der Regel mehr Container (und daher auch mehr Pods) ausgeführt. GKE reserviert bei diesen Maschinen daher mehr Ressourcen für Kubernetes-Komponenten. Windows Server-Knoten benötigen außerdem mehr Ressourcen als ein typischer Linux-Knoten. Die Knoten benötigen die zusätzlichen Ressourcen, um das Windows-Betriebssystem auszuführen, und für die Windows Server-Komponenten, die nicht in Containern ausgeführt werden können.

Sie können Ressourcen für Ihre Pods anfordern oder deren Ressourcennutzung einschränken. Informationen zum Anfordern oder Einschränken der Ressourcennutzung für Pods finden Sie unter Ressourcen für Container verwalten.

Führen Sie den folgenden Befehl aus, um die in einem Cluster verfügbaren zuweisbaren Knotenressourcen zu überprüfen. Ersetzen Sie dabei NODE_NAME durch den Namen des Knotens, den Sie überprüfen möchten:

kubectl describe node NODE_NAME | grep Allocatable -B 7 -A 6

Die Ausgabe enthält die Felder Capacity und Allocatable mit Messwerten für den sitzungsspezifischen Speicher, den Arbeitsspeicher und die CPU.

Schwellenwert für die Bereinigung

Wenn Sie ermitteln möchten, wie viel Speicherplatz für Pods verfügbar ist, müssen Sie auch den Schwellenwert für die Bereinigung berücksichtigen. GKE reserviert zusätzlich 100 MiB Arbeitsspeicher pro Knoten für die Kubelet-Bereinigung.

Zuweisbare Arbeitsspeicher- und CPU-Ressourcen

Zuweisbare Ressourcen werden so berechnet:

ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD

Für Arbeitsspeicherressourcen reserviert GKE Folgendes:

  • 255 MiB Arbeitsspeicher für Geräte mit weniger als 1 GiB Arbeitsspeicher
  • 25% der ersten 4 GiB Arbeitsspeicher
  • 20% der nächsten 4 GiB Arbeitsspeicher (bis zu 8 GiB)
  • 10% der nächsten 8 GiB Arbeitsspeicher (bis zu 16 GiB)
  • 6% der nächsten 112 GiB Arbeitsspeicher (bis zu 128 GiB)
  • 2% sämtlichen Speichers oberhalb von 128 GiB

Für CPU-Ressourcen reserviert GKE Folgendes:

  • 6 % des ersten Kerns
  • 1 % des nächsten Kerns (bis zu zwei Kerne)
  • 0,5 % der nächsten zwei Kerne (bis zu vier Kerne)
  • 0,25 % aller Kerne oberhalb von vier Kernen

Zuweisbare lokale, sitzungsspezifische Speicherressourcen

Ab der GKE-Version 1.10 können Sie Ihre lokalen, sitzungsspezifischen Speicherressourcen wie Ihre CPU- und Arbeitsspeicherressourcen verwalten. Informationen dazu, wie Sie durch Ihre Pods sitzungsspezifische Speicheranforderungen und -beschränkungen festlegen lassen und wie mit diesen umzugehen ist, finden Sie unter Lokaler sitzungsspezifischer Speicher in der Kubernetes-Dokumentation.

GKE konfiguriert seine Knoten in der Regel mit einem einzelnen Dateisystem und regelmäßigen Scans. Sitzungsspezifischer Speicher kann auch von lokalen SSDs unterstützt werden. In beiden Fällen ist ein Teil des Dateisystems für die Verwendung von Kubelet reserviert. Der verbleibende Teil, zuweisbarer lokaler sitzungsspezifischer Speicher genannt, kann als Ressource für sitzungsspezifischen Speicher verwendet werden.

Der Umfang des Dateisystems, der für Kubelet und andere Systemkomponenten reserviert ist, wird durch Folgendes bestimmt:

EVICTION-THRESHOLD + SYSTEM-RESERVATION

Von Bootlaufwerk unterstützter sitzungsspezifischer Speicher

Standardmäßig wird sitzungsspezifischer Speicher vom Bootlaufwerk des Knotens unterstützt. In diesem Fall werden der Schwellenwert für die Bereinigung und die Größe der Systemreservierung gemäß folgenden Formeln festgelegt:

EVICTION-THRESHOLD = 10% * BOOT-DISK-CAPACITY

SYSTEM-RESERVATION = Min(50% * BOOT-DISK-CAPACITY, 6GB + 35% * BOOT-DISK-CAPACITY, 100 GB)

In der folgenden Grafik finden Sie eine ungefähre Darstellung der Menge des zuweisbaren sitzungsspezifischen Speichers bei steigender Bootlaufwerkkapazität:

Grafik, die zeigt, wie sitzungsspezifischer Speicher mit der Bootlaufwerkkapazität zunimmt. Die Beziehung ist in etwa linear.

Von lokalen SSDs unterstützter sitzungsspezifischer Speicher

Der für das System reservierte Speicherplatz hängt von der Anzahl der lokalen SSDs ab:

Anzahl der lokalen SSDs SYSTEM-RESERVATION (GB)
1 50
2 75
Mindestens drei 100

Der Schwellenwert für die Bereinigung entspricht dem sitzungsspezifischen Speicher, der vom Bootlaufwerk unterstützt wird:

EVICTION-THRESHOLD = 10% * NUM-LOCAL-SSDS * 375 GB

Die Kapazität einer lokalen SSD beträgt 375 GB. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Lokale SSDs hinzufügen.