Erweiterte Konfigurationen für private Cluster

Autopilot Standard

Auf dieser Seite werden einige erweiterte Konfigurationen beschrieben, die Sie beim Erstellen eines privaten Clusters verwenden können. Informationen zur grundlegenden Konfiguration eines privaten Clusters finden Sie unter Private Cluster erstellen.

Privaten Knoten ausgehenden Internetzugriff gewähren

Wenn Sie privaten Knoten ausgehenden Internetzugriff gewähren möchten, z. B. um Images aus einer externen Registry abzurufen, verwenden Sie Cloud NAT, um einen Cloud Router zu erstellen und zu konfigurieren. Mit Cloud NAT können private Cluster ausgehende Verbindungen über das Internet herstellen, um Pakete zu senden und zu empfangen.

Der Cloud Router ermöglicht allen Knoten in der Region, Cloud NAT für alle primären und Alias-IP-Bereiche zu verwenden. Außerdem werden die externen IP-Adressen für das NAT-Gateway automatisch zugeordnet.

Eine Anleitung zum Erstellen und Konfigurieren eines Cloud Routers finden Sie in der Cloud NAT-Dokumentation unter Cloud NAT-Konfiguration mit Cloud Router erstellen.

Privaten Cluster in einem freigegebenen VPC-Netzwerk erstellen

Informationen zum Erstellen eines privaten Clusters in einem freigegebenen VPC-Netzwerk finden Sie unter Private Cluster in einer freigegebenen VPC erstellen.

Windows Server-Containeranwendung in einem privaten Cluster bereitstellen

Informationen zum Bereitstellen einer Windows Server-Containeranwendung in einem privaten Cluster finden Sie in der Dokumentation zu Windows-Knotenpools.

Global auf privaten Endpunkt der Steuerungsebene zugreifen

Der private Endpunkt der Steuerungsebene wird von einem internen Passthrough-Network Load Balancer im VPC-Netzwerk der Steuerungsebene implementiert. Interne oder über Cloud VPN-Tunnel und Cloud Interconnect-VLAN-Anhänge verbundene Clients können auf interne Passthrough-Network Load Balancer zugreifen.

Standardmäßig müssen sich diese Clients in derselben Region wie der Load-Balancer befinden.

Wenn Sie den globalen Zugriff auf die Steuerungsebene aktivieren, ist der interne Passthrough-Network Load Balancer global zugänglich. Client-VMs und lokale Systeme können gemäß der Konfiguration der autorisierten Netzwerke von einer beliebigen Region aus eine Verbindung zum privaten Endpunkt der Steuerungsebene herstellen.

Weitere Informationen zu den internen Passthrough-Network Load Balancern und dem globalen Zugriff finden Sie unter Interne Load Balancer und verbundene Netzwerke.

Globalen Zugriff auf privaten Endpunkt der Steuerungsebene aktivieren

Standardmäßig ist der globale Zugriff nicht für den privaten Endpunkt der Steuerungsebene aktiviert, wenn Sie einen privaten Cluster erstellen. Verwenden Sie die folgenden Tools basierend auf Ihrem Clustermodus, um den globalen Zugriff auf die Steuerungsebene zu aktivieren:

Für Standardcluster können Sie Google Cloud CLI oder die Google Cloud Console verwenden.

Für Autopilot-Cluster können Sie die Terraform-Ressource google_container_cluster verwenden.

Console

Führen Sie die folgenden Schritte aus, um einen neuen privaten Cluster mit aktiviertem globalem Zugriff auf die Steuerungsebene zu erstellen:

Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

Zur Seite "Google Kubernetes Engine"
Klicken Sie auf Erstellen und dann im Bereich „Standard“ oder „Autopilot“ auf Konfigurieren.
Geben Sie einen Namen ein.
Klicken Sie im Navigationsbereich auf Netzwerk.
Wählen Sie Privater Cluster aus.
Klicken Sie das Kästchen Globalen Zugriff auf Steuerungsebene aktivieren an.
Konfigurieren Sie gegebenenfalls andere Felder.
Klicken Sie auf Erstellen.

Führen Sie die folgenden Schritte aus, um den globalen Zugriff auf die Steuerungsebene für einen vorhandenen privaten Cluster zu aktivieren:

Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

Zur Seite "Google Kubernetes Engine"
Klicken Sie neben dem Cluster, den Sie bearbeiten möchten, auf Aktionen und dann auf Bearbeiten.
Klicken Sie unter Netzwerk neben Globaler Zugriff auf Steuerungsebene auf Bearbeiten.
Klicken Sie im Dialogfeld Globalen Zugriff auf Steuerungsebene bearbeiten das Kästchen Globalen Zugriff auf Steuerungsebene aktivieren an.
Klicken Sie auf Änderungen speichern.

gcloud

Fügen Sie das Flag --enable-master-global-access hinzu, um einen privaten Cluster mit aktiviertem globalem Zugriff auf den privaten Endpunkt der Steuerungsebene zu erstellen:

gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --enable-master-global-access

Sie können den globalen Zugriff auf den privaten Endpunkt der Steuerungsebene auch für einen vorhandenen privaten Cluster aktivieren:

gcloud container clusters update CLUSTER_NAME \
    --enable-master-global-access

Globalen Zugriff auf privaten Endpunkt der Steuerungsebene prüfen

Sie können prüfen, ob der globale Zugriff auf den privaten Endpunkt der Steuerungsebene aktiviert ist. Führen Sie dafür den folgenden Befehl aus und sehen Sie sich die Ausgabe an.

gcloud container clusters describe CLUSTER_NAME

Die Ausgabe enthält den Abschnitt privateClusterConfig, in dem Sie den Status von masterGlobalAccessConfig sehen können.

privateClusterConfig:
  enablePrivateNodes: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
  masterGlobalAccessConfig:
    enabled: true

Von anderen Netzwerken auf den privaten Endpunkt der Steuerungsebene zugreifen

Wenn Sie einen privaten GKE-Cluster erstellen und den öffentlichen Endpunkt der Steuerungsebene deaktivieren, müssen Sie den Cluster mit Tools wie kubectl verwalten. Verwenden Sie dazu den privaten Endpunkt der Steuerungsebene. Sie können über ein anderes Netzwerk auf den privaten Endpunkt der Steuerungsebene des Clusters zugreifen. Dazu gehören:

Ein lokales Netzwerk, das über Cloud VPN-Tunnel oder Cloud Interconnect-VLAN-Anhänge mit dem VPC-Netzwerk des Clusters verbunden ist
Ein anderes VPC-Netzwerk, das über Cloud VPN-Tunnel mit dem VPC-Netzwerk des Clusters verbunden ist

Das folgende Diagramm zeigt einen Routingpfad zwischen einem lokalen Netzwerk und den Knoten der GKE-Steuerungsebene:

Diagramm: Routing zwischen der lokalen VPC und der Steuerungsebene des Clusters

Die folgenden Anforderungen müssen erfüllt sein, damit Systeme in einem anderen Netzwerk eine Verbindung zum privaten Endpunkt der Steuerungsebene eines Clusters herstellen können:

Identifizieren und notieren Sie relevante Netzwerkinformationen für den Cluster und den privaten Endpunkt seiner Steuerungsebene.
```
gcloud container clusters describe CLUSTER_NAME \
   --location=COMPUTE_LOCATION \
   --format="yaml(network, privateClusterConfig)"
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters.
- COMPUTE_LOCATION: der Compute Engine-Standort des Clusters.
Identifizieren Sie in der Ausgabe des Befehls die folgenden Informationen und notieren Sie sie zur Verwendung in den nächsten Schritten:
- network: der Name oder URI für das VPC-Netzwerk des Clusters.
- privateEndpoint: die IPv4-Adresse des privaten Endpunkts der Steuerungsebene oder der einschließende IPv4-CIDR-Bereich (masterIpv4CidrBlock).
- peeringName: der Name der VPC-Netzwerk-Peering-Verbindung, die zum Herstellen einer Verbindung des VPC-Netzwerks des Clusters zum VPC-Netzwerk der Steuerungsebene verwendet wird.
Die Ausgabe sieht in etwa so aus:
```
network: cluster-network
privateClusterConfig:
  enablePrivateNodes: true
  masterGlobalAccessConfig:
    enabled: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
```
Erwägen Sie, den globalen Zugriff auf den privaten Endpunkt der Steuerungsebene zu aktivieren, damit Pakete aus jeder Region im VPC-Netzwerk des Clusters eingegeben werden können. Wenn Sie den globalen Zugriff auf den privaten Endpunkt der Steuerungsebene aktivieren, können Sie eine Verbindung zum privaten Endpunkt über Cloud VPN-Tunnel oder Cloud Interconnect-VLAN-Anhänge herstellen, die sich in einer beliebigen Region befinden, nicht nur in der Region des Clusters.
Erstellen Sie eine Route für die IP-Adresse des privateEndpoint oder den IP-Adressbereich des masterIpv4CidrBlock im anderen Netzwerk. Da die IP-Adresse des privaten Endpunkts der Steuerungsebene immer im IPv4-Adressbereich masterIpv4CidrBlock liegt, wird durch Erstellen einer Route für die IP-Adresse privateEndpoint oder den einschließenden Bereich ein Pfad für Pakete aus einem anderen Netzwerk zum privaten Endpunkt der Steuerungsebene bereitgestellt, wenn Folgendes zutrifft:
- Das andere Netzwerk stellt eine Verbindung zum VPC-Netzwerk des Clusters über Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel her, die dynamische (BGP-)Routen verwenden: Verwenden Sie eine benutzerdefinierte beworbene Cloud Router-Route. Weitere Informationen finden Sie in der Cloud Router-Dokumentation unter Benutzerdefinierte Adressbereiche bewerben.
- Das andere Netzwerk stellt über klassische VPN-Tunnel, die keine dynamischen Routen verwenden, eine Verbindung zum VPC-Netzwerk des Clusters her: Sie müssen eine statische Route im anderen Netzwerk konfigurieren.
Wichtig: Wenn Globaler Zugriff auf Steuerungsebene deaktiviert ist, müssen sich die Cloud VPN-Tunnel oder Cloud Interconnect-VLAN-Anhänge, die das VPC-Netzwerk des Clusters mit dem anderen Netzwerk verbinden, in derselben Region befinden wie der Cluster.
Konfigurieren Sie das VPC-Netzwerk des Clusters so, dass die benutzerdefinierten Routen in der Peering-Beziehung in das VPC-Netzwerk der Steuerungsebene exportiert werden. Google Cloud konfiguriert das VPC-Netzwerk der Steuerungsebene immer so, dass benutzerdefinierte Routen aus dem VPC-Netzwerk des Clusters importiert werden. In diesem Schritt wird ein Pfad für Pakete vom privaten Endpunkt der Steuerungsebene zurück zum anderen Netzwerk bereitgestellt.

Verwenden Sie den folgenden Befehl, um den Export benutzerdefinierter Routen aus dem VPC-Netzwerk des Clusters zu aktivieren:
```
gcloud compute networks peerings update PEERING_NAME \
    --network=CLUSTER_VPC_NETWORK \
    --export-custom-routes
