Installation vorbereiten

Diese Seite ist der erste Teil eines Leitfadens, der Sie durch die Verwendung der Google Distributed Cloud-Software (früher Google Distributed Cloud Virtual) zum Erstellen einer kleinen Proof-of-Concept-Installation von GKE-Clustern auf Ihrer Bare-Metal-Hardware führt. In diesem Dokument erfahren Sie, wie Sie eine minimale Hardwareumgebung einrichten und Ihre IP-Adressen planen. Im anschließenden Abschnitt Grundlegende Cluster erstellen erfahren Sie, wie Sie einen Administrator- und einen Nutzercluster erstellen.

Die Infrastruktur, die Sie mit diesem Leitfaden einrichten, ist für Ihre tatsächlichen Produktionsanforderungen und Anwendungsfälle möglicherweise nicht geeignet. Weitere Informationen zu Produktionsinstallationen finden Sie unter Bereitstellungsmodell auswählen.

Hinweise

  1. Informationen zu Google Distributed Cloud
  2. Machen Sie sich mit einigen grundlegenden Google Cloud-Konzepten wie Projekten, IAM-Berechtigungen und Dienstkonten vertraut.
  3. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

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

Verfahrensübersicht

Die minimale Infrastruktureinrichtung umfasst die folgenden Hauptschritte:

  1. Richten Sie Ihre Administratorworkstation ein. Richten Sie eine Linux-Administratorworkstation für lokale Verwaltungsaufgaben ein. Dies kann ein vorhandener oder ein dedizierter Computer sein, der mehrere Cluster verwalten kann.

  2. Richten Sie Ihre Clusterknotenmaschinen ein. 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. Netzwerk planen Planen Sie die IP-Adressen für Ihre Knotenmaschinen, virtuelle IP-Adressen (VIPs) sowie Dienst- und Pod-CIDR-Bereiche.

  4. Erforderliche Google Cloud-Ressourcen prüfen. Zum Erstellen von Clustern sind für Ihr Google Cloud-Projekt bestimmte Google APIs und Dienstkonten erforderlich.

1. Administratorworkstation einrichten

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

Hardwareanforderungen

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.

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

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

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 Erstellen eines Clusters hat die Administratorworkstation die gleichen Betriebssystemanforderungen wie Knoten. Auf jedem Computer 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 die Uncomplicated Firewall (UFW) und überprüfen Sie ihren 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 die Docker-Version 19.03 oder höher verwenden:

    sudo docker version

    Sowohl die Client- als auch die Serverversion muss mindestens 19.03 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 zur 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 prüfen, ob die Systemuhr synchronisiert ist:

    timedatectl

    Die Ausgabe von timedatectl sollte den folgenden Status enthalten:

    System clock synchronized: yes

Google Cloud CLI installieren

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

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 korrekt 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 den folgenden Befehl auf der Administratorworkstation aus:

    gcloud components install kubectl

bmctl installieren

bmctl ist das proprietäre Befehlszeilentool für Google Distributed Cloud, das Sie zum Erstellen und Verwalten von Clustern verwenden können.

So installieren Sie bmctl auf Ihrer Administratorworkstation:

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

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

Zugriff über die Administratorworkstation

Zum Erstellen und Verwalten von Clustern über Ihre Administratorworkstation benötigen Sie 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 mit 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 minimale Installation eines einzelnen Administratorclusters mit nicht hoher Verfügbarkeit und eines einzelnen Nutzerclusters mit Nicht-Hochverfügbarkeit benötigen Sie drei Maschinen:

  • Eine 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 Speicherplatz

Ubuntu konfigurieren

Konfigurieren Sie Ubuntu auf jedem Knoten mit derselben Anleitung, die für die Administratorworkstation verwendet wurde.

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 Computern 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 Computern 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 auf jeder Knotenmaschine ausgeführt werden.

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

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

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

  2. Aktivieren Sie die SSH-Passwortauthentifizierung für root. Entfernen Sie dazu die Kommentarzeichen oder fügen Sie die Zeilen PermitRootLogin und PasswordAuthentication in die Datei /etc/ssh/sshd_config ein 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. Stellen Sie von einem anderen Computer aus eine SSH-Verbindung her, um zu prüfen, ob SSH funktioniert.

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 keine Passphrase für die Schlüssel 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 zur 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ür jede Knotenmaschine:

  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 von der Administratorworkstation (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 Administratorworkstation 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 zur 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

Beim Installieren von Clustern ist es wichtig, dass Sie Ihre IP-Adressen planen und dafür sorgen, dass keine Adresskonflikte entstehen. Es kann sein, dass Ihr Netzwerkadministrator Ihnen bei der Suche nach geeigneten Adressen hilft, auch bei dieser einfachen Installation. Ohne Berücksichtigung von Pods und Dienst-CIDRs benötigen Sie mindestens 15 eindeutige IP-Adressen für die Installation eines Administrator- und Nutzerclusters.

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

  • Clusterknoten: Sie benötigen für jede Knotenmaschine eine IP-Adresse.
  • 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 alle in den Clustern ausgeführten Pods und Dienste aufzunehmen

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 die 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 Knotencomputeradressen 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 Administratorworkstation, 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 für Clusterknoten

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

Computer 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 enthält 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 Zehn Adressen zur Verwendung als externe IP-Adressen für Dienste vom Typ LoadBalancer. Adressen werden nach Bedarf auf Nutzerclusterknoten zugewiesen.

Dieser Bereich umfasst 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 IP-Adressen im privaten Adressbereich, wie in RFC 1918 beschrieben. Diese Adressen 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. Sofern Sie keinen Grund haben, etwas anderes zu tun, verwenden Sie die folgenden vorgeschlagenen Bereiche:

Zweck Vorab ausgefüllter 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 Inselmodus-Netzwerkmodell gleich sein.

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

  • Normalerweise benötigen Sie in einem Cluster mehr Pods als Dienste. Daher möchten Sie wahrscheinlich einen Pod-CIDR-Bereich, 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

Damit sich die IP-Adressen nicht mit IP-Adressen überschneiden, 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 ist 192.168.0.0/16. Traffic, der von einem Pod an eine Adresse in einem dieser Bereiche gesendet wird, wird als clusterintern 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 mit bestimmten IAM-Rollen in Ihrem verknüpften Google Cloud-Projekt konfiguriert sind.

Mit dem Prozess zum Erstellen von Clustern im nächsten Teil dieses Leitfadens (Grundlegende Cluster erstellen) werden APIs aktiviert und Dienstkonten werden automatisch für Sie erstellt.

Dies sind die Google APIs, die automatisch aktiviert sind:

  • 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 Verbindungsgateways für die Interaktion mit dem Cluster. 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 von 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