Diese Seite wurde von der Cloud Translation API übersetzt.

Cluster mit freigegebener VPC einrichten

Autopilot Standard

In dieser Anleitung wird beschrieben, wie Sie zwei GKE-Cluster (Google Kubernetes Engine) in separaten Projekten erstellen, die eine freigegebene VPC verwenden. Allgemeine Informationen zum GKE-Netzwerk finden Sie in der Netzwerkübersicht.

Übersicht

Bei einer freigegebenen VPC legen Sie zuerst ein Projekt als Hostprojekt fest. Danach können Sie weitere Projekte, sogenannte Dienstprojekte, an das Hostprojekt anhängen. Sie erstellen Netzwerke, Subnetze, sekundäre Adressbereiche, Firewallregeln und andere Netzwerkressourcen im Hostprojekt. Dann geben Sie ausgewählte Subnetze, einschließlich sekundäre Bereiche, für die Dienstprojekte frei. Komponenten, die in einem Dienstprojekt ausgeführt werden, können über die freigegebene VPC mit Komponenten kommunizieren, die in den anderen Dienstprojekten ausgeführt werden.

Sie können freigegebene VPCs mit Autopilot-Clustern sowie mit zonalen und regionalen Standardclustern verwenden.

Standardcluster, die eine freigegebene VPC verwenden, können keine Legacy-Netzwerke nutzen und müssen VPC-natives Traffic-Routing aktiviert haben. In Autopilot-Clustern ist immer VPC-natives Traffic-Routing aktiviert.

Sie können eine freigegebene VPC beim Erstellen eines neuen Clusters konfigurieren. Das Konvertieren vorhandener Cluster in das Modell für freigegebene VPCs wird von GKE nicht unterstützt.

Für freigegebene VPCs gelten bestimmte Kontingente und Limits. Beispielsweise gibt es ein Kontingent für die Anzahl der Netzwerke in einem Projekt und ein Limit für die Anzahl der Dienstprojekte, die an ein Hostprojekt angehängt werden können. Einzelheiten finden Sie unter Kontingente und Limits.

Über die Beispiele

Mit den Beispielen in dieser Anleitung wird die Infrastruktur für eine zweistufige Webanwendung eingerichtet, wie unter Freigegebene VPC – Übersicht beschrieben.

Hinweise

Bevor Sie einen Cluster mit freigegebener VPC einrichten, sollten Sie Folgendes tun:

Vergewissern Sie sich, dass Sie eine Google Cloud-Organisation haben.
Stellen Sie sicher, dass Ihre Organisation über drei Google Cloud-Projekte verfügt.
Sie sollten mit den Konzepten der freigegebenen VPC vertraut sein, einschließlich der verschiedenen IAM-Rollen (Identity and Access Management), die von der freigegebenen VPC verwendet werden. Die Aufgaben in dieser Anleitung müssen von einem Administrator für freigegebene VPCs ausgeführt werden.
Sie sollten mit allen Einschränkungen für Organisationsrichtlinien vertraut sein, die für Ihre Organisation, Ihren Ordner oder Ihre Projekte gelten. Ein Administrator für Unternehmensrichtlinien hat möglicherweise Einschränkungen definiert, die beschränken, welche Projekte Hostprojekte für freigegebene VPCs sein oder welche Subnetze freigegeben werden können. Weitere Informationen finden Sie unter Einschränkungen für Organisationsrichtlinien.

Bevor Sie die Übungen in dieser Anleitung durchführen, müssen Sie Folgendes tun:

Wählen Sie eines Ihrer Projekte als Hostprojekt aus.
Wählen Sie zwei Ihrer Projekte als Dienstprojekte aus.

Jedes Projekt hat einen Namen, eine ID und eine Nummer. In einigen Fällen sind der Name und die ID identisch. In dieser Anleitung werden für Ihre Projekte die folgenden Anzeigenamen und Platzhalter verwendet:

Anzeigename	Platzhalter für die Projekt-ID	Platzhalter für die Projektnummer
Ihr Hostprojekt	`HOST_PROJECT_ID`	`HOST_PROJECT_NUM`
Ihr erstes Dienstprojekt	`SERVICE_PROJECT_1_ID`	`SERVICE_PROJECT_1_NUM`
Ihr zweites Dienstprojekt	`SERVICE_PROJECT_2_ID`	`SERVICE_PROJECT_2_NUM`

Projekt-IDs und -nummern ermitteln

Ihre Projekt-ID und -nummern können Sie mit der gcloud CLI oder der Google Cloud Console ermitteln.

Console

Rufen Sie die Startseite in der Google Cloud Console auf.

Zur Startseite
Wählen Sie in der Projektauswahl das Projekt aus, das Sie als Hostprojekt designiert haben.
Unter Projektinformationen können Sie den Projektnamen, die Projekt-ID und die Projektnummer sehen. Notieren Sie sich die ID und die Nummer für später.
Wiederholen Sie das für jedes Projekt, das Sie als Dienstprojekt designiert haben.

gcloud

Listen Sie Ihre Projekte mit dem folgenden Befehl auf:

gcloud projects list

Die Ausgabe zeigt Ihre Projektnamen, -IDs und -nummern. Notieren Sie sich die IDs und Nummern für später:

PROJECT_ID        NAME        PROJECT_NUMBER
host-123          host        1027xxxxxxxx
srv-1-456         srv-1       4964xxxxxxxx
srv-2-789         srv-2       4559xxxxxxxx

GKE API in Projekten aktivieren

Prüfen Sie, bevor Sie mit den Übungen in dieser Anleitung fortfahren, ob die GKE API in allen drei Projekten aktiviert ist. Durch das Aktivieren der API in einem Projekt wird ein GKE-Dienstkonto für das Projekt erstellt. Zum Ausführen der verbleibenden Aufgaben in dieser Anleitung muss jedes der Projekte ein GKE-Dienstkonto haben.

Sie können die GKE API über die Google Cloud Console oder die Google Cloud CLI aktivieren.

Console

Rufen Sie in der Google Cloud Console die Seite APIs & Dienste auf.

