Vorbereitung der Administratorworkstation

Die Administratorworkstation hostet Befehlszeilentools und Konfigurationsdateien zum Bereitstellen von Clustern während der Installation sowie Befehlszeilentools für die Interaktion mit bereitgestellten Clustern nach der Installation.

Sie laden Tools wie bmctl und die Google Cloud CLI auf die Administratorworkstation herunter und führen sie aus, um mit Clustern und Google Cloud-Ressourcen zu interagieren. Die Administratorworkstation hostet Konfigurationsdateien, um während der Installation, Upgrades und Updates Cluster bereitzustellen. Nach der Installation hostet die Administratorworkstation kubeconfig-Dateien, sodass Sie kubectl verwenden können, um mit bereitgestellten Clustern zu interagieren. Sie greifen auch auf Logs für kritische Clustervorgänge auf der Administratorworkstation zu. Eine einzelne Administratorworkstation kann zum Erstellen und Verwalten vieler Cluster verwendet werden.

Prüfen Sie, ob die Administratorworkstation die in den folgenden Abschnitten beschriebenen Voraussetzungen erfüllt.

Hinweis: Eine Workstation, die die Anforderungen auf dieser Seite erfüllt, kann als Administratorworkstation zum Erstellen und Verwalten Ihrer Cluster verwendet werden. Sie können die Workstation auch als Knoten der Administrator-Steuerungsebene für einen Ihrer Cluster verwenden.

Betriebssystem und Software

Zum Ausführen von bmctl und als Knoten der Steuerungsebene hat die Administratorworkstation die gleichen Betriebssystemanforderungen wie Knoten. Die Administrator-Workstation erfordert Docker, kann jedoch nicht als Containerlaufzeit verwendet werden. Wenn Google Distributed Cloud Cluster erstellt, wird ein Kubernetes-in-Docker-Cluster (Typ) auf der Administrator-Workstation bereitgestellt. Dieser Bootstrap-Cluster hostet die Kubernetes-Controller, die zum Erstellen von Clustern erforderlich sind. Sofern nicht anders angegeben, wird der Bootstrap-Cluster entfernt, wenn die Clustererstellung erfolgreich abgeschlossen wurde. Für den Bootstrap-Cluster ist Docker erforderlich, um Container-Images abzurufen.

Hinweis: Der Bootstrap-Cluster verwendet einen einzelnen speicherinternen Knoten für die Installation und verfügt über begrenzte Ressourcen. Wenn Sie einen Cluster mit mehr als 20 Knoten installieren, erstellen Sie den Cluster nur mit Knoten der Steuerungsebene. Sobald der Cluster ausgeführt wird, fügen Sie die verbleibenden Worker-Knoten hinzu. In diesem Szenario führen die Knoten der Steuerungsebene die Installation des Worker-Knotens aus.

Die Administratorworkstation muss die folgenden Anforderungen erfüllen, bevor Sie einen Cluster installieren können:

• Das Betriebssystem ist eine unterstützte Linux-Distribution.

  Eine Liste der unterstützten Linux-Betriebssysteme und -Versionen finden Sie unter Betriebssystem auswählen. Diese Seite enthält Links zu Konfigurationsanleitungen, einschließlich Docker-Konfiguration, für jedes Betriebssystem.

• Docker-Version 19.03 oder höher ist installiert. Wenn Ihr System jedoch cgroup v2 verwendet, muss die Docker-Installation auf Ihrer Administrator-Workstation mindestens Version 20.10.0 haben. Ob Ihr System cgroup v2 verwendet, erkennen Sie an der Datei /sys/fs/cgroup/cgroup.controllers. cgroup v2 wird nur als Vorabversion unterstützt. Die Verwendung von Vorschaufunktionen und -funktionen in Produktionsumgebungen wird nicht empfohlen.

  Warnung: Das von snap installierte Docker befindet sich standardmäßig im strikten Beschränkungsmodus, d. h., Docker kann nicht auf Dateien außerhalb des Verzeichnisses $HOME zugreifen. Prüfen Sie, ob sich Docker im strikten Beschränkungsmodus befindet. Führen Sie dazu snap info --verbose docker | grep confinement auf Ihrer Administratorworkstation aus. Achten Sie in diesem Fall darauf, dass sich der Ordner bmctl-workspace im Verzeichnis $HOME befindet.

• Ein Nutzer ohne Root-Berechtigung ist Mitglied der Gruppe docker. Eine Anleitung dazu finden Sie unter Docker als Nicht-Root-Nutzer verwalten.

