Auf dieser Seite wird erläutert, wie private Cluster in Google Kubernetes Engine (GKE) funktionieren. Sie können auch lernen, wie Sie private Cluster erstellen und verwalten.
Mit privaten Clustern können Sie Knoten von eingehenden und ausgehenden Verbindungen zum öffentlichen Internet isolieren. Diese Isolation wird erreicht, da die Knoten nur interne IP-Adressen haben.
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.
Obwohl die IP-Adressen der Knoten privat sind, können externe Clients Services in Ihrem Cluster erreichen. Sie können beispielsweise einen Service vom Typ LoadBalancer erstellen und externe Clients können die IP-Adresse des Load-Balancers aufrufen. Alternativ haben Sie die Möglichkeit, einen Service vom Typ NodePort zu erstellen und anschließend einen Ingress. GKE verwendet Informationen im Service und im Ingress, um einen HTTP(S)-Load-Balancer zu konfigurieren. Externe Clients können dann die externe IP-Adresse des HTTP(S)-Load-Balancers aufrufen.
Das folgende Diagramm bietet einen Überblick über die Architektur eines privaten Clusters:
Privaten Google-Zugriff in privaten Clustern verwenden
Standardmäßig ist Privater Google-Zugriff aktiviert. Über den privaten Google-Zugriff erhalten private Knoten und deren Arbeitslasten eingeschränkten ausgehenden Zugriff auf Google Cloud APIs und Google-Dienste über das private Netzwerk von Google. Mit dem privaten Google-Zugriff können private Knoten beispielsweise Container-Images von Container Registry abrufen und Logs an Cloud Logging senden.
Steuerungsebene in privaten Clustern
Jeder GKE-Cluster hat einen Kubernetes API-Server, der von der Steuerungsebene (Master) verwaltet wird. Die Steuerungsebene wird auf einer VM 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. Ein separates Google Cloud-VPC-Netzwerk enthält die Steuerungsebene Ihres Clusters. Das VPC-Netzwerk der Steuerungsebene befindet sich in einem von Google gesteuerten Projekt. Der Traffic zwischen den Knoten und der Steuerungsebene wird ausschließlich über interne IP-Adressen weitergeleitet.
Wiederverwendung von VPC-Netzwerk-Peering
Alle neu erstellten privaten Cluster verwenden vorhandene VPC-Netzwerk-Peering-Verbindungen automatisch wieder. Der erste von Ihnen erstellte zonale oder regionale private Cluster generiert eine neue VPC-Netzwerk-Peering-Verbindung. Zusätzliche private Cluster in derselben Zone oder Region und demselben Netzwerk können dasselbe Peering verwenden, ohne dass zusätzliche VPC-Netzwerk-Peering-Verbindungen erstellt werden müssen. Wenn Sie beispielsweise zwei private Einzelzonencluster in der Zone us-east1-b
und drei regionale private Cluster in der Region asia-east1
erstellen, werden nur zwei Peering-Verbindungen erstellt. Wenn Sie jedoch einen regionalen Cluster und einen zonalen Cluster in derselben Region erstellen, z. B. asia-east1
und asia-east1-a
, werden zwei verschiedene Peering-Verbindungen erstellt. Sie können prüfen, ob Ihr privater Cluster Verbindungen wiederverwendet.
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. Sie können den Zugriff auf diesen Endpunkt mithilfe von autorisierten Netzwerken steuern. Sie können den Zugriff auf den öffentlichen Endpunkt auch deaktivieren.
Private Cluster der Standard- und Autopilot verwenden standardmäßig öffentliche Endpunkte der Steuerungsebene. Sie können diese Einstellung überschreiben und einen privaten Endpunkt angeben.
Zugriff auf Cluster-Endpunkte
Sie können die Zugriffsebene für 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. Diese Technologien verbinden Ihr Unternehmensnetzwerk effektiv mit der VPC, ohne dass der Traffic das öffentliche Internet durchlaufen muss.
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. Außerdem müssen autorisierte Netzwerke interne IP-Adressen sein.
Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke aktiviert: Private Cluster mit aktivierten autorisierten Netzwerken bieten eingeschränkten Zugriff auf die Steuerungsebene über von Ihnen definierte Quell-IP-Adressen. Diese Option ist zu empfehlen, wenn Sie keine bestehende VPN-Infrastruktur haben oder Road Warriors bzw. Zweigstellen vorhanden sind, die über das öffentliche Internet statt über das Unternehmens-VPN und Cloud Interconnect/Cloud VPN eine Verbindung herstellen.
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 Masternetzwerke |
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