Rufen Sie "APIs & Dienste" auf.
Wählen Sie in der Projektauswahl das Projekt aus, das Sie als Hostprojekt designiert haben.
Wenn sich die Kubernetes Engine API in der Liste der APIs befindet, ist sie bereits aktiviert und Sie müssen nichts tun. Wenn sie in der Liste fehlt, klicken Sie auf APIs und Dienste aktivieren. Suchen nach Kubernetes Engine API. Klicken Sie auf die Karte Kubernetes Engine API und anschließend auf Aktivieren.
Wiederholen Sie diese Schritte für jedes Projekt, das Sie als Dienstprojekt designiert haben. Jeder Vorgang kann einige Zeit in Anspruch nehmen.

gcloud

Aktivieren Sie die GKE API für Ihre drei Projekte. Jeder Vorgang kann einige Zeit in Anspruch nehmen:

gcloud services enable container.googleapis.com --project HOST_PROJECT_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_1_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_2_ID

Netzwerk und zwei Subnetze erstellen

Aufgaben in diesem Abschnitt:

Im Hostprojekt ein Netzwerk mit dem Namen shared-net erstellen.
Zwei Subnetze mit den Namen tier-1 und tier-2 erstellen.
Für jedes Subnetz zwei sekundäre Adressbereiche erstellen: einen für Dienste und einen für Pods.

Console

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

Zur Seite VPC-Netzwerke
Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.
Klicken Sie auf VPC-Netzwerk erstellen.
Geben Sie für Name shared-net ein.
Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
Geben Sie im Feld Neues Subnetz für Name den Wert tier-1 ein.
Wählen Sie bei Region eine Region aus.
Wählen Sie unter IP-Stack-Typ die Option IPv4 (Single-Stack) aus.
Geben Sie unter IPv4-Bereich 10.0.4.0/22 ein.
Klicken Sie auf Sekundären IPv4-Bereich erstellen. Geben Sie für Name des Subnetzbereichs tier-1-services und für Sekundärer IPv4-Bereich 10.0.32.0/20 ein.
Klicken Sie auf IP-Bereich hinzufügen. Geben Sie für Name des Subnetzbereichs tier-1-pods und für Sekundärer IPv4-Bereich 10.4.0.0/14 ein.
Klicken Sie auf Subnetz hinzufügen.
Geben Sie für Name tier-2 ein.
Wählen Sie unter Region die Region aus, die Sie für das vorherige Subnetz ausgewählt haben.
Geben Sie unter IPv4-Bereich 172.16.4.0/22 ein.
Klicken Sie auf Sekundären IPv4-Bereich erstellen. Geben Sie für Name des Subnetzbereichs tier-2-services und für Sekundärer IPv4-Bereich 172.16.16.0/20 ein.
Klicken Sie auf IP-Bereich hinzufügen. Geben Sie für Name des Subnetzbereichs tier-2-pods und für Sekundärer IPv4-Bereich 172.20.0.0/14 ein.
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie im Hostprojekt ein Netzwerk mit dem Namen shared-net:

gcloud compute networks create shared-net \
    --subnet-mode custom \
    --project HOST_PROJECT_ID

Erstellen Sie in Ihrem neuen Netzwerk ein Subnetz mit dem Namen tier-1:

gcloud compute networks subnets create tier-1 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 10.0.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-1-services=10.0.32.0/20,tier-1-pods=10.4.0.0/14

Erstellen Sie ein weiteres Subnetz mit dem Namen tier-2:

gcloud compute networks subnets create tier-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 172.16.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

Ersetzen Sie COMPUTE_REGION durch eine Compute Engine-Region.

Namen von Dienstkonten in den Dienstprojekten ermitteln

Sie haben zwei Dienstprojekte, die jeweils mehrere Dienstkonten enthalten. Dieser Abschnitt befasst sich mit Ihren GKE- und Google APIs-Dienstkonten. Sie benötigen die Namen dieser Dienstkonten für den nächsten Abschnitt.

In der folgenden Tabelle sind die Namen der Dienstkonten von GKE und der Google APIs in den beiden Dienstprojekten aufgeführt:

Dienstkontotyp	Name des Dienstkontos
GKE	service-`SERVICE_PROJECT_1_NUM`@container-engine-robot.iam.gserviceaccount.com
GKE	service-`SERVICE_PROJECT_2_NUM`@container-engine-robot.iam.gserviceaccount.com
Google APIs	`SERVICE_PROJECT_1_NUM`@cloudservices.gserviceaccount.com
Google APIs	`SERVICE_PROJECT_2_NUM`@cloudservices.gserviceaccount.com

Freigegebene VPC aktivieren und Rollen gewähren

Damit Sie die Aufgaben in diesem Abschnitt ausführen können, muss Ihre Organisation die Rolle Administrator für freigegebene VPC definiert haben.

Aufgaben in diesem Abschnitt:

Im Hostprojekt die freigegebene VPC aktivieren.
Die beiden Dienstprojekte an das Hostprojekt anhängen.
Den Dienstkonten, die zu Ihren Dienstprojekten gehören, die entsprechenden IAM-Rollen zuweisen:
- Im ersten Dienstprojekt weisen Sie zwei Dienstkonten die Rolle Compute Network User im Subnetz tier-1 Ihres Hostprojekts zu.
- Im zweiten Dienstprojekt weisen Sie zwei Dienstkonten die Rolle Compute Network User im Subnetz tier-2 Ihres Hostprojekts zu.

Console

Führen Sie die folgenden Schritte aus, um die freigegebene VPC zu aktivieren, Dienstprojekte anzuhängen und Rollen zuzuweisen:

Rufen Sie in der Google Cloud Console die Seite Freigegebene VPC auf.

