Cluster mit freigegebene VPC konfigurieren

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.

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

Vorteile der Verwendung einer freigegebene VPC mit GKE

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.

Hinweise

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

• Sie benötigen eine Google Cloud -Organisation.
• Ihre Organisation muss über drei Google Cloud -Projekte verfügen.
• Machen Sie sich mit den Konzepten für freigegebene VPCs vertraut, einschließlich der verschiedenen IAM-Rollen (Identity and Access Management), die von freigegebene VPC verwendet werden. Die Aufgaben in dieser Anleitung müssen von einem Administrator für freigegebene VPC ausgeführt werden.
• Machen Sie sich mit allen Einschränkungen für Organisationsrichtlinien vertraut, 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

Hinweis: Die Begriffe „erstes Dienstprojekt“ und „zweites Dienstprojekt“ bezeichnen keine Reihenfolge. Die Begriffe „erstes“ und „zweites“ werden nur zur Unterscheidung der zwei Projekte verwendet.

Projekt-IDs und -nummern ermitteln

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

Console

1. Rufen Sie die Startseite der Google Cloud Console auf.

   Zur Startseite

2. Wählen Sie in der Projektauswahl das Projekt aus, das Sie als Hostprojekt designiert haben.

3. 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.

4. 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

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

   Rufen Sie "APIs & Dienste" auf.

2. Wählen Sie in der Projektauswahl das Projekt aus, das Sie als Hostprojekt designiert haben.

3. Wenn sich 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 dann auf Aktivieren.

4. 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:

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

Hinweis: Die sekundären Adressbereiche für Pods, Dienste und Knoten dürfen sich nicht mit 172.17.0.0/16 überschneiden und müssen den Standardeinstellungen und Limits für Bereichsgrößen entsprechen.

Console

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

   Zur Seite VPC-Netzwerke

2. Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.

3. Klicken Sie auf VPC-Netzwerk erstellen.

4. Geben Sie für Name shared-net ein.

5. Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.

tier-1 hinzufügen

1. Geben Sie unter Subnetze im Feld Neues Subnetz für Name den Wert tier-1 ein.
2. Wählen Sie bei Region eine Region aus.
3. Wählen Sie unter IP-Stack-Typ die Option IPv4 (Single-Stack) aus.
4. Geben Sie für IPv4-Bereich 10.0.4.0/22 als primären Adressbereich für das Subnetz ein.

5. Klicken Sie auf Sekundären IPv4-Bereich hinzufügen.

   • Geben Sie für Name des Subnetzbereichs den Wert tier-1-services ein.
   • Geben Sie unter Sekundärer IPv4-Bereich 10.0.32.0/20 ein.

6. Klicken Sie auf Fertig.

7. Klicken Sie auf Sekundären IPv4-Bereich hinzufügen.

   • Geben Sie für Name des Subnetzbereichs den Wert tier-1-pods ein.
   • Geben Sie unter Sekundärer IPv4-Bereich 10.4.0.0/14 ein.

8. Klicken Sie auf Fertig.

tier-2 hinzufügen

1. Klicken Sie auf Subnetz hinzufügen.
2. Geben Sie für Name tier-2 ein.
3. Wählen Sie unter Region die Region aus, die Sie für das vorherige Subnetz ausgewählt haben.
4. Geben Sie für IPv4-Bereich 172.16.4.0/22 als primären Adressbereich für das Subnetz ein.

5. Klicken Sie auf Sekundären IPv4-Bereich hinzufügen.

   • Geben Sie für Name des Subnetzbereichs den Wert tier-2-services ein.
   • Geben Sie unter Sekundärer IPv4-Bereich 172.16.16.0/20 ein.

6. Klicken Sie auf Fertig.

7. Klicken Sie auf Sekundären IPv4-Bereich hinzufügen.

   • Geben Sie für Name des Subnetzbereichs den Wert tier-2-pods ein.
   • Geben Sie unter Sekundärer IPv4-Bereich 172.20.0.0/14 ein.

8. Klicken Sie auf Fertig.

9. Scrollen Sie zum Ende der Seite und 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	[e-mail]
	[e-mail]
Google APIs	[e-mail]
	[e-mail]

Freigegebene VPC aktivieren und Rollen gewähren

