GKE-Clusterarchitektur

Auf dieser Seite wird die Architektur der GKE-Cluster (Google Kubernetes Engine) beschrieben, auf denen Ihre containerisierten Arbeitslasten ausgeführt werden. Hier erfahren Sie mehr über die Steuerungsebene, Knoten und die Interaktion der verschiedenen GKE-Clusterkomponenten miteinander.

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

Machen Sie sich vor dem Lesen dieser Seite mit der Kubernetes-Clusterarchitektur vertraut.

Ein GKE-Cluster besteht aus einer Steuerungsebene und Worker-Maschinen, die Knoten genannt werden. Die Steuerungsebene und die Knoten bilden das Kubernetes-Cluster-Orchestrierungssystem. 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-Cluster:

Dieses Diagramm zeigt die folgenden Komponenten:

  • Steuerungsebene: von GKE verwaltet. Führt den Kubernetes API-Server, Arbeitslastcontroller, Kubernetes-Planer und Clusterspeicherung aus.
  • Knoten: im Autopilot-Modus von GKE und im Standardmodus von Kunden verwaltet. Alle Ihre Pods werden auf Knoten ausgeführt.
  • Andere Google Cloud Dienste: für die Einbindung in GKE verfügbar.

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:

Steuerungsebene und die Clusterstatusdatenbank

Im Open-Source-Kubernetes-Projekt wird standardmäßig etcd als Speicherdatenbank für alle Clusterdaten verwendet. Der Clusterstatus wird in einem Schlüssel/Wert-Speicher aufbewahrt, der Informationen zum Status jedes Kubernetes API-Objekts in Ihrem Cluster enthält. In der Clusterstatusdatenbank werden beispielsweise alle Secrets, ConfigMaps und Bereitstellungen gespeichert.

In GKE-Clustern wird der Clusterstatus in einem der folgenden Schlüssel/Wert-Speicher gespeichert:

  • etcd: GKE speichert den Clusterstatus in etcd-Instanzen, die auf jeder virtuellen Maschine (VM) der Steuerungsebene ausgeführt werden.
  • Spanner: GKE speichert den Clusterstatus in Spanner. Die Spanner-Datenbank wird nicht auf der Clustersteuerungsebene ausgeführt.

Unabhängig vom Datenbanktyp stellt jeder GKE-Cluster die etcd API auf der Steuerungsebene bereit. Der Kubernetes API-Server verwendet die etcd API, um mit der Backend-Clusterstatusdatenbank zu kommunizieren.

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 Artifact Registry-Repositories in der Domain pkg.dev oder 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 des Artifact Registry-Repositorys 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 stdout es Ihrer Plattform ermöglicht, die Anwendungsprotokolle zu verarbeiten.

Die Knotenverwaltung variiert je nach Betriebsmodus des Clusters :

Knotenkomponente Autopilot-Modus Standardmodus
Lebenszyklus

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.

Knoten bei der Kubernetes API registrieren

Wenn ein Knoten in einem GKE-Cluster erstellt wird, stellt der kubelet Prozess auf diesem Knoten eine TLS Verbindung zum Kubernetes API-Server her. Während der Knoteninitialisierung erstellt das Kubelet eine CertificateSigningRequest, um ein eindeutiges Clientzertifikat vom API-Server anzufordern. Das kubelet verwendet das Zertifikat, um ein Node-Objekt in der Kubernetes API zu erstellen.

Eine GKE-Funktion namens Shielded GKE-Knoten, die in allen neuen Clustern standardmäßig aktiviert ist, erhöht die Sicherheit dieses Prozesses zur Selbstregistrierung von Knoten, indem ein virtuelles Trusted Platform Module (vTPM) auf dem Knoten verwendet wird, um die Identität des Knotens kryptografisch zu überprüfen. Durch diese Überprüfung wird sichergestellt, dass die Steuerungsebene Anmeldedaten nur für legitime Knoten ausstellt.

Optional können Sie festlegen, dass eine vertrauenswürdige GKE-Steuerungsebenenkomponente diese Node-Objekte anstelle des kubelet erstellt. Dadurch werden die potenziellen Auswirkungen reduziert, wenn ein Knoten kompromittiert wird. Weitere Informationen finden Sie unter Knotenerstellung auf der Steuerungsebene (Vorschau).

Nächste Schritte