Private Cluster

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

Ein privater Cluster ist eine Art von VPC-nativem Cluster, der nur von internen IP-Adressen abhängt. Für Knoten, Pods und Dienste in einem privaten Cluster sind eindeutige Subnetz-IP-Adressbereiche erforderlich.

Sie können private Cluster in "Standard" oder "Autopilot" erstellen und konfigurieren.

Wenn Sie für bestimmte private Knoten einen ausgehenden Internetzugang bereitstellen möchten, können Sie Cloud NAT verwenden oder Ihr eigenes NAT-Gateway verwalten.

Architektur

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. Beispielsweise ist ein Dienst vom Typ NodePort, der in einem privaten Cluster gehostet wird, für externe Clients nicht zugänglich, da der Knoten keine über das Internet routingfähige öffentliche IP-Adresse hat.

Im Gegensatz zu einem öffentlichen Cluster hat ein privater Cluster sowohl einen privaten Endpunkt der Steuerungsebene als auch einen öffentlichen Endpunkt der Steuerungsebene. Sie müssen einen eindeutigen /28-IP-Adressbereich für den privaten Endpunkt der Steuerungsebene angeben. Sie können auch den öffentlichen Endpunkt der Steuerungsebene deaktivieren.

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

Auch wenn die Knoten interne IP-Adressen verwenden, können externe Clients eine Verbindung zu Diensten in Ihrem Cluster herstellen. Beispiel:

Ein externer Client mit einer Quell-IP-Adresse im Internet kann eine Verbindung zu einem externen Dienst vom Typ LoadBalancer herstellen, wenn Sie spec.loadBalancerSourceRanges aus dem Dienstmanifest weglassen.
Sie können einen Dienst vom Typ NodePort oder ClusterIP erstellen und den Dienst mithilfe eines externen Ingress für externe Clients verfügbar machen.

Privaten Google-Zugriff in privaten Clustern verwenden

Bei privaten Clustern, die VPC-Netzwerke im selben Projekt wie der Cluster verwenden, sorgt GKE dafür, dass der private Google-Zugriff in dem Subnetz aktiviert ist, das vom privaten Cluster beim Erstellen des Clusters verwendet wird. Ein Netzwerkadministrator, Projektinhaber oder Projektbearbeiter für ein Hostprojekt in einer freigegebenen VPC muss den privaten Google-Zugriff in Subnetzen, die von privaten Clustern verwendet werden, manuell aktivieren, wenn die privaten Cluster in Dienstprojekten einer freigegebenen VPC erstellt werden.

Der private Google-Zugriff ist in privaten Clustern standardmäßig aktiviert, mit Ausnahme von freigegebenen VPC-Clustern. Für freigegebene VPC-Cluster müssen Sie den privaten Google-Zugriff manuell aktivieren.

Der private Google-Zugriff ermöglicht privaten Knoten und deren Arbeitslasten über das private Netzwerk von Google Zugriff auf Google Cloud APIs und -Dienste. Privater Google-Zugriff ist beispielsweise erforderlich, damit private Cluster auf Container-Images von Artifact Registry zugreifen und Logs an Cloud Logging senden können.

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 Projekt von Google befindet. Ein regionaler Cluster hat mehrere Steuerungsebenen, 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 Google 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.

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 am selben Standort befinden und dasselbe VPC-Netzwerk verwenden. In diesem Zusammenhang bezieht sich Standort ausschließlich auf eine Google Cloud-Region oder eine Google Cloud-Zone.

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.
GKE verwendet kein gemeinsames Peering für zonale Cluster und regionale Cluster, auch wenn die zonalen Cluster zur selben Region wie die regionalen Cluster gehören.

Die folgenden Beispiele verdeutlichen dieses Verhalten. In jedem Beispiel wird eine VPC-Netzwerk-Peering-Verbindung verwendet:

Zwei oder mehr zonale private Cluster in der Zone us-east1-b, die dasselbe VPC-Netzwerk verwenden.
Zwei oder mehr regionale private Cluster in der Region us-east1, die dasselbe VPC-Netzwerk verwenden.

Für einen oder mehrere zonale private Cluster in us-east1-b und einen oder mehrere regionale Cluster in us-east1 mit demselben VPC-Netzwerk sind jedoch zwei VPC-Netzwerk-Peering-Verbindungen erforderlich.

