Minimale Infrastruktur einrichten

Dies ist der erste Teil einer Anleitung, die Sie durch eine kleine Proof-of-Concept-Installation von Google Distributed Cloud mit einem einzelnen Nutzercluster führt.

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 Administratorworkstation, einen Administratorcluster und einen Nutzercluster erstellen.

Die Infrastruktur, die Sie mit diesem Leitfaden 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 Leitfäden.

Hinweise

Verfahrensübersicht

Dies sind die wichtigsten Schritte bei dieser Einrichtung:

  1. Richten Sie die Umgebung ein. Achten Sie darauf, dass Sie die Ressourcenanforderungen erfüllen können. Wir stellen eine Beispielkonfiguration für einen ESXi-Host und einen vSphere-Datenspeicher bereit, die die Anforderungen für diese Installation erfüllen.
  2. vSphere-Objekte einrichten Google Distributed Cloud-Komponenten werden in einer vSphere-Objekthierarchie ausgeführt.
  3. Planen Sie Ihre IP-Adressen. Bei Google Distributed Cloud müssen Sie zusätzlich zu virtuellen IP-Adressen (VIPs) IP-Adressen für alle Knoten für den Administrator- und Nutzerzugriff auf Ihre Bereitstellung angeben. Bei dieser Einrichtung verwenden Sie statische IP-Adressen für Ihre Clusterknoten. Wir geben Ihnen Beispiele, empfehlen Ihnen jedoch, sich bei der Auswahl geeigneter Adressen für Ihr Netzwerk von Ihrem Netzwerkadministrator beraten zu lassen.
  4. Firewall- und Proxy-Regeln konfigurieren
  5. Richten Sie Google Cloud-Ressourcen ein, darunter ein Google Cloud-Projekt, das Sie zum Einrichten und Verwalten von Google Distributed Cloud verwenden, und ein Dienstkonto mit den erforderlichen Berechtigungen für den Zugriff und das Herunterladen der Komponentensoftware von Google Distributed Cloud.

1. Umgebung einrichten

Für diese minimale Installation können Sie einen einzelnen physischen Host verwenden, auf dem ESXi ausgeführt wird.

  1. Achten Sie darauf, dass Ihr Host die folgenden Mindest-CPU-, RAM- und Speicherkapazitäten hat:

    • 8 physische CPUs mit 2,7-GHz-Hyperthreading aktiviert
    • 80  Gibibyte (GiB) RAM
    • 470 GiB Speicher

  2. Stellen Sie sicher, dass Sie die ESXi-Version 7.0u2 oder höher installiert haben.

  3. Achten Sie darauf, dass Sie 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, Ihres Clusters, Ihres Datenspeichers und Ihres Netzwerks, da Sie diese bei der Einrichtung Ihrer Administratorworkstation unter Einfache Cluster erstellen benötigen.

Wenn Sie einen vSAN-Datenspeicher eingerichtet haben, erstellen Sie mit govc im Verzeichnis datastore einen Ordner, der für das VM-Laufwerk (VMDK) von GKE on VMware 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, erfordert eine Google Distributed Cloud-Installation eine Reihe von IP-Adressen, darunter:

  • IP-Adressen für alle Knoten
  • Virtuelle IP-Adressen (VIPs) für den Zugriff auf Komponenten der Steuerungsebene wie Kubernetes API-Server und auf Anwendungen, die auf Ihren Nutzerclustern ausgeführt werden
  • CIDR-Bereiche für die Kommunikation zwischen Pods und Diensten

Aus diesem Grund ist ein wichtiger Bestandteil der Einrichtung von Google Distributed Cloud die Planung Ihrer IP-Adressen. Dabei wird unter anderem darauf geachtet, dass es keine Adresskonflikte gibt. Auch bei dieser einfachen Installation kann es sein, dass Ihr Netzwerkadministrator Ihnen dabei hilft, geeignete Werte für die Konfiguration zu finden. 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 sein.

  • Die Cluster in dieser Mindestinstallation verwenden den gebündelten MetalLB-Load-Balancer. Dieser Load-Balancer wird auf den Clusterknoten ausgeführt, sodass keine zusätzlichen VMs für das Load-Balancing erforderlich sind

  • Mit Google Distributed Cloud können Sie zwischen der Bereitstellung statischer 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. Angenommen, Ihr Netzwerkadministrator gibt an, dass Sie 172.16.20.49 bis 172.16.20.69 für VMs und virtuelle IP-Adressen (VIPs) verwenden können.

Das folgende Diagramm zeigt ein VLAN mit einer Administrator-Workstation, einem Administratorcluster und einem Nutzercluster. VIPs werden nicht mit einem bestimmten Knoten in einem Cluster verknüpft. 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.

IP-Adressen für einen Administrator- und einen Nutzercluster.
IP-Adressen für einen Administrator- und einen Nutzercluster (zum Vergrößern klicken)

Beispiel-IP-Adresse: Administrator-Workstation

Für die Administrator-Workstation wird in diesem Beispiel die erste Adresse in dem Bereich verwendet, den Sie von Ihrem Netzwerkadministrator erhalten haben: 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. Beachten Sie, dass die Tabelle Adressen für zwei zusätzliche Knoten enthält: admin-vm-6 und user-vm-5. Die zusätzlichen Knoten werden während Clusterupgrades, Updates und automatischer Reparatur 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
Nutzer-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 virtuelle IP-Adresse für den Kubernetes API-Server des Nutzerclusters und die virtuelle IP-Adresse für eingehenden Traffic 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
Virtuelle IP-Adresse für eingehenden Traffic 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 in jedem Cluster für Traffic im Cluster verwendet werden können.