Damit Sie die Aufgaben in diesem Abschnitt ausführen können, müssen Sie ein Administrator für freigegebene VPC sein. Wenn Sie kein Administrator für freigegebene VPC sind, bitten Sie einen Organisationsadministrator, Ihnen die Rollen „Administrator für freigegebene Compute-VPC“ (compute.xpnAdmin) und „Projekt-IAM-Administrator“ (resourcemanager.projectIamAdmin) für die Organisation oder einen oder mehrere Ordner zuzuweisen.

Aufgaben in diesem Abschnitt:

1. Im Hostprojekt die freigegebene VPC aktivieren.
2. Die beiden Dienstprojekte an das Hostprojekt anhängen.
3. Entfernen Sie die Rolle Compute Network User für die Dienstkonten, die zu Ihren Dienstprojekten gehören, oder weisen Sie sie ihnen zu. Wenn Sie dieGoogle Cloud -Konsole verwenden, entfernen Sie die Rolle. Wenn Sie die gcloud CLI verwenden, weisen Sie die Rolle zu.

Console

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

   Zu Shared VPC gehen

2. Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.

3. Klicken Sie auf Freigegebene VPC einrichten. Der Bildschirm Hostprojekt aktivieren wird angezeigt.

4. Klicken Sie auf Aktivieren und fortfahren. Der Bereich Dienstprojekte anhängen und Hauptkonten auswählen wird angezeigt.

5. Wählen Sie unter Kubernetes Engine-Zugriff die Option Aktiviert aus.

6. Klicken Sie unter Auszuwählende Projekte zum Anhängen auf Element hinzufügen.

7. Klicken Sie im Feld Projekt auswählen auf Auswählen und wählen Sie Ihr erstes Dienstprojekt aus.

8. Klicken Sie noch einmal auf  Element hinzufügen und wählen Sie Ihr zweites Dienstprojekt aus.

9. Klicken Sie auf Weiter. Der Bereich Zugriff erlauben wird angezeigt.

10. Wählen Sie unter Zugriffsmodus die Option Einzelner Subnetzzugriff aus.

11. Scrollen Sie unter Subnetze mit individuellem Subnetzzugriff durch die Liste und wählen Sie tier-1 und tier-2 aus.

12. Klicken Sie auf Speichern. Eine neue Seite wird angezeigt.

13. Wählen Sie Nur Subnetze anzeigen, die individuelle IAM-Richtlinien haben aus.

Dienstkonten aus tier-1 entfernen

1. Wählen Sie unter Einzelner Subnetzzugriff die Option tier-1 aus und klicken Sie auf Bereich „Berechtigungen“ einblenden.
2. Maximieren Sie im Berechtigungsfeld unter Rolle/Hauptkonto die Option Compute-Netzwerknutzer.
3. Suchen Sie nach SERVICE_PROJECT_2_NUM.
4. Löschen Sie alle Dienstkonten, die zu Ihrem zweiten Dienstprojekt gehören. Löschen Sie also alle Dienstkonten, die SERVICE_PROJECT_2_NUM enthalten.

5. Prüfen Sie, ob die folgenden Dienstkonten für Ihr erstes Dienstprojekt mit der Rolle Compute-Netzwerknutzer in der Liste aufgeführt sind:

   • [e-mail]
   • [e-mail]
   • [e-mail]

   Wenn ein Dienstkonto nicht in der Liste enthalten ist, gehen Sie so vor, um es hinzuzufügen:

   1. Klicken Sie auf Hauptkonto hinzufügen.
   2. Geben Sie im Feld Neue Hauptkonten den Namen des Dienstkontos ein.
   3. Wählen Sie unter Rollen zuweisen die Option Compute-Netzwerknutzer aus.
   4. Klicken Sie auf Speichern.

6. Entfernen Sie unter Einzelner Subnetzzugriff das Häkchen aus dem Kästchen tier-1.

Dienstkonten aus tier-2 entfernen

1. Wählen Sie unter Einzelner Subnetzzugriff den Eintrag tier-2 aus.
2. Maximieren Sie im Berechtigungsfeld unter Rolle/Hauptkonto die Option Compute-Netzwerknutzer.
3. Suchen Sie nach SERVICE_PROJECT_1_NUM.
4. Löschen Sie alle Dienstkonten, die zu Ihrem ersten Dienstprojekt gehören. Löschen Sie also alle Dienstkonten, die SERVICE_PROJECT_1_NUM enthalten.

