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 Siespec.loadBalancerSourceRanges
aus dem Dienstmanifest weglassen.Sie können einen Dienst vom Typ
NodePort
oderClusterIP
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.
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 |
|
|
|
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 |
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 |
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.
Von anderen VMs im VPC-Netzwerk des Clusters: Andere VMs können über Von öffentlichen IP-Adressen: Nie. |
Von Knoten: Es wird immer der private Endpunkt verwendet.
Von anderen VMs im VPC-Netzwerk des Clusters: Andere VMs können über
Von öffentlichen IP-Adressen: Maschinen mit öffentlichen IP-Adressen können über |
Von Knoten: Es wird immer der private Endpunkt verwendet.
Von anderen VMs im VPC-Netzwerk des Clusters: Andere VMs können über
Von öffentlichen IP-Adressen: Maschinen mit öffentlichen IP-Adressen können über |
Nächste Schritte
- Netzwerkübersicht
- Privaten Cluster erstellen
- VPC-native Cluster erstellen
- Windows-Anwendung in einem privaten Cluster bereitstellen
- Weitere Informationen zum VPC-Peering