• Die Google Cloud CLI ist installiert.

  Cluster werden mit den Tools kubectl und bmctl erstellt und verwaltet. Zum Installieren dieser Tools benötigen Sie die Tools gcloud und gsutil. Die Befehlszeilentools gcloud, gsutil und kubectl sind Komponenten der gcloud CLI. Installationsanweisungen, einschließlich Anweisungen zur Installation von Komponenten, finden Sie unter gcloud CLI installieren.

• kubectl ist installiert. Verwenden Sie die gcloud CLI, um kubectl mit dem folgenden Befehl zu installieren:

  gcloud components install kubectl
  

• bmctl ist für die Version des Clusters installiert, den Sie erstellen oder betreiben.

  Die Installation besteht aus der Verwendung von gsutil, um das Binär- oder Image-Paket bmctl herunterzuladen. Eine Anleitung finden Sie unter Google Distributed Cloud für Bare-Metal-Downloads.

Anforderungen an Hardwareressourcen

Die Administratorworkstation benötigt eine erhebliche Rechenleistung sowie viel Arbeitsspeicher und Speicher, um Tools auszuführen und die mit der Erstellung und Verwaltung von Clustern verbundenen Ressourcen zu speichern.

Standardmäßig verwenden die Clusterupgrades und Clustererstellungsvorgänge einen Bootstrap-Cluster. Bei der Verwendung eines Bootstrap-Clusters nimmt die CPU- und Arbeitsspeichernutzung erheblich zu. Wenn Sie die Administratorworkstation als Knoten der Steuerungsebene verwenden möchten, verwenden Sie mindestens die höhere empfohlene Anzahl von CPUs und RAM, um zu verhindern, dass Aktivitäten der Administratorworkstation die Funktionen der Cluster-Steuerungsebene beeinträchtigen.

Je nach Größe der etcd-Datenbank und der Anzahl der Knoten der Steuerungsebene verbrauchen Clustersicherungs- und -wiederherstellungsvorgänge einen erheblichen RAM-Speicher. Der für Sicherungen erforderliche RAM beträgt ungefähr 3–5 GiB pro Knoten der Steuerungsebene. Die Sicherung schlägt fehl, da nicht genügend Arbeitsspeicher vorhanden ist. Planen Sie Ihre RAM-Anforderungen entsprechend.

Die folgende Tabelle enthält die Mindest- und empfohlenen Hardwareanforderungen für die Administrator-Workstation:

Ressource	Minimum	Empfohlen
CPUs / vCPUs^*	2 Core	4 Core
RAM	Ubuntu: 4 GiB RHEL: 6 GiB	Ubuntu: 8 GiB RHEL: 12 GiB
Speicherplatz	128 GiB	256 GiB

^* Google Distributed Cloud unterstützt nur x86-64-CPUs und vCPUs auf CPU-Mikroarchitekturebene v3 (x86-64-v3) und höher.

Netzwerkanforderungen

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. Sie können keine Cluster ohne Zugriff auf Google Cloud erstellen.

Der Zugriff auf Google Cloud kann entweder direkt oder über einen Proxyserver erfolgen. Informationen zu den verschiedenen Möglichkeiten, eine Verbindung zu Google Cloud herzustellen, finden Sie unter Mit Google verbinden. Informationen zum Konfigurieren eines Proxyservers finden Sie unter Installation hinter einem Proxy.

Informationen zu den Folgen eines unterbrochenen Zugriffs auf Google Cloud finden Sie unter Auswirkungen der vorübergehenden Trennung von Google Cloud.

Zugriff auf Knoten

Zum Erstellen und Verwalten von Clustern über Ihre Administratorworkstation benötigen Sie die folgenden Zugriffsrechte für die Knotenmaschinen:

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

IP-Weiterleitung

Auf der Administratorworkstation muss die IP-Weiterleitung aktiviert sein. Ohne IP-Weiterleitung kann der Bootstrap-Cluster nicht erstellt werden. Dadurch wird die Clustererstellung blockiert. Wenn die IP-Weiterleitung deaktiviert ist, wird beim Erstellen eines Clusters ein Fehler wie der folgende angezeigt:

Error message: E0202 14:53:25.979322 225917 console.go:110] Error creating cluster: create kind cluster failed: error creating bootstrap cluster: failed to init node with kubeadm: command "docker exec --privileged bmctl-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1

