Dies ist der erste Teil eines Leitfadens, der Sie durch eine kleine Proof-of-Concept-Installation von Google Distributed Cloud (nur Software) für VMware mit einem einzelnen Nutzercluster führt. Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die technische Infrastrukturen einrichten, überwachen und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.
In diesem Dokument erfahren Sie, wie Sie minimale vSphere- und Google Cloud-Umgebungen für diese Installation einrichten und Ihre IP-Adressen planen. Im nachfolgenden Abschnitt Einfache Cluster erstellen erfahren Sie, wie Sie eine Administrator-Workstation, einen Administratorcluster und einen Nutzercluster erstellen.
Die Infrastruktur, die Sie mit dieser Anleitung einrichten, ist möglicherweise nicht für Ihre tatsächlichen Produktionsanforderungen und Anwendungsfälle geeignet. Weitere Informationen zu Produktionsinstallationen finden Sie in der Installationsübersicht und in den Anleitungen.
Vorbereitung
Lesen Sie den Artikel Google Distributed Cloud (nur Software) für VMware. Darin finden Sie eine Übersicht über alle Komponenten, die Sie in dieser Einrichtung installieren.
Weitere Informationen finden Sie unter vSphere-Lizenzanforderungen. Für diese minimale Installation ist eine vSphere Standard-Lizenz ausreichend.
Sie benötigen eine laufende Instanz von vCenter Server.
Sie benötigen ein vCenter-Nutzerkonto mit ausreichenden Berechtigungen. Notieren Sie sich den Nutzernamen und das Passwort für dieses Konto.
Sie sollten mit einigen grundlegenden Google Cloud-Konzepten vertraut sein, einschließlich Projekten, IAM-Berechtigungen und Dienstkonten. Falls nicht, finden Sie in den folgenden Leitfäden weitere Informationen:
Verfahrensübersicht
Dies sind die wichtigsten Schritte für diese Einrichtung:
- Richten Sie die Umgebung ein. Sie müssen die Ressourcenanforderungen erfüllen. Wir stellen Beispielkonfigurationen für einen ESXi-Host und einen vSphere-Datenspeicher bereit, die die Anforderungen für diese Installation erfüllen.
- vSphere-Objekte einrichten. Google Distributed Cloud-Komponenten werden in einer vSphere-Objekthierarchie ausgeführt.
- IP-Adressen planen. Für Google Distributed Cloud müssen Sie neben virtuellen IP-Adressen (VIPs) für den Administrator- und Nutzerzugriff auf Ihre Bereitstellung auch IP-Adressen für alle Knoten angeben. In dieser Einrichtung verwenden Sie statische IP-Adressen für Ihre Clusterknoten. Wir stellen Beispiele zur Verfügung. Wir empfehlen Ihnen jedoch, sich an Ihren Netzwerkadministrator zu wenden, um geeignete Adressen für Ihr eigenes Netzwerk auszuwählen.
- Firewall- und Proxyregeln konfigurieren
- Google Cloud-Ressourcen einrichten, einschließlich eines Google Cloud-Projekts, das Sie beim Einrichten und Verwalten von Google Distributed Cloud verwenden, und eines Dienstkontos mit den erforderlichen Berechtigungen für den Zugriff auf und den Download der Software der Google Distributed Cloud-Komponenten.
1. Umgebung einrichten
Für diese minimale Installation können Sie einen einzelnen physischen Host verwenden, auf dem ESXi ausgeführt wird.
Ihr Host muss die folgenden Mindestanforderungen an CPU, RAM und Speicherkapazität erfüllen:
- 8 physische CPUs bei 2,7 GHz mit aktiviertem Hyperthreading
- 80 Gibibyte (GiB) RAM
- 470 GiB Speicher
ESXi 7.0u2 oder höher muss installiert sein.
Sie müssen vCenter Server Version 7.0u2 oder höher verwenden.
Beispiel für Host und Datenspeicher
Hier sehen Sie ein Beispiel für einen ESXi-Host und einen vSphere-Datenspeicher, die die Anforderungen erfüllen:
ESXi-Host-Konfiguration:
- Hersteller: Dell Inc.
- Physische CPUs: 8 CPUs bei 2,7 GHz
- Prozessortyp: Intel(R) Xeon(R) Platinum 8168 CPU @ 2,70 GHz
- Prozessor-Sockets: 2
- ESXi-Version: 7.0u2 oder höher
- vCenter Server-Version: 7.0u2 oder höher
- Hyperthreading: aktiviert
Datastore-Konfiguration:
- Typ: VMFS 6.82
- Laufwerkstyp: SSD
- Anbieter: DELL
- Laufwerkstyp: logisch
- RAID-Level: RAID1
2. vSphere-Objekte einrichten
Richten Sie in der vSphere-Umgebung die folgenden Objekte ein:
Notieren Sie sich die Namen Ihres vSphere-Rechenzentrums, ‑Clusters, ‑Datenspeichers und ‑Netzwerks. Sie benötigen diese, wenn Sie Ihre Administrator-Workstation unter Grundlegende Cluster erstellen einrichten.
Wenn Sie einen vSAN-Datenspeicher eingerichtet haben, erstellen Sie mit govc einen Ordner im Verzeichnis datastore, der für das VMDK (Virtual Machine Disk) von Google Distributed Cloud verwendet werden soll:
govc datastore.mkdir -namespace=true data-disks
3. IP-Adressen planen
Wie Sie in der Übersicht zu Google Distributed Cloud gesehen haben, sind für eine Google Distributed Cloud-Installation mehrere IP-Adressen erforderlich, darunter:
- IP-Adressen für alle Knoten
- Virtuelle IP-Adressen (VIPs) für den Zugriff auf Steuerungsebenenkomponenten wie Kubernetes API-Server und Anwendungen, die in Ihren Nutzerclustern ausgeführt werden
- CIDR-Bereiche für die Kommunikation zwischen Pods und Diensten
Daher ist die Planung Ihrer IP-Adressen ein wichtiger Teil der Einrichtung von Google Distributed Cloud. Achten Sie dabei darauf, dass keine Adresskonflikte auftreten. Möglicherweise benötigen Sie die Hilfe Ihres Netzwerkadministrators, um geeignete Werte für die Konfiguration zu finden, auch für diese einfache Installation. Im Rest dieses Abschnitts finden Sie anschauliche Beispiele für Werte, die für diese Installation in einem hypothetischen Netzwerk funktionieren – Ihre Werte werden anders lauten.
Die Cluster in dieser minimalen Installation verwenden den Load Balancer MetalLB. Dieser Load-Balancer wird auf den Clusterknoten ausgeführt, sodass keine zusätzlichen VMs für das Load-Balancing erforderlich sind
In Google Distributed Cloud können Sie zwischen der Angabe von statischen IP-Adressen für Ihre Clusterknoten oder der Verwendung eines DHCP-Servers wählen. Bei dieser einfachen Installation verwenden Sie statische IP-Adressen.
Beispiel-VLAN
Für diese kleine Installation empfehlen wir, dass sich Ihre Administrator-Workstation, Ihre Administratorclusterknoten und die Nutzerclusterknoten in demselben VLAN in Ihrem vSphere-Netzwerk befinden. Angenommen, alle IP-Adressen im Bereich 172.16.20.0/24 werden an ein bestimmtes VLAN weitergeleitet. Nehmen wir außerdem an, dass Ihr Netzwerkadministrator sagt, dass Sie für VMs und virtuelle IP-Adressen (VIPs) 172.16.20.49 bis 172.16.20.69 verwenden können.
Das folgende Diagramm zeigt ein VLAN mit einer Administrator-Workstation, einem Administratorcluster und einem Nutzercluster. Beachten Sie, dass VIPs nicht in Verbindung mit einem bestimmten Knoten in einem Cluster angezeigt werden. Das liegt daran, dass der MetalLB-Load-Balancer wählen kann, welcher Knoten das VIP für einen einzelnen Dienst ankündigt. Im Nutzercluster könnte beispielsweise ein Worker-Knoten 172.16.20.64 und ein anderer Worker-Knoten 172.16.20.65 ankündigen.
Beispiel-IP-Adresse: Administrator-Workstation
Für die Administrator-Workstation verwendet dieses Beispiel die erste Adresse in dem Bereich, der Ihnen von Ihrem Netzwerkadministrator zugewiesen wird: 172.16.20.49.
Beispiel-IP-Adressen: Clusterknoten
Die folgende Tabelle enthält ein Beispiel für die Verwendung von IP-Adressen für Clusterknoten. Die Tabelle enthält Adressen für zwei zusätzliche Knoten: admin-vm-6 und user-vm-5. Die zusätzlichen Knoten werden während Cluster-Upgrades, Aktualisierungen und automatischen Reparaturen benötigt. Weitere Informationen finden Sie unter Knoten-IP-Adressen verwalten.
| VM-Hostname | Beschreibung | IP-Adresse |
|---|---|---|
| admin-vm-1 | Knoten der Steuerungsebene für den Administratorcluster | 172.16.20.50 |
| admin-vm-2 | Knoten der Steuerungsebene für den Administratorcluster | 172.16.20.51 |
| admin-vm-3 | Knoten der Steuerungsebene für den Administratorcluster | 172.16.20.52 |
| user-vm-1 | Knoten der Steuerungsebene für den Nutzercluster | 172.16.20.53 |
| user-vm-2 | Worker-Knoten des Nutzerclusters | 172.16.20.54 |
| user-vm-3 | Worker-Knoten des Nutzerclusters | 172.16.20.55 |
| user-vm-4 | Worker-Knoten des Nutzerclusters | 172.16.20.56 |
| user-vm-5 | 172.16.20.57 |
Beispiel-IP-Adressen: VIP für den Administratorcluster
Die folgende Tabelle enthält ein Beispiel dafür, wie Sie eine VIP der Steuerungsebene für Ihren Administratorcluster angeben können.
| VIP | Beschreibung | IP-Adresse |
|---|---|---|
| VIP für den Kubernetes API-Server des Administratorclusters | Auf dem Load Balancer für den Administratorcluster konfiguriert. | 172.16.20.58 |
Beispiel-IP-Adressen: VIPs für den Nutzercluster
Die folgende Tabelle enthält ein Beispiel dafür, wie Sie VIPs für Ihren Nutzercluster angeben können.
Beachten Sie, dass sich die VIP für den Kubernetes API-Server des Nutzerclusters und die VIP für den eingehenden Traffic beide im selben VLAN wie die Worker-Knoten und die Knoten der Steuerungsebene befinden.
| VIP | Beschreibung | IP-Adresse |
|---|---|---|
| VIP für den Kubernetes API-Server des Nutzerclusters | Auf dem Load Balancer für den Administratorcluster konfiguriert. | 172.16.20.59 |
| Ingress-VIP | Auf dem Load Balancer für den Nutzercluster konfiguriert. | 172.16.20.60 |
| Dienst-VIPs | Zehn Adressen für Dienste vom Typ LoadBalancer.Nach Bedarf auf dem Load-Balancer für den Nutzercluster konfiguriert. Beachten Sie, dass dieser Bereich die Ingress-VIP enthält. Dies ist eine Anforderung für den MetalLB-Load Balancer. |
172.16.20.60 - 172.16.20.69 |
IP-Adressen für Pods und Dienste
Zusätzlich zu den IP-Adressen für Ihre Clusterknoten und für den Zugriff auf Ihre Bereitstellung müssen Sie auch die Adressbereiche angeben, die innerhalb jedes Clusters für den Traffic innerhalb des Clusters verwendet werden können.
Dazu geben Sie einen CIDR-Bereich an, der für Pod-IP-Adressen verwendet werden soll, und einen weiteren CIDR-Bereich, der für die ClusterIP-Adressen von Kubernetes-Diensten verwendet wird. Diese werden im Rahmen der Clusterkonfiguration angegeben, wie im nächsten Teil dieser Anleitung dargestellt.
Entscheiden Sie im Rahmen der IP-Planung, welche CIDR-Bereiche Sie für Pods und Dienste verwenden möchten. Wenn Sie keinen anderen Grund haben, verwenden Sie die folgenden Standardbereiche:
| Zweck | CIDR-Standardbereich |
|---|---|
| Administratorcluster-Pods | 192.168.0.0/16 |
| Nutzercluster-Pods | 192.168.0.0/16 |
| Dienste des Administratorclusters | 10.96.232.0/24 |
| Nutzercluster-Dienste | 10.96.0.0/20 |
Die Standardwerte veranschaulichen diese Punkte:
Der Pod-CIDR-Bereich kann für mehrere Cluster identisch sein.
Der Dienst-CIDR-Bereich eines Clusters darf sich nicht mit dem Dienst-CIDR-Bereich eines anderen Clusters überschneiden.
In der Regel benötigen Sie mehr Pods als Dienste. Daher benötigen Sie für einen bestimmten Cluster wahrscheinlich einen Pod-CIDR-Bereich, der größer als der Dienst-CIDR-Bereich ist. Der Standard-Pod-Bereich für einen Nutzercluster hat beispielsweise 2^(32-16) = 2^16 Adressen, der Standarddienstbereich für einen Nutzercluster jedoch nur 2^(32-20) = 2^12 Adressen.
Überlappung vermeiden
In einigen Fällen müssen Sie möglicherweise nicht standardmäßige CIDR-Bereiche verwenden, um eine Überschneidung mit IP-Adressen zu vermeiden, die in Ihrem Netzwerk erreichbar sind. Die Dienst- und Pod-Bereiche dürfen sich nicht mit einer Adresse außerhalb des Clusters überschneiden, die Sie von innerhalb des Clusters erreichen möchten.
Angenommen, der Dienstbereich lautet 10.96.232.0/24 und der Pod-Bereich lautet 192.168.0.0/16. Traffic, der von einem Pod an eine Adresse in einem dieser Bereiche gesendet wird, wird als clusterintern behandelt und erreicht kein Ziel außerhalb des Clusters.
Insbesondere dürfen sich die Bereiche für Dienste und Pods nicht überschneiden mit:
IP-Adressen von Knoten in einem beliebigen Cluster
Von Load-Balancer-Maschinen verwendete IP-Adressen
Von Knoten der Steuerungsebene und Load-Balancern verwendete VIPs
IP-Adresse von vCenter-Servern, DNS-Servern und NTP-Servern
Wir empfehlen, die von RFC 1918 definierten internen IP-Adressbereiche für Ihre Pod- und Dienstbereiche zu verwenden.
Dies ist ein Grund für die Empfehlung, RFC 1918-Adressen zu verwenden. Angenommen, Ihr Pod- oder Dienstbereich enthält externe IP-Adressen. Traffic von einem Pod an eine dieser externen Adressen wird als clusterinterner Traffic behandelt und erreicht das externe Ziel nicht.
DNS-Server und Standardgateway
Bevor Sie Ihre Administrator- und Nutzercluster erstellen, müssen Sie auch die IP-Adressen der folgenden Elemente kennen:
Einen DNS-Server, der von Ihrer Administrator-Workstation und Clusterknoten verwendet werden kann
Einen NTP-Server, der von Ihren Clusterknoten verwendet werden kann
Die IP-Adresse des Standardgateways für das Subnetz mit Ihrer Administrator-Workstation und Clusterknoten. Angenommen, Ihre Administrator-Workstation, Administratorclusterknoten und Nutzerclusterknoten befinden sich alle im Subnetz 172.16.20.0/24. Die Adresse des Standardgateways für das Subnetz kann 172.16.20.1 sein.
4. Firewall und Proxy konfigurieren
Konfigurieren Sie Ihre Firewall und Ihren Proxy gemäß den Proxy- und Firewallregeln, um den erforderlichen Traffic für Google Distributed Cloud zuzulassen. Sie benötigen die IP-Adressen der Clusterknoten, die Sie im vorherigen Abschnitt ermittelt haben, um diese Aufgabe auszuführen. Da die IP-Adressen für Nutzer- und Administratorcluster keinen bestimmten Knoten zugewiesen sind, müssen Sie dafür sorgen, dass alle relevanten Firewallregeln für alle IP-Adressen für jeden Cluster gelten.
5. Google Cloud-Ressourcen einrichten
Google Cloud-Projekte bilden die Grundlage zum Erstellen, Aktivieren und Verwenden aller Google Cloud-Dienste, einschließlich derjenigen, die zum Installieren und Verwalten von Google Distributed Cloud verwendet werden. Wenn Sie mit Google Cloud-Projekten noch nicht vertraut sind, finden Sie unter Projekte erstellen und verwalten weitere Informationen.
Wählen Sie ein vorhandenes Google Cloud-Projekt aus oder erstellen Sie ein neues.
Notieren Sie sich die Google Cloud-Projekt-ID, da sie später benötigt wird.
Google Cloud CLI einrichten
Die Google Cloud CLI ist ein Befehlszeilentool, mit dem Sie Ihr Projekt bearbeiten können. Folgen Sie der Anleitung unter Google Cloud SDK installieren, um sicherzustellen, dass Sie die neueste Version verwenden.
Erforderliche Berechtigungen
Wenn Sie der Projektinhaber sind (z. B. wenn Sie das Projekt selbst erstellt haben), haben Sie bereits alle erforderlichen Berechtigungen, um den Rest dieser einfachen Installation auszuführen. Wenn Sie nicht der Projektinhaber sind, müssen Sie oder Ihr Projektadministrator dafür sorgen, dass Ihr Google-Konto die erforderlichen Berechtigungen hat.
Mit den folgenden IAM-Rollen können Sie ein Dienstkonto erstellen, ihm IAM-Rollen zuweisen, APIs aktivieren und dafür sorgen, dass das gkeadm-Tool im zweiten Teil dieser Einrichtung Dienstkonten für Sie erstellen und verwalten kann:
resourcemanager.projectIamAdminserviceusage.serviceUsageAdminiam.serviceAccountCreatoriam.serviceAccountKeyAdmin
Weitere Informationen zu den Berechtigungen, die zum Zuweisen von IAM-Rollen erforderlich sind, finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen. Wenn Sie diese Berechtigungen nicht haben, muss eine andere Person in Ihrer Organisation Ihnen die Rollen zuweisen.
So weisen Sie die Rollen zu:
Linux und macOS
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountKeyAdmin"
Windows
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountKeyAdmin"
Ersetzen Sie Folgendes:
PROJECT_IDist die ID Ihres Google Cloud-ProjektsACCOUNT: die E-Mail-Adresse zur Identifizierung für Ihr Google-Konto
Dienstkonten einrichten
Ihr Google Cloud-Projekt muss vier Dienstkonten haben, die von Google Distributed Cloud verwendet werden können. In dieser Übung werden zwei dieser Dienstkonten automatisch für Sie generiert. Die anderen beiden Dienstkonten müssen Sie jedoch manuell erstellen:
- Connect-Register-Dienstkonto (automatisch generiert)
- Logging-Monitoring-Dienstkonto (automatisch generiert)
- Audit-Logging-Dienstkonto (manuell erstellen)
- Dienstkonto für den Komponentenzugriff (manuell erstellen)
Audit-Logging-Dienstkonto
Erstellen Sie in Ihrem Google Cloud-Projekt ein Dienstkonto, mit dem Google Distributed Cloud Kubernetes-Audit-Logs von Ihrem Cluster an Cloud-Audit-Logs senden kann. Dieses Konto wird als Audit-Logging-Dienstkonto bezeichnet.
gcloud iam service-accounts create audit-logging-sa \ --display-name "Audit Logging Service Account" \ --project PROJECT_IDErsetzen Sie
PROJECT_IDdurch die ID Ihres Google Cloud-Projekts.Rufen Sie die E-Mail-Adresse des neu erstellten Audit-Logging-Dienstkontos ab:
gcloud iam service-accounts list \ --project PROJECT_IDErstellen Sie einen JSON-Schlüssel für Ihr Audit-Logging-Dienstkonto:
gcloud iam service-accounts keys create audit-logging-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGINGErsetzen Sie
SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGINGdurch die E-Mail-Adresse Ihres Audit-Logging-Dienstkontos.Sie müssen Ihrem Audit-Logging-Dienstkonto keine Rollen zuweisen.
Komponenten-Zugriff-Dienstkonto
Erstellen Sie in Ihrem Google Cloud-Projekt ein Dienstkonto, mit dem Google Distributed Cloud Clusterkomponentencode in Ihrem Namen aus Container Registry herunterladen kann. Dies wird als Dienstkonto für den Komponentenzugriff bezeichnet:
gcloud iam service-accounts create component-access-sa \ --display-name "Component Access Service Account" \ --project PROJECT_IDErsetzen Sie
PROJECT_IDdurch die ID Ihres Google Cloud-Projekts.Rufen Sie die E-Mail-Adresse des neu erstellten Dienstkontos für den Komponentenzugriff ab:
gcloud iam service-accounts list \ --project PROJECT_IDErstellen Sie einen JSON-Schlüssel für das Dienstkonto für den Komponentenzugriff:
gcloud iam service-accounts keys create component-access-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS
Ersetzen Sie
SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESSdurch die E-Mail-Adresse des Dienstkontos für den Komponentenzugriff.Fügen Sie Ihrem Dienstkonto für den Komponentenzugriff die folgenden IAM-Rollen hinzu:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --role "roles/serviceusage.serviceUsageViewer" gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --role "roles/iam.roleViewer" gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --role "roles/iam.serviceAccountViewer"
Google APIs aktivieren
Aktivieren Sie die folgenden Google APIs in Ihrem Google Cloud-Projekt: So können Sie alle Google Cloud-Dienste verwenden, die für Google Distributed Cloud in Ihrem Projekt erforderlich sind.
gcloud services enable --project PROJECT_ID \ anthos.googleapis.com \ anthosgke.googleapis.com \ anthosaudit.googleapis.com \ cloudresourcemanager.googleapis.com \ connectgateway.googleapis.com \ container.googleapis.com \ gkeconnect.googleapis.com \ gkehub.googleapis.com \ gkeonprem.googleapis.com \ kubernetesmetadata.googleapis.com \ serviceusage.googleapis.com \ stackdriver.googleapis.com \ opsconfigmonitoring.googleapis.com \ monitoring.googleapis.com \ logging.googleapis.com \ iam.googleapis.com \ storage.googleapis.comWenn Sie die GKE On-Prem API (
gkeonprem.googleapis.com) zum ersten Mal in Ihrem Projekt aktivieren, müssen Sie die API initialisieren. Dazu können Sie einen gcloud CLI-Befehl aufrufen, mit dem die verfügbaren Versionen angezeigt werden, mit denen Sie einen Nutzercluster erstellen können:gcloud container vmware clusters query-version-config \ --project=PROJECT_ID \ --location="us-central1"Nächste Schritte