5. Prüfen Sie, ob die folgenden Dienstkonten für Ihr zweites Dienstprojekt mit der Rolle Compute-Netzwerknutzer in der Liste enthalten sind:

   • [e-mail]
   • [e-mail]
   • [e-mail]

   Wenn ein Dienstkonto nicht in der Liste enthalten ist, gehen Sie so vor, um es hinzuzufügen:

   1. Klicken Sie auf Hauptkonto hinzufügen.
   2. Geben Sie den Namen des Dienstkontos in das Feld Neue Hauptkonten ein.
   3. Wählen Sie unter Rollen zuweisen die Option Compute-Netzwerknutzer aus.
   4. Klicken Sie auf Speichern.

gcloud

1. 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
   

2. 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
   

3. 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
   

4. 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.

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

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

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

6. 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
   

7. 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.

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

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

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

9. 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:

Hinweis: Wählen Sie zur Einhaltung der Best Practices für die Sicherheit einen detaillierteren Ansatz aus. Wenn Sie dem GKE-Dienstkonto des Dienstprojekts die Rolle „Compute-Sicherheitsadministrator“ zuweisen, erhält es mehr IAM-Berechtigungen als für die Anleitung erforderlich ist.

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

Console

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

   IAM aufrufen

2. Wählen Sie das Hostprojekt aus.

3. Klicken Sie auf Zugriff gewähren und geben Sie dann das GKE-Dienstkontohauptkonto ([e-mail]) des Dienstprojekts ein.

4. Wählen Sie in der Drop-down-Liste die Rolle Compute Security Admin aus.

5. 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:[e-mail] \
    --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:

1. Rufen Sie in der Google Cloud Console die Seite Rollen auf.

   Zur Seite „Rollen“

2. Wählen Sie oben auf der Seite in der Drop-down-Liste das Hostprojekt aus.

3. Klicken Sie auf Rolle erstellen.

4. 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.

5. Klicken Sie auf Berechtigungen hinzufügen.

6. Filtern Sie nach compute.networks und wählen Sie die oben genannten IAM-Berechtigungen aus.

7. Nachdem Sie alle erforderlichen Berechtigungen ausgewählt haben, klicken Sie auf Hinzufügen.

8. Klicken Sie auf Erstellen.

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

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

   IAM aufrufen

2. Wählen Sie das Hostprojekt aus.

3. Klicken Sie auf Zugriff gewähren und geben Sie das GKE-Dienstkontohauptkonto ([e-mail]) des Dienstprojekts ein.

4. Filtern Sie nach dem Titel der neu erstellten benutzerdefinierten Rolle und wählen Sie ihn aus.

5. Klicken Sie auf Speichern.

gcloud

1. 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
   

2. 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:[e-mail] \
       --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.

Hinweis: Wenn Sie Ingress für die internen Anwendungs-Load-Balancer verwenden, erstellt der Ingress-Controller keine Firewallregel, die Verbindungen aus den Load-Balancer-Proxys im Proxy-Subnetz zulässt. Sie müssen diese Firewallregel manuell erstellen. Der Ingress-Controller erstellt jedoch Firewallregeln, um eingehenden Traffic für Google Cloud Systemdiagnosen zuzulassen.

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
[e-mail]	Compute-Netzwerknutzer	tier-1
[e-mail]	Compute-Netzwerknutzer	tier-1
[e-mail]	Compute-Netzwerknutzer	tier-2
[e-mail]	Compute-Netzwerknutzer	tier-2

GKE-Zugriff prüfen

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

GKE weist beim Aktivieren des GKE-Zugriffs automatisch die folgende Rolle im Hostprojekt zu:

Mitglied	Rolle	Ressource
[e-mail]	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
[e-mail]	Compute-Netzwerknutzer	Spezifisches Subnetz oder ganzes Hostprojekt

Wenn ein Dienstprojekt angehängt wurde, ohne den GKE-Zugriff zu aktivieren, können Sie die Berechtigungen dem GKE-Dienstkonto des Dienstprojekts manuell zuweisen, indem Sie die folgenden IAM-Rollenbindungen im Hostprojekt hinzufügen, sofern die GKE API bereits sowohl im Host- als auch im Dienstprojekt aktiviert wurde:

Mitglied	Rolle	Ressource
[e-mail]	Compute-Netzwerknutzer	Spezifisches Subnetz oder ganzes Hostprojekt
[e-mail]	Host-Service-Agent-Nutzer	GKE-Dienst-Agent im Hostprojekt

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

Der GKE-Dienst-Agent jedes Dienstprojekts muss eine Bindung für die Rolle Nutzer des Dienst-Agents für Host (roles/container.hostServiceAgentUser) im Hostprojekt haben. Der GKE-Dienst-Agent hat das folgende Format:

