Installation vorbereiten

Diese Seite ist der erste Teil einer Anleitung, die Sie durch eine kleine Proof-of-Concept-Installation von Google Distributed Cloud führt. In diesem Dokument erfahren Sie, wie Sie eine minimale Hardwareumgebung einrichten und Ihre IP-Adressen planen. Im nachfolgenden Abschnitt Einfache Cluster erstellen erfahren Sie, wie Sie einen Administrator- 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 unter Bereitstellungsmodell auswählen.

Hinweise

  1. Lesen Sie Informationen zu Google Distributed Cloud.
  2. Machen Sie sich mit einigen grundlegenden Google Cloud-Konzepten wie Projekten, IAM-Berechtigungen und Dienstkonten vertraut.
  3. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

  4. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  5. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  6. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  7. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  8. Notieren Sie sich die Google Cloud-Projekt-ID, da sie später benötigt wird.

Verfahrensübersicht

Die Einrichtung einer minimalen Infrastruktur umfasst die folgenden Hauptschritte:

  1. Administratorworkstation einrichten. Richten Sie eine Linux-Administratorworkstation für lokale Verwaltungsaufgaben ein. Dies kann eine vorhandene oder eine dedizierte Maschine sein, die mehrere Cluster verwalten kann.

  2. Clusterknotenmaschinen einrichten. Richten Sie mindestens drei Maschinen für Knoten ein: einen Knoten des Administratorclusters, einen Knoten der Steuerungsebene des Nutzerclusters und einen Worker-Knoten des Nutzerclusters.

  3. Planen Sie Ihr Netzwerk. Planen Sie die IP-Adressen für Ihre Knotenmaschinen, virtuelle IP-Adressen (VIPs) und Dienst- und Pod-CIDR-Bereiche.

  4. Prüfen Sie die erforderlichen Google Cloud-Ressourcen. Zum Erstellen von Clustern benötigt Ihr Google Cloud-Projekt bestimmte Google APIs und Dienstkonten.

1. Administratorworkstation einrichten

Die Administratorworkstation hostet Tools und Konfigurationsdateien zum Erstellen und Arbeiten mit Ihren Clustern.

Hardwareanforderungen

Die Administratorworkstation benötigt eine erhebliche Rechenleistung, Arbeitsspeicher und Speicher, um Tools auszuführen und die mit der Clustererstellung und -verwaltung verbundenen Ressourcen zu speichern.

Achten Sie darauf, dass Ihre Administrator-Workstation die folgenden Hardwareanforderungen erfüllt:

  • Mindestens 2 CPU-Kerne
  • Mindestens 4 GiB RAM
  • Mindestens 128 GiB Speicher

Betriebssystem und Software konfigurieren

Auf der Administrator-Workstation installieren und konfigurieren Sie Folgendes:

  • Ubuntu konfigurieren

  • gcloud-CLI installieren

  • Installierenkubectl

  • Installierenbmctl

Betriebssystem konfigurieren

Zum Ausführen von bmctl und zum Erstellen eines Clusters hat die Administratorworkstation dieselben Betriebssystemanforderungen wie Knoten. Auf jeder Maschine muss eine unterstützte Version von Ubuntu ausgeführt werden, z. B. Ubuntu 20.04.

Führen Sie die folgenden Befehle aus, um die Firewalleinstellungen zu aktualisieren, Docker zu installieren und zu konfigurieren und dafür zu sorgen, dass jede Maschine die Zeitsynchronisierung verwendet:

  1. Deaktivieren Sie Uncomplicated Firewall (UFW) und überprüfen Sie seinen Status:

    sudo ufw disable
sudo ufw status

  2. Entfernen Sie alle vorherigen Docker-Versionen, aktualisieren Sie den Paketmanager und installieren Sie die neueste Version von Docker:

    sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg-agent \
  software-properties-common \
  docker.io

  3. Prüfen Sie, ob Sie jetzt Version 19.03 oder höher von Docker ausführen:

    sudo docker version

    Sowohl die Client- als auch die Serverversion sollten 19.03 oder höher sein, wie in der folgenden Beispielantwort gezeigt:

    Client:
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.1
 ...

Server:
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.1
  ...

  4. Erstellen Sie die Gruppe docker.

    sudo groupadd docker

  5. Fügen Sie sich selbst der Docker-Gruppe hinzu:

    sudo usermod -aG docker $USER

  6. Führen Sie den folgenden Befehl aus, um die Gruppenänderungen zu aktivieren:

    newgrp docker

  7. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Systemuhr synchronisiert ist:

    timedatectl

    Die Ausgabe von timedatectl sollte den folgenden Status enthalten:

    System clock synchronized: yes