Zu Shared VPC gehen
Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.
Klicken Sie auf Freigegebene VPC einrichten. Der Bildschirm Hostprojekt aktivieren wird angezeigt.
Klicken Sie auf Speichern und weiter. Die Seite Subnetze auswählen wird angezeigt.
Wählen Sie unter Freigabemodus die Option Einzelne Subnetze aus.
Klicken Sie unter Subnetze zum Freigeben auf das Kästchen von tier-1 und tier-2. Entfernen Sie die Häkchen aus allen anderen Kästchen.
Klicken Sie auf Weiter. Die Seite Berechtigungen erteilen wird angezeigt.
Klicken Sie unter Dienstprojekte anhängen auf das Kästchen Ihres ersten und zweiten Dienstprojekts. Entfernen Sie die Häkchen aus allen anderen Kästchen unter Dienstprojekte anhängen.
Klicken Sie unter Kubernetes Engine-Zugriff auf Aktiviert.
Klicken Sie auf Speichern. Eine neue Seite wird angezeigt.
Klicken Sie unter Einzelne Subnetzberechtigungen auf das Kästchen von tier-1.
Löschen Sie im rechten Bereich alle Dienstkonten, die zu Ihrem zweiten Dienstprojekt gehören. Löschen Sie also alle Dienstkonten, die SERVICE_PROJECT_2_NUM enthalten.
Suchen Sie im rechten Bereich nach den Namen der Kubernetes Engine- und Google APIs-Dienstkonten, die zu Ihrem ersten Dienstprojekt gehören. Es müssen beide Dienstkontonamen in der Liste aufgeführt werden. Wenn einer der Dienstkontonamen nicht in der Liste enthalten ist, geben Sie ihn unter Mitglieder hinzufügen ein. Klicken Sie dann auf Hinzufügen.
Klicken Sie im mittleren Bereich unter Einzelne Subnetzberechtigungen auf das Kästchen tier-2 und entfernen Sie das Häkchen von tier-1.
Löschen Sie im rechten Bereich alle Dienstkonten, die zu Ihrem ersten Dienstprojekt gehören. Löschen Sie also alle Dienstkonten, die SERVICE_PROJECT_1_NUM enthalten.
Suchen Sie im rechten Bereich nach den Namen der Kubernetes Engine- und Google APIs-Dienstkonten, die zu Ihrem zweiten Dienstprojekt gehören. Es müssen beide Dienstkontonamen in der Liste aufgeführt werden. Wenn einer der Dienstkontonamen nicht in der Liste enthalten ist, geben Sie ihn unter Mitglieder hinzufügen ein. Klicken Sie dann auf Hinzufügen.

gcloud

Aktivieren Sie eine freigegebene VPC in Ihrem Hostprojekt: Der verwendete Befehl hängt von der erforderlichen Administratorrolle ab.

Wenn Ihnen die Rolle „Administrator für freigegebene VPC” auf Organisationsebene zugewiesen wurde:
```
gcloud compute shared-vpc enable HOST_PROJECT_ID
```
Wenn Ihnen die Rolle "Administrator für freigegebene VPC" auf Ordnerebene zugewiesen wurde:
```
gcloud beta compute shared-vpc enable HOST_PROJECT_ID
```

Hängen Sie Ihr erstes Dienstprojekt an Ihr Hostprojekt an:

gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

Hängen Sie Ihr zweites Dienstprojekt an Ihr Hostprojekt an:

gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

Rufen Sie die IAM-Richtlinie für das Subnetz tier-1 ab:

gcloud compute networks subnets get-iam-policy tier-1 \
   --project HOST_PROJECT_ID \
   --region COMPUTE_REGION

Die Ausgabe enthält das Feld etag. Notieren Sie sich den Wert von etag.

Erstellen Sie eine Datei namens tier-1-policy.yaml mit folgendem Inhalt:

bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

Ersetzen Sie dabei ETAG_STRING durch den zuvor notierten etag-Wert.

Legen Sie die IAM-Richtlinie für das Subnetz tier-1 fest:

gcloud compute networks subnets set-iam-policy tier-1 \
    tier-1-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

Rufen Sie die IAM-Richtlinie für das Subnetz tier-2 ab:

gcloud compute networks subnets get-iam-policy tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

Die Ausgabe enthält das Feld etag. Notieren Sie sich den Wert von etag.

Erstellen Sie eine Datei namens tier-2-policy.yaml mit folgendem Inhalt:

bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

Ersetzen Sie dabei ETAG_STRING durch den zuvor notierten etag-Wert.

Legen Sie die IAM-Richtlinie für das Subnetz tier-2 fest:

gcloud compute networks subnets set-iam-policy tier-2 \
    tier-2-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

Firewallressourcen verwalten

Wenn Sie möchten, dass ein GKE-Cluster in einem Dienstprojekt die Firewallressourcen in Ihrem Hostprojekt erstellt und verwaltet, müssen Sie dem GKE-Dienstkonto des Dienstprojekts die entsprechenden IAM-Berechtigungen mithilfe einer der folgenden Strategien erteilen:

Weisen Sie dem GKE-Dienstkonto des Dienstprojekts im Hostprojekt die Rolle Compute Security Admin zu.

Console

Öffnen Sie in der Google Cloud Console die Seite IAM.

IAM aufrufen
Wählen Sie das Hostprojekt aus.
Klicken Sie auf Zugriff gewähren und geben Sie dann das GKE-Dienstkontohauptkonto (service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com) des Dienstprojekts ein.
Wählen Sie in der Drop-down-Liste die Rolle Compute Security Admin aus.
Klicken Sie auf Speichern.

gcloud

Weisen Sie dem GKE-Dienstkonto des Dienstprojekts im Hostprojekt die Rolle Compute Security Admin zu.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/compute.securityAdmin

Dabei gilt:

HOST_PROJECT_ID ist die ID des freigegebenen VPC-Hostprojekts
SERVICE_PROJECT_NUM ist die ID des Dienstprojekts, das das GKE-Dienstkonto enthält

Für einen detaillierteren Ansatz erstellen Sie eine benutzerdefinierte IAM-Rolle, die nur die folgenden Berechtigungen enthält: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update und compute.firewalls.delete. Weisen Sie dem GKE-Dienstkonto des Dienstprojekts diese benutzerdefinierte Rolle im Hostprojekt zu.

Console

Erstellen Sie im Hostprojekt eine benutzerdefinierte Rolle mit den zuvor erwähnten IAM-Berechtigungen:

Öffnen Sie in der Google Cloud Console die Seite Rollen.

Zur Seite „Rollen“
Wählen Sie oben auf der Seite in der Drop-down-Liste das Hostprojekt aus.
Klicken Sie auf Rolle erstellen.
Geben Sie einen Titel, eine Beschreibung, eine ID und eine Phase der Rollenerstellung für die Rolle ein. Der Rollenname kann nach dem Erstellen der Rolle nicht mehr geändert werden.
Klicken Sie auf Berechtigungen hinzufügen.
Filtern Sie nach compute.networks und wählen Sie die oben genannten IAM-Berechtigungen aus.
Nachdem Sie alle erforderlichen Berechtigungen ausgewählt haben, klicken Sie auf Hinzufügen.
Klicken Sie auf Erstellen.

