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 verwendeter ö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:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren.
Prüfen Sie, ob Sie die erforderliche Berechtigung zum Erstellen von Clustern haben. Sie sollten mindestens ein Kubernetes Engine-Cluster-Administrator sein.
Achten Sie darauf, dass Sie eine Route zum Standard-Internetgateway haben.
Privaten Cluster ohne Clientzugriff auf den öffentlichen Endpunkt erstellen
In diesem Abschnitt erstellen Sie die folgenden Ressourcen:
- Einen privaten Cluster mit dem Namen
private-cluster-0
, der private Knoten und keinen Clientzugriff auf den öffentlichen Endpunkt hat. - Ein Netzwerk mit dem Namen
my-net-0
. - Ein Subnetz mit dem Namen
my-subnet-0
.
gcloud
Führen Sie für Standardcluster 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
Führen Sie für Autopilot-Cluster den folgenden Befehl aus:
gcloud container clusters create-auto private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-private-nodes \ --enable-private-endpoint
wobei
--create-subnetwork name=my-subnet-0
bewirkt, dass GKE automatisch ein Subnetz mit dem Namenmy-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 (nicht für Autopilot erforderlich).--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 (optional für Autopilot). Diese Einstellung ist für diesen Cluster dauerhaft und muss innerhalb der VPC eindeutig sein. Die Verwendung von internen IP-Adressen außerhalb von RFC 1918 wird unterstützt.
Console
Netzwerk und Subnetz erstellen
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie auf add_box VPC-Netzwerk erstellen.
Geben Sie für Name
my-net-0
ein.Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
Geben Sie im Feld Neues Subnetz für Name den Wert
my-subnet-0
ein.Wählen Sie in der Liste Region die gewünschte Region aus.
Geben Sie
10.2.204.0/22
als IP-Adressbereich ein.Setzen Sie Privater Google-Zugriff auf An.
Klicken Sie auf Fertig.
Klicken Sie auf Erstellen.
Privaten Cluster erstellen
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_box Erstellen.
Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.
Geben Sie im Feld Name
private-cluster-0
ein.Klicken Sie für Standardcluster im Navigationsbereich unter Cluster auf Netzwerk.
Wählen Sie in der Liste Netzwerk die Option my-net-0 aus.
Wählen Sie in der Liste Knotensubnetz die Option my-subnet-0 aus.
Wählen Sie das Optionsfeld Privater Cluster aus.
Entfernen Sie das Häkchen aus dem Kästchen Zugriffssteuerungsebene über die externe IP-Adresse.
(Optional für Autopilot): Setzen Sie IP-Bereich der Steuerungsebene auf
172.16.0.32/28
.Klicken Sie auf Erstellen.
API
Zum Erstellen eines Clusters ohne öffentlich erreichbare Steuerungsebene geben Sie in der Ressource privateClusterConfig
das Feld enablePrivateEndpoint: true
an.
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.
Sie können dazu die Google Cloud CLI oder die GKE API verwenden.
gcloud
Führen Sie für Standardcluster 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
Führen Sie für Autopilot-Cluster den folgenden Befehl aus:
gcloud container clusters create-auto private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-private-nodes
wobei
--create-subnetwork name=my-subnet-1
bewirkt, dass GKE automatisch ein Subnetz mit dem Namenmy-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 (nicht für Autopilot erforderlich).--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 (optional für Autopilot). Diese Einstellung ist für diesen Cluster dauerhaft und muss innerhalb der VPC eindeutig sein. Die Verwendung von internen IP-Adressen außerhalb von RFC 1918 wird unterstützt.
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 erstellen Sie die folgenden Ressourcen:
- Ein privater Cluster mit dem Namen
private-cluster-2
. - Ein Netzwerk mit dem Namen
my-net-2
. Ein Subnetz mit dem Namen
my-subnet-2
mit dem primären Bereich192.168.0.0/20
für Ihre Clusterknoten. Das Subnetz hat die folgenden sekundären Adressbereiche:my-pods
für die Pod-IP-Adressen.my-services
für die Service-IP-Adressen.
gcloud
Netzwerk erstellen
Erstellen Sie zuerst ein Netzwerk für den Cluster. Mit dem folgenden Befehl wird das Netzwerk my-net-2
erstellt:
gcloud compute networks create my-net-2 \
--subnet-mode custom
Subnetz und sekundäre Bereiche erstellen
Erstellen Sie dann das Subnetz my-subnet-2
im Netzwerk my-net-2
mit den sekundären Bereichen my-pods
für Pods und my-services
für Dienste:
gcloud compute networks subnets create my-subnet-2 \
--network my-net-2 \
--range 192.168.0.0/20 \
--secondary-range my-pods=10.4.0.0/14,my-services=10.0.32.0/20 \
--enable-private-ip-google-access
Privaten Cluster erstellen
Erstellen Sie nun den privaten Cluster private-cluster-2
mit dem Netzwerk, Subnetz und den sekundären Bereichen, die Sie erstellt haben.
Führen Sie für Standardcluster den folgenden Befehl aus:
gcloud container clusters create private-cluster-2 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes \ --enable-ip-alias \ --master-ipv4-cidr 172.16.0.16/28 \ --no-enable-basic-auth \ --no-issue-client-certificate
Führen Sie für Autopilot-Cluster den folgenden Befehl aus:
gcloud container clusters create-auto private-cluster-2 \ --region us-central1 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes
Console
Netzwerk, Subnetz und sekundäre Bereiche erstellen
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie auf add_box VPC-Netzwerk erstellen.
Geben Sie für Name
my-net-2
ein.Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
Geben Sie im Feld Neues Subnetz für Name den Wert
my-subnet-2
ein.Wählen Sie in der 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
für Name des Subnetzbereichs und10.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
und für Sekundärer IP-Bereich10.4.0.0/14
ein.Setzen Sie 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 Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_box Erstellen.
Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.
Geben Sie im Feld Name
private-cluster-2
ein.Klicken Sie für Standardcluster im Navigationsbereich unter Cluster auf Netzwerk.
Wählen Sie das Optionsfeld Privater Cluster aus.
Wenn Sie eine Steuerungsebene erstellen möchten, auf die von autorisierten externen IP-Bereichen aus zugegriffen werden kann, behalten Sie das Häkchen im Kästchen Zugriffsebene der Steuerungsebene mit externer IP-Adresse bei.
(Optional für Autopilot) Legen Sie den IP-Bereich der Steuerungsebene auf
172.16.0.16/28
fest.Wählen Sie in der Liste Netzwerk die Option my-net-2 aus.
Wählen Sie in der Liste Knotensubnetz die Option my-subnet-2 aus.
Entfernen Sie das Häkchen aus dem Kästchen Sekundäre Bereiche automatisch erstellen.
Wählen Sie in der Liste Sekundärer Pod-CIDR-Bereich die Option my-pods aus.
Wählen Sie in der Liste Sekundärer CIDR-Dienstbereich die Option my-services aus.
Klicken Sie das Kästchen Autorisierte Steuerungsebenennetzwerke aktivieren an.
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
Angenommen, Sie haben eine Gruppe von Computern außerhalb von my-net-2
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-2 \
--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
- Von Ihnen autorisierte Adressbereiche, beispielsweise
203.0.113.0/29
.
Mit Cloud Shell auf einen privaten Cluster zugreifen
Der private Cluster private-cluster-1
, den Sie im Abschnitt Automatisch erzeugtes Subnetz verwenden erstellt haben, hat einen öffentlichen Endpunkt und aktivierte autorisierte Netzwerke. 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 \ --enable-master-authorized-networks \ --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
Dabei gilt:
EXISTING_AUTH_NETS
: Die IP-Adressen der vorhandenen Liste autorisierter Netzwerke. Sie finden Ihre autorisierten Netzwerke in der Console oder durch Ausführen des folgenden Befehls: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 \ --project PROJECT_ID
Ersetzen Sie
PROJECT_ID
durch Ihre Projekt-ID.Verwenden Sie in Cloud Shell
kubectl
, um auf Ihren privaten Cluster zuzugreifen:kubectl get nodes
Die entsprechende Ausgabe sieht etwa so aus:
NAME STATUS ROLES AGE VERSION gke-private-cluster-1-default-pool-7d914212-18jv Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-3d9p Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-wgqf Ready <none> 104m v1.21.5-gke.1302
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 für Standardcluster den folgenden Befehl aus:
gcloud container clusters create private-cluster-3 \ --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
Führen Sie für Autopilot-Cluster den folgenden Befehl aus:
gcloud container clusters create-auto private-cluster-3 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-private-nodes
wobei
--create-subnetwork name=my-subnet-3
bewirkt, dass GKE automatisch ein Subnetz mit dem Namenmy-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 (nicht für Autopilot erforderlich).--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 IP-Adressbereich für die Steuerungsebene an (optional für Autopilot). Diese Einstellung ist für diesen Cluster dauerhaft und muss innerhalb der VPC eindeutig sein. Die Verwendung von internen IP-Adressen außerhalb von RFC 1918 wird unterstützt.
Console
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_box Erstellen.
Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.
Geben Sie im Feld Name
private-cluster-3
ein.Klicken Sie für Standardcluster im Navigationsbereich unter Cluster auf Netzwerk.
Wählen Sie die Option Privater Cluster aus.
Behalten Sie das Häkchen im Kästchen Zugriffsebene der Steuerungsebene mit externer IP-Adresse bei.
(Optional für Autopilot) Legen Sie den IP-Bereich der Steuerungsebene auf
172.16.0.32/28
fest.Belassen Sie Netzwerk und Knotensubnetz auf
default
. GKE generiert dadurch ein Subnetz für den Cluster.Entfernen Sie das Häkchen aus dem Kästchen Autorisierte Steuerungsebenennetzwerke aktivieren.
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, 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 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. 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.
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 Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie auf add_box Erstellen.
Geben Sie einen Namen ein.
Klicken Sie im Navigationsbereich unter Cluster 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.
Klicken Sie neben dem Cluster, den Sie bearbeiten möchten, auf more_vert Aktionen und dann auf edit Bearbeiten.
Klicken Sie im Abschnitt Netzwerk neben Autorisierte Netzwerke auf Steuerungsebene auf edit Bearbeiten.
Klicken Sie im Dialogfeld Autorisierte Netzwerke auf Steuerungsebene bearbeiten das Kästchen Autorisierte Netzwerke auf Steuerungsebene aktivieren an.
Klicken Sie auf Änderungen 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:
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 kann die Steuerungsebene Pakete an lokale Ressourcen zurücksenden.
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
und128.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_NAME \
--network VPC_NAME \
--no-export-custom-routes
Dabei gilt:
PEERING_NAME
der Wert vonprivateClusterConfig.peeringName
.VPC_NAME
ist der Name der 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 Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie in der Liste der Cluster auf den Clusternamen.
Klicken Sie auf der Seite Cluster auf den Tab Knoten.
Klicken Sie unter Knotenpools auf den Namen des Knotenpools.
Klicken Sie auf der Seite Knotenpooldetails unter Instanzgruppen 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_NAME
Ersetzen Sie NETWORK_NAME
durch 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
Ersetzen Sie SUBNET_NAME
durch den Namen 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 Google Cloud Console die Seite VPC-Netzwerke auf.
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 eines privaten Clusters mit der gcloud CLI oder der Google 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 Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie in der Clusterliste auf den Clusternamen.
Suchen Sie dann auf dem Tab Details unter Clustergrundlagen nach dem Feld Endpunkt.
Container-Images von einer Image-Registry herunterladen
In einem privaten Cluster kann die Containerlaufzeit Container-Images nur von Artifact 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 Artifact 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 Artifact Registry-Repository von Google heruntergeladen wird.
kubectl run hello-deployment --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.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 und Pods 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
Ersetzen Sie CLUSTER_NAME
durch den Namen Ihres privaten Clusters.
Notieren Sie sich in der Befehlsausgabe den Wert im Feld masterIpv4CidrBlock.
Console
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Klicken Sie in der Clusterliste auf den Clusternamen.
Notieren Sie sich vom Tab Details unter Netzwerk den Wert im Feld Adressbereich der Steuerungsebene.
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.
Console
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Geben Sie bei Tabelle filtern den Wert
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 CONTROL_PLANE_RANGE \
--rules PROTOCOL:PORT \
--target-tags TARGET
Dabei gilt:
FIREWALL_RULE_NAME
ist der von Ihnen ausgewählte Name für die Firewallregel.CONTROL_PLANE_RANGE
ist der IP-Adressbereich der Clustersteuerungsebene (masterIpv4CidrBlock
), den Sie zuvor erfasst haben.PROTOCOL:PORT
ist der gewünschte Port und das zugehörige Protokoll,tcp
oderudp
.TARGET
ist der vorher notierte Zielwert (Targets
).
Console
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie auf add_box Firewallregel erstellen.
Geben Sie für Name einen Namen für die Firewallregel ein.
Wählen Sie in der Liste Netzwerk das entsprechende Netzwerk aus.
Klicken Sie unter Trafficrichtung auf Eingehend.
Klicken Sie unter Aktion bei Übereinstimmung auf Zulassen.
Wählen Sie in der Liste Ziele Angegebene Ziel-Tags aus.
Geben Sie unter Zieltags den zuvor notierten Zielwert ein.
Wählen Sie in der Liste Quellfilter die Option IP-Bereiche aus.
Geben Sie bei Quell-IP-Bereiche den CIDR-Block der Clustersteuerungsebene ein.
Klicken Sie unter Protokolle und Ports auf Angegebene Protokolle und Ports, wählen Sie das Kästchen für das entsprechende Protokoll aus (TCP oder udp) und geben Sie die Portnummer in das Protokollfeld 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 unter Informationen zu Dienstperimetern und deren Konfiguration.
Wenn Sie Container Registry oder Artifact Registry mit Ihrem privaten GKE-Cluster verwenden, sind zusätzliche Schritte erforderlich, um diesen privaten Cluster mit VPC Service Controls zu verwenden. Weitere Informationen finden Sie auf der Seite Container Registry oder Artifact 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 Wiederverwendung von VPC-Netzwerk-Peering 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.
Die Wiederverwendung des VPC-Netzwerk-Peerings gilt nur für Cluster am selben Standort, z. B. regionale Cluster in derselben Region oder zonale Cluster in derselben Zone. Es sind maximal vier VPC-Netzwerk-Peerings pro Region möglich, wenn Sie sowohl regionale Cluster als auch zonale Cluster in allen Zonen dieser Region erstellen.
Mit der gcloud CLI oder der Google Cloud Console können Sie prüfen, ob Ihr privater Cluster VPC-Netzwerk-Peering-Verbindungen wiederverwendet.
gcloud
gcloud container clusters describe CLUSTER_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 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 private-cluster-2 private-cluster-3
Console
Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.
Wählen Sie jeden Cluster aus.
Klicken Sie auf delete Löschen.
Netzwerk löschen
gcloud
gcloud compute networks delete my-net-0
Console
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie in der Liste der Netzwerke auf
my-net-0
.Klicken Sie auf der Seite VPC-Netzwerkdetails auf delete VPC-Netzwerk löschen.
Klicken Sie im Dialogfeld Netzwerk löschen auf Löschen.
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. Wenn Sie die Standardroute löschen, müssen Sie dafür sorgen, dass der Traffic an die erforderlichen Google-Dienste weitergeleitet wird. Weitere Informationen finden Sie unter Benutzerdefiniertes Routing.
- Wenn der Export benutzerdefinierter Routen für die VPC aktiviert ist, kann das Erstellen von Routen, die sich mit IP-Bereichen von Google überschneiden, den Cluster beeinträchtigen.
- 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 Sie können Cloud NAT verwenden, um ausgehenden privaten Zugriff auf Ihre privaten Knoten bereitzustellen.
- Der private Google-Zugriff wird automatisch aktiviert, wenn Sie einen privaten Cluster erstellen, es sei denn, Sie verwenden eine freigegebene VPC. Sie dürfen den privaten Google-Zugriff nur deaktivieren, wenn Sie NAT für den Zugriff auf das Internet verwenden.
- 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.
- Wenn Sie den primären IP-Bereich eines Subnetzes erweitern, um weitere Knoten hinzuzufügen, müssen Sie den primären IP-Adressbereich des erweiterten Subnetzes der Liste autorisierter Netzwerke für Ihren Cluster hinzufügen. Andernfalls werden Firewallregeln, die eingehenden Traffic zulassen und für die Steuerungsebene relevant sind, nicht aktualisiert. Neue Knoten, die im erweiterten IP-Adressbereich erstellt wurden, können sich nicht bei der Steuerungsebene registrieren. Dies kann zu einem Ausfall führen, bei dem neue Knoten kontinuierlich gelöscht und ersetzt werden. Ein solcher Ausfall kann auftreten, wenn Upgrades von Knotenpools durchgeführt werden oder wenn Knoten aufgrund von Aktivitätsprüfungen automatisch ersetzt werden.
- Erstellen Sie keine Firewallregeln oder hierarchischen Firewallregeln, die eine höhere Priorität als die automatisch erstellte Firewallregeln haben.
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 der folgende zurückgegeben:
Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network.
- 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.
Steuerungsebene eines privaten Clusters kann nicht erreicht werden
Erhöhen Sie die Wahrscheinlichkeit, dass Ihre Cluster-Steuerungsebene erreichbar ist. Implementieren Sie dazu eine der Konfigurationen für den Zugang zu den Clusterendpunkten. Weitere Informationen finden Sie unter Zugriff auf Clusterendpunkte.
- Symptome
Nach dem Erstellen eines privaten Clusters wird bei dem Versuch,
kubectl
-Befehle für den Cluster auszuführen, ein Fehler wie einer der folgenden zurückgegeben:Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out.
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
Prüfen Sie, ob die Anmeldedaten für den Cluster für kubeconfig generiert wurden oder der richtige Kontext aktiviert ist. Weitere Informationen zum Festlegen der Clusteranmeldedaten finden Sie unter kubeconfig-Eintrag generieren.
Prüfen Sie, ob der Zugriff auf die Steuerungsebene mithilfe ihrer externen IP-Adresse zulässig ist. Wenn Sie den externen Zugriff auf die Clustersteuerungsebene deaktivieren, wird der Cluster vom Internet isoliert. Diese Konfiguration ist nach der Clustererstellung unveränderlich. Bei dieser Konfiguration haben nur autorisierte interne CIDR-Bereiche oder reservierte Netzwerke Zugriff auf die Steuerungsebene.
Prüfen Sie, ob die ursprüngliche IP-Adresse berechtigt ist, die Steuerungsebene zu erreichen:
gcloud container clusters describe CLUSTER_NAME \ --format="value(masterAuthorizedNetworksConfig)"\ --region=COMPUTE_REGION
Dabei gilt:
CLUSTER_NAME
: Der Name Ihres Clusters.COMPUTE_REGION
: die Compute Engine-Region für den Cluster. Verwenden Sie für zonale Cluster--zone=COMPUTE_ZONE
.
Wenn die ursprüngliche IP-Adresse nicht autorisiert ist, kann die Ausgabe ein leeres Ergebnis (nur geschweifte Klammern) oder CIDR-Bereiche zurückgeben, die nicht die ursprüngliche IP-Adresse enthalten.
cidrBlocks: cidrBlock: 10.XXX.X.XX/32 displayName: jumphost cidrBlock: 35.XXX.XXX.XX/32 displayName: cloud shell enabled: true
Fügen Sie autorisierte Netzwerke für den Zugriff auf die Steuerungsebene hinzu.
Wenn Sie den Befehl
kubectl
in einer lokalen Umgebung oder in einer anderen Region als der Standort des Clusters ausführen, muss der private Endpunkt der Steuerungsebene für den globalen Zugriff aktiviert sein. Weitere Informationen finden Sie unter Global auf privaten Endpunkt der Steuerungsebene zugreifen.Beschreiben Sie den Cluster, um die Antwort der Masterzugriffskonfiguration zu sehen:
gcloud container clusters describe CLUSTER_NAME \ --region=COMPUTE_REGION \ --flatten "privateClusterConfig.masterGlobalAccessConfig"
Dabei gilt:
CLUSTER_NAME
: Der Name Ihres Clusters.COMPUTE_REGION
: die Compute Engine-Region für den Cluster. Verwenden Sie für zonale Cluster--zone=COMPUTE_ZONE
.
Eine erfolgreiche Ausgabe sieht etwa so aus:
enabled: true
Wenn
null
zurückgegeben wird, aktivieren Sie den globalen Masterzugriff.
Cluster kann aufgrund von überschneidendem IPv4-CIDR-Block nicht erstellt werden
- Symptome
gcloud container clusters create
gibt einen Fehler ähnlich wie diesen zurück:The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.
- 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.
Cluster kann aufgrund von Dienstbereich, der bereits von einem anderen Cluster verwendet wird, nicht erstellt werden
- Symptome
Bei dem Versuch, einen privaten Cluster zu erstellen, wird ein Fehler wie der folgende zurückgegeben:
Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork [SUBNET_NAME] is already used by another cluster.
- Mögliche Ursachen
Eine der folgenden:
- Sie haben einen Dienstbereich ausgewählt, der noch von einem anderen Cluster verwendet wird, oder der Cluster wurde nicht gelöscht.
- Es wurde ein Cluster mit diesem Dienstbereich verwendet, der gelöscht wurde, aber die Metadaten der sekundären Bereiche wurden nicht ordnungsgemäß bereinigt. Sekundäre Bereiche für einen GKE-Cluster werden in den Compute Engine-Metadaten gespeichert und sollten entfernt werden, sobald der Cluster gelöscht wurde. Selbst wenn der Cluster erfolgreich gelöscht wurde, wurden die Metadaten möglicherweise nicht entfernt.
- Lösung
Gehen Sie so vor:
- Prüfen, ob der Dienstbereich von einem vorhandenen Cluster verwendet wird Sie können den Befehl
gcloud container clusters list
mit dem Flagfilter
verwenden, um nach dem Cluster zu suchen. Wenn ein Cluster den Dienstbereich verwendet, müssen Sie diesen Cluster löschen oder einen neuen Dienstbereich erstellen. - Wenn der Dienstbereich nicht von einem vorhandenen Cluster verwendet wird, entfernen Sie den Metadateneintrag manuell, der dem Dienstbereich entspricht, den Sie verwenden möchten.
- Prüfen, ob der Dienstbereich von einem vorhandenen Cluster verwendet wird Sie können den Befehl
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: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 keine externen IP-Adressen. Daher erfüllen sie nicht die Anforderungen für den Internetzugriff. Die Knoten können jedoch auf Google APIs und Google-Dienste zugreifen, einschließlich Artifact Registry und Container Registry, wenn Sie den privaten Google-Zugriff aktiviert und die Netzwerkanforderungen erfüllt haben.
- Lösung
Verwenden Sie eine der folgenden Lösungen:
Kopieren Sie die Images in Ihrem privaten Cluster von Docker Hub nach Container Registry. Weitere Informationen finden Sie unter Container aus einer Drittanbieter-Registry migrieren.
GKE prüft
mirror.gcr.io
automatisch auf zwischengespeicherte Kopien von häufig aufgerufenen Docker Hub-Images.Wenn Sie Images aus Docker Hub oder einem anderen öffentlichen Repository abrufen müssen, verwenden Sie Cloud NAT oder einen instanzbasierten Proxy, der das Ziel für eine statische
0.0.0.0/0
-Route ist.
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.
Cluster kann aufgrund von Fehlern bei der Systemdiagnose nicht erstellt werden
- Symptome
Nachdem ein privater Cluster erstellt wurde, bleibt der Schritt bei der Systemdiagnose hängen und meldet einen Fehler wie einen der folgenden:
All cluster resources were brought up, but only 0 of 2 have registered.
All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
- Mögliche Ursachen
Eine der folgenden:
- Clusterknoten können die erforderlichen Binärdateien nicht von der Cloud Storage API (
storage.googleapis.com
) herunterladen. - Firewallregeln schränken den ausgehenden Traffic ein.
- IAM-Berechtigungen für die freigegebene VPC sind falsch.
- Für den privaten Google-Zugriff müssen Sie das DNS für
*.gcr.io
konfigurieren.
- Clusterknoten können die erforderlichen Binärdateien nicht von der Cloud Storage API (
- Lösung
Verwenden Sie eine der folgenden Lösungen:
Aktivieren Sie Privater Google-Zugriff im Subnetz für den Netzwerkzugriff des Knotens auf
storage.googleapis.com
oder aktivieren Sie Cloud NAT, damit die Knoten mitstorage.googleapis.com
-Endpunkten kommunizieren können. Weitere Informationen finden Sie unter Fehlerbehebung bei Problemen mit der Erstellung von privaten GKE-Clustern.Bestätigen Sie für den Knoten-Lesezugriff auf
storage.googleapis.com
, dass das dem Clusterknoten zugewiesene Dienstkonto Speicherlesezugriff hat.Verwenden Sie entweder eine Google Cloud-Firewallregel, um den gesamten ausgehenden Traffic zuzulassen, oderkonfigurieren Sie eine Firewallregel, um ausgehenden Traffic für Knoten zur Clustersteuerungsebene und zu
*.googleapis.com
zuzulassen.Erstellen Sie die DNS-Konfiguration für
*.gcr.io
.Wenn Sie eine nicht standardmäßige Firewall- oder Routeneinrichtung verwenden, konfigurieren Sie den privaten Google-Zugriff.
Wenn Sie VPC Service Controls verwenden, richten Sie Container Registry oder Artifact Registry für private GKE-Cluster ein.
Achten Sie darauf, dass die automatisch erstellten Firewallregeln für eingehenden Traffic nicht gelöscht oder geändert wurden.
Wenn Sie eine freigegebene VPC verwenden, müssen Sie die erforderlichen IAM-Berechtigungen konfigurieren.
Kubelet konnte keine Pod-Sandbox erstellen
- Symptome
Nachdem Sie einen privaten Cluster erstellt haben, wird ein Fehler wie einer der folgenden angezeigt:
Warning FailedCreatePodSandBox 12s (x9 over 4m) kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
- Mögliche Ursachen
Der Pod
calico-node
odernetd
kann*.gcr.io
nicht erreichen.- Lösung
Verwenden Sie eine der folgenden Lösungen:
- Prüfen Sie, ob Sie die erforderliche Einrichtung für Container Registry oder Artifact Registry abgeschlossen haben.
Private Clusterknoten wurden erstellt, aber nicht dem Cluster hinzugefügt
Bei der Verwendung von benutzerdefiniertem Routing und Netzwerk-Appliances von Drittanbietern in der VPC, die Ihr privater Cluster verwendet, wird die Standardroute (0.0.0.0/0
) an die Appliance weitergeleitet anstatt an das Standard-Internetgateway. Zusätzlich zur Verbindung der Steuerungsebene müssen Sie dafür sorgen, dass die folgenden Ziele erreichbar sind:
- *.googleapis.com
- *.gcr.io
- gcr.io
Konfigurieren Sie den privaten Google-Zugriff für alle drei Domains. Diese Best Practice ermöglicht es Ihnen, die neuen Knoten zu starten und dem Cluster beizutreten, während der ausgehende Internettraffic eingeschränkt bleibt.
Nächste Schritte
- Netzwerkübersicht
- VPC-native Cluster erstellen
- Weitere Informationen zum VPC-Netzwerk-Peering.
- Anleitung zum Zugriff auf private GKE-Cluster mit privaten Cloud Build-Pools