Weitere Informationen zu privaten Clustern und Verbindungen finden Sie unter Wiederverwendung des VPC-Netzwerk-Peerings.

Endpunkte in privaten Clustern

Die Steuerungsebene für einen privaten Cluster hat neben einem öffentlichen Endpunkt einen privaten Endpunkt. Die Steuerungsebene für einen nicht privaten Cluster hat lediglich einen öffentlichen Endpunkt.

Privater Endpunkt: Der private Endpunkt ist eine interne IP-Adresse im VPC-Netzwerk der Steuerungsebene. In einem privaten Cluster kommunizieren Knoten immer mit dem privaten 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 verwendet wie Ihr privater Cluster, kann auch auf den privaten Endpunkt zugreifen.
Öffentlicher Endpunkt: Dies ist die externe IP-Adresse der Steuerungsebene. Standardmäßig kommunizieren Tools wie kubectl mit der Steuerungsebene an ihrem öffentlichen Endpunkt.

Zugriff auf Cluster-Endpunkte

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

Zugriff auf öffentliche 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 öffentliche Endpunkte deaktivieren, müssen Sie autorisierte Netzwerke für den privaten Endpunkt konfigurieren. Wenn Sie das nicht tun, können Sie nur von Clusterknoten oder VMs im selben Subnetz wie der Cluster aus eine Verbindung zum privaten Endpunkt herstellen. Bei dieser Einstellung müssen autorisierte Netzwerke interne IP-Adressen sein.
Wichtig: Google kann den öffentlichen Endpunkt der Steuerungsebene für die Clusterverwaltung verwenden, auch wenn Sie den Zugriff auf den öffentlichen Endpunkt deaktivieren. Beispiel: planmäßige Wartung und automatische Upgrades der Steuerungsebene
Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke aktiviert: In dieser Konfiguration gelten die autorisierten Netzwerke für den öffentlichen 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 öffentliche 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.

In der folgenden Tabelle sind die verschiedenen Möglichkeiten für den Zugriff auf die Endpunkte zusammengefasst:

	Zugriff auf öffentliche Endpunkte deaktiviert	Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke aktiviert	Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke deaktiviert
