Private Cluster erstellen

Auf dieser Seite wird erläutert, wie Sie einen privaten GKE-Cluster (Google Kubernetes Engine) erstellen, der eine Art VPC-nativer Cluster ist. In einem privaten Cluster haben Knoten nur interne IP-Adressen. Das heißt, Knoten und Pods sind standardmäßig vom Internet isoliert.

Interne IP-Adressen für Knoten stammen aus dem primären IP-Adressbereich des Subnetzes, das Sie für den Cluster auswählen. Pod-IP-Adressen und Service-IP-Adressen stammen aus zwei sekundären Subnetz-IP-Adressbereichen desselben Subnetzes. Weitere Informationen finden Sie unter IP-Bereiche für VPC-native Cluster.

Die GKE-Versionen ab 1.14.2 unterstützen alle internen IP-Adressbereiche, einschließlich privater Bereiche (RFC 1918 und anderer privater Bereiche) sowie privat wiederverwendeter öffentlicher IP-Adressbereiche. Eine Liste der gültigen internen IP-Adressbereiche finden Sie in der VPC-Dokumentation.

Weitere Informationen zur Funktionsweise von privaten Clustern finden Sie unter Private Cluster.

Hinweis

Machen Sie sich mit den Anforderungen, Beschränkungen und Einschränkungen vertraut, bevor Sie mit dem nächsten Schritt fortfahren.

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Achten Sie darauf, dass die Google Kubernetes Engine API aktiviert ist.

Aktivieren Sie Google Kubernetes Engine API

Prüfen Sie, ob das Cloud SDK installiert ist.

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

Führen Sie gcloud init aus und folgen Sie der Anleitung:
```
gcloud init
```
Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:
```
gcloud init --console-only
```
Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
Wählen Sie ein Google Cloud-Projekt aus.
Wählen Sie eine Compute Engine-Standardzone aus.

Hinweis: Sie können diese Standardeinstellungen in gcloud-Befehlen mit den Flags --project, --zone und --region überschreiben.

gcloud config verwenden

Legen Sie Ihre standardmäßige Projekt-ID fest:
```
gcloud config set project project-id
```
Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:
```
gcloud config set compute/zone compute-zone
```
Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
```
gcloud config set compute/region compute-region
```
Aktualisieren Sie gcloud auf die neueste Version:
```
gcloud components update
```

Hinweis: Sie können diese Standardeinstellungen in gcloud-Befehlen mit den Flags --project, --zone und --region überschreiben.

Zugriff auf die Steuerungsebene

In privaten Clustern hat die Steuerungsebene (Master) einen privaten und einen öffentlichen Endpunkt. Es gibt drei Konfigurationskombinationen, um den Zugriff auf die Clusterendpunkte zu steuern:

Zugriff auf öffentliche Endpunkte deaktiviert: Damit wird ein privater Cluster ohne Clientzugriff auf den öffentlichen Endpunkt erstellt.
Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke aktiviert: Dadurch wird ein privater Cluster mit beschränktem Zugriff auf den öffentlichen Endpunkt erstellt.
Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke deaktiviert: Dadurch wird ein privater Cluster mit uneingeschränktem Zugriff auf den öffentlichen Endpunkt erstellt.

Einen Überblick über die Unterschiede zwischen den oben genannten Konfigurationsoptionen finden Sie unter Zugriff auf Clusterendpunkte.

Privaten Cluster ohne Clientzugriff auf den öffentlichen Endpunkt erstellen

In diesem Abschnitt erstellen Sie einen privaten Cluster mit dem Namen private-cluster-0, der private Knoten und keinen Clientzugriff auf den öffentlichen Endpunkt hat.

gcloud

Führen Sie den folgenden Befehl aus:

gcloud container clusters create private-cluster-0 \
    --create-subnetwork name=my-subnet-0 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Dabei gilt:

--create-subnetwork name=my-subnet-0 bewirkt, dass GKE automatisch ein Subnetz mit dem Namen my-subnet-0 erstellt.
--enable-master-authorized-networks gibt an, dass der Zugriff auf den öffentlichen Endpunkt auf von Ihnen autorisierte IP-Adressbereiche beschränkt ist.
--enable-ip-alias sorgt dafür, dass der Cluster VPC-nativ ist.
--enable-private-nodes gibt an, dass die Knoten des Clusters keine externen IP-Adressen haben.
--enable-private-endpoint gibt an, dass der Cluster mithilfe der privaten IP-Adresse für den API-Endpunkt der Steuerungsebene verwaltet wird.
--master-ipv4-cidr 172.16.0.32/28 gibt einen internen IP-Adressbereich für die Steuerungsebene an. Diese Einstellung ist für diesen Cluster dauerhaft. Die Verwendung von internen IP-Adressen außerhalb von RFC 1918 wird unterstützt.
--no-enable-basic-auth gibt an, dass die Basisauthentifizierung für den Cluster deaktiviert werden soll.
--no-issue-client-certificate deaktiviert die Ausgabe eines Clientzertifikats.

Console

Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

Zum Google Kubernetes Engine-Menü
Klicken Sie auf Cluster erstellen.
Geben Sie im Feld Name my-subnet-0 ein.
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Belassen Sie Netzwerk und Knotensubnetz auf default. GKE generiert dadurch ein Subnetz für den Cluster.
Klicken Sie auf das Kästchen Privater Cluster.
Entfernen Sie das Häkchen aus dem Kästchen Mit externer IP-Adresse auf Master zugreifen.
Legen Sie den Master-IP-Bereich auf 172.16.0.32/28 fest.
Klicken Sie im Navigationsbereich unter Cluster auf Sicherheit.
Kontrollieren Sie, dass das Häkchen aus dem Kästchen Clientzertifikat ausstellen entfernt wurde.
Klicken Sie auf Erstellen.

API

Geben Sie das Feld enablePrivateEndpoint: true in der Ressource privateClusterConfig an, um einen Cluster mit einer öffentlich erreichbaren Steuerungsebene zu erstellen.

Dies sind derzeit die einzigen IP-Adressen mit Zugriff auf die Steuerungsebene:

Der primäre Bereich von my-subnet-0
Der für Pods verwendete sekundäre Bereich

Angenommen, Sie haben im primären Bereich von my-subnet-0 eine VM erstellt. Dann können Sie für diese VM kubectl so konfigurieren, dass die interne IP-Adresse der Steuerungsebene verwendet wird.

