Private Cluster

Autopilot Standard

Auf dieser Seite wird erläutert, wie private Cluster in Google Kubernetes Engine (GKE) funktionieren. Sie erfahren auch, wie Sie private Cluster erstellen.

Private Cluster verwenden Knoten, die keine externen IP-Adressen haben. Das bedeutet, dass Clients im Internet keine Verbindung zu den IP-Adressen der Knoten herstellen können. Private Cluster sind ideal für Arbeitslasten, die beispielsweise aufgrund von Datenschutz- und Sicherheitsvorschriften kontrollierten Zugriff erfordern.

Private Cluster sind im Standard- oder im Autopilot-Modus verfügbar.

Architektur privater Cluster

Im Gegensatz zu einem öffentlichen Cluster hat ein privater Cluster sowohl einen internen Endpunkt der Steuerungsebene als auch einen externen Endpunkt der Steuerungsebene.

Das folgende Diagramm bietet einen Überblick über die Architektur eines privaten Clusters:

Im Folgenden sind die Kernkomponenten eines privaten Clusters aufgeführt:

Steuerungsebene: Die Steuerungsebene hat sowohl einen internen Endpunkt für die interne Clusterkommunikation als auch einen externen Endpunkt. Sie können den externen Endpunkt deaktivieren.
Knoten: Knoten verwenden nur interne IP-Adressen, die sie vom öffentlichen Internet isolieren.
VPC-Netzwerk: Dies ist ein virtuelles Netzwerk, in dem Sie Subnetze mit internen IP-Adressbereichen speziell für die Knoten und Pods des Clusters erstellen.
Privater Google-Zugriff Diese Option ist im Subnetz des Clusters aktiviert und ermöglicht Knoten mit internen IP-Adressen, wichtige Google Cloud APIs und -Dienste ohne öffentliche IP-Adressen zu erreichen. Privater Google-Zugriff ist beispielsweise erforderlich, damit private Cluster auf Container-Images von Artifact Registry zugreifen und Logs an Cloud Logging senden können. Der private Google-Zugriff ist in privaten Clustern standardmäßig aktiviert, mit Ausnahme von freigegebenen VPC-Clustern, für die eine manuelle Aktivierung erforderlich ist.

Steuerungsebene in privaten Clustern

Jeder GKE-Cluster hat einen Kubernetes API-Server, der von der Steuerungsebene verwaltet wird.

Die Steuerungsebene wird auf einer VM (virtuelle Maschine) ausgeführt, die sich in einem VPC-Netzwerk in einem von Google verwalteten Projekt befindet. Ein regionaler Cluster hat mehrere Replikate der Steuerungsebene, die jeweils auf einer eigenen VM ausgeführt werden.

In privaten Clustern ist das VPC-Netzwerk der Steuerungsebene mit VPC-Netzwerk-Peering mit dem VPC-Netzwerk Ihres Clusters verbunden. Ihr VPC-Netzwerk enthält die Clusterknoten. Das von Google verwaltete Cloud-VPC-Netzwerk enthält die Steuerungsebene Ihres Clusters.

Der Traffic zwischen den Knoten und der Steuerungsebene wird ausschließlich über interne IP-Adressen weitergeleitet. Wenn Sie das VPC-Netzwerk-Peering verwenden, um das VPC-Netzwerk des Clusters mit einem dritten Netzwerk zu verbinden, kann das dritte Netzwerk keine Ressourcen im VPC-Netzwerk der Steuerungsebene erreichen. Dies liegt daran, dass VPC-Netzwerk-Peering nur die Kommunikation zwischen direkt verbundenen Peering-Netzwerken unterstützt und das dritte Netzwerk nicht mit dem Netzwerk der Steuerungsebene verbunden sein kann. Weitere Informationen finden Sie unter Einschränkungen für VPC-Netzwerk-Peering.

Endpunkte in privaten Clustern

Die Steuerungsebene für einen privaten Cluster hat neben einem externen Endpunkt einen internen Endpunkt.

Der interne Endpunkt ist eine interne IP-Adresse im VPC-Netzwerk der Steuerungsebene. In einem privaten Cluster kommunizieren Knoten immer mit dem internen Endpunkt der Steuerungsebene. Abhängig von Ihrer Konfiguration können Sie den Cluster mit Tools wie kubectl verwalten, die auch eine Verbindung zum privaten Endpunkt herstellen. Jede VM, die dasselbe Subnetz wie Ihr privater Cluster verwendet, kann auch auf den internen Endpunkt zugreifen.

Der externe Endpunkt ist die externe IP-Adresse der Steuerungsebene. Standardmäßig kommunizieren Tools wie kubectl mit der Steuerungsebene an ihrem externem Endpunkt.

Optionen für den Zugriff auf Cluster-Endpunkte

Sie können den Zugriff auf die Endpunkte mit einer der folgenden Konfigurationen steuern:

Zugriff auf externe Endpunkte deaktiviert: Dies ist die sicherste Option, da dadurch der gesamte Internetzugriff auf die Steuerungsebene verhindert wird. Dieser Schutz ist zu empfehlen, wenn Sie Ihr lokales Netzwerk so konfiguriert haben, dass mit Cloud Interconnect und Cloud VPN eine Verbindung zu Google Cloud hergestellt wird.