Weisen Sie dem GKE-Dienstkonto des Dienstprojekts die neu erstellte benutzerdefinierte Rolle innerhalb des Hostprojekts zu:

Öffnen Sie in der Google Cloud Console die Seite IAM.

IAM aufrufen
Wählen Sie das Hostprojekt aus.
Klicken Sie auf Zugriff gewähren und geben Sie das GKE-Dienstkontohauptkonto (service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com) des Dienstprojekts ein.
Filtern Sie nach dem Titel der neu erstellten benutzerdefinierten Rolle und wählen Sie ihn aus.
Klicken Sie auf Speichern.

gcloud

Erstellen Sie im Hostprojekt eine benutzerdefinierte Rolle mit den zuvor erwähnten IAM-Berechtigungen:

gcloud iam roles create ROLE_ID \
    --title="ROLE_TITLE" \
    --description="ROLE_DESCRIPTION" \
    --stage=LAUNCH_STAGE \
    --permissions=compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete \
    --project=HOST_PROJECT_ID

Weisen Sie dem GKE-Dienstkonto des Dienstprojekts die neu erstellte benutzerdefinierte Rolle innerhalb des Hostprojekts zu:
```
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
```
Dabei gilt:
- ROLE_ID ist der Name der Rolle, z. B. gkeFirewallAdmin.
- ROLE_TITLE ist der angezeigte Titel für die Rolle, z. B. GKE Firewall Admin
- ROLE_DESCRIPTION ist eine kurze Beschreibung der Rolle, z. B. GKE service account FW permissions.
- LAUNCH_STAGE ist die Startphase der Rolle im Lebenszyklus, z. B. ALPHA, BETA oder GA
- HOST_PROJECT_ID ist die ID des freigegebenen VPC-Hostprojekts
- SERVICE_PROJECT_NUM ist die ID des Dienstprojekts, das das GKE-Dienstkonto enthält

Wenn Sie Cluster in mehr als einem Dienstprojekt haben, müssen Sie eine der Strategien auswählen und für das GKE-Dienstkonto jedes Dienstprojekts wiederholen.

Zusammenfassung der Rollen, die Subnetzen gewährt wurden

Im Folgenden finden Sie eine Zusammenfassung der Rollen, die für die Subnetze gewährt wurden:

Dienstkonto	Rolle	Subnetz
service-`SERVICE_PROJECT_1_NUM`@container-engine-robot.iam.gserviceaccount.com	Compute-Netzwerknutzer	tier-1
`SERVICE_PROJECT_1_NUM`@cloudservices.gserviceaccount.com	Compute-Netzwerknutzer	tier-1
service-`SERVICE_PROJECT_2_NUM`@container-engine-robot.iam.gserviceaccount.com	Compute-Netzwerknutzer	tier-2
`SERVICE_PROJECT_2_NUM`@cloudservices.gserviceaccount.com	Compute-Netzwerknutzer	tier-2

Kubernetes Engine-Zugriff

Wenn Sie ein Dienstprojekt anhängen, wird beim Aktivieren des Kubernetes Engine-Zugriffs dem GKE-Dienstkonto des Dienstprojekts die Berechtigung zum Ausführen von Netzwerkverwaltungsvorgängen im Hostprojekt erteilt.

Wenn Sie den Kubernetes Engine-Zugriff aktivieren, weist GKE dem Hostprojekt automatisch die folgende Rolle zu:

Mitglied	Rolle	Ressource
service-`SERVICE_PROJECT_NUM`@container-engine-robot.iam.gserviceaccount.com	Host-Service-Agent-Nutzer	GKE-Dienstkonto im Hostprojekt

Sie müssen dem GKE-Dienstkonto des Dienstprojekts jedoch manuell die IAM-Berechtigung Compute Network User hinzufügen, um auf das Hostnetzwerk zugreifen zu können.

Mitglied	Rolle	Ressource
service-`SERVICE_PROJECT_NUM`@container-engine-robot.iam.gserviceaccount.com	Compute-Netzwerknutzer	Spezifisches Subnetz oder ganzes Hostprojekt

Wenn ein Dienstprojekt angehängt wurde, ohne den Kubernetes Engine-Zugriff zu aktivieren, können Sie, sofern die Kubernetes Engine API bereits im Host- und Dienstprojekt aktiviert wurde, dem GKE-Dienstkonto des Dienstprojekts manuell Berechtigungen zuweisen. Fügen Sie dazu die folgenden IAM-Rollenbindungen im Hostprojekt hinzu:

Mitglied	Rolle	Ressource
service-`SERVICE_PROJECT_NUM`@container-engine-robot.iam.gserviceaccount.com	Compute-Netzwerknutzer	Spezifisches Subnetz oder ganzes Hostprojekt
service-`SERVICE_PROJECT_NUM`@container-engine-robot.iam.gserviceaccount.com	Host-Service-Agent-Nutzer	GKE-Dienstkonto im Hostprojekt

Rolle „Nutzer des Dienst-Agents für Host“ gewähren

In jedem Dienstprojekt muss das GKE-Dienstkonto eine Bindung für die Rolle Nutzer des Dienst-Agents für Kubernetes Engine-Host im Hostprojekt haben. Das GKE-Dienstkonto hat das folgende Format:

service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com

Dabei ist SERVICE_PROJECT_NUM die Projektnummer Ihres Dienstprojekts.

Durch diese Bindung kann das GKE-Dienstkonto des Dienstprojekts Netzwerkverwaltungsvorgänge im Hostprojekt so ausführen, als wäre es das GKE-Dienstkonto des Hostprojekts. Diese Rolle kann nur einem GKE-Dienstkonto des Dienstprojekts zugewiesen werden.

Console

Wenn Sie die Google Cloud Console verwendet haben, müssen Sie die Rolle "Nutzer des Dienst-Agents für Host" nicht explizit gewähren. Das ist automatisch erfolgt, als Sie mit der Google Cloud Console Dienstprojekte an Ihr Hostprojekt angehängt haben.