Wenn Sie außerhalb von my-subnet-0 auf die Steuerungsebene zugreifen möchten, gewähren Sie mindestens einem Adressbereich Zugriff auf den privaten Endpunkt.

Angenommen, Sie haben eine VM im Standardnetzwerk in derselben Region wie Ihr Cluster, aber nicht in my-subnet-0.

Beispiel:

my-subnet-0: 10.0.0.0/22
Sekundärer Bereich für Pods: 10.52.0.0/14
VM-Adresse: 10.128.0.3

Sie können der VM mit folgendem Befehl Zugriff auf die Steuerungsebene gewähren:

gcloud container clusters update private-cluster-0 \
    --enable-master-authorized-networks \
    --master-authorized-networks 10.128.0.3/32

Privaten Cluster mit beschränktem Zugriff auf den öffentlichen Endpunkt erstellen

Beim Erstellen eines privaten Clusters mit dieser Konfiguration können Sie ein automatisch erzeugtes Subnetz oder ein benutzerdefiniertes Subnetz verwenden.

Automatisch erzeugtes Subnetz verwenden

In diesem Abschnitt erstellen Sie einen privaten Cluster mit dem Namen private-cluster-1, in dem GKE automatisch ein Subnetz für Ihre Clusterknoten erzeugt. Für das Subnetz ist der private Google-Zugriff aktiviert. GKE erstellt im Subnetz automatisch zwei sekundäre Bereiche: einen für Pods und einen für Dienste.

gcloud

Führen Sie den folgenden Befehl aus:

gcloud container clusters create private-cluster-1 \
    --create-subnetwork name=my-subnet-1 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.0/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Dabei gilt:

--create-subnetwork name=my-subnet-1 bewirkt, dass GKE automatisch ein Subnetz mit dem Namen my-subnet-1 erstellt.
--enable-master-authorized-networks gibt an, dass der Zugriff auf den öffentlichen Endpunkt auf von Ihnen autorisierte IP-Adressbereiche beschränkt ist.
--enable-ip-alias sorgt dafür, dass der Cluster VPC-nativ ist.
--enable-private-nodes gibt an, dass die Knoten des Clusters keine externen IP-Adressen haben.
--master-ipv4-cidr 172.16.0.0/28 gibt einen internen IP-Adressbereich für die Steuerungsebene an. Diese Einstellung ist für diesen Cluster dauerhaft. Die Verwendung von internen IP-Adressen außerhalb von RFC 1918 wird unterstützt.
--no-enable-basic-auth deaktiviert die Basisauthentifizierung für den Cluster.
--no-issue-client-certificate deaktiviert die Ausgabe eines Clientzertifikats.

Console

Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

Zum Google Kubernetes Engine-Menü
Klicken Sie auf Cluster erstellen.
Geben Sie im Feld Name my-subnet-1 ein.
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Belassen Sie Netzwerk und Knotensubnetz auf default. GKE generiert dadurch ein Subnetz für den Cluster.
Klicken Sie auf das Kästchen Privater Cluster.
Wenn Sie eine Steuerungsebene erstellen möchten, auf die von autorisierten externen IP-Bereichen aus zugegriffen werden kann, lassen Sie das Kästchen Mit externer IP-Adresse auf Master zugreifen aktiviert.
Legen Sie den Master-IP-Bereich auf 172.16.0.0/28 fest.
Klicken Sie auf das Kästchen Autorisierte Masternetzwerke aktivieren.
Klicken Sie im Navigationsbereich unter Cluster auf Sicherheit.
Kontrollieren Sie, dass das Häkchen aus dem Kästchen Clientzertifikat ausstellen entfernt wurde.
Klicken Sie auf Erstellen.

API

Geben Sie das Feld privateClusterConfig in der API-Ressource Cluster an:

{
  "name": "private-cluster-1",
  ...
  "ipAllocationPolicy": {
    "createSubnetwork": true,
  },
  ...
    "privateClusterConfig" {
      "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
      "enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
      "masterIpv4CidrBlock": string # CIDR block for the cluster control plane
      "privateEndpoint": string # Output only
      "publicEndpoint": string # Output only
  }
}

Dies sind an diesem Punkt die einzigen IP-Adressen mit Zugriff auf die Clustersteuerungsebene:

Der primäre Bereich von my-subnet-1
Der für Pods verwendete sekundäre Bereich

Angenommen, Sie haben außerhalb Ihres VPC-Netzwerks mehrere Maschinen mit Adressen im Bereich 203.0.113.0/29. Diesen Maschinen können Sie mit folgendem Befehl Zugriff auf den öffentlichen Endpunkt gewähren:

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

Dies sind jetzt die einzigen IP-Adressen mit Zugriff auf die Steuerungsebene:

Der primäre Bereich von my-subnet-1
Der für Pods verwendete sekundäre Bereich
Von Ihnen autorisierte Adressbereiche, beispielsweise 203.0.113.0/29

Benutzerdefiniertes Subnetz verwenden

In diesem Abschnitt legen Sie einen privaten Cluster mit dem Namen private-cluster-2 an. Sie erstellen das Netzwerk my-net-0. Sie erstellen das Subnetz my-subnet-2 mit dem primären Bereich 192.168.0.0/20 für Ihre Clusterknoten. Das Subnetz hat zwei sekundäre Adressbereiche: my-pods-1 für die Pod-IP-Adressen und my-services-1 für die Dienst-IP-Adressen.

gcloud

Netzwerk erstellen

Erstellen Sie zuerst ein Netzwerk für den Cluster. Mit dem folgenden Befehl wird das Netzwerk my-net-0 erstellt:

gcloud compute networks create my-net-0 \
    --subnet-mode custom

Subnetz und sekundäre Bereiche erstellen

Erstellen Sie dann das Subnetz my-subnet-2 im Netzwerk my-net-0 mit den sekundären Bereichen my-pods-2 für Pods und my-services-2 für Dienste:

gcloud compute networks subnets create my-subnet-2 \
    --network my-net-0\
    --region us-central1 \
    --range 192.168.0.0/20 \
    --secondary-range my-pods-2=10.4.0.0/14,my-services-2=10.0.32.0/20 \
    --enable-private-ip-google-access

Privaten Cluster erstellen