Mit dem folgenden Befehl können Sie die IP-Weiterleitungseinstellung prüfen:

cat /proc/sys/net/ipv4/ip_forward

Der Wert 1 gibt an, dass die IP-Weiterleitung aktiviert ist. Wenn die IP-Weiterleitung deaktiviert ist (0), verwenden Sie den folgenden Befehl, um sie zu aktivieren:

echo '1' | sudo tee /proc/sys/net/ipv4/ip_forward

root-SSH-Zugriff auf Knoten einrichten

Erstellen Sie auf Ihrer Administratorworkstation einen SSH-Schlüssel und geben Sie den öffentlichen Schlüssel für Clusterknoten frei, um sichere, passwortlose Verbindungen zwischen der Administratorworkstation und den Clusterknotenmaschinen zu ermöglichen.

Hinweis: Mit der folgenden Anleitung wird für den Nutzer root ein SSH-Zugriff ohne Passwort auf Knoten eingerichtet. Alternativ können Sie einen Nutzer ohne Root-Berechtigung verwenden, der passwortlose sudo-Berechtigungen hat. Dieser Nutzer ohne Root-Berechtigung muss in der Clusterkonfigurationsdatei (nodeAccess.loginUser) angegeben werden. Weitere Informationen finden Sie unter Anmeldenutzer festlegen.

1. Aktivieren Sie die SSH-Passwortauthentifizierung root auf allen Clusterknotencomputern. Entfernen Sie dazu die Auskommentierung oder fügen Sie die Zeilen PermitRootLogin und PasswordAuthentication in die Datei /etc/ssh/sshd_config ein und setzen Sie die Werte auf yes.

   # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
   
   # This is the sshd server system-wide configuration file.  See
   # sshd_config(5) for more information.
   
   ...
   
   # Authentication:
   
   #LoginGraceTime 2m
   PermitRootLogin yes
   #StrictModes yes
   #MaxAuthTries 6
   #MaxSessions 10
   
   ...
   
   PasswordAuthentication yes
   

   Zu Beginn muss die SSH-Passwortauthentifizierung auf den Maschinen mit Remote-Clusterknoten aktiviert sein, um Schlüssel von der Administratorworkstation freizugeben.

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

   sudo systemctl restart ssh.service
   

3. Generieren Sie ein Paar aus privatem und öffentlichem Schlüssel auf der Administratorworkstation. Legen Sie keine Passphrase für die Schlüssel fest. Generieren Sie die Schlüssel mit dem folgenden Befehl:

   ssh-keygen -t rsa
   

   Sie können SSH auch mit dem sudo-Nutzerzugriff auf die Maschinen mit Clusterknoten einrichten. Für passwortlose Nutzerverbindungen ohne Root-Berechtigung müssen Sie die Clusterkonfigurationsdatei jedoch mit dem Feld spec.nodeAccess.loginUser aktualisieren. Dieses Feld ist standardmäßig auskommentiert. Sie können Ihren Nicht-Root-Nutzernamen mit loginUser während der Clustererstellung oder jederzeit danach angeben. Weitere Informationen finden Sie unter loginUser.

4. Fügen Sie den generierten öffentlichen Schlüssel zu den Maschinen des Clusterknotens hinzu:

   ssh-copy-id -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
   

   Ersetzen Sie Folgendes:

   • PATH_TO_IDENTITY_FILE: der Pfad zur Datei, die den öffentlichen SSH-Schlüssel enthält. Standardmäßig lautet der Pfad zur Identitätsdatei, die den öffentlichen Schlüssel enthält, /home/USERNAME/.ssh/id_rsa.pub.
   • CLUSTER_NODE_IP: die IP-Adresse des Knotencomputers, dem Sie den öffentlichen SSH-Schlüssel hinzufügen.

5. Deaktivieren Sie die SSH-Passwortauthentifizierung auf den Maschinen mit Clusterknoten, indem Sie PasswordAuthentication in der Datei sshd_config auf no setzen und den SSH-Dienst neu starten.

6. Prüfen Sie mit dem folgenden Befehl auf der Administratorworkstation, ob die Authentifizierung mit öffentlichem Schlüssel zwischen der Workstation und den Knotenmaschinen funktioniert.

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

   Wenn SSH richtig konfiguriert ist, können Sie sich von der Administratorworkstation aus (als root) beim Knotencomputer anmelden, ohne ein Passwort eingeben zu müssen.

Nächste Schritte

• Voraussetzungen für Knotenmaschinen