[e-mail]

Dabei ist SERVICE_PROJECT_NUM die Projektnummer Ihres Dienstprojekts.

Durch diese Bindung kann der GKE-Dienst-Agent des Dienstprojekts Netzwerkverwaltungsvorgänge im Hostprojekt so ausführen, als wäre er der GKE-Dienst-Agent des Hostprojekts. Diese Rolle kann nur einem GKE-Dienst-Agent eines Dienstprojekts zugewiesen werden.

Console

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

gcloud

1. Weisen Sie dem GKE-Dienst-Agent des Projekts für das erste 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:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. Weisen Sie dem Dienst-Agent 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:[e-mail] \
       --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               REGION    NETWORK     SUBNET  RANGE
example-host-project  us-west1  shared-net  tier-1  10.0.4.0/22
┌──────────────────────┬───────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
├──────────────────────┼───────────────┼─────────────────────────────┤
│ tier-1-services      │ 10.0.32.0/20  │ usable for pods or services │
│ tier-1-pods          │ 10.4.0.0/14   │ usable for pods or services │
└──────────────────────┴───────────────┴─────────────────────────────┘
example-host-project  us-west1  shared-net  tier-2  172.16.4.0/22
┌──────────────────────┬────────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE  │            STATUS           │
├──────────────────────┼────────────────┼─────────────────────────────┤
│ tier-2-services      │ 172.16.16.0/20 │ usable for pods or services │
│ tier-2-pods          │ 172.20.0.0/14  │ usable for pods or services │
└──────────────────────┴────────────────┴─────────────────────────────┘

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

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

Weitere Informationen finden Sie unter Fehlerbehebung.

Limits für sekundäre IP-Adressbereiche

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.

Hinweis: Der primäre Bereich und der sekundäre Bereich für Pods können von Clustern gemeinsam genutzt werden. Diese Konfiguration wird jedoch nicht empfohlen.

Cluster im ersten Dienstprojekt erstellen

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

Console

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Wählen Sie in der Projektauswahl Ihr erstes Dienstprojekt aus.

3. Klicken Sie auf Erstellen.

4. Klicken Sie im Abschnitt "Autopilot" oder "Standard" auf Konfigurieren.

5. Geben Sie für Name tier-1-cluster ein.

6. Wählen Sie in der Drop-down-Liste Region die Region aus, die Sie für die Subnetze verwendet haben.

7. Klicken Sie im Navigationsbereich auf Netzwerk.

8. Klicken Sie unter Clusternetzwerk auf Für mich freigegebene Netzwerke.

9. Wählen Sie im Feld Netzwerk die Option shared-net aus.

10. Wählen Sie für Knotensubnetz den Eintrag tier-1 aus.

11. Wählen Sie unter Erweiterte Netzwerkoptionen für Sekundärer Pod-CIDR-Bereich die Option tier-1-pods aus.

12. Wählen Sie für Sekundärer CIDR-Dienstbereich den Eintrag tier-1-services aus.

13. Klicken Sie auf Erstellen.

Wenn Sie einen Standard-Cluster erstellt haben, können Sie so prüfen, ob sich die Knoten des Clusters im primären Adressbereich des Subnetzes „tier-1“ befinden:

1. Nach Abschluss der Erstellung wird die Seite Clusterdetails angezeigt.
2. Klicken Sie auf den Tab Knoten.
3. Klicken Sie unter Knotenpools auf default-pool.
4. Klicken Sie unter Instanzgruppen auf den Namen der Instanzgruppe, die Sie prüfen möchten. Beispiel: gke-tier-1-cluster-default-pool-5c5add1f-grp.
5. 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=CONTROL_PLANE_LOCATION \
    --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

Ersetzen Sie CONTROL_PLANE_LOCATION durch die Compute Engine-Region der Steuerungsebene Ihres Clusters.

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

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Wählen Sie in der Projektauswahl Ihr zweites Dienstprojekt aus.

3. Klicken Sie auf Erstellen.

4. Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.

5. Geben Sie für Name tier-2-cluster ein.

6. Wählen Sie in der Drop-down-Liste Region die Region aus, die Sie für die Subnetze verwendet haben.

7. Klicken Sie im Navigationsbereich auf Netzwerk.

8. Klicken Sie unter Clusternetzwerk auf Für mich freigegebene Netzwerke.