Google Cloud CLI installieren

Um die Google Cloud CLI unter Ubuntu zu installieren, folgen Sie der Anleitung in dieser Installationsanleitung.

Führen Sie auf der Administratorworkstation die folgenden Schritte aus, um die gcloud CLI zu konfigurieren:

  1. Melden Sie sich an, um das Attribut account der gcloud CLI festzulegen:

    gcloud auth login

  2. Legen Sie das Attribut project der gcloud CLI fest:

    gcloud config set project PROJECT_ID

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

  3. Prüfen Sie, ob die Attribute account und project richtig festgelegt sind:

    gcloud config list

    Die Ausgabe zeigt die Werte der Attribute account und project. Beispiel:

    [core]
account = my-name@google.com
disable_usage_reporting = False
project = my-project-1234
Your active configuration is: [default]

kubectl installieren

So installieren Sie kubectl:

  1. Führen Sie auf der Administratorworkstation den folgenden Befehl aus:

    gcloud components install kubectl

bmctl installieren

bmctl ist das proprietäre Befehlszeilentool für Google Distributed Cloud, mit dem Sie Cluster erstellen und verwalten können.

So installieren Sie bmctl auf Ihrer Administratorworkstation:

  1. Erstellen Sie ein baremetal-Verzeichnis und fügen Sie es Ihrem Pfad hinzu. Wenn Sie sich in Ihrem Basisverzeichnis befinden, lauten die Befehle:

    mkdir baremetal
export PATH="$HOME/baremetal:$PATH"

  2. Führen Sie den folgenden Befehl aus, um die neueste Version der Binärdatei bmctl herunterzuladen und ausführbar zu machen:

    gsutil cp gs://anthos-baremetal-release/bmctl/1.29.100-gke.251/linux-amd64/bmctl .
chmod +x ./bmctl

  3. Prüfen Sie, ob bmctl installiert und ausführbar ist:

    bmctl version

    Die Antwort sollte in etwa so aussehen:

    [2023-05-12 17:36:16+0000] bmctl version: 1.14.2-gke.11, git commit: 4ff1347446a93925a079000b50437d4ecebcdf3a, build date: Mon Feb 27 14:07:30 PST 2023

Verbindung

Die Administratorworkstation benötigt Zugriff auf Google Cloud und alle Clusterknoten.

Zugriff auf Google Cloud

Die Administratorworkstation greift auf Google Cloud zu, um Tools und Images herunterzuladen und zu installieren, Autorisierungsanfragen zu verarbeiten, Dienstkonten zu erstellen, Logging und Monitoring zu verwalten und vieles mehr. Ohne Zugriff auf Google Cloud können Sie keine Cluster erstellen.

Zugriff über die Administratorworkstation

Zum Erstellen und Verwalten von Clustern über Ihre Administratorworkstation benötigen Sie den folgenden Zugriff auf die Knotenmaschinen:

  • Es muss eine Ebene-3-Verbindung zu allen Clusterknoten-Rechnern existieren.
  • Zugriff auf die VIP der Steuerungsebene.
  • Passwortloser SSH-Zugriff auf alle Maschinen von Clusterknoten als root oder als Nutzer mit passwortlosen sudo-Berechtigungen.

Der folgende Abschnitt enthält eine Anleitung zum Einrichten von SSH auf der Administrator-Workstation und den Knotenmaschinen.

2. Clusterknotenmaschinen einrichten

Für die Mindestinstallation eines einzelnen Administratorclusters ohne Hochverfügbarkeit und eines einzelnen Nutzerclusters ohne Hochverfügbarkeit benötigen Sie drei Maschinen:

  • Maschine für einen Administratorcluster mit einem Knoten der Steuerungsebene.

  • Zwei Maschinen für einen Nutzercluster mit einem Knoten der Steuerungsebene und einem Worker-Knoten.

Hardwareanforderungen

Jede Knotenmaschine muss die folgenden Hardwareanforderungen erfüllen:

  • Mindestens 2 CPU-Kerne
  • Mindestens 4 GiB RAM
  • Mindestens 128 GiB Speicher

Ubuntu konfigurieren

Konfigurieren Sie Ubuntu auf jedem Knoten mit derselben Anleitung wie für die Administratorworkstation.

SSH-Zugriff auf Knoten einrichten

Die Administratorworkstation benötigt passwortlosen SSH-Zugriff auf alle Clusterknotenmaschinen. Sie können SSH als root oder mit einem Nutzer mit passwortlosen sudo-Berechtigungen einrichten.