gcloud

Weisen Sie dem GKE-Dienstkonto des Projekts für das erste Projekt die Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ zu. Diese Rolle wird in Ihrem Hostprojekt gewährt:

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

Weisen Sie dem GKE-Dienstkonto des Projekts für das zweite Projekt die Rolle „Nutzer des Dienst-Agents für Host“ zu. Diese Rolle wird in Ihrem Hostprojekt gewährt:

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

Verwendbare Subnetze und sekundäre IP-Adressbereiche verifizieren

Beim Erstellen eines Clusters müssen Sie ein Subnetz und die sekundären IP-Adressbereiche angeben, die für die Pods und Dienste des Clusters verwendet werden sollen. Es kann mehrere Gründe dafür geben, dass einzelne IP-Adressbereiche nicht zur Verfügung stehen. Unabhängig davon, ob Sie den Cluster mit der Google Cloud Console oder der gcloud CLI erstellen, sollten Sie verwendbare IP-Adressbereiche angeben.

Ein IP-Adressbereich kann für die Dienste des neuen Clusters verwendet werden, wenn der Bereich nicht bereits in Verwendung ist. Der IP-Adressbereich, den Sie für die Pods des neuen Clusters angeben, kann entweder ein nicht verwendeter Bereich oder ein Bereich sein, der mit den Pods in anderen Clustern gemeinsam genutzt wird. Von GKE erstellte und verwaltete IP-Adressbereiche können von Ihrem Cluster nicht verwendet werden.

Mit der gcloud CLI können Sie die verwendbaren Subnetze und sekundären IP-Adressbereiche eines Projekts auflisten.

gcloud

gcloud container subnets list-usable \
    --project SERVICE_PROJECT_ID \
    --network-project HOST_PROJECT_ID

Ersetzen Sie SERVICE_PROJECT_ID durch die Projekt-ID des Dienstprojekts.

Wenn Sie die Option --project oder --network-project auslassen, verwendet der gcloud CLI-Befehl das Standardprojekt aus Ihrer aktiven Konfiguration. Da das Hostprojekt und das Netzwerkprojekt unterschiedlich sind, müssen Sie entweder --project oder --network-project oder beide angeben.

Die Ausgabe sieht in etwa so aus:

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-2
RANGE: 172.16.4.0/22

SECONDARY_RANGE_NAME: tier-2-services
IP_CIDR_RANGE: 172.20.0.0/14
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-2-pods
IP_CIDR_RANGE: 172.16.16.0/20
STATUS: usable for pods or services

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-1
RANGE: 10.0.4.0/22

SECONDARY_RANGE_NAME: tier-1-services
IP_CIDR_RANGE: 10.0.32.0/20
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-1-pods
IP_CIDR_RANGE: 10.4.0.0/14
STATUS: usable for pods or services

Der Befehl list-usable gibt in den folgenden Situationen eine leere Liste zurück:

Wenn das Kubernetes Engine-Dienstkonto des Dienstprojekts im Hostprojekt nicht die Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ hat.
Wenn das Kubernetes Engine-Dienstkonto im Hostprojekt nicht existiert (z. B. wenn Sie das Konto versehentlich gelöscht haben).
Wenn die Kubernetes Engine API im Hostprojekt nicht aktiviert ist, was darauf hindeutet, dass das Kubernetes Engine-Dienstkonto im Hostprojekt fehlt.

Weitere Informationen finden Sie unter Fehlerbehebung.

Hinweise zu sekundären Bereichen

Sie können in einem bestimmten Subnetz 30 sekundäre Bereiche erstellen. Für jeden Cluster benötigen Sie zwei sekundäre Bereiche: einen für Pods und einen für Dienste.

Cluster im ersten Dienstprojekt erstellen

Führen Sie mit der gcloud CLI (die) oder der Google Cloud Console die folgenden Schritte aus, um einen Cluster im ersten Dienstprojekt zu erstellen.

Console

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

Zur Seite „Google Kubernetes Engine“
Wählen Sie in der Projektauswahl Ihr erstes Dienstprojekt aus.
Klicken Sie auf Erstellen.
Klicken Sie im Abschnitt "Autopilot" oder "Standard" auf Konfigurieren.
Geben Sie für Name tier-1-cluster ein.
Wählen Sie in der Drop-down-Liste Region die Region aus, die Sie für die Subnetze verwendet haben.
Klicken Sie im Navigationsbereich auf Netzwerk.
Wählen Sie Für mich freigegebene Netzwerke (von Hostprojekt …) aus.
Wählen Sie für Netzwerk den Eintrag shared-net aus.
Wählen Sie für Knotensubnetz den Eintrag tier-1 aus.
Wählen Sie für Sekundärer Pod-CIDR-Bereich den Eintrag tier-1-pods aus.
Wählen Sie für Sekundärer CIDR-Dienstbereich den Eintrag tier-1-services aus.
Klicken Sie auf Erstellen.
Klicken Sie nach der Erstellung in der Liste der Cluster auf tier-1-cluster.
Klicken Sie auf der Seite Clusterdetails auf den Tab Knoten.
Klicken Sie unter Knotenpools auf den Namen des Knotenpools, den Sie prüfen möchten.
Klicken Sie unter Instanzgruppen auf den Namen der Instanzgruppe, die Sie prüfen möchten. Beispiel: gke-tier-1-cluster-default-pool-5c5add1f-grp.
Bestätigen Sie in der Liste der Instanzen, dass sich die internen IP-Adressen Ihrer Knoten im primären Bereich 10.0.4.0/22 des Subnetzes „tier-1“ befinden.

gcloud

Erstellen Sie im ersten Dienstprojekt einen Cluster mit dem Namen tier-1-cluster:

gcloud container clusters create-auto tier-1-cluster \
    --project=SERVICE_PROJECT_1_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-1 \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services

Bestätigen Sie nach dem Erstellen des Clusters, dass sich Ihre Clusterknoten im primären Bereich des Subnetzes „tier-1“ befinden: 10.0.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_1_ID

In der Ausgabe werden die internen IP-Adressen der Knoten aufgeführt:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.2
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.3
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.4

Cluster im zweiten Dienstprojekt erstellen