Erstellen Sie nun den privaten Cluster private-cluster-1 mit dem Netzwerk, Subnetz und den sekundären Bereichen, die Sie erstellt haben.

gcloud container clusters create private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --network my-net-0 \
    --subnetwork my-subnet-2 \
    --cluster-secondary-range-name my-pods-2 \
    --services-secondary-range-name my-services-2 \
    --enable-private-nodes \
    --enable-ip-alias \
    --master-ipv4-cidr 172.16.0.16/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Console

Netzwerk, Subnetz und sekundäre Bereiche erstellen

Rufen Sie in der Cloud Console die Seite "VPC-Netzwerke" auf.

Zur VPC-Netzwerkseite
Klicken Sie auf VPC-Netzwerk erstellen.
Geben Sie für Name my-net-0 ein.
Achten Sie darauf, dass der Modus für Subnetzerstellung auf Benutzerdefiniert eingestellt ist.
Geben Sie unter Neues Subnetz in Name my-subnet-2 ein.
Wählen Sie in der Drop-down-Liste Region die gewünschte Region aus.
Geben Sie 192.168.0.0/20 als IP-Adressbereich ein.
Klicken Sie auf Sekundären IP-Bereich erstellen. Geben Sie my-services-1 für Name des Subnetzbereichs und 10.0.32.0/20 für Sekundärer IP-Bereich ein.
Klicken Sie auf IP-Bereich hinzufügen. Geben Sie für Name des Subnetzbereichs my-pods-1 und für Sekundärer IP-Bereich 10.4.0.0/14 ein.
Klicken Sie bei Privater Google-Zugriff auf An.
Klicken Sie auf Fertig.
Klicken Sie auf Erstellen.

Privaten Cluster erstellen

Erstellen Sie einen privaten Cluster, der Ihr Subnetz verwendet:

Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

Zum Google Kubernetes Engine-Menü
Klicken Sie auf Cluster erstellen.
Geben Sie im Feld Name private-cluster-2 ein.
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Klicken Sie auf das Kästchen Privater Cluster.
Wenn Sie eine Steuerungsebene erstellen möchten, auf die von autorisierten externen IP-Bereichen aus zugegriffen werden kann, lassen Sie das Kästchen Mit externer IP-Adresse auf Master zugreifen aktiviert.
Legen Sie den Master-IP-Bereich auf 172.16.0.16/28 fest.
Wählen Sie in der Drop-down-Liste Netzwerk die Option my-net-1 aus.
Wählen Sie in der Drop-down-Liste Knotensubnetz die Option my-subnet-2 aus.
Entfernen Sie das Häkchen des Kästchens Sekundäre Bereiche automatisch erstellen.
Wählen Sie in der Drop-down-Liste Sekundärer Pod-CIDR-Bereich die Option my-pods-1 aus.
Wählen Sie in der Drop-down-Liste Sekundärer CIDR-Dienstbereich die Option my-services-1 aus.
Klicken Sie auf das Kästchen Autorisierte Masternetzwerke aktivieren.
Klicken Sie im Navigationsbereich unter Cluster auf Sicherheit.
Kontrollieren Sie, dass das Häkchen aus dem Kästchen Clientzertifikat ausstellen entfernt wurde.
Klicken Sie auf Erstellen.

Dies sind derzeit die einzigen IP-Adressen mit Zugriff auf die Steuerungsebene:

Der primäre Bereich von my-subnet-2
Der sekundäre Bereich my-pods-1

Angenommen, Sie haben eine Gruppe von Computern außerhalb von my-net-1 mit Adressen im Bereich 203.0.113.0/29. Diesen Maschinen können Sie mit folgendem Befehl Zugriff auf den öffentlichen Endpunkt gewähren:

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

Dies sind derzeit die einzigen IP-Adressen mit Zugriff auf die Steuerungsebene:

Der primäre Bereich von my-subnet-2
Der sekundäre Bereich my-pods-1
Von Ihnen autorisierte Adressbereiche, beispielsweise 203.0.113.0/29

Mit Cloud Shell auf einen privaten Cluster zugreifen

Für den privaten Cluster private-cluster-1, den Sie in der vorherigen Übung erstellt haben, sind ein öffentlicher Endpunkt und autorisierte Netzwerke aktiviert. Wenn Sie mit Cloud Shell auf den Cluster zugreifen möchten, müssen Sie der Liste autorisierter Netzwerke des Clusters die öffentliche IP-Adresse von Cloud Shell hinzufügen.

So gehen Sie dazu vor:

Verwenden Sie im Cloud Shell-Befehlszeilenfenster dig, um die externe IP-Adresse Ihrer Cloud Shell zu finden:
```
dig +short myip.opendns.com @resolver1.opendns.com
```
Fügen Sie der Liste autorisierter Netzwerke Ihres Clusters die externe Adresse von Cloud Shell hinzu:
```
gcloud container clusters update private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --master-authorized-networks existing-auth-nets,shell-IP/32
```
Dabei gilt:
- existing-auth-nets ist die bestehende Liste autorisierter Netzwerke. Sie finden die autorisierten Netzwerke in der Konsole oder über den folgenden Befehl:
```
gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
```
- shell-IP ist die externe IP-Adresse Ihrer Cloud Shell.
Rufen Sie die Anmeldedaten ab, damit Sie kubectl für den Zugriff auf den Cluster verwenden können:
```
gcloud container clusters get-credentials private-cluster-1 \
    --zone us-central1-a \
    --project project-id
```
Dabei ist project-id Ihre Projekt-ID.

Jetzt können Sie mit kubectl in Cloud Shell auf Ihren privaten Cluster zugreifen. Beispiel:

kubectl get nodes

Privaten Cluster mit unbeschränktem Zugriff auf den öffentlichen Endpunkt erstellen

In diesem Abschnitt erstellen Sie einen privaten Cluster, in dem jede IP-Adresse auf die Steuerungsebene zugreifen kann.

gcloud

Führen Sie den folgenden Befehl aus:

gcloud container clusters create private-cluster-2 \
    --create-subnetwork name=my-subnet-3 \
    --no-enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Dabei gilt:

--create-subnetwork name=my-subnet-3 bewirkt, dass GKE automatisch ein Subnetz mit dem Namen my-subnet-3 erstellt.
--no-enable-master-authorized-networks deaktiviert autorisierte Netzwerke für den Cluster.
--enable-ip-alias sorgt dafür, dass der Cluster VPC-nativ ist.
--enable-private-nodes gibt an, dass die Knoten des Clusters keine externen IP-Adressen haben.
--master-ipv4-cidr 172.16.0.32/28 gibt einen internen Adressbereich für die Steuerungsebene an. Diese Einstellung ist für diesen Cluster dauerhaft. Die Verwendung von internen IP-Adressen außerhalb von RFC 1918 wird unterstützt.
--no-enable-basic-auth gibt an, dass die Basisauthentifizierung für den Cluster deaktiviert werden soll.
--no-issue-client-certificate deaktiviert die Ausgabe eines Clientzertifikats.

Console

Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

Zum Google Kubernetes Engine-Menü
Klicken Sie auf Cluster erstellen.
Geben Sie im Feld Name private-cluster-2 ein.
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Belassen Sie Netzwerk und Knotensubnetz auf default. GKE generiert dadurch ein Subnetz für den Cluster.
Wählen Sie die Option Privater Cluster aus.
Lassen Sie das Kästchen Mit externer IP-Adresse auf Master zugreifen aktiviert.
Legen Sie den Master-IP-Bereich auf 172.16.0.32/28 fest.
Entfernen Sie das Häkchen aus dem Kästchen Autorisierte Masternetzwerke aktivieren.
Klicken Sie im Navigationsbereich unter Cluster auf Sicherheit.
Kontrollieren Sie, dass das Häkchen aus dem Kästchen Clientzertifikat ausstellen entfernt wurde.
Klicken Sie auf Erstellen.

Andere Konfigurationen privater Cluster

Neben den vorherigen Konfigurationen können private Cluster auch mit folgenden Konfigurationen ausgeführt werden.

Privaten Knoten ausgehenden Internetzugriff gewähren

Wenn Sie privaten Knoten ausgehenden Internetzugriff gewähren möchten, können Sie Cloud NAT verwenden oder Ihr eigenes NAT-Gateway verwalten.

Privaten Cluster in einem freigegebenen VPC-Netzwerk erstellen

Informationen zum Erstellen eines privaten Clusters in einem freigegebenen VPC-Netzwerk finden Sie in der Dokumentation zu freigegebenen VPCs.

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 TCP/UDP-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 TCP/UDP-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 TCP/UDP-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 TCP/UDP-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. Für den globalen Zugriff auf Steuerungsebene verwenden Sie gcloud oder die Google Cloud Console.

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-ip-alias \
  --master-ipv4-cidr=172.16.16.0/28 \
  --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

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 Cloud Console das Kubernetes Engine-Menü auf.

Zum Google Kubernetes Engine-Menü
Klicken Sie auf Cluster erstellen.
Geben Sie einen Namen ein.
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Klicken Sie auf das Kästchen Privater Cluster.
Klicken Sie auf das Kästchen Globaler Masterzugriff.
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 Cloud Console das Kubernetes Engine-Menü auf.

Zum Google Kubernetes Engine-Menü
Klicken Sie auf die Schaltfläche "Bearbeiten" (Stiftsymbol) des Clusters.
Wählen Sie in der Drop-down-Liste Globaler Masterzugriff die Option Aktiviert aus.
Klicken Sie auf Speichern.

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 lokalen Netzwerken aus mit dem privaten Endpunkt der Steuerungsebene verbinden

Wenn Sie einen privaten GKE-Cluster erstellen und den öffentlichen Endpunkt der Steuerungsebene deaktivieren, können Sie mit Tools wie kubectl trotzdem eine Verbindung von einem lokalen Netzwerk zum privaten Endpunkt der Steuerungsebene herstellen. In diesem Abschnitt werden die Netzwerkanforderungen beschrieben, die für den Zugriff auf den privaten Endpunkt der Steuerungsebene von einem lokalen Netzwerk aus erforderlich sind.

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

Führen Sie folgende Schritte aus, um über ein lokales Netzwerk eine Verbindung zum privaten Endpunkt einer Steuerungsebene herzustellen:

Identifizieren Sie das Peering zwischen dem VPC-Netzwerk des Clusters und dem VPC-Netzwerk der Steuerungsebene:
```
gcloud container clusters describe cluster-name
```
Die Ausgabe dieses Befehls enthält das Feld privateClusterConfig.peeringName des Clusters. Dies ist der Name des Peering-Vorgangs zwischen Ihrem Cluster und dem VPC-Netzwerk der Steuerungsebene. Beispiel:
```
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
```
Konfigurieren Sie Ihr VPC-Netzwerk so, dass die benutzerdefinierten Routen in der Peering-Beziehung in das VPC-Netzwerk der Steuerungsebene exportiert werden. Das VPC-Netzwerk der Steuerungsebene ist bereits für den Import benutzerdefinierter Routen konfiguriert. Dadurch steht Ihnen ein Pfad für die Steuerungsebene zur Verfügung, über den Pakete an lokale Ressourcen zurückgesendet werden können.

Aktualisieren Sie die Peering-Verbindung und aktivieren Sie den Export benutzerdefinierter Routen für die im vorherigen Schritt identifizierte Verbindung.
Führen Sie einen der folgenden Schritte aus, um einen Pfad für den Traffic von Ihrem lokalen Netzwerk zum VPC-Netzwerk der Steuerungsebene bereitzustellen:
- Für Cloud Interconnect und Cloud VPN: Bieten Sie den CIDR-Bereich der Steuerungsebene mit einem benutzerdefinierten Cloud Router-Route-Advertisement an. Wenn der globale Zugriff auf die Steuerungsebene deaktiviert ist, muss sich dieses benutzerdefinierte Route Advertisement in einer BGP-Sitzung eines Cloud Routers in derselben Region wie der Cluster befinden. Wenn der globale Zugriff auf die Steuerungsebene aktiviert ist, können Sie dieses benutzerdefinierte Route Advertisement auf einem Cloud Router in einer beliebigen Region platzieren. Weitere Informationen finden Sie unter Benutzerdefinierte IP-Bereiche bewerben.
- Für einen klassischen VPN-Tunnel, der kein dynamisches Routing verwendet: Sie müssen eine statische Route für den CIDR-Bereich der Steuerungsebene in Ihren lokalen Routern konfigurieren.

Hinweise zu lokalen Route Advertisements

