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
- Informationen zu Google Distributed Cloud
- Machen Sie sich mit einigen grundlegenden Google Cloud-Konzepten wie Projekten, IAM-Berechtigungen und Dienstkonten vertraut.
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
- Notieren Sie sich die Google Cloud-Projekt-ID, da sie später benötigt wird.
Verfahrensübersicht
Die minimale Infrastruktureinrichtung umfasst die folgenden Hauptschritte:
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.
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.
Netzwerk planen Planen Sie die IP-Adressen für Ihre Knotenmaschinen, virtuelle IP-Adressen (VIPs) sowie Dienst- und Pod-CIDR-Bereiche.
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
Installieren
kubectl
Installieren
bmctl
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:
Deaktivieren Sie die Uncomplicated Firewall (UFW) und überprüfen Sie ihren Status:
sudo ufw disable sudo ufw status
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
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 ...
Erstellen Sie die Gruppe
docker
.sudo groupadd docker
Fügen Sie sich selbst zur Docker-Gruppe hinzu:
sudo usermod -aG docker $USER
Führen Sie den folgenden Befehl aus, um die Gruppenänderungen zu aktivieren:
newgrp docker
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:
Melden Sie sich an, um das Attribut
account
der gcloud CLI festzulegen:gcloud auth login
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.Prüfen Sie, ob die Attribute
account
undproject
korrekt festgelegt sind:gcloud config list
Die Ausgabe zeigt die Werte der Attribute
account
undproject
. 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
:
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:
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"
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
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 passwortlosensudo
-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:
SSH auf allen Computern installieren und konfigurieren
SSH-Schlüssel erstellen und den öffentlichen Schlüssel auf jeden Knotencomputer kopieren
Passwortauthentifizierung auf Knotenmaschinen deaktivieren
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:
Wenn noch kein SSH-Server ausgeführt wird, installiere jetzt einen:
sudo apt update sudo apt install openssh-server sudo systemctl status ssh
Aktivieren Sie die SSH-Passwortauthentifizierung für
root
. Entfernen Sie dazu die Kommentarzeichen oder fügen Sie die ZeilenPermitRootLogin
undPasswordAuthentication
in die Datei/etc/ssh/sshd_config
ein und setzen Sie die Werte aufyes
:# Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 ... PasswordAuthentication yes
Legen Sie ein Root-Passwort fest:
sudo passwd root
Starten Sie den SSH-Dienst neu, um die Änderungen an der SSH-Konfiguration zu übernehmen:
sudo systemctl restart ssh.service
Starten Sie das Gerät neu.
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.
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
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:
Öffnen Sie
/etc/ssh/sshd_config
, setzen SiePasswordAuthentication
aufno
und speichern Sie die Datei.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:
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:
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 |