GKE-Clusterarchitektur


Auf dieser Seite wird die Architektur eines GKE-Clusters (Google Kubernetes Engine) vorgestellt. Alle containerisierten Kubernetes-Arbeitslasten werden in einem GKE-Cluster ausgeführt.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die IT-Lösungen und die Systemarchitektur definieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Ein GKE-Cluster besteht aus einer Steuerungsebene und Worker-Maschinen, die Knoten genannt werden. Die Steuerungsebene und die Knoten bilden das Kubernetes. GKE Autopilot verwaltet die gesamte zugrunde liegende Infrastruktur der Cluster, einschließlich der Steuerungsebene, Knoten und aller Systemkomponenten. Wenn Sie den GKE-Standardmodus verwenden, verwaltet GKE die Steuerungsebene und die Systemkomponenten sowie die Knoten. Das folgende Diagramm zeigt die Architektur eines GKE-Clusters:

GKE-Clusterarchitektur. Die Steuerungsebene wird von GKE verwaltet und führt den API-Server, Ressourcen-Controller, Planer und Clusterspeicher aus. Die Knoten werden von GKE im Autopilot-Modus und vom Nutzer im Standardmodus verwaltet.
     Nutzer-Pods führen Container in Knoten aus. Für die Einbindung in GKE stehen weitere Google Cloud-Dienste zur Verfügung.

Informationen zur Steuerungsebene

Die Steuerungsebene führt Prozesse wie den Kubernetes API-Server, den Planer und die Kernressourcen-Controller aus. GKE verwaltet den Lebenszyklus der Steuerungsebene von der Clustererstellung bis zum Löschen. 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 der Steuerungsebene über Kubernetes API-Aufrufe. Die Steuerungsebene führt den Kubernetes API-Serverprozess (kube-apiserver) zur Verarbeitung von API-Anfragen aus. So können Sie Kubernetes API-Aufrufe ausführen:

  • Direkte Aufrufe: HTTP/gRPC
  • Indirekte Aufrufe: Kubernetes-Befehlszeilenclients wie kubectl oder die Google Cloud Console.

Der API-Serverprozess ist der Hub für sämtliche Kommunikation, die sich an den Cluster richtet. Alle internen Clusterkomponenten wie Knoten, Systemprozesse und Anwendungscontroller fungieren als Clients des API-Servers.

Die API-Anfragen teilen Kubernetes mit, was Ihr gewünschter Status für die Objekte in Ihrem Cluster ist. Kubernetes versucht, diesen Status ständig zu erhalten. Mit Kubernetes können Sie Objekte in der API imperativ oder deklarativ konfigurieren.

Weitere Informationen zur Objektverwaltung in Kubernetes finden Sie auf den folgenden Seiten:

Interaktion zwischen Steuerungsebene und Knoten

Die Steuerungsebene verwaltet, was auf allen Knoten des Clusters ausgeführt wird. Auf der Steuerungsebene werden Arbeitslasten geplant und der Lebenszyklus, die Skalierung und Upgrades der Arbeitslasten verwaltet. Die Steuerungsebene verwaltet außerdem die Netzwerk- und Speicherressourcen für diese Arbeitslasten. Die Steuerungsebene und die Knoten kommunizieren über Kubernetes-APIs miteinander.

Interaktionen der Steuerungsebene mit Artifact Registry

Wenn Sie einen Cluster erstellen oder aktualisieren, ruft GKE Container-Images für die Kubernetes-Systemsoftware, die auf der Steuerungsebene und den Knoten ausgeführt wird, aus der Artifact Registry pkg.dev oder der Container Registry gcr.io ab. Ein Ausfall, der diese Registries betrifft, kann dazu führen, dass die folgenden Aktionen fehlschlagen:

  • Neue Cluster erstellen
  • Clusterversion upgraden

Je nach Art und Dauer des Ausfalls kann es auch ohne Ihr Eingreifen zu Unterbrechungen der Arbeitslast kommen.

Wenn der Ausfall der Artifact Registry pkg.dev oder der Container Registry gcr.io regionaler Natur ist, leiten wir die Anfragen möglicherweise an eine Zone oder Region um, die nicht vom Ausfall betroffen ist.

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

Best Practice:

Stellen Sie in mehreren Regionen bereit, um die Verfügbarkeit von Anwendungen bei regionalen Ausfällen zu ermöglichen.

Über die Knoten

Knoten sind die Worker-Maschinen, auf denen Ihre Containeranwendungen und andere Arbeitslasten ausgeführt werden. Die einzelnen Maschinen sind virtuelle Compute Engine-Maschinen (VMs), die von GKE erstellt werden. Die Steuerungsebene verwaltet und empfängt Aktualisierungen für den selbst gemeldeten Status jedes Knotens.

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.

GKE führt auch eine Reihe von Systemcontainern aus, die als Agenten pro Knoten ausgeführt werden, sogenannte DaemonSets, die Funktionen wie Logerfassung und Netzwerkverbindungen innerhalb des Clusters bereitstellen.

Best Practice:

Verwenden Sie stdout für containerisierte Anwendungen, da Ihre Plattform mit stdout die Anwendungslogs verarbeiten kann.

Die Knotenverwaltung variiert je nach Betriebsmodus des Clusters:
Knotenkomponente Autopilot-Modus Standardmodus
Lifecycle

Vollständig von GKE verwaltet, einschließlich:

GKE verwaltet Folgendes:

Sie können Folgendes verwalten:

Sichtbarkeit Knoten mit kubectl ansehen. Zugrunde liegende Compute Engine-VMs, die in der gcloud CLI oder der Google Cloud Console nicht sichtbar oder nicht zugänglich sind. Knoten mit kubectl, der gcloud CLI und der Google Cloud Console ansehen Zugrunde liegende Compute Engine-VMs aufrufen und darauf zugreifen
Verbindung Keine direkte Verbindung zu den zugrunde liegenden VMs. Stellen Sie eine SSH-Verbindung zu den zugrunde liegenden VMs her.
Betriebssystem des Knotens Von GKE verwaltet. Alle Knoten verwenden Container-Optimized OS mit containerd (cos_containerd). Wählen Sie ein Betriebssystem für Ihre Knoten aus.
Auswahl der Maschinenhardware

Fordern Sie je nach Anwendungsfall Compute-Klassen in Pods an.

GKE verwaltet Maschinenkonfiguration, Planung, Menge und Lebenszyklus.

Wählen Sie beim Erstellen von Knotenpools Compute Engine-Maschinentypen aus und konfigurieren Sie sie. Konfigurieren Sie Einstellungen für Größe, Skalierung, Menge, Planung und Standort nach Bedarf.