Führen Sie zum Erstellen eines Clusters im zweiten Dienstprojekt mit der gcloud CLI oder der Google Cloud Console die folgenden Schritte aus.

Console

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

Zur Seite "Google Kubernetes Engine"
Wählen Sie in der Projektauswahl Ihr zweites Dienstprojekt aus.
Klicken Sie auf Erstellen.
Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.
Geben Sie für Name tier-2-cluster ein.
Wählen Sie in der Drop-down-Liste Region die Region aus, die Sie für die Subnetze verwendet haben.
Klicken Sie im Navigationsbereich auf Netzwerk.
Wählen Sie für Netzwerk den Eintrag shared-net aus.
Wählen Sie für Knotensubnetz den Eintrag tier-2 aus.
Wählen Sie für Sekundärer Pod-CIDR-Bereich den Eintrag tier-2-pods aus.
Wählen Sie für Sekundärer CIDR-Dienstbereich den Eintrag tier-2-services aus.
Klicken Sie auf Erstellen.
Klicken Sie nach der Erstellung in der Liste der Cluster auf tier-2-cluster.
Klicken Sie auf der Seite Clusterdetails auf den Tab Knoten.
Klicken Sie unter Knotenpools auf den Namen des Knotenpools, den Sie prüfen möchten.
Klicken Sie unter Instanzgruppen auf den Namen der Instanzgruppe, die Sie prüfen möchten. Beispiel: gke-tier-2-cluster-default-pool-5c5add1f-grp.
Bestätigen Sie in der Liste der Instanzen, dass sich die internen IP-Adressen Ihrer Knoten im primären Bereich 172.16.4.0/22 des Subnetzes „tier-2“ befinden.

gcloud

Erstellen Sie im zweiten Dienstprojekt einen Cluster mit dem Namen tier-2-cluster:

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-2 \
    --cluster-secondary-range-name=tier-2-pods \
    --services-secondary-range-name=tier-2-services

Bestätigen Sie nach dem Erstellen des Clusters, dass sich Ihre Clusterknoten im primären Bereich des Subnetzes „tier-2“ befinden: 172.16.4.0/22

gcloud compute instances list --project SERVICE_PROJECT_2_ID

In der Ausgabe werden die internen IP-Adressen der Knoten aufgeführt:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.2
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.3
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.4

Firewallregeln erstellen

Damit Traffic in das Netzwerk und zwischen den Clustern innerhalb des Netzwerks zugelassen wird, müssen Sie Firewalls erstellen. In den folgenden Abschnitten wird gezeigt, wie Sie Firewallregeln erstellen und aktualisieren:

Firewallregel zum Aktivieren der SSH-Verbindung zu einem Knoten erstellen: Erläutert das Erstellen einer Firewallregel, die Traffic von außerhalb der Cluster mithilfe von SSH zulässt.
Firewallregel zum Pingen zwischen Knoten aktualisieren: Erläutert das Aktualisieren der Firewallregel, um ICMP-Traffic zwischen den Clustern zuzulassen.

SSH und ICMP werden als Beispiele verwendet. Sie müssen Firewallregeln erstellen, mit denen die Netzwerkanforderungen Ihrer spezifischen Anwendung ermöglicht werden.

Firewallregel zum Aktivieren der SSH-Verbindung zu einem Knoten erstellen

Erstellen Sie in Ihrem Hostprojekt eine Firewallregel für das Netzwerk shared-net. Lassen Sie Traffic über den TCP-Port 22 zu. So können Sie über SSH eine Verbindung zu Ihren Clusterknoten herstellen.

Console

Rufen Sie in der Google Cloud Console die Seite Firewall auf.

Zur Firewall
Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.
Klicken Sie im Menü VPC-Netzwerk auf Firewallregel erstellen.
Geben Sie für Name my-shared-net-rule ein.
Wählen Sie für Netzwerk den Eintrag shared-net aus.
Wählen Sie für Traffic-Richtung die Option Eingehend aus.
Wählen Sie für Aktion bei Übereinstimmung die Option Zulassen aus.
Wählen Sie für Ziele die Option Alle Instanzen im Netzwerk aus.
Wählen Sie für Quellfilter die Option IP ranges aus.
Geben Sie für Quell-IP-Bereiche 0.0.0.0/0 ein.
Wählen Sie für Protokolle und Ports die Option Angegebene Protokolle und Ports aus. Geben Sie tcp:22 in das Feld ein.
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie eine Firewallregel für Ihr freigegebenes Netzwerk:

gcloud compute firewall-rules create my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --direction INGRESS \
    --allow tcp:22

Verbindung zu einem Knoten über SSH herstellen

Nachdem Sie die Firewall erstellt haben, die eingehenden Traffic über den TCP-Port 22 zulässt, stellen Sie über SSH eine Verbindung zum Knoten her.

Console

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

Zur Seite „Google Kubernetes Engine“
Wählen Sie in der Projektauswahl Ihr erstes Dienstprojekt aus.
Klicken Sie auf tier-1-cluster.
Klicken Sie auf der Seite Clusterdetails auf den Tab Knoten.
Klicken Sie unter Knotenpools auf den Namen Ihres Knotenpools.
Klicken Sie unter Instanzgruppen auf den Namen Ihrer Instanzgruppe. Beispiel: gke-tier-1-cluster-default-pool-faf87d48-grp.
Notieren Sie sich in der Liste der Instanzen die internen IP-Adressen der Knoten. Diese Adressen befinden sich im Bereich 10.0.4.0/22.
Klicken Sie für einen Ihrer Knoten auf SSH. Dies ist erfolgreich, da SSH den TCP-Port 22 verwendet, der von Ihrer Firewallregel zugelassen wird.

gcloud

Listen Sie die Knoten in Ihrem ersten Dienstprojekt auf:

gcloud compute instances list --project SERVICE_PROJECT_1_ID

Die Ausgabe enthält die Namen der Knoten in Ihrem Cluster:

NAME                                           ...
gke-tier-1-cluster-default-pool-faf87d48-3mf8  ...
gke-tier-1-cluster-default-pool-faf87d48-q17k  ...
gke-tier-1-cluster-default-pool-faf87d48-x9rk  ...

Stellen Sie über SSH eine Verbindung zu einem Ihrer Knoten her:

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