Dies sind die übergeordneten Schritte zum Einrichten von SSH für Google Distributed Cloud:

  1. SSH auf allen Maschinen installieren und konfigurieren

  2. SSH-Schlüssel erstellen und den öffentlichen Schlüssel auf jeden Knotencomputer kopieren

  3. Passwortauthentifizierung auf Knotenmaschinen deaktivieren

  4. SSH-Zugriff zwischen Administratorworkstation und Knotenmaschinen prüfen

SSH auf allen Maschinen installieren und konfigurieren

Google Distributed Cloud erfordert eine passwortlose SSH-Kommunikation zwischen der Administratorworkstation und den Clusterknoten. Die folgenden Schritte müssen auf der Administratorworkstation und jeder Knotenmaschine ausgeführt werden.

So konfigurieren Sie SSH auf Maschinen, auf denen Ubuntu ausgeführt wird:

  1. Wenn noch kein SSH-Server ausgeführt wird, installieren Sie jetzt einen:

    sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh

  2. Aktivieren Sie die SSH-Passwortauthentifizierung root. Entfernen Sie dazu die Kommentarzeichen oder fügen Sie die Zeilen PermitRootLogin und PasswordAuthentication in der Datei /etc/ssh/sshd_config hinzu und setzen Sie die Werte auf yes:

    # Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
...
PasswordAuthentication yes

  3. Legen Sie ein Root-Passwort fest:

    sudo passwd root

  4. Starten Sie den SSH-Dienst neu, um die Änderungen an der SSH-Konfiguration zu übernehmen:

    sudo systemctl restart ssh.service

  5. Starten Sie das Gerät neu.

  6. Prüfen Sie, ob die SSH-Verbindung funktioniert, indem Sie von einem anderen Computer aus eine SSH-Verbindung herstellen.

SSH-Schlüssel erstellen und den öffentlichen Schlüssel auf jeden Knotencomputer kopieren

Erstellen Sie für sichere, passwortlose Verbindungen zwischen der Administratorworkstation und den Knoten einen SSH-Schlüssel auf Ihrer Administratorworkstation und geben Sie den öffentlichen Schlüssel für die Knoten frei.

  1. Generieren Sie auf Ihrer Administrator-Workstation ein Paar aus privatem und öffentlichem Schlüssel. Legen Sie für die Schlüssel keine Passphrase fest:

    ssh-keygen -t rsa

  2. Kopieren Sie auf Ihrer Administrator-Workstation den generierten öffentlichen Schlüssel auf jede Ihrer Knotenmaschinen:

    ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP

    Ersetzen Sie Folgendes:

    • PUBLIC_KEY: der Pfad zu der Datei, die den öffentlichen SSH-Schlüssel enthält. Standardmäßig lautet der Pfad /home/USERNAME/.ssh/id_rsa.pub
    • CLUSTER_NODE_IP: die IP-Adresse der Knotenmaschine
Passwortauthentifizierung auf Knotenmaschinen deaktivieren

Ab diesem Zeitpunkt muss die Passwortauthentifizierung nicht mehr aktiviert sein.

Führen Sie für jede Knotenmaschine folgende Schritte aus:

  1. Öffnen Sie /etc/ssh/sshd_config, setzen Sie PasswordAuthentication auf no und speichern Sie die Datei.

  2. Starten Sie den SSH-Dienst neu.

    sudo systemctl restart ssh.service
SSH-Zugriff zwischen Administratorworkstation und Knotenmaschinen prüfen

Wenn SSH richtig konfiguriert ist, können Sie über die Administrator-Workstation (als Root) ohne Passwort eine SSH-Verbindung zum Knotencomputer herstellen.

So prüfen Sie, ob die Authentifizierung mit öffentlichem Schlüssel zwischen Ihrer Administratorworkstation und Ihren Clusterknoten funktioniert:

  1. Führen Sie auf der Administrator-Workstation den folgenden Befehl für jede Knotenmaschine aus:

    ssh -o IdentitiesOnly=yes -i PRIVATE_KEY root@CLUSTER_NODE_IP

    Ersetzen Sie Folgendes:

    • PRIVATE_KEY: der Pfad zu der Datei, die den privaten SSH-Schlüssel enthält. Standardmäßig lautet der Pfad /home/USERNAME/.ssh/id_rsa
    • CLUSTER_NODE_IP: die IP-Adresse der Knotenmaschine

3. Networking planen

