Private Cluster

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:

Diagramm: Private Clusterarchitektur

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
  1. Wählen Sie VPC nativ aktivieren aus.
  2. Wählen Sie Privater Cluster aus.
  3. Deaktivieren Sie Mit externer IP-Adresse auf Master zugreifen.
    Autorisierte Masternetzwerke aktivieren ist automatisch aktiviert.
  1. Wählen Sie VPC nativ aktivieren aus.
  2. Wählen Sie Privater Cluster aus.
  3. Wählen Sie Mit externer IP-Adresse auf Master zugreifen aus.
  4. Wählen Sie Autorisierte Master-Netzwerke aktivieren aus.
  1. Wählen Sie VPC nativ aktivieren aus.
  2. Wählen Sie Privater Cluster aus.
  3. Wählen Sie Mit externer IP-Adresse auf Master zugreifen aus.
  4. Deaktivieren Sie Autorisierte Masternetzwerke 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 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 --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.

Nächste Schritte