Dazu geben Sie einen CIDR-Bereich für Pod-IP-Adressen und einen weiteren CIDR-Bereich für die ClusterIP-Adressen von Kubernetes-Diensten an. Diese werden im Rahmen der Clusterkonfiguration angegeben, wie im nächsten Teil dieser Anleitung beschrieben wird.

Entscheiden Sie im Rahmen der IP-Planung, welche CIDR-Bereiche Sie für Pods und Dienste verwenden möchten. Sofern Sie keinen Grund haben, etwas anderes zu tun, verwenden Sie die folgenden Standardbereiche:

ZweckCIDR-Standardbereich
Administratorcluster-Pods192.168.0.0/16
Nutzercluster-Pods192.168.0.0/16
Dienste des Administratorclusters10.96.232.0/24
Nutzercluster-Dienste10.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.

  • Normalerweise benötigen Sie mehr Pods als Dienste. Daher sollten Sie für einen bestimmten Cluster wahrscheinlich einen Pod-CIDR-Bereich verwenden, 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, aber der Standard-Dienstbereich für einen Nutzercluster hat 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 Überschneidungen 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. Der gesamte 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, für Ihre Pod- und Dienstbereiche die durch RFC 1918 definierten internen IP-Adressbereiche 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. Der gesamte Traffic, der von einem Pod an eine dieser externen Adressen gesendet wird, wird als clusterinterner Traffic behandelt und erreicht nicht das externe Ziel.

DNS-Server und Standardgateway

Bevor Sie Ihre Administrator- und Nutzercluster erstellen, müssen Sie auch die IP-Adressen von Folgendem kennen:

  • Einen DNS-Server, der von Ihrer Administrator-Workstation und Clusterknoten verwendet werden kann

  • Ein 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, um den erforderlichen Google Distributed Cloud-Traffic gemäß den Proxy- und Firewallregeln 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 nicht 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 der Dienste, die zur Installation und Verwaltung von Google Distributed Cloud verwendet werden. Wenn Sie mit der Arbeit mit Google Cloud-Projekten nicht vertraut sind, finden Sie weitere Informationen unter Projekte erstellen und verwalten.

  1. Wählen Sie ein vorhandenes Google Cloud-Projekt aus oder erstellen Sie ein neues.

  2. 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 mit Ihrem Projekt arbeiten können. Folgen Sie der Anleitung unter Google Cloud SDK installieren, um sicherzustellen, dass Sie über die neueste Version verfügen.

Erforderliche Berechtigungen

Wenn Sie der Projektinhaber sind (z. B. wenn Sie das Projekt selbst erstellt haben), verfügen Sie bereits über alle Berechtigungen, die für diese einfache Installation erforderlich sind. Wenn Sie nicht der Projektinhaber sind, müssen Sie oder Ihr Projektadministrator sicherstellen, dass Ihr Google-Konto über die erforderlichen Berechtigungen verfügt.

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.projectIamAdmin
  • serviceusage.serviceUsageAdmin
  • iam.serviceAccountCreator
  • iam.serviceAccountKeyAdmin

Ausführliche Informationen zu den Berechtigungen, die zum Zuweisen von IAM-Rollen selbst erforderlich sind, finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen. Wenn Sie diese Berechtigungen nicht haben, muss Ihnen eine andere Person in Ihrer Organisation 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_ID ist die ID Ihres Google Cloud-Projekts
  • ACCOUNT: die E-Mail-Adresse zur Identifizierung Ihres Google-Kontos

Dienstkonten einrichten

Ihr Google Cloud-Projekt muss vier Dienstkonten haben, die Google Distributed Cloud verwenden kann. 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

  1. 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. Dies wird als Audit-Logging-Dienstkonto bezeichnet.

    gcloud iam service-accounts create audit-logging-sa \
    --display-name "Audit Logging Service Account" \
    --project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

  2. Rufen Sie die E-Mail-Adresse des neu erstellten Audit-Logging-Dienstkontos ab:

    gcloud iam service-accounts list \
    --project PROJECT_ID

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

    Ersetzen Sie SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING durch die E-Mail-Adresse Ihres Audit-Logging-Dienstkontos.

    Sie müssen Ihrem Audit-Logging-Dienstkonto keine Rollen zuweisen.

Komponenten-Zugriff-Dienstkonto

  1. Erstellen Sie in Ihrem Google Cloud-Projekt ein Dienstkonto, mit dem Google Distributed Cloud in Ihrem Namen Clusterkomponentencode 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_ID

    Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

  2. Rufen Sie die E-Mail-Adresse des neu erstellten Dienstkontos für den Komponentenzugriff ab:

    gcloud iam service-accounts list \
    --project PROJECT_ID

  3. Erstellen 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_ACCESS durch die E-Mail-Adresse des Dienstkontos für den Komponentenzugriff.

  4. Fügen Sie dem 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

  1. Aktivieren Sie die folgenden Google APIs in Ihrem Google Cloud-Projekt. So können Sie alle Google Cloud-Dienste verwenden, die von Google Distributed Cloud in Ihrem Projekt benötigt werden.

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

  2. Wenn Sie die GKE On-Prem API (gkeonprem.googleapis.com) zum ersten Mal in Ihrem Projekt aktiviert haben, müssen Sie die API initialisieren. Dazu rufen Sie einen gcloud CLI-Befehl auf, der verfügbare Versionen anzeigt, mit denen Sie einen Nutzercluster erstellen können:

    gcloud container vmware clusters query-version-config \
    --project=PROJECT_ID \
    --location="us-central1"

    Nächste Schritte

Einfache Cluster erstellen