Bei der Installation von Clustern ist es wichtig, dass Sie Ihre IP-Adressen planen und darauf achten, dass keine Adresskonflikte entstehen. Möglicherweise muss Ihr Netzwerkadministrator Ihnen bei der Suche nach geeigneten Adressen helfen, selbst für diese einfache Installation. Wenn Pods und Dienst-CIDRs nicht berücksichtigt werden, benötigen Sie mindestens 15 eindeutige IP-Adressen für eine Mindestinstallation von Administratorclustern und Nutzerclustern.

Planen und geben Sie IP-Adressen für die folgenden Clusterkomponenten an:

  • Clusterknoten: Sie benötigen eine IP-Adresse für jede Knotenmaschine.
  • Virtuelle IP-Adressen (VIPs): Sie benötigen VIPs für den Zugriff auf die Kubernetes API-Server, den Ingress-Proxy und Dienste vom Typ LoadBalancer.
  • Pods und Dienste: Sie benötigen CIDR-Adressbereiche, um jeden Pod und Dienst unterzubringen, der auf Ihren Clustern ausgeführt wird.

Der Rest dieses Abschnitts enthält anschauliche Beispiele für Werte, die für diese Installation in einem hypothetischen Netzwerk funktionieren. Ihre Werte werden anders sein.

Platzieren Sie für diese kleine Installation Ihre Administratorworkstation, den Administratorclusterknoten und die Nutzerclusterknoten in derselben Ebene-2-Domain. Angenommen, alle IP-Adressen im Bereich 172.16.20.0/24 werden an eine bestimmte Ebene-2-Domain weitergeleitet. Angenommen, Ihr Netzwerkadministrator gibt an, dass Sie 172.16.20.10–172.16.20.12 für Knotenmaschinenadressen und 172.16.0.13–172.16.20.24 für VIPs verwenden können.

Das folgende Diagramm zeigt eine Ebene-2-Domain mit einer Administrator-Workstation, einem Administratorcluster und einem Nutzercluster:

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

Beispiel-IP-Adressen von Clusterknoten

Die folgende Tabelle enthält ein Beispiel dafür, wie IP-Adressen für Clusterknoten verwendet werden können:

Maschine Beschreibung IP-Adresse
Knoten der Steuerungsebene des Administratorclusters Physische Maschine, die als Knoten der Steuerungsebene für den Administratorcluster dient 172.16.20.10
Knoten der Steuerungsebene des Nutzerclusters Physische Maschine, die als Knoten der Steuerungsebene für den Nutzercluster dient 172.16.20.11
Worker-Knoten des Nutzerclusters Physische Maschine, auf der Nutzerarbeitslasten ausgeführt werden 172.16.20.12

Beispiele für virtuelle IP-Adressen (VIPs)

Die folgende Tabelle zeigt ein Beispiel dafür, wie Sie VIPs für Ihre Cluster angeben können:

VIP Beschreibung IP-Adresse
Virtuelle IP-Adresse der Steuerungsebene des Administratorclusters Virtuelle IP-Adresse der Steuerungsebene des Administratorclusters (Kubernetes API-Server des Administratorclusters) 172.16.20.13
Virtuelle IP-Adresse der Steuerungsebene des Nutzerclusters Virtuelle IP-Adresse der Steuerungsebene des Nutzerclusters (Kubernetes API-Server des Nutzerclusters) 172.16.20.14
Virtuelle IP-Adresse für eingehenden Traffic Virtuelle IP-Adresse für eingehenden Traffic (im MetalLB-Adresspoolbereich enthalten) 172.16.20.15
Virtuelle IP-Adressen des Dienstes 10 Adressen zur Verwendung als externe IP-Adressen für Dienste vom Typ LoadBalancer. Adressen werden nach Bedarf auf Nutzerclusterknoten zugewiesen.

Dieser Bereich enthält die virtuelle IP-Adresse für eingehenden Traffic. Diese Überschneidung von IP-Adressen ist eine Voraussetzung für MetalLB, den gebündelten Standard-Load-Balancer.

 172.16.20.15–172.16.20.24

IP-Adressen für Pods und Dienste

Zusätzlich zu den IP-Adressen, die Sie für Clusterknoten und VIPs angegeben haben, müssen Sie Adressen für Pods und Dienste angeben. Sie geben einen CIDR-Bereich für Pod-IP-Adressen und einen weiteren CIDR-Bereich für die ClusterIP-Adressen von Kubernetes-Diensten an. Verwenden Sie im privaten Adressbereich IP-Adressen wie in RFC 1918 beschrieben. Diese Adressen werden im Rahmen der Clusterkonfiguration angegeben, wie im nächsten Teil dieses Leitfadens dargestellt.