Wenn Sie den Zugriff auf externe Endpunkte deaktivieren, müssen Sie für den internen Endpunkt autorisierte Netzwerke konfigurieren. Wenn Sie das nicht tun, können Sie nur von Clusterknoten oder VMs im selben Subnetz wie der Cluster aus eine Verbindung zum internen Endpunkt herstellen. Bei dieser Einstellung müssen autorisierte Netzwerke interne IP-Adressen sein.
Wichtig: Google kann den externen Endpunkt der Steuerungsebene für die Clusterverwaltung verwenden, auch wenn Sie den Zugriff auf den externen Endpunkt deaktivieren. Beispiel: planmäßige Wartung und automatische Upgrades der Steuerungsebene
Zugriff auf externe Endpunkte aktiviert; autorisierte Netzwerke aktiviert: In dieser Konfiguration gelten die autorisierten Netzwerke für den externen Endpunkt der Steuerungsebene. Diese Option ist zu empfehlen, wenn Sie den Cluster über Quellnetzwerke verwalten müssen, die nicht über Cloud Interconnect oder Cloud VPN mit dem VPC-Netzwerk des Clusters verbunden sind.
Zugriff auf externe Endpunkte aktiviert; autorisierte Netzwerke deaktiviert Dies ist die Standardeinstellung und es ist auch die Option mit der geringsten Einschränkung. Da autorisierte Netzwerke nicht aktiviert sind, können Sie Ihren Cluster von jeder Quell-IP-Adresse aus verwalten, wenn Sie sich authentifizieren.

Wiederverwendung von VPC-Netzwerk-Peering

Private Cluster, die nach dem 15. Januar 2020 erstellt wurden, verwenden eine gemeinsame VPC-Netzwerk-Peering-Verbindung, wenn sich die Cluster in derselben Google Cloud-Zone oder -Region befinden und dasselbe VPC-Netzwerk verwenden.

Bei zonalen Clustern generiert der erste private Cluster, den Sie in einer Zone erstellen, eine neue VPC-Netzwerk-Peering-Verbindung zum VPC-Netzwerk des Clusters. Zusätzliche zonale private Cluster, die Sie in derselben Zone und demselben VPC-Netzwerk erstellen, verwenden dieselbe Peering-Verbindung.
Bei regionalen Clustern: Der erste private Cluster, den Sie in einer Region erstellen, generiert eine neue VPC-Netzwerk-Peering-Verbindung zum VPC-Netzwerk des Clusters. Zusätzliche regionale private Cluster, die Sie in derselben Region und demselben VPC-Netzwerk erstellen, verwenden dieselbe Peering-Verbindung.

Zonale und regionale Cluster verwenden ihre eigenen Peering-Verbindungen, auch wenn sie sich in derselben Region befinden. Beispiel:

Sie erstellen zwei oder mehr zonale private Cluster in der Zone us-east1-b und konfigurieren sie für die Verwendung desselben VPC-Netzwerks. Beide Cluster verwenden dieselbe Peering-Verbindung.
Sie erstellen zwei oder mehr regionale private Cluster in der Region us-east1 und konfigurieren sie so, dass sie dasselbe VPC-Netzwerk wie die zonalen Cluster verwenden. Diese regionalen Cluster verwenden dieselbe VPC-Netzwerk-Peering-Verbindung miteinander, benötigen jedoch eine andere Peering-Verbindung für die Kommunikation mit den zonalen Clustern.

Alle privaten Cluster, die vor dem 15. Januar 2020 erstellt wurden, verwenden eine einmalige VPC-Netzwerk-Peering-Verbindung. Mit anderen Worten, diese Cluster verwenden nicht dieselbe Peering-Verbindung mit anderen zonalen oder regionalen Clustern. Für die Wiederverwendung des VPC-Netzwerk-Peerings durch ältere private Cluster können Sie Cluster löschen und neu erstellen. Das Upgrade eines Clusters ermöglicht keine Wiederverwendung einer vorhandenen VPC-Netzwerk-Peering-Verbindung.

Informationen zum Prüfen, ob Ihr privater Cluster eine gemeinsame VPC-Netzwerk-Peering-Verbindung verwendet, finden Sie unter Wiederverwendung des VPC-Peerings prüfen.

Beschränkungen

Jede Zone oder Region kann maximal 75 private Cluster unterstützen, wenn für die Cluster die Wiederverwendung von VPC-Netzwerk-Peering aktiviert ist.

Hinweis: Wenden Sie sich an das Google Cloud-Supportteam, wenn Sie mehr als 75 private Cluster pro Standort konfigurieren müssen. Dies gilt nur, wenn für Ihre Cluster die Wiederverwendung von VPC-Netzwerk-Peering aktiviert ist.

So lassen sich z. B. bis zu 75 private zonale Cluster in us-east1-b und weitere 75 private regionale Cluster in us-east1 erstellen. Dies gilt auch, wenn Sie private Cluster in einem freigegebenen VPC-Netzwerk verwenden.
Es sind maximal 25 Verbindungen zu einem einzelnen VPC-Netzwerk möglich. Dies bedeutet, dass Sie nur private Cluster mit 25 separaten Standorten erstellen können.
Die Wiederverwendung des VPC-Netzwerk-Peerings gilt nur für Cluster am selben Standort, z. B. regionale Cluster in derselben Region oder zonale Cluster in derselben Zone. Es sind maximal vier VPC-Netzwerk-Peerings pro Region möglich, wenn Sie sowohl regionale Cluster als auch zonale Cluster in allen Zonen dieser Region erstellen.
Für Cluster, die vor dem 15. Januar 2020 erstellt wurden, kann jedes VPC-Netzwerk mit bis zu 25 anderen VPC-Netzwerken verbunden werden. Für diese Cluster besteht also ein Limit von maximal 25 privaten Clustern pro Netzwerk (vorausgesetzt, Peerings werden nicht für andere Zwecke verwendet.)