Ersetzen Sie Folgendes:

NODE_NAME ist der Name einer Ihrer Knoten.
COMPUTE_ZONE ist der Name einer Compute Engine-Zone innerhalb der Region.

Firewallregel zum Pingen zwischen Knoten aktualisieren

Starten Sie in Ihrem SSH-Befehlszeilenfenster die CoreOS Toolbox:
```
/usr/bin/toolbox
```
Pingen Sie in der Toolbox-Shell einen Ihrer anderen Knoten im selben Cluster. Beispiel:
```
ping 10.0.4.4
```
Der Befehl ping ist erfolgreich, da sich sowohl Ihr Knoten als auch der andere Knoten im Bereich 10.0.4.0/22 befinden.
Versuchen Sie nun, einen der Knoten im Cluster in Ihrem anderen Dienstprojekt zu pingen. Beispiel:
```
ping 172.16.4.3
```
Dieses Mal schlägt der Befehl ping fehl, da Ihre Firewallregel keinen ICMP-Traffic (Internet Control Message Protocol) zulässt.
Aktualisieren Sie in einer normalen Eingabeaufforderung (nicht in der Toolbox-Shell) Ihre Firewallregel so, dass ICMP zugelassen wird:
```
gcloud compute firewall-rules update my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --allow tcp:22,icmp
```
Pingen Sie den Knoten in Ihrer Toolbox-Shell noch einmal. Beispiel:
```
ping 172.16.4.3
```
Diesmal ist der Befehl ping erfolgreich.

Zusätzliche Firewallregeln erstellen

Sie können zusätzliche Firewallregeln erstellen, um die Kommunikation zwischen Knoten, Pods und Diensten in Ihren Clustern zu ermöglichen.

Die folgende Regel lässt beispielsweise eingehenden Traffic von jedem Knoten, Pod oder Dienst in tier-1-cluster über jeden TCP- oder UDP-Port zu.

gcloud compute firewall-rules create my-shared-net-rule-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

Die folgende Regel lässt eingehenden Traffic von jedem Knoten, Pod oder Dienst in tier-2-cluster über jeden TCP- oder UDP-Port zu:

gcloud compute firewall-rules create my-shared-net-rule-3 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 172.16.4.0/22,172.20.0.0/14,172.16.16.0/20

Bei Bedarf versucht Kubernetes außerdem, Firewallressourcen zu erstellen und zu verwalten, z. B. wenn Sie einen Load-Balancer-Dienst erstellen. Wenn Kubernetes die Firewallregeln aufgrund eines Berechtigungsproblems nicht ändern kann, wird ein Kubernetes-Ereignis ausgelöst, um Ihnen zu zeigen, wie Sie die Änderungen vornehmen können.

Wenn Sie Kubernetes die Berechtigung zum Ändern der Firewallregeln erteilen möchten, finden Sie weitere Informationen unter Firewallregeln verwalten.

Wenn Kubernetes bei Load-Balancern für eingehenden Traffic die Firewallregeln aufgrund unzureichender Berechtigungen nicht ändern kann, wird alle paar Minuten ein firewallXPNError-Ereignis ausgegeben. Ab GLBC 1.4 können Sie das Ereignis firewallXPNError stummschalten. Dazu müssen Sie der Ressource für eingehenden Traffic die Annotation networking.gke.io/suppress-firewall-xpn-error: "true" hinzufügen. Sie können diese Anmerkung jederzeit entfernen, um die Stummschaltung aufzuheben.

Privaten Cluster in einer freigegebenen VPC erstellen

Sie können freigegebene VPCs mit privaten Clustern verwenden.

Dafür müssen Sie dem Nutzerkonto oder dem Dienstkonto, das zum Erstellen des Clusters verwendet wurde, die folgenden Berechtigungen für das Hostprojekt erteilen:

compute.networks.get
compute.networks.updatePeering

Sie müssen auch darauf achten, dass sich der IP-Adressbereich der Steuerungsebene nicht mit anderen reservierten Bereichen im freigegebenen Netzwerk überschneidet.

Bei privaten Clustern, die vor dem 15. Januar 2020 erstellt wurden, ist die maximale Anzahl privater GKE-Cluster pro VPC-Netzwerk auf die Anzahl der Peering-Verbindungen aus einem einzelnen VPC-Netzwerk beschränkt. Bei neuen privaten Clustern werden VPC-Netzwerk-Peering-Verbindungen wiederverwendet, wodurch diese Beschränkung aufgehoben wird. 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.

In diesem Abschnitt erstellen Sie einen VPC-nativen Cluster namens private-cluster-vpc in einem vordefinierten freigegebenen VPC-Netzwerk.

Console

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

Zur Seite "Google Kubernetes Engine"
Klicken Sie auf Erstellen.
Klicken Sie im Abschnitt "Autopilot" oder "Standard" auf Konfigurieren.
Geben Sie für Name private-cluster-vpc ein.
Klicken Sie im Navigationsbereich auf Netzwerk.
Wählen Sie Privater Cluster aus.
(Optional für Autopilot): Setzen Sie IP-Bereich der Steuerungsebene auf 172.16.0.16/28.
Wählen Sie in der Drop-down-Liste Netzwerk das zuvor erstellte VPC-Netzwerk aus.
Wählen Sie in der Drop-down-Liste Knotensubnetz das zuvor erstellte freigegebene Subnetz aus.
Konfigurieren Sie den Cluster nach Bedarf.
Klicken Sie auf Erstellen.

gcloud

Führen Sie den folgenden Befehl aus, um einen Cluster mit dem Namen private-cluster-vpc in einer vordefinierten freigegebenen VPC zu erstellen:

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork=SHARED_SUBNETWORK \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28

IP-Adressen reservieren

Sie können für Ihre freigegebenen VPC-Cluster sowohl interne IP-Adressen als auch externe IP-Adressen reservieren. Überprüfen Sie, ob die IP-Adressen im Dienstprojekt reserviert sind.

Für interne IP-Adressen müssen Sie das Subnetzwerk angeben, zu dem die IP-Adresse gehört. Sie müssen zum Identifizieren des Subnetzes die vollständige Ressourcen-URL verwenden, wenn Sie eine IP-Adresse projektübergreifend reservieren möchten.