```
Ersetzen Sie Folgendes:
- PEERING_NAME: der Name der Peering-Verbindung, über die das VPC-Netzwerk des Clusters mit dem VPC-Netzwerk der Steuerungsebene verbunden wird.
- CLUSTER_VPC_NETWORK: der Name oder URI für das VPC-Netzwerk des Clusters.
Wenn der Export benutzerdefinierter Routen für die VPC aktiviert ist, kann das Erstellen von Routen, die sich mit IP-Bereichen von Google Cloud überschneiden, den Cluster beeinträchtigen.

Weitere Informationen zum Aktualisieren des Routenaustauschs für vorhandene VPC-Netzwerk-Peering-Verbindungen finden Sie unter Peering-Verbindung aktualisieren.

Benutzerdefinierte Routen im VPC-Netzwerk des Clusters enthalten Routen, deren Ziele IP-Adressbereiche in anderen Netzwerken sind, z. B. ein lokales Netzwerk. Wie Sie dafür sorgen, dass diese Routen als benutzerdefinierte Peering-Routen im VPC-Netzwerk der Steuerungsebene wirksam werden, erfahren Sie unter Unterstützte Ziele aus dem anderen Netzwerk.

Unterstützte Ziele aus dem anderen Netzwerk

Die Adressbereiche, die das andere Netzwerk an die Cloud Router im VPC-Netzwerk des Clusters sendet, müssen die folgenden Bedingungen erfüllen:

Während die VPC Ihres Clusters eine Standardroute (0.0.0.0/0) akzeptiert, lehnt das VPC-Netzwerk der Steuerungsebene immer Standardrouten ab, da es bereits eine lokale Standardroute hat. Wenn das andere Netzwerk eine Standardroute an Ihr VPC-Netzwerk sendet, muss das andere Netzwerk auch die spezifischen Ziele von Systemen senden, die eine Verbindung zum privaten Endpunkt der Steuerungsebene herstellen müssen. Weitere Informationen finden Sie unter Routingreihenfolge.
Wenn das VPC-Netzwerk der Steuerungsebene Routen akzeptiert, die eine Standardroute effektiv ersetzen, wird die Verbindung zu Google APIs und Google-Diensten getrennt und die Steuerungsebene des Clusters wird dadurch unterbrochen. Ein repräsentatives Beispiel: Das andere Netzwerk darf keine Routen mit den Zielen 0.0.0.0/1 und 128.0.0.0/1 anbieten. Eine Alternative finden Sie im vorherigen Punkt.

Überwachen Sie die Cloud Router-Limits, insbesondere die maximale Anzahl eindeutiger Ziele für erkannte Routen.

Private Cluster mit VPC Service Controls schützen

Mit VPC Service Controls können Sie Ihre privaten GKE-Cluster noch besser schützen.

VPC Service Controls bietet zusätzliche Sicherheit für private GKE-Cluster, um das Risiko einer Datenexfiltration zu verringern. Mithilfe von VPC Service Controls können Sie Projekte in Perimeterbereiche einfügen, die Ressourcen und Services vor Anfragen schützen, die ihren Ursprung außerhalb des Perimeters haben.

Weitere Informationen zu Dienstperimetern finden Sie unter Informationen zu Dienstperimetern und deren Konfiguration.

Wenn Sie Artifact Registry mit Ihrem privaten GKE-Cluster in einem VPC Service Controls-Dienstperimeter verwenden, müssen Sie das Routing zur eingeschränkten virtuellen IP-Adresse konfigurieren, um die Exfiltration von Daten zu verhindern.