Entscheiden Sie im Rahmen der IP-Planung, welche CIDR-Bereiche Sie für Pods und Dienste verwenden möchten. Sofern es keinen Grund gibt, verwenden Sie die folgenden vorgeschlagenen Bereiche:

Zweck Voreingestellter CIDR-Bereich
Administratorcluster-Pods 192.168.0.0/16
Dienste des Administratorclusters 10.96.0.0/20
Nutzercluster-Pods 192.168.0.0/16
Nutzercluster-Dienste 10.96.0.0/20

Die vorgeschlagenen Bereiche verdeutlichen diese Punkte:

  • Der Pod-CIDR-Bereich kann für mehrere Cluster im standardmäßigen Netzwerkmodell im Inselmodus gleich sein.

  • Der Dienst-CIDR-Bereich kann für mehrere Cluster gleich sein.

  • In der Regel benötigen Sie in einem Cluster mehr Pods als Dienste. Daher sollten Sie einen Pod-CIDR-Bereich verwenden, der größer als der Dienst-CIDR-Bereich ist. Der vorgeschlagene Pod-Bereich für einen Nutzercluster hat beispielsweise 2(32–16) = 216 Adressen, der vorgeschlagene Dienstbereich für einen Nutzercluster jedoch nur 2(32 – 20) = 212 Adressen.

Überlappung vermeiden

Um eine Überschneidung mit IP-Adressen zu vermeiden, die in Ihrem Netzwerk erreichbar sind, müssen Sie möglicherweise CIDR-Bereiche verwenden, die sich von den vorherigen Vorschlägen unterscheiden. 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, Ihr Dienstbereich ist 10.96.232.0/24 und Ihr Pod-Bereich 192.168.0.0/16. Traffic, der von einem Pod an eine Adresse in einem dieser Bereiche gesendet wird, wird als clusterinterne behandelt und kann kein Ziel außerhalb des Clusters erreichen.

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 DNS- oder NTP-Servern

4. Erforderliche Google Cloud-Ressourcen prüfen

Bevor Sie Cluster erstellen können, muss für Google Distributed Cloud ein bestimmter Satz von Google APIs in Ihrem verknüpften Google Cloud-Projekt aktiviert sein. Zur Verwendung der Google APIs benötigt Google Distributed Cloud Dienstkonten, die in Ihrem verknüpften Google Cloud-Projekt mit bestimmten IAM-Rollen konfiguriert sind.

Der Prozess zum Erstellen von Clustern im nächsten Teil dieses Leitfadens, Einfache Cluster erstellen, aktiviert APIs und erstellt automatisch Dienstkonten für Sie.

Die folgenden Google APIs sind automatisch aktiviert:

  • anthos.googleapis.com
  • anthosaudit.googleapis.com
  • anthosgke.googleapis.com
  • cloudresourcemanager.googleapis.com
  • connectgateway.googleapis.com
  • container.googleapis.com
  • gkeconnect.googleapis.com
  • gkehub.googleapis.com
  • gkeonprem.googleapis.com
  • iam.googleapis.com
  • logging.googleapis.com
  • monitoring.googleapis.com
  • opsconfigmonitoring.googleapis.com
  • serviceusage.googleapis.com
  • stackdriver.googleapis.com
  • storage.googleapis.com

In der folgenden Tabelle werden die Dienstkonten beschrieben, die automatisch erstellt werden:

Dienstkonto Zweck Rollen
anthos-baremetal-gcr Google Distributed Cloud verwendet dieses Dienstkonto, um Container-Images aus Container Registry herunterzuladen. Ohne
anthos-baremetal-connect Connect Agent verwendet dieses Dienstkonto, um eine Verbindung zwischen Ihrem Cluster und Google Cloud aufrechtzuerhalten. Dadurch erhalten Sie Zugriff auf den Cluster und auf Features zur Arbeitslastverwaltung, einschließlich der Google Cloud Console und des Connect Gateway, um mit dem Cluster zu interagieren. roles/gkehub.connect
anthos-baremetal-register Connect Agent verwendet dieses Dienstkonto, um Ihre Cluster bei einer Flotte zu registrieren. roles/gkehub.admin
anthos-baremetal-cloud-ops Stackdriver Agent verwendet dieses Dienstkonto, um Logs und Messwerte aus Clustern nach Cloud Logging und Cloud Monitoring zu exportieren. roles/logging.logWriter
roles/monitoring.metricWriter
roles/Stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

Nächste Schritte

Einfache Cluster erstellen