Mit dem folgenden Befehl in Google Cloud CLI können Sie eine interne IP-Adresse reservieren:

gcloud compute addresses create RESERVED_IP_NAME \
    --region=COMPUTE_REGION \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNETWORK_NAME \
    --addresses=IP_ADDRESS \
    --project=SERVICE_PROJECT_ID

Damit Sie diesen Befehl aufrufen können, müssen Sie dem Subnetzwerk die Berechtigung compute.subnetworks.use hinzufügen. Sie können dem Anrufer wahlweise im Subnetzwerk die Rolle compute.networkUser erteilen oder auf Projektebene eine benutzerdefinierte Rolle mit der Berechtigung compute.subnetworks.use zuweisen.

Bereinigen

Wenn Sie mit den Übungen aus dieser Anleitung fertig sind, führen Sie die folgenden Schritte aus, um die Ressourcen zu entfernen und damit unerwünschte Kosten für Ihr Konto zu vermeiden:

Cluster löschen

Löschen Sie die beiden von Ihnen erstellten Cluster.

Console

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

Zur Seite „Google Kubernetes Engine“
Wählen Sie in der Projektauswahl Ihr erstes Dienstprojekt aus.
Wählen Sie tier-1-cluster aus und klicken Sie auf Löschen.
Wählen Sie in der Projektauswahl Ihr zweites Dienstprojekt aus.
Wählen Sie tier-2-cluster aus und klicken Sie auf Löschen.

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --zone COMPUTE_ZONE

Freigegebene VPC deaktivieren

Deaktivieren Sie die freigegebene VPC im Hostprojekt.

Console

Rufen Sie in der Google Cloud Console die Seite Freigegebene VPC auf.

Zu Shared VPC gehen
Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.
Klicken Sie auf Freigegebene VPC deaktivieren.
Geben Sie die HOST_PROJECT_ID in das Feld ein und klicken Sie auf Deaktivieren.

gcloud

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc disable HOST_PROJECT_ID

Firewallregeln löschen

Entfernen Sie die erstellten Firewallregeln.

Console

Rufen Sie in der Google Cloud Console die Seite Firewall auf.

Zur Firewall
Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.
Wählen Sie in der Liste der Regeln my-shared-net-rule, my-shared-net-rule und my-shared-net-rule aus.
Klicken Sie auf Löschen.

gcloud

Löschen Sie Ihre Firewallregeln:

gcloud compute firewall-rules delete \
    my-shared-net-rule \
    my-shared-net-rule-2 \
    my-shared-net-rule-3 \
    --project HOST_PROJECT_ID

Das freigegebene Netzwerk löschen

Löschen Sie das freigegebene Netzwerk, das Sie erstellt haben.

Console

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

Zur Seite VPC-Netzwerke
Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.
Wählen Sie in der Liste der Netzwerke shared-net aus.
Klicken Sie auf VPC-Netzwerk löschen.

gcloud

gcloud compute networks subnets delete tier-1 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks subnets delete tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

Rolle „Nutzer des Dienst-Agents für Host“ entfernen

Entfernen Sie die Rollen „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ aus beiden Dienstprojekten.

Console

Rufen Sie in der Google Cloud Console die Seite IAM auf.

Seite „IAM“
Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.
Wählen Sie in der Mitgliederliste die Zeile aus, in der angezeigt wird, dass service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com die Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ zugewiesen ist.
Wählen Sie die Zeile aus, in der angezeigt wird, dass service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com die Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ zugewiesen ist.
Klicken Sie auf Zugriff entfernen.

gcloud

Entfernen Sie die Rolle „Nutzer des Dienst-Agents für Host“ aus dem GKE-Dienstkonto Ihres ersten Dienstprojekts:

gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

Entfernen Sie die Rolle „Nutzer des Dienst-Agents für Host“ aus dem GKE-Dienstkonto Ihres zweiten Dienstprojekts:

gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

Fehlerbehebung

Berechtigung verweigert

Symptom:

Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google
Compute Engine: Required 'compute.projects.get' permission for
'projects/HOST_PROJECT_ID

Mögliche Gründe:

Die Kubernetes Engine API wurde im Hostprojekt nicht aktiviert.
Das GKE-Dienstkonto des Hostprojekts ist nicht vorhanden. Möglicherweise wurde es gelöscht.
Das GKE-Dienstkonto des Hostprojekts hat im Hostprojekt nicht die Rolle Kubernetes Engine-Dienst-Agent (container.serviceAgent). Die Bindung wurde möglicherweise versehentlich entfernt.
Das GKE-Dienstkonto des Dienstprojekts hat im Hostprojekt nicht die Rolle "Nutzer des Dienst-Agents für Kubernetes Engine-Host".

So beheben Sie das Problem: Prüfen Sie, ob das GKE-Dienstkonto des Hostprojekts vorhanden ist. Ist dies nicht der Fall, gehen Sie so vor:

Aktivieren Sie die Kubernetes Engine API im Hostprojekt, falls sie nicht aktiviert ist. Dadurch wird das GKE-Dienstkonto des Hostprojekts erstellt und dem GKE-Dienstkonto des Hostprojekts wird die Rolle Kubernetes Engine-Dienst-Agent (container.serviceAgent) im Hostprojekt zugewiesen.
Wenn die Kubernetes Engine API im Hostprojekt aktiviert ist, wurde entweder das GKE-Dienstkonto des Hostprojekts gelöscht oder es hat im Hostprojekt nicht die Rolle Kubernetes Engine-Dienst-Agent (container.serviceAgent). Wenn Sie das GKE-Dienstkonto oder die Rollenbindung wiederherstellen möchten, müssen Sie die Kubernetes Engine API deaktivieren und dann wieder aktivieren. Weitere Informationen finden Sie unter Google Kubernetes Engine – Fehlerbehebung.

Hinweis: Das Deaktivieren und anschließende Aktivieren der Kubernetes Engine API im Hostprojekt wirkt sich nicht auf die Arbeit vorhandener Cluster in Dienstprojekten aus. Sie können jedoch keine neuen Cluster erstellen, die ein freigegebenes VPC-Netzwerk in einem Dienstprojekt oder im Hostprojekt verwenden, während die Kubernetes Engine API deaktiviert ist.