Diese Seite wurde von der Cloud Translation API übersetzt.

GKE-Clusterarchitektur

Autopilot Standard

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

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-Clusters:

Dieses Diagramm zeigt die folgenden Komponenten:

Steuerungsebene: von GKE verwaltet. Führt den Kubernetes API-Server, die Workload-Controller, den Kubernetes-Planer und den Clusterspeicher aus.
Knoten: Im Autopilot-Modus von GKE verwaltet, 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 dieGoogle Cloud -Konsole.

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 Clusterstatusdatenbank

Im Open-Source-Projekt Kubernetes wird standardmäßig etcd als Speicherdienst 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 Datenbank für den Clusterstatus werden beispielsweise alle Secrets, ConfigMaps und Deployments gespeichert.

In GKE-Clustern wird der Clusterstatus in einem der folgenden Key-Value-Stores gespeichert:

etcd: GKE speichert den Clusterstatus in etcd-Instanzen, die auf jeder VM der Steuerungsebene ausgeführt werden.
Spanner: GKE speichert den Clusterstatus in Spanner. Die Spanner-Datenbank wird nicht auf der Steuerungsebene des Clusters ausgeführt.

Unabhängig vom Datenbanktyp stellt jeder GKE-Cluster die etcd-API in 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.