9. Wählen Sie im Feld Netzwerk die Option shared-net aus.

10. Wählen Sie für Knotensubnetz den Eintrag tier-2 aus.

11. Wählen Sie unter Erweiterte Netzwerkoptionen für Sekundärer Pod-CIDR-Bereich die Option tier-2-pods aus.

12. Wählen Sie für Sekundärer CIDR-Dienstbereich den Eintrag tier-2-services aus.

13. Klicken Sie auf Erstellen.

Wenn Sie einen Standard-Cluster erstellt haben, können Sie so prüfen, ob sich die Knoten des Clusters im primären Adressbereich des Subnetzes „tier-2“ befinden:

1. Nach Abschluss der Erstellung wird die Seite Clusterdetails angezeigt.
2. Klicken Sie auf den Tab Knoten.
3. Klicken Sie unter Knotenpools auf default-pool.
4. Klicken Sie unter Instanzgruppen auf den Namen der Instanzgruppe, die Sie prüfen möchten. Beispiel: gke-tier-2-cluster-default-pool-5c5add1f-grp.
5. 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=CONTROL_PLANE_LOCATION \
    --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

Hinweis :Während GKE-Cluster-Upgrades fügt GKE automatisch Metadateneinträge auf Projektebene wie google_compute_project_metadata hinzu, um die Nutzung des sekundären IP-Adressbereichs zu verfolgen. Weitere Informationen und Anleitungen zum Verwalten dieser Metadaten mit IaC-Tools (Infrastructure as Code) finden Sie unter Projektmetadaten für sekundäre IP-Adressbereiche.

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.

Hinweis: Administratoren für freigegebene VPC sind für das Erstellen von Firewallregeln im freigegebenen VPC-Netzwerk zuständig.

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

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

   Zur Firewall

2. Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.

3. Klicken Sie im Menü VPC-Netzwerk auf Firewallregel erstellen.

4. Geben Sie für Name my-shared-net-rule ein.

5. Wählen Sie für Netzwerk den Eintrag shared-net aus.

6. Wählen Sie für Traffic-Richtung die Option Eingehend aus.

7. Wählen Sie für Aktion bei Übereinstimmung die Option Zulassen aus.

8. Wählen Sie für Ziele die Option Alle Instanzen im Netzwerk aus.

9. Wählen Sie für Quellfilter die Option IP ranges aus.

10. Geben Sie für Quell-IP-Bereiche 0.0.0.0/0 ein.

11. Wählen Sie für Protokolle und Ports die Option Angegebene Protokolle und Ports aus. Geben Sie tcp:22 in das Feld ein.

12. 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

Über SSH eine Verbindung zu einem Knoten 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

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Wählen Sie in der Projektauswahl Ihr erstes Dienstprojekt aus.

3. Klicken Sie auf tier-1-cluster.

4. Klicken Sie auf der Seite Clusterdetails auf den Tab Knoten.

5. Klicken Sie unter Knotenpools auf den Namen Ihres Knotenpools.

6. Klicken Sie unter Instanzgruppen auf den Namen Ihrer Instanzgruppe. Beispiel: gke-tier-1-cluster-default-pool-faf87d48-grp.

7. 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.

8. 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 aktualisieren, um Traffic zwischen Knoten zuzulassen

1. Starten Sie in Ihrem SSH-Befehlszeilenfenster die CoreOS Toolbox:

   /usr/bin/toolbox
   

2. 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.

3. 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.

4. 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
   

5. Pingen Sie den Knoten in Ihrer Toolbox-Shell noch einmal. Beispiel:

   ping 172.16.4.3
   

   Diesmal ist der Befehl ping erfolgreich.

Weitere 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 Firewallressourcen 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.

Cluster auf Grundlage von VPC-Netzwerk-Peering in einer freigegebene VPC erstellen

Sie können freigegebene VPC mit Clustern verwenden, die auf VPC-Netzwerk-Peering basieren.

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.

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

Console

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf Erstellen.

3. Klicken Sie im Abschnitt "Autopilot" oder "Standard" auf Konfigurieren.

4. Geben Sie für Name cluster-vpc ein.

5. Klicken Sie im Navigationsbereich auf Netzwerk.

6. Klicken Sie im Bereich Clusternetzwerk das Kästchen Private Knoten aktivieren an.

7. (Optional für Autopilot): Setzen Sie IP-Bereich der Steuerungsebene auf 172.16.0.16/28.