Die CIDRs, die Ihr lokales Netzwerk Cloud Routern im VPC-Netzwerk des Clusters anbietet, müssen die folgenden Bedingungen erfüllen:

Während die VPC Ihres Clusters eine Standardroute akzeptiert, lehnt das VPC-Netzwerk der Steuerungsebene Routen mit dem Ziel 0.0.0.0/0 (Standardroute) immer ab, da das VPC-Netzwerk der Steuerungsebene bereits eine lokale Standardroute hat. Diese lokale Route wird immer zuerst berücksichtigt. Wenn Ihr lokaler Router eine Standardroute in Ihrem VPC-Netzwerk anbietet, sollte er auch bestimmte lokale Ziele anbieten, damit die Steuerungsebene einen Rückgabepfad zum lokalen Netzwerk hat. Diese spezifischeren Ziele führen zu spezifischeren benutzerdefinierten dynamischen Routen in Ihrem VPC-Netzwerk. Diese spezifischeren Routen werden über VPC-Netzwerk-Peering vom VPC-Netzwerk der Steuerungsebene akzeptiert.
Wenn das VPC-Netzwerk der Steuerungsebene andere weit gefasste Routen akzeptiert, wird die Verbindung zu den öffentlichen IP-Adressen für Google APIs und -Dienste unterbrochen. Als repräsentatives Beispiel sollten Sie keine Routen mit den Zielen 0.0.0.0/1 und 128.0.0.0/1 anbieten. Eine Alternative finden Sie im vorherigen Punkt.
Prüfen Sie die Cloud Router-Limits, insbesondere die maximale Anzahl eindeutiger Ziele für erkannte Routen.

Export benutzerdefinierter Routen deaktivieren

So deaktivieren Sie den Export benutzerdefinierter Routen aus Ihrer VPC:

gcloud compute networks peerings update peering --network network --no-export-custom-routes

Dabei gilt:

peering ist der Wert von privateClusterConfig.peeringName.
network ist der Name Ihrer VPC.

Zum Feststellen des peeringName gehen Sie wie im ersten Schritt oben beschrieben vor, um den Export der benutzerdefinierten Route zu aktivieren.

Externe IP-Adressen für Knoten ausschließen

Kontrollieren Sie nach dem Erstellen eines privaten Clusters, dass die Knoten des Clusters keine externen IP-Adressen haben.

gcloud

Führen Sie den folgenden Befehl aus:

kubectl get nodes --output wide

Die Spalte EXTERNAL-IP der Ausgabe ist leer:

STATUS ... VERSION        EXTERNAL-IP  OS-IMAGE ...
Ready      v.8.7-gke.1                 Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google

Console

Rufen Sie in der Cloud Console das GKE-Menü auf.

Zum GKE-Menü
Klicken Sie in der Liste der Cluster auf den gewünschten Cluster.
Klicken Sie unter Knotenpools auf den Namen Ihrer Instanzgruppe. Beispiel: gke-private-cluster-0-default-pool-5c5add1f-grp
Bestätigen Sie in der Liste der Instanzen, dass Ihre Instanzen keine externen IP-Adressen haben.

Subnetz und sekundäre Adressbereiche des Clusters ansehen

Nachdem Sie einen privaten Cluster erstellt haben, können Sie die von Ihnen oder GKE für den Cluster bereitgestellten Subnetze und sekundären Adressbereiche anzeigen lassen.

gcloud

Alle Subnetze auflisten

Listen Sie die im Netzwerk Ihres Clusters enthaltenen Subnetze mit folgendem Befehl auf:

gcloud compute networks subnets list --network network

Dabei gilt: network ist das Netzwerk des privaten Clusters. Wenn Sie den Cluster mit einem automatisch erstellten Subnetz angelegt haben, verwenden Sie default.

Suchen Sie in der Ausgabe des Befehls den Namen des Subnetzes des Clusters.

Subnetz des Clusters ansehen

Rufen Sie Informationen zum automatisch erstellten Subnetz ab:

gcloud compute networks subnets describe subnet-name

Dabei gilt: subnet-name ist der Name des Subnetzes.

In der Ausgabe werden im ersten Feld ipCidrRange der primäre Adressbereich für Knoten und unter secondaryIpRanges die sekundären Bereiche für Pods und Dienste angezeigt:

...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
  rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
  rangeName: gke-private-cluster-1-services-163e3c97
...

Console

Rufen Sie in der Cloud Console die Seite "VPC-Netzwerke" auf.

Zur VPC-Netzwerkseite
Klicken Sie auf den Namen des Subnetzes. Beispiel: gke-private-cluster-0-subnet-163e3c97.
Unter IP-Adressbereich sehen Sie den primären Adressbereich Ihres Subnetzes. Dies ist der Bereich, der für Knoten verwendet wird.
Unter Sekundäre IP-Bereiche sehen Sie den IP-Adressbereich für Pods und den für Dienste.

Endpunkte eines privaten Clusters ansehen

Sie können sich die Endpunkte privater Cluster mit dem gcloud-Befehlszeilentool oder der Cloud Console anzeigen lassen.

gcloud

Führen Sie den folgenden Befehl aus:

gcloud container clusters describe cluster-name

Die Ausgabe zeigt die privaten und öffentlichen Endpunkte:

...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67

Console

Rufen Sie in der Cloud Console das GKE-Menü auf.

Zum GKE-Menü
Klicken Sie in der Liste auf den gewünschten Cluster.
Suchen Sie dann auf dem Tab Details unter Cluster nach dem Feld Endpunkt.

Container-Images von einer Image-Registry herunterladen

In einem privaten Cluster kann die Containerlaufzeit Container-Images nur von Container Registry herunterladen, also von keiner anderen Registry für Container-Images im Internet. Das liegt daran, dass die Knoten in einem privaten Cluster keine externen IP-Adressen haben. Daher können sie standardmäßig nicht mit Diensten außerhalb des Google-Netzwerks kommunizieren.

Die Knoten in einem privaten Cluster können mit Google-Diensten wie Container Registry kommunizieren, wenn sie sich in einem Subnetz befinden, für das der private Google-Zugriff aktiviert ist.

Mit den folgenden Befehlen erstellen Sie ein Deployment, mit dem ein Beispiel-Image von einem Container Registry-Repository von Google heruntergeladen wird.