Sicherheit	Der am stärksten beschränkte Zugriff auf die Steuerungsebene. Der Clientzugriff auf den öffentlichen Endpunkt der Steuerungsebene wird blockiert. Der Zugriff auf die Steuerungsebene muss von internen IP-Adressen aus erfolgen.	Beschränkter Zugriff auf die Steuerungsebene über von Ihnen definierte interne und externe IP-Adressen.	Zugriff auf die Steuerungsebene von beliebigen IP-Adressen aus.
Detaillierte Konfigurationsschritte	Privaten Cluster ohne Clientzugriff auf den öffentlichen Endpunkt erstellen	Privaten Cluster mit eingeschränktem Zugriff auf den öffentlichen Endpunkt erstellen	Privaten Cluster mit uneingeschränktem Zugriff auf den öffentlichen Endpunkt erstellen
Konfigurationsoptionen für die Cloud Console	Wählen Sie VPC nativ aktivieren aus. Wählen Sie Privater Cluster aus. Deaktivieren Sie Mit externer IP-Adresse auf Steuerungsebene zugreifen. Autorisierte Netzwerkebenen für Steuerungsebene aktivieren ist automatisch aktiviert.	Wählen Sie VPC nativ aktivieren aus. Wählen Sie Privater Cluster aus. Wählen Sie Mit externer IP-Adresse auf Steuerungsebene zugreifen aus. Wählen Sie Autorisierte Netzwerke auf Steuerungsebene aktivieren aus.	Wählen Sie VPC nativ aktivieren aus. Wählen Sie Privater Cluster aus. Wählen Sie Mit externer IP-Adresse auf Steuerungsebene zugreifen aus. Deaktivieren Sie Autorisierte Netzwerke auf Steuerungsebene aktivieren.
`gcloud`-Flags zur Clustererstellung	`--enable-ip-alias` `--enable-private-nodes` `--enable-private-endpoint` `--enable-master-authorized-networks`	`--enable-ip-alias` `--enable-private-nodes` `--enable-master-authorized-networks`	`--enable-ip-alias` `--enable-private-nodes` `--no-enable-master-authorized-networks`
Kommunikation zwischen Knoten und Steuerungsebene	Knoten kontaktieren die Steuerungsebene immer mithilfe des privaten Endpunkts.
Webhook-Kommunikation zwischen Knoten und API-Server	Webhooks, die einen Dienst mit einem anderen targetPort als 443 verwenden, benötigen eine Firewallregel, damit dies zugelassen ist. Weitere Informationen finden Sie unter Firewallregeln für bestimmte Anwendungsfälle hinzufügen.
Autorisierte Netzwerke der Steuerungsebene	Erforderlich für den Zugriff auf die Steuerungsebene von internen IP-Adressen, die keine Knoten oder Pods sind. Sie müssen den internen IP-Adressbereich der Knoten nicht explizit autorisieren. Adressen im primären IP-Adressbereich des Subnetzes des Clusters sind immer berechtigt, mit dem privaten Endpunkt zu kommunizieren. Geben Sie mit `--master-authorized-networks` weitere interne IP-Adressen an, die auf die Steuerungsebene zugreifen können. Sie können keine externen IP-Adressen in die Liste der autorisierten Netzwerke aufnehmen, da der Zugriff auf den öffentlichen Endpunkt deaktiviert ist.	Erforderlich für den Zugriff auf die Steuerungsebene von externen IP-Adressen sowie von internen IP-Adressen, die keine Knoten oder Pods sind. Geben Sie mit `--master-authorized-networks` externe und interne IP-Adressen (keine Knoten und Pods) an, die auf die Steuerungsebene zugreifen können.	Nicht verwendet. Wenn Sie den Zugriff auf den öffentlichen Endpunkt der Steuerungsebene aktivieren, ohne autorisierte Netzwerke zu aktivieren, wird der Zugriff auf den öffentlichen Endpunkt der Steuerungsebene nicht eingeschränkt.
Zugriff mit `kubectl`	Von Knoten: Es wird immer der private Endpunkt verwendet. `kubectl` muss für die Verwendung des privaten Endpunkts konfiguriert sein. Von anderen VMs im VPC-Netzwerk des Clusters: Andere VMs können über `kubectl` nur dann mit dem privaten Endpunkt kommunizieren, wenn sie sich in derselben Region wie der Cluster befinden und entweder ihre internen IP-Adressen in der Liste der autorisierten Netzwerke enthalten sind oder sie sich in demselben Subnetz wie die Knoten des Clusters befinden. `kubectl` muss für die Verwendung des privaten Endpunkts konfiguriert sein. Von öffentlichen IP-Adressen: Nie.	Von Knoten: Es wird immer der private Endpunkt verwendet. `kubectl` muss für die Verwendung des privaten Endpunkts konfiguriert sein. Von anderen VMs im VPC-Netzwerk des Clusters: Andere VMs können über `kubectl` nur dann mit dem privaten Endpunkt kommunizieren, wenn sie sich in derselben Region wie der Cluster befinden und entweder ihre internen IP-Adressen in der Liste der autorisierten Netzwerke enthalten sind oder sie sich in demselben Subnetz wie die Knoten des Clusters befinden. `kubectl` muss für die Verwendung des privaten Endpunkts konfiguriert sein. Von öffentlichen IP-Adressen: Maschinen mit öffentlichen IP-Adressen können über `kubectl` nur dann mit dem öffentlichen Endpunkt kommunizieren, wenn ihre öffentliche IP-Adressen in der Liste der autorisierten Netzwerke enthalten sind. Dies gilt auch für Maschinen außerhalb von Google Cloud sowie Google Cloud-VMs mit externen IP-Adressen.	Von Knoten: Es wird immer der private Endpunkt verwendet. `kubectl` muss für die Verwendung des privaten Endpunkts konfiguriert sein. Von anderen VMs im VPC-Netzwerk des Clusters: Andere VMs können über `kubectl` nur dann mit dem privaten Endpunkt kommunizieren, wenn sie sich in derselben Region wie der Cluster befinden. `kubectl` muss für die Verwendung des privaten Endpunkts konfiguriert sein. Von öffentlichen IP-Adressen: Maschinen mit öffentlichen IP-Adressen können über `kubectl` mit dem öffentlichen Endpunkt kommunizieren. Dies gilt auch für Maschinen außerhalb von Google Cloud sowie Google Cloud-VMs mit externen IP-Adressen.