8. Wählen Sie in der Drop-down-Liste Netzwerk das zuvor erstellte VPC-Netzwerk aus.

9. Wählen Sie in der Drop-down-Liste Knotensubnetz das zuvor erstellte freigegebene Subnetz aus.

10. Konfigurieren Sie den Cluster nach Bedarf.

11. Klicken Sie auf Erstellen.

gcloud

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

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --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

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Wählen Sie in der Projektauswahl Ihr erstes Dienstprojekt aus.

3. Wählen Sie tier-1-cluster aus und klicken Sie auf Löschen.

4. Wählen Sie in der Projektauswahl Ihr zweites Dienstprojekt aus.

5. 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 \
    --location CONTROL_PLANE_LOCATION

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --location CONTROL_PLANE_LOCATION

Freigegebene VPC deaktivieren

Deaktivieren Sie die freigegebene VPC im Hostprojekt.

Console

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

   Zu Shared VPC gehen

2. Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.

3. Klicken Sie auf Freigegebene VPC deaktivieren.

4. 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

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

   Zur Firewall

2. Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.

3. Wählen Sie in der Liste der Regeln my-shared-net-rule, my-shared-net-rule-2 und my-shared-net-rule-3 aus.

4. 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

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

   Zur Seite VPC-Netzwerke

2. Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.

3. Klicken Sie in der Liste der Netzwerke auf den Link shared-net.

4. 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

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

   IAM aufrufen

2. Wählen Sie in der Projektauswahl Ihr Hostprojekt aus.

3. Wählen Sie Von Google bereitgestellte Rollenzuweisungen einschließen aus.

4. Wählen Sie in der Mitgliederliste die Zeile aus, in der angezeigt wird, dass [e-mail] die Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ zugewiesen ist.

5. Klicken Sie auf  Hauptkonto bearbeiten.

6. Klicken Sie unter Nutzer des Dienst-Agents für Kubernetes Engine-Host auf das Symbol , um die Rolle zu entfernen.

7. Klicken Sie auf Speichern.

8. Wählen Sie die Zeile aus, in der angezeigt wird, dass [e-mail] die Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ zugewiesen ist.

9. Klicken Sie auf  Hauptkonto bearbeiten.

10. Klicken Sie unter Nutzer des Dienst-Agents für Kubernetes Engine-Host auf das Symbol , um die Rolle zu entfernen.

11. Klicken Sie auf Speichern.

gcloud

1. 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:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. 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:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

Fehlerbehebung

In den folgenden Abschnitten erfahren Sie, wie Sie häufige Probleme mit Clustern mit freigegebene VPC beheben können.

Fehler: Metadaten konnten nicht aus dem Netzwerkprojekt abgerufen werden

Die folgende Meldung ist ein häufiger Fehler bei der Arbeit mit freigegebene VPC-Clustern:

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

Dieser Fehler kann folgende Ursachen haben:

• Die GKE 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".

Prüfen Sie, ob das GKE-Dienstkonto des Hostprojekts vorhanden ist, um das Problem zu beheben.

Wenn das Dienstkonto nicht vorhanden ist, gehen Sie so vor:

• Aktivieren Sie die GKE 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 GKE 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 GKE API deaktivieren und dann wieder aktivieren. Weitere Informationen finden Sie unter Fehler 400/403: Dem Konto fehlen Bearbeitungsberechtigungen.

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

Problem: Verbindung

Wenn Sie Verbindungsprobleme zwischen Compute Engine-VMs haben, die sich im selben VPC-Netzwerk (Virtual Private Cloud) oder in zwei VPC-Netzwerken befinden, die mit VPC-Netzwerk-Peering verbunden sind, lesen Sie den Abschnitt Verbindungsprobleme zwischen VM-Instanzen mit internen IP-Adressen beheben in der VPC-Dokumentation.

Problem: Paketverlust

Wenn Paketverluste beim Senden von Traffic von einem Cluster an eine externe IP-Adresse mit Cloud NAT, VPC-nativen Clustern oder IP-Masquerade-Agent auftreten, finden Sie Informationen unter Fehlerbehebung bei Cloud NAT-Paketverlusten aus einem Cluster.

Nächste Schritte

• Freigegebene VPC – Übersicht
• Freigegebene VPC bereitstellen
• GKE-Netzwerkübersicht
• Automatisch erstellte Firewallregeln
• Fehlerbehebung für die Konnektivität zwischen VM-Instanzen mit internen IP-Adressen