kubectl run hello-deployment --image gcr.io/google-samples/hello-app:2.0

Firewallregeln für bestimmte Anwendungsfälle hinzufügen

In diesem Abschnitt wird erläutert, wie Sie eine Firewallregel zu einem privaten Cluster hinzufügen. Die Steuerungsebene Ihres Clusters wird von Firewallregeln standardmäßig so beschränkt, dass nur TCP-Verbindungen zu den Knoten auf den Ports 443 (HTTPS) und 10250 (Kubelet) initiiert werden. Bei einigen Kubernetes-Features müssen eventuell Firewallregeln ergänzt werden, um den Zugriff auf zusätzlichen Ports zuzulassen.

Zu den Kubernetes-Features, für die weitere Firewallregeln erforderlich sind, gehören:

Zulassungs-Webhooks
Aggregierte API-Server
Webhook-Umwandlung
Dynamische Audit-Konfiguration
Im Allgemeinen sind für jede API mit einem Feld „ServiceReference“ zusätzliche Firewallregeln erforderlich.

Durch Hinzufügen einer Firewallregel wird Traffic von der Clustersteuerungsebene zu Folgendem ermöglicht:

Zum angegebenen Port jedes Knotens (hostPort)
Zum angegebenen Port jedes Pods, der auf diesen Knoten ausgeführt wird
Zum angegebenen Port jedes Dienstes, der auf diesen Knoten ausgeführt wird

Informationen zu Firewallregeln finden Sie in der Dokumentation zu Cloud Load Balancing unter Firewallregeln.

Wenn Sie eine Firewallregel in einem privaten Cluster hinzufügen möchten, müssen Sie den CIDR-Block der Clustersteuerungsebene und das verwendete Ziel erfassen. Nach dem Erfassen können Sie die Regel erstellen.

Schritt 1: CIDR-Block der Steuerungsebene ansehen

Sie benötigen den CIDR-Block der Clustersteuerungsebene, um eine Firewallregel hinzuzufügen.

gcloud

Führen Sie den folgenden Befehl aus:

gcloud container clusters describe cluster-name

Dabei ist cluster-name der Name Ihres privaten Clusters.

Notieren Sie sich in der Befehlsausgabe den Wert im Feld masterIpv4CidrBlock.

Console

Rufen Sie in der Cloud Console das GKE-Menü auf.

Zum GKE-Menü
Wählen Sie den gewünschten Cluster aus.

Notieren Sie sich auf dem Tab Details unter Cluster den Wert im Feld Masteradressbereich.

Schritt 2: Vorhandene Firewallregeln ansehen

Das von den vorhandenen Firewallregeln des Clusters verwendete Ziel muss angegeben werden. In diesem Fall sind es Zielknoten.

gcloud

Führen Sie den folgenden Befehl aus:

gcloud compute firewall-rules list \
    --filter 'name~^gke-cluster-name' \
    --format 'table(
        name,
        network,
        direction,
        sourceRanges.list():label=SRC_RANGES,
        allowed[].map().firewall_rule().list():label=ALLOW,
        targetTags.list():label=TARGET_TAGS
    )'

Notieren Sie sich aus der Befehlsausgabe den Wert im Feld Ziele.

Hinweis: Wenn Sie Firewallregeln für eine freigegebene VPC aufrufen möchten, fügen Sie dem Befehl das Flag --project host-project-id hinzu.

Weitere Informationen zur freigegebenen VPC finden Sie unter Cluster mit freigegebener VPC einrichten.

Console

Rufen Sie in der Cloud Console das Menü "Firewallregeln" auf.

Zum Menü "Firewallregeln"
Geben Sie im Feld Ressourcen filtern gke-cluster-name ein.

Notieren Sie aus den Ergebnissen den Wert im Feld Ziele.

Schritt 3: Firewallregel hinzufügen

gcloud

Führen Sie den folgenden Befehl aus:

gcloud compute firewall-rules create firewall-rule-name \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges master-CIDR-block \
    --rules protocol:port \
    --target-tags target

Dabei gilt:

firewall-rule-name ist der von Ihnen ausgewählte Name für die Firewallregel.
master-CIDR-block ist der zuvor ermittelte CIDR-Block der Clustersteuerungsebene (masterIpv4CidrBlock).
protocol:port ist der gewünschte Port und das zugehörige Protokoll, tcp oder udp.
target ist der vorher notierte Zielwert (Targets).

Hinweis: Wenn Sie eine Firewallregel für eine freigegebene VPC hinzufügen möchten, fügen Sie dem Befehl die folgenden Flags hinzu:

--project host-project-id
--network network-id

Weitere Informationen zur freigegebenen VPC finden Sie unter Cluster mit freigegebener VPC einrichten.

Console

Rufen Sie in der Cloud Console das Menü "Firewallregeln" auf.

Zum Menü "Firewallregeln"
Klicken Sie auf Firewallregel erstellen.
Geben Sie in das Feld Name den gewünschten Namen für die Firewallregel ein.
Wählen Sie in der Drop-down-Liste Netzwerk das entsprechende Netzwerk aus.
Klicken Sie dann unter Traffic-Richtung auf Eingehend.
Klicken Sie anschließend unter Aktion bei Übereinstimmung auf Zulassen.
Wählen Sie in der Drop-down-Liste Ziele die Option Angegebene Ziel-Tags aus.
Geben Sie dann im Feld Zieltags den vorher notierten Zielwert ein.
Wählen Sie in der Drop-down-Liste Quellfilter die Option IP-Bereiche aus.
Geben Sie dann im Feld Quell-IP-Bereiche den zuvor ermittelten CIDR-Block der Clustersteuerungsebene ein.
Klicken Sie anschließend unter Protokolle und Ports auf Angegebene Protokolle und Ports, klicken Sie das Kästchen bei dem entsprechenden Protokoll (TCP oder UDP) an und geben Sie im vorhandenen Feld den gewünschten Port ein.
Klicken Sie auf Erstellen.

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 auf der Seite Dienstperimeterkonfiguration der Dokumentation zu VPC Service Controls.

Wenn Sie die Container Registry mit Ihrem privaten GKE-Cluster verwenden, sind zusätzliche Schritte erforderlich, um den privaten Cluster mit VPC Service Controls zu verwenden. Weitere Informationen finden Sie auf der Seite Container Registry für private GKE-Cluster einrichten.

VPC-Peering wiederverwenden

Für private Cluster, die nach dem 15. Januar 2020 erstellt werden, können VPC-Netzwerk-Peering-Verbindungen wiederverwendet werden.

Alle privaten Cluster, die Sie vor dem 15. Januar 2020 erstellt haben, verwenden eine einmalige VPC-Netzwerk-Peering-Verbindung. Jedes VPC-Netzwerk kann ein Peering mit bis zu 25 anderen VPC-Netzwerken ausführen. Für diese Cluster besteht also ein Limit von maximal 25 privaten Clustern pro Netzwerk. Dabei wird davon ausgegangen, dass Peerings nicht für andere Zwecke verwendet werden.

Dieses Feature wird nicht zu früheren Releases zurückportiert. Für die Wiederverwendung des VPC-Netzwerk-Peerings durch ältere private Cluster können Sie Cluster löschen und neu erstellen. Das Upgrade eines Clusters ermöglicht keine Wiederverwendung einer vorhandenen VPC-Netzwerk-Peering-Verbindung.

Jeder Standort kann maximal 75 private Cluster unterstützen, wenn für die Cluster die VPC-Peering-Wiederverwendung aktiviert ist. Zonen und Regionen werden als separate Standorte behandelt. So lassen sich z. B. bis zu 75 private zonale Cluster in us-east1-a und weitere 75 private regionale Cluster in us-east1 erstellen. Dies gilt auch, wenn Sie private Cluster in einem freigegebenen VPC-Netzwerk verwenden. Es sind maximal 25 Verbindungen zu einem einzelnen VPC-Netzwerk möglich. Dies bedeutet, dass Sie nur private Cluster mit 25 separaten Standorten erstellen können.

Sie können prüfen, ob Ihr privater Cluster VPC-Peering-Verbindungen wiederverwendet.

gcloud

gcloud container clusters describe cluster-name \
--zone=zone-name \
--format="value(privateClusterConfig.peeringName)"

Wenn Ihr Cluster VPC-Peering-Verbindungen wiederverwendet, beginnt die Ausgabe mit gke-n. Beispiel: gke-n34a117b968dee3b2221-93c6-40af-peer

Console

Prüfen Sie die Zeile für das VPC-Peering auf der Seite der Clusterdetails. Wenn Ihr Cluster VPC-Peering-Verbindungen wiederverwendet, beginnt die Ausgabe mit gke-n. Beispiel: gke-n34a117b968dee3b2221-93c6-40af-peer

Bereinigen

Wenn Sie mit den Aufgaben auf dieser Seite fertig sind, entfernen Sie die Ressourcen anhand der folgenden Schritte, sodass keine unerwünschten Kosten für Ihr Konto entstehen:

Cluster löschen

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1

Console

Rufen Sie in der Cloud Console das GKE-Menü auf.

Zum GKE-Menü
Wählen Sie jeden Cluster aus.
Klicken Sie auf Löschen.

Netzwerk löschen

gcloud

gcloud compute networks delete net-0

Console

Rufen Sie in der Cloud Console die Seite "VPC-Netzwerke" auf.

Zur VPC-Netzwerkseite
Klicken Sie unter net-0 in der Liste der Netzwerke auf das Papierkorbsymbol.
Klicken Sie neben jedem Subnetz auf das Papierkorbsymbol.

Anforderungen, Beschränkungen und Einschränkungen

Für private Cluster gelten folgende Anforderungen:

Ein privater Cluster muss ein VPC-nativer Cluster sein, für den Alias-IP-Bereiche aktiviert sind. "VPC nativ" ist für neue Cluster standardmäßig aktiviert. VPC-native Cluster sind nicht mit Legacy-Netzwerken kompatibel.

Für private Cluster gelten folgende Beschränkungen:

Bestehende nicht private Cluster können nicht in private Cluster konvertiert werden.
Bei Clustern, auf denen Versionen vor 1.16.9 oder Versionen zwischen 1.17.0 und 1.17.4 ausgeführt werden, kann die Clustersteuerungsebene nicht von 172.17.0.0/16-CIDRs erreicht werden.
Bei Clustern mit Versionen vor 1.14.4 darf sich der IP-Bereich einer Clustersteuerungsebene, eines Knotens, eines Pods oder eines Service nicht mit 172.17.0.0/16 überschneiden.
Wenn Sie 172.17.0.0/16 für den IP-Bereich der Steuerungsebene verwenden, können Sie diesen Bereich nicht für Knoten-, Pod- oder Service-IP-Adressen verwenden. Diese Einschränkung gilt für zonale Cluster mit Version 1.14.4 oder höher sowie für regionale Cluster mit den Versionen 1.16.9 bis 1.17.0 oder 1.17.4 und höher.
Ein privater Cluster funktioniert nicht mehr, wenn das VPC-Peering zwischen der Clustersteuerungsebene und den Clusterknoten gelöscht wird, wenn die Firewallregeln, die eingehenden Traffic von der Clustersteuerungsebene zu Knoten auf Port 10250 zulassen, gelöscht werden, und wenn die Standardroute zum Standard-Internetgateway gelöscht wird. Damit ein privater Cluster nach dem Löschen der Standardroute wieder aufgerufen werden kann, müssen Sie die eingeschränkte VIP statisch bereitstellen.
Einem Projekt können bis zu 50 autorisierte Netzwerke (zugelassene CIDR-Blöcke) hinzugefügt werden. Weitere Informationen finden Sie unter Einem vorhandenen Cluster ein autorisiertes Netzwerk hinzufügen.

Für private Cluster gelten folgende Beschränkungen:

Der RFC 1918-Block für die Clustersteuerungsebene muss eine Größe von /28 haben.
GKE kann Überschneidungen mit dem Adressblock der Clustersteuerungsebene erkennen. Dies ist in einem freigegebenen VPC-Netzwerk jedoch nicht möglich.
Alle Knoten in einem privaten Cluster werden ohne öffentliche IP-Adresse erstellt. Sie haben eingeschränkten Zugriff auf Google APIs und Google-Dienste Wenn Sie privaten Knoten ausgehenden Internetzugriff gewähren möchten, können Sie Cloud NAT verwenden oder Ihr eigenes NAT-Gateway verwalten. Damit Knoten mit Google APIs und Google-Diensten kommunizieren können, aktivieren Sie den privaten Google-Zugriff in Ihrem Subnetz.
Private Cluster, die vor dem 15. Januar 2020 erstellt wurden, können maximal 25 private Cluster pro Netzwerk haben. Dabei wird davon ausgegangen, dass Peerings nicht für andere Zwecke verwendet werden. Weitere Informationen finden Sie unter VPC-Peering wiederverwenden.
Jeder private Cluster erfordert eine Peering-Route zwischen Ihren VPCs und den VPCs von Google. Es ist jedoch jeweils immer nur ein Peering-Vorgang möglich. Wenn Sie versuchen, mehrere private Cluster gleichzeitig zu erstellen, kann es zu einer Zeitüberschreitung bei der Clustererstellung kommen. Wenn Sie dies vermeiden möchten, erstellen Sie seriell neue private Cluster, damit die VPC-Peering-Routen für jeden nachfolgenden privaten Cluster bereits vorhanden sind. Beim Versuch, einen einzelnen privaten Cluster zu erstellen, kann es zu einer Zeitüberschreitung kommen, wenn Vorgänge in Ihrer VPC ausgeführt werden.

Fehlerbehebung

In den folgenden Abschnitten wird beschrieben, wie Sie häufige Probleme im Zusammenhang mit privaten Clustern beheben können.

Cluster überschneidet sich mit aktivem Peer

Symptome: Bei dem Versuch, einen privaten Cluster zu erstellen, wird ein Fehler wie Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network. zurückgegeben.
Mögliche Ursachen: Sie haben ein überlappendes CIDR der Steuerungsebene ausgewählt.
Lösung: Löschen Sie den Cluster und erstellen Sie ihn noch einmal mit einem anderen CIDR der Steuerungsebene.

Cluster kann nicht erreicht werden

Symptome: Wenn Sie nach dem Erstellen eines privaten Clusters Befehle vom Typ kubectl ausführen, wird ein Fehler zurückgegeben, beispielsweise Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out oder Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Mögliche Ursachen: kubectl kann nicht mit der Clustersteuerungsebene kommunizieren.
Lösung: Sie müssen dem Cluster autorisierte Netzwerke hinzufügen, um Verbindungen zur Clustersteuerungsebene über Ihr Netzwerk zuzulassen.; Sorgen Sie dafür, dass der globale Zugriff auf den privaten Endpunkt der Steuerungsebene aktiviert ist, wenn Clients den Befehl kubectl aus einer anderen Region als der des Clusters verwenden. Weitere Informationen finden Sie unter Globaler Zugriff auf den privaten Endpunkt der Steuerungsebene.

Cluster kann aufgrund von fehlendem Flag nicht erstellt werden

Symptome: gcloud container clusters create gibt einen Fehler wie Cannot specify --enable-private-endpoint without --enable-private-nodes. zurück.
Mögliche Ursachen: Sie haben ein erforderliches Flag nicht angegeben.
Lösung: Prüfen Sie, ob Sie die erforderlichen Flags angegeben haben. Es ist nicht möglich, einen privaten Endpunkt für die Clustersteuerungsebene zu aktivieren, ohne auch private Knoten zu aktivieren.

Cluster kann aufgrund von überschneidendem IPv4-CIDR-Block nicht erstellt werden

Symptome: gcloud container clusters create gibt einen Fehler wie The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20. zurück.
Mögliche Ursachen: Sie haben einen CIDR-Block der Steuerungsebene angegeben, der sich mit einem vorhandenen Subnetz in Ihrer VPC überschneidet.
Lösung: Geben Sie einen CIDR-Block für --master-ipv4-cidr an, der sich nicht mit einem vorhandenen Subnetz überschneidet.

Subnetz kann nicht erstellt werden

Symptome: Wenn Sie einen privaten Cluster mit einem automatischen Subnetz oder ein benutzerdefiniertes Subnetz erstellen, wird möglicherweise der folgende Fehler zurückgegeben: An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.
Mögliche Ursachen: Der von Ihnen angegebene CIDR-Bereich der Steuerungsebene überschneidet sich mit einem anderen IP-Bereich im Cluster. Dieser Fehler kann auch auftreten, wenn Sie kürzlich einen privaten Cluster gelöscht haben und versuchen, einen neuen privaten Cluster mit demselben CIDR-Bereich der Steuerungsebene zu erstellen.
Lösung: Probieren Sie einen anderen CIDR-Bereich aus.

Image kann nicht von öffentlichem Docker Hub heruntergeladen werden

Symptome: Ein Pod, der in Ihrem Cluster ausgeführt wird, zeigt in kubectl describe eine Warnung an, z. B. Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Mögliche Ursachen: Knoten in einem privaten Cluster haben keinen ausgehenden Zugriff auf das öffentliche Internet. Sie haben eingeschränkten Zugriff auf Google APIs und Google-Dienste, einschließlich Container Registry.
Lösung: Images können nicht direkt von Docker Hub abgerufen werden. Verwenden Sie stattdessen Images, die in der Container Registry gehostet werden. Hinweis: Der Docker Hub-Spiegel von Container Registry ist zwar von einem privaten Cluster aus zugänglich. Sie sollten jedoch nicht ausschließlich darauf zurückgreifen. Da der Spiegel nur ein Cache ist, werden Images regelmäßig entfernt und ein privater Cluster kann nicht auf Docker Hub zurückgreifen.

API-Anfrage, bei der Zeitüberschreitung für Zulassungs-Webhook ausgelöst wird

Symptome

Bei einer API-Anfrage, die einen Zulassungs-Webhook auslöst, der für die Verwendung eines Dienstes mit einem anderen targetPort als 443 konfiguriert ist, tritt eine Zeitüberschreitung ein, wodurch die Anfrage fehlschlägt:

Error from server (Timeout): request did not complete within requested timeout 30s

Mögliche Ursachen

Standardmäßig lässt die Firewall keine TCP-Verbindungen zu Knoten zu, mit Ausnahme an den Ports 443 (HTTPS) und 10250 (kubelet). Ein Zulassungs-Webhook, der versucht, mit einem Pod über einen anderen Port als 443 zu kommunizieren, schlägt fehl, wenn keine benutzerdefinierte Firewallregel vorhanden ist, die den Traffic erlaubt.

Lösung

Fügen Sie für Ihren Anwendungsfall eine Firewallregel hinzu.