Version 1.15 Diese Version wird nicht mehr unterstützt. Informationen zum Upgrade auf Version 1.16 finden Sie in der aktuellen Dokumentation unter Cluster upgraden. Weitere Informationen zu unterstützten und nicht unterstützten Versionen finden Sie in der aktuellen Dokumentation auf der Seite Versionsverlauf.

GKE on Bare Metal-Cluster auf Edge-Geräten bereitstellen

In dieser Anleitung wird eine sofort einsatzbereite Lösung vorgestellt, die GKE on Bare Metal und Config Sync verwendet, um Kubernetes-Cluster auf Edge-Geräten in großem Maßstab bereitzustellen. Diese Anleitung richtet sich an Plattformbetreiber und Entwickler. Sie sollten mit den folgenden Technologien und Konzepten vertraut sein:

Ansible-Playbooks.
Edge-Bereitstellungen und ihre Herausforderungen
Mit einem Google Cloud-Projekt arbeiten
Container-Webanwendung bereitstellen
gcloud- und kubectl-Befehlszeilenschnittstellen.

In dieser Anleitung verwenden Sie virtuelle Compute Engine-Maschinen (VMs), um Knoten zu emulieren, die auf dem Edge bereitgestellt werden, und eine beispielhafte Point-of-Sale-Anwendung als Edge-Arbeitslast. GKE on Bare Metal und Config Sync bieten zentrale Verwaltung und Kontrolle für Ihren Edge-Cluster. Config Sync ruft neue Konfigurationen dynamisch aus GitHub ab und wendet diese Richtlinien und Konfigurationen auf Ihre Cluster an.

Edge-Bereitstellungsarchitektur

Ein Retail-Edge-Deployment ist eine gute Möglichkeit, die Architektur zu veranschaulichen, die in einer typischen GKE on Bare Metal-Bereitstellung verwendet wird.

Ein Ladengeschäft ist der nächste Interaktionspunkt zwischen einer Geschäftseinheit eines Unternehmens und dem Verbraucher. Softwaresysteme in Geschäften müssen ihre Arbeitslasten ausführen, zeitnahe Updates erhalten und wichtige Messwerte isoliert vom zentralen Verwaltungssystem des Unternehmens melden. Darüber hinaus müssen diese Softwaresysteme so konzipiert werden, dass sie in Zukunft auf weitere Filialstandorte ausgeweitet werden können. Während GKE on Bare Metal alle diese Anforderungen für Speichersoftwaresysteme erfüllt, ermöglicht das Edge-Profil einen wichtigen Anwendungsfall: Bereitstellungen in Umgebungen mit begrenzten Hardwareressourcen, wie z. B. in einer Ladenfront.

Das folgende Diagramm zeigt ein Deployment von GKE on Bare Metal, das das Edge-Profil in einem Einzelhandelsgeschäft verwendet:

GKE on Bare Metal-Bereitstellung, die das Edge-Profil in einem Einzelhandelsgeschäft verwendet

Das obige Diagramm zeigt ein typisches Ladengeschäft. Das Geschäft verfügt über intelligente Geräte wie Kartenlesegeräte, Kassensysteme, Kameras und Drucker. Der Store verfügt außerdem über drei physische Computing-Hardware mit der Bezeichnung Node 1, Node 2 und Node 3. Diese Geräte sind mit einem zentralen Netzwerk-Switch verbunden. Somit sind die drei Rechengeräte über ein Schicht-2-Netzwerk miteinander verbunden. Die miteinander verbundenen Rechengeräte bilden die Bare-Metal-Infrastruktur. GKE on Bare Metal wird in jedem der drei Rechengeräte ausgeführt. Diese Geräte haben auch einen eigenen Laufwerkspeicher und sind für die Datenreplikation zwischen ihnen für Hochverfügbarkeit konfiguriert.

Das Diagramm zeigt auch die folgenden Hauptkomponenten, die Teil einer GKE on Bare Metal-Bereitstellung sind:

Die als MetalLB gekennzeichnete Komponente ist der gebündelte Load-Balancer, der mit GKE on Bare Metal bereitgestellt wird.
Die Config Sync-Komponente ermöglicht die Synchronisierung des Status des Clusters mit Quell-Repositories. Es ist ein dringend empfohlenes optionales Add-on, das eine separate Installation und Konfiguration erfordert. Weitere Informationen zum Einrichten von Config Sync und den unterschiedlichen Nomenklaturen finden Sie in der Dokumentation zu Config Sync.
Das Root-Repository und das Namespace-Repository, die oben im Diagramm außerhalb des Speicherorts angezeigt werden, stellen zwei Quell-Repositories dar.

Änderungen am Cluster werden an diese zentralen Quell-Repositories übertragen. GKE on Bare Metal-Bereitstellungen an verschiedenen Edge-Standorten rufen Updates aus den Quell-Repositories ab. Dieses Verhalten wird durch Pfeile dargestellt, die die beiden Repositories im Diagramm mit den Config Sync-Komponenten im GKE on Bare Metal-Cluster verbinden, der auf den Geräten ausgeführt wird.
Eine weitere wichtige Komponente, die als Teil des Clusters dargestellt wird, ist die VM-Laufzeit auf GDC. Mit der VM-Laufzeit auf GDC können vorhandene VM-basierte Arbeitslasten innerhalb des Clusters ausgeführt werden, ohne dass eine Containerisierung erforderlich ist. In der Dokumentation zur VM-Laufzeit auf GDC wird erläutert, wie Sie sie aktivieren und Ihre VM-Arbeitslasten im Cluster bereitstellen.
Die mit Application gekennzeichnete Komponente gibt Software an, die vom Einzelhandelsgeschäft im Cluster bereitgestellt wird. Ein Beispiel für eine solche Anwendung ist die Kassenanwendung, die an den Kiosken eines Einzelhandelsgeschäfts zu sehen ist.

Die Kästchen unten im Diagramm stellen die vielen Geräte (z. B. Kioske, Tablets oder Kameras) in einem Einzelhandelsgeschäft dar, die alle mit einem zentralen Netzwerk-Switch verbunden sind. Das lokale Netzwerk im Speicher ermöglicht es den Anwendungen, die in der GKE on Bare Metal-Bereitstellung ausgeführt werden, diese Geräte zu erreichen.

Im nächsten Abschnitt sehen Sie die Emulation dieser Retail Store-Bereitstellung in Google Cloud mithilfe von Compute Engine-VMs. Diese Emulation verwenden Sie in der folgenden Anleitung, um GKE on Bare Metal zu testen.

Emulierte Edge-Bereitstellung in Google Cloud

Das folgende Diagramm zeigt alles, was Sie in dieser Anleitung in Google Cloud einrichten. Dieses Diagramm korreliert mit dem Diagramm der Einzelhandelsgeschäfte aus dem vorherigen Abschnitt. Diese Bereitstellung stellt einen emulierten Edge-Standort dar, an dem die Point-of-Sale-Anwendung bereitgestellt wird. Die Architektur zeigt auch eine einfache Point-of-Sale-Beispielanwendungsarbeitslast, die Sie in dieser Anleitung verwenden. Der Zugriff auf die Point-of-Sale-Anwendung innerhalb des Clusters erfolgt über einen Webbrowser als Kiosk.

Architektur der Point-of-Sale-Anwendung und deren Bereitstellung in einem GKE on Bare-Metal-Cluster, der auf Compute Engine-VMs ausgeführt wird

Die drei virtuellen Compute Engine-Maschinen (VMs) im vorherigen Diagramm stellen die physische Hardware (oder Knoten) an einem typischen Edge-Standort dar. Diese Hardware wird mit Netzwerk-Switches verbunden, um die Bare-Metal-Infrastruktur zu bilden. In unserer emulierten Umgebung in Google Cloud sind diese VMs über das standardmäßige VPC-Netzwerk (Virtual Private Cloud) im Google Cloud-Projekt miteinander verbunden.

In einer typischen GKE on Bare Metal-Installation können Sie Ihre eigenen Load-Balancer konfigurieren. In dieser Anleitung richten Sie jedoch keinen externen Load-Balancer ein. Verwenden Sie stattdessen den gebündelten MetalLB-Load-Balancer, der mit GKE on Bare Metal installiert ist. Der gebündelte MetalLB-Load-Balancer erfordert eine Ebene-2-Netzwerkverbindung zwischen den Knoten. Daher wird die Ebene-2-Verbindung zwischen den Compute Engine-VMs aktiviert, indem ein VxLAN-Overlay-Netzwerk auf dem standardmäßigen VPC-Netzwerk (Virtual Private Cloud) erstellt wird.

Innerhalb des Rechtecks mit der Bezeichnung "L2 Overlay Network (VxLAN)" sind die Softwarekomponenten zu sehen, die in den drei Compute Engine-VMs ausgeführt werden. Dieses Rechteck enthält den GKE on Bare Metal-Cluster und einen Reverse-Proxy. Der Cluster wird durch das Rechteck GKE on Bare Metal dargestellt. Dieses Rechteck, das den Cluster darstellt, enthält ein weiteres Rechteck mit der Markierung Kubernetes-Namespace (pos). Dies stellt einen Kubernetes-Namespace im Cluster dar. Alle Komponenten in diesem Kubernetes-Namespace bilden die Point-of-Sale-Anwendung, die im GKE on Bare Metal-Cluster bereitgestellt wird. Die Point-of-Sale-Anwendung umfasst drei Mikrodienste: API-Server, Inventar und Zahlungen. Alle diese Komponenten bilden zusammen eine „Anwendung“, die im vorherigen Diagramm der Edge-Roll-out-Architektur dargestellt ist.

Der gebündelte MetalLB-Load-Balancer des GKE on Bare Metal-Clusters kann von außerhalb der VMs nicht direkt erreicht werden. Das Diagramm zeigt einen NGINX-Reverse-Proxy, der so konfiguriert wird, dass er innerhalb der VMs ausgeführt wird, um den von den Compute Engine-VMs eingehenden Traffic an den Load-Balancer weiterzuleiten. Dies ist nur eine Umgehung für die Zwecke dieser Anleitung, bei der die Edge-Knoten mithilfe von Google Cloud Compute Engine-VMs emuliert werden. An einem echten Edge-Standort ist dies mit der richtigen Netzwerkkonfiguration möglich.

Lernziele

Mit Compute Engine-VMs eine Bare-Metal-Infrastruktur emulieren, die an einem Edge-Standort ausgeführt wird.
Erstellen Sie einen GKE on Bare Metal-Cluster in der emulierten Edge-Infrastruktur.
Verbinden Sie den Cluster und registrieren Sie ihn bei Google Cloud.
Stellen Sie eine Beispiel-Arbeitslast einer Kassenanwendung im GKE on Bare Metal-Cluster bereit.
Verwenden Sie die Google Cloud Console, um die Point-of-Sale-Anwendung, die am Edge-Standort ausgeführt wird, zu prüfen und zu überwachen.
Verwenden Sie Config Sync, um die Point-of-Sale-Anwendung zu aktualisieren, die im GKE on Bare Metal-Cluster ausgeführt wird.

Hinweise

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

Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit ihm verknüpften Ressourcen entfernen.

Zur Projektauswahl
Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist.
Installieren und initialize Sie die Google Cloud CLI.

Verzweigung und Klonen des anthos-sample-Repositorys

Alle in dieser Anleitung verwendeten Skripts werden im Repository anthos-samples gespeichert. Die Ordnerstruktur unter /anthos-bm-edge-deployment/acm-config-sink ist entsprechend den Erwartungen von Config Sync organisiert. Klonen Sie dieses Repository in Ihr eigenes GitHub-Konto, bevor Sie mit den folgenden Schritten fortfahren.

Erstellen Sie ein Konto auf GitHub, falls Sie noch keines haben.
Erstellen Sie ein persönliches Zugriffstoken für die Verwendung in der Config Sync-Konfiguration. Dies ist erforderlich, damit sich die Config Sync-Komponenten im Cluster bei Ihrem GitHub-Konto authentifizieren können, wenn sie versuchen, neue Änderungen zu synchronisieren.
1. Wählen Sie nur den Bereich public_repo aus.
2. Speichern Sie das erstellte Zugriffstoken zur späteren Verwendung an einem sicheren Ort.
Erstellen Sie einen Fork des Repositorys anthos-samples in Ihrem eigenen GitHub-Konto:
1. Rufen Sie das anthos-sample-Repository auf.
2. Klicken Sie in der oberen rechten Ecke der Seite auf das Symbol Fork.
3. Klicken Sie auf das GitHub-Nutzerkonto, das den Fork des Repositorys enthalten soll. Sie werden automatisch zur Seite mit der Fork-Version des Repositorys anthos-samples weitergeleitet.
Öffnen Sie ein Terminal in der lokalen Umgebung.
Klonen Sie das verzweigte Repository mit dem folgenden Befehl, wobei GITHUB_USERNAME der Nutzername für Ihr GitHub-Konto ist:
```
git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment
```
Hinweis: Sowohl das Quell-Repository für diese Lösung als auch die Verzweigung dieses Repositorys sind öffentliche Repositories. In diesem Dokument wird die Verwendung eines Zugriffstokens gezeigt, um einen tatsächlichen Anwendungsfall mit einem privaten Repository nachzuahmen.

Workstation-Umgebung einrichten

Um die in diesem Dokument beschriebene Edge-Bereitstellung abzuschließen, benötigen Sie eine Workstation mit Internetzugriff und die folgenden Tools:

Docker
envsubst-Befehlszeilentool (normalerweise unter Linux und anderen Unix-ähnlichen Betriebssystemen vorinstalliert)

Führen Sie alle Befehle in der Anleitung auf der Workstation aus, die Sie in diesem Abschnitt konfigurieren.

Initialisieren Sie auf Ihrer Workstation die Umgebungsvariablen in einer neuen Shell-Instanz:

export PROJECT_ID="PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

# port on the admin Compute Engine instance you use to set up an nginx proxy
# this allows to reach the workloads inside the cluster via the VM IP
export PROXY_PORT="8082"

# should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
export GCE_COUNT="3"

# url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples
export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples"

# this is the username used to authenticate to your fork of this repository
export SCM_TOKEN_USER="GITHUB_USERNAME"

# access token created in the earlier step
export SCM_TOKEN_TOKEN="ACCESS_TOKEN"

Ersetzen Sie die folgenden Werte:

PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
GITHUB_USERNAME ist Ihr GitHub-Nutzername
ACCESS_TOKEN: das persönliche Zugriffstoken, das Sie für Ihr GitHub-Repository erstellt haben

Behalten Sie die Standardwerte für die anderen Umgebungsvariablen bei. Sie werden in den folgenden Abschnitten näher erläutert.

Initialisieren Sie die Google Cloud CLI auf Ihrer Workstation:

gcloud config set project "${PROJECT_ID}"
gcloud services enable compute.googleapis.com

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

Erstellen Sie auf Ihrer Workstation das Google Cloud-Dienstkonto für die Compute Engine-Instanzen. Dieses Skript erstellt die JSON-Schlüsseldatei für das neue Dienstkonto unter <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Außerdem werden der Schlüsselbund und der Schlüssel von Cloud Key Management Service für die Verschlüsselung privater SSH-Schlüssel eingerichtet.

./scripts/create-primary-gsa.sh

Das folgende Beispiel ist nur ein Teil des Skripts. Klicken Sie auf Auf GitHub ansehen, um das gesamte Skript zu sehen.

# ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Compute Engine-Instanzen bereitstellen

In diesem Abschnitt erstellen Sie die Compute Engine-VMs, auf denen GKE on Bare Metal installiert wird. Außerdem prüfen Sie die Verbindung zu diesen VMs, bevor Sie mit dem Installationsbereich fortfahren.

Erstellen Sie auf Ihrer Workstation SSH-Schlüssel, die für die Kommunikation zwischen den Compute Engine-Instanzen verwendet werden.
```
ssh-keygen -f ./build-artifacts/consumer-edge-machine
```

Verschlüsseln Sie den privaten SSH-Schlüssel mit dem Cloud Key Management Service.

gcloud kms encrypt \
    --key gdc-ssh-key \
    --keyring gdc-ce-keyring \
    --location global \
    --plaintext-file build-artifacts/consumer-edge-machine \
    --ciphertext-file build-artifacts/consumer-edge-machine.encrypted

Generieren Sie die Umgebungskonfigurationsdatei .envrc und legen Sie sie als Quelle fest. Prüfen Sie nach dem Erstellen in der Datei .envrc, ob die Umgebungsvariablen durch die richtigen Werte ersetzt wurden.

envsubst < templates/envrc-template.sh > .envrc
source .envrc

Das folgende Beispiel zeigt eine .envrc-Datei, die durch Ersetzen der Umgebungsvariablen in der templates/envrc-template.sh-Datei generiert wurde. Die aktualisierten Zeilen sind hervorgehoben:

# GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

Compute Engine-Instanzen erstellen, in denen GKE on Bare Metal installiert ist

./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

GKE auf Bare Metal mit Ansible installieren

Mit dem in dieser Anleitung verwendeten Skript werden GKE on Bare-Metal-Cluster in Gruppen von drei Compute Engine-Instanzen erstellt. Die Anzahl der erstellten Cluster wird von der Umgebungsvariable GCE_COUNT gesteuert. Beispiel: Sie legen die Umgebungsvariable GCE_COUNT auf 6 fest, um zwei GKE on Bare Metal-Cluster mit jeweils 3 VM-Instanzen zu erstellen. Die Umgebungsvariable GCE_COUNT ist standardmäßig auf 3 festgelegt. Daher wird in dieser Anleitung ein Cluster mit 3 Compute Engine-Instanzen erstellt. Die VM-Instanzen werden mit dem Präfix cnuc-, gefolgt von einer Zahl, benannt. Die erste VM-Instanz jedes Clusters fungiert als Administratorworkstation, von der die Installation ausgelöst wird. Der Cluster erhält auch denselben Namen wie die Administrator-Workstation-VM (z. B. cnuc-1, cnuc-4, cnuc-7).

Das Ansible-Playbook tut Folgendes:

Konfiguriert die Compute Engine-Instanzen mit den erforderlichen Tools, z. B. docker, bmctl, gcloud und nomos.
GKE on Bare Metal in den konfigurierten Compute Engine-Instanzen installieren
Erstellt einen eigenständigen GKE on Bare Metal-Cluster namens cnuc-1.
Registriert den Cluster cnuc-1 bei Google Cloud.
Installiert Config Sync im Cluster cnuc-1.
Konfiguriert Config Sync für die Synchronisierung mit den Clusterkonfigurationen unter anthos-bm-edge-deployment/acm-config-sink in Ihrem verzweigten Repository.
Generiert den Login token für den Cluster.

Führen Sie die folgenden Schritte aus, um den Installationsprozess einzurichten und zu starten:

Erstellen Sie auf Ihrer Workstation das für die Installation verwendete Docker-Image. Dieses Image enthält alle für den Installationsprozess erforderlichen Tools, z. B. Ansible, Python und Google Cloud CLI.

gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

Wenn der Build erfolgreich ausgeführt wird, gibt er eine Ausgabe wie diese zurück:

...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

Generieren Sie die Ansible-Inventardatei aus einer Vorlage.

envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

Führen Sie das Installationsskript aus, das einen Docker-Container aus dem zuvor erstellten Image startet. Das Skript verwendet intern Docker, um den Container mit einer Volume-Bereitstellung im aktuellen Arbeitsverzeichnis zu erstellen. Nach erfolgreichem Abschluss dieses Skripts müssen Sie sich im erstellten Docker-Container befinden. Sie lösen die Ansible-Installation aus diesem Container aus.

./install.sh

Wenn das Skript erfolgreich ausgeführt wird, gibt es eine Ausgabe wie die folgende:

...
Check the values above and if correct, do you want to proceed? (y/N): y
Starting the installation
Pulling docker install image...

==============================
Starting the docker container. You will need to run the following 2 commands (cut-copy-paste)
==============================
1: ./scripts/health-check.sh
2: ansible-playbook all-full-install.yaml -i inventory
3: Type 'exit' to exit the Docker shell after installation
==============================
Thank you for using the quick helper script!
(you are now inside the Docker shell)

Prüfen Sie im Docker-Container den Zugriff auf die Compute Engine-Instanzen.

./scripts/health-check.sh

Wenn das Skript erfolgreich ausgeführt wird, gibt es eine Ausgabe wie die folgende:

...
cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}

Führen Sie im Docker-Container das Ansible-Playbook zur Installation von GKE on Bare Metal auf Compute Engine-Instanzen aus. Nach Abschluss des Vorgangs wird die Login Token für den Cluster auf dem Bildschirm angezeigt.

ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

Wenn die Installation erfolgreich ausgeführt wird, erhalten Sie eine Ausgabe wie die folgende:

...
TASK [abm-login-token : Display login token] **************************************************************************
ok: [cnuc-1] => {
    "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW
iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd
4CwanGlof6s-fbu8"
}
skipping: [cnuc-2]
skipping: [cnuc-3]

PLAY RECAP ***********************************************************************************************************
cnuc-1                     : ok=205  changed=156  unreachable=0    failed=0    skipped=48   rescued=0    ignored=12
cnuc-2                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2
cnuc-3                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2

In der Google Cloud Console im GKE on Bare Metal-Cluster anmelden

Nachdem das Ansible-Playbook vollständig ausgeführt wurde, wird ein eigenständiger GKE on Bare-Metal-Cluster in den Compute Engine-VMs installiert. Dieser Cluster wird auch mit dem Connect Agent bei Google Cloud registriert. Wenn Sie jedoch Details zu diesem Cluster sehen möchten, müssen Sie sich über die Google Cloud Console beim Cluster anmelden. Führen Sie die folgenden Schritte aus, um sich beim Cluster anzumelden.

Kopieren Sie das Token aus der Ausgabe des Ansible-Playbook im vorherigen Abschnitt.

Hinweis: Wenn Sie keinen Zugriff mehr auf die Konsolenausgabe haben, suchen Sie in der Logdatei unter ./build-artifacts/ansible-run.log nach Ihrem Token. Sie können auch das folgende Ansible-Playbook ausführen, um das Token noch einmal abzurufen: ansible-playbook all-get-login-tokens.yaml -i inventory
Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf und melden Sie sich mit dem kopierten Token beim Cluster cnuc-1 an.

Zur Seite "Kubernetes-Cluster"
1. Klicken Sie in der Liste der Cluster neben dem Cluster cnuc-1 auf Aktionen und dann auf Anmelden.
2. Wählen Sie Token aus und fügen Sie das kopierte Token ein.
3. Klicken Sie auf Anmelden.
Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.

Zur Konfiguration

Prüfen Sie auf dem Tab Pakete in der Clustertabelle die Spalte Synchronisierungsstatus. Prüfen Sie, ob der Status Synchronisiert lautet. Der Status Synchronisiert bedeutet, dass Config Sync Ihre GitHub-Konfigurationen erfolgreich mit dem bereitgestellten Cluster cnuc-1 synchronisiert hat.

Proxy für externen Traffic konfigurieren

Der in den vorherigen Schritten installierte GKE on Bare Metal-Cluster verwendet einen gebündelten Load-Balancer namens MetalLB. Auf diesen Load-Balancer-Dienst kann nur über eine VPC-IP-Adresse (Virtual Private Cloud) zugegriffen werden. Damit der über die externe IP-Adresse eingehende Traffic an den gebündelten Load-Balancer weitergeleitet werden kann, müssen Sie im Administratorhost (cnuc-1) einen Reverse-Proxy-Dienst einrichten. Mit diesem Reverse-Proxy-Dienst können Sie den API-Server der Point-of-Sale-Anwendung über die externe IP-Adresse des Administratorhosts (cnuc-1) erreichen.

Mit den Installationsskripts in den vorherigen Schritten wurde NGINX zusammen mit einer Beispielkonfigurationsdatei auf den Administratorhosts installiert. Aktualisieren Sie diese Datei, um die IP-Adresse des Load-Balancer-Dienstes zu verwenden, und starten Sie NGINX neu.

Verwenden Sie SSH auf Ihrer Workstation, um sich bei der Administrator-Workstation anzumelden:
```
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1
```
Richten Sie in der Administrator-Workstation den NGINX-Reverse-Proxy ein, um den Traffic an den Load-Balancer-Dienst des API-Servers weiterzuleiten. Rufen Sie die IP-Adresse des Kubernetes-Dienstes des Load-Balancers-Typs ab:
```
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
```

Aktualisieren Sie die Vorlagenkonfigurationsdatei mit der abgerufenen IP-Adresse:

sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

Starten Sie NGINX neu, damit die neue Konfiguration angewendet wird:
```
sudo systemctl restart nginx
```

Prüfen und verifizieren Sie den Status des NGINX-Servers, um „active (running)“ zu melden:

sudo systemctl status nginx

Wenn NGINX erfolgreich ausgeführt wird, wird eine Ausgabe wie im folgenden Beispiel erzeugt:

● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago
    Docs: man:nginx(8)
    Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 92573 (nginx)
    Tasks: 17 (limit: 72331)
    Memory: 13.2M
    CGroup: /system.slice/nginx.service
            ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─92574 nginx: worker process
            ├─92575 nginx: worker process
            ├─92577 nginx: ....
            ...
            ...

Beenden Sie die SSH-Sitzung auf der Administrator-Workstation:
```
exit
```
Beenden Sie die Shell-Sitzung in den Docker-Container. Nachdem die Administratorinstanz beendet wurde, befinden Sie sich noch im Docker-Container, der für die Installation verwendet wurde:
```
exit
```

Auf die Kassenanwendung zugreifen

Mit der externen Proxyeinrichtung können Sie auf die Anwendung zugreifen, die im Cluster ausgeführt wird. Führen Sie die folgenden Schritte aus, um auf die Beispiel-Point-of-Sale-Anwendung zuzugreifen.

Rufen Sie auf Ihrer Workstation die externe IP-Adresse der Compute Engine-Administratorinstanz ab und greifen Sie auf die UI der Kassenanwendung zu:

EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

Wenn die Skripts erfolgreich ausgeführt werden, produzieren sie in etwa folgende Ausgabe:

Point the browser to: 34.134.194.84:8082

Öffnen Sie Ihren Webbrowser und rufen Sie die IP-Adresse auf, die in der Ausgabe des vorherigen Befehls angezeigt wurde. Sie können auf die Beispiel-Point-of-Sale-Anwendung zugreifen und sie testen, wie im folgenden Beispiel-Screenshot gezeigt:

API-Server mit Config Sync aktualisieren

Sie können die Beispielanwendung auf eine neuere Version aktualisieren, indem Sie die Konfigurationsdateien im Root-Repository aktualisieren. Config Sync erkennt die Aktualisierungen und nimmt die Änderungen automatisch am Cluster vor. In diesem Beispiel ist das Root-Repository das anthos-samples-Repository, das Sie am Anfang dieser Anleitung geklont haben. Führen Sie die folgenden Schritte aus, um zu sehen, wie die Beispiel-Point-of-Sale-Anwendung eine Upgradebereitstellung auf eine neuere Version durchlaufen kann.

Aktualisieren Sie auf Ihrer Workstation das Feld image, um die Version des API-Servers von v1 in v2 zu ändern. Die YAML-Konfiguration für das Deployment befindet sich in der Datei unter anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.
```
containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
```
Fügen Sie die Änderungen dem verzweigten Repository hinzu, führen Sie dafür einen Commit durch und übertragen Sie die Änderungen:
```
git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push
```
Rufen Sie in der Google Cloud Console die Seite Config Management auf, um den Status der Konfigurationsspezifikation zu prüfen. Prüfen Sie, ob der Status Synchronisiert lautet.

Zur Seite „Config Management“
Rufen Sie in der Google Cloud Console die Seite Kubernetes Engine-Arbeitslasten auf, um nachzusehen, ob das Deployment aktualisiert wurde.

Zur Seite "Kubernetes Engine-Arbeitslasten"
Wenn der Status der Bereitstellung OK lautet, zeigen Sie mit dem Browser die IP-Adresse aus dem vorherigen Abschnitt an, um die Kassenanwendung aufzurufen. Beachten Sie, dass die Version im Titel „V2“ anzeigt. Dies bedeutet, dass Ihre Anwendungsänderung bereitgestellt wurde, wie im folgenden Beispiel-Screenshot gezeigt:

Möglicherweise müssen Sie den Browser-Tab vollständig aktualisieren, damit die Änderungen angezeigt werden.

Bereinigen

Löschen Sie die für diese Anleitung verwendeten Ressourcen, um unnötige Google Cloud-Gebühren zu vermeiden. Sie können diese Ressourcen entweder manuell löschen oder Ihr Google Cloud-Projekt löschen, wodurch auch alle Ressourcen entfernt werden. Darüber hinaus können Sie auch die Änderungen bereinigen, die Sie auf Ihrer lokalen Workstation vorgenommen haben:

Lokale Workstation

Die folgenden Dateien müssen aktualisiert werden, um Änderungen zu löschen, die von den Installationsskripts vorgenommen wurden.

Entfernen Sie die Compute Engine-VM-IP-Adressen, die der Datei /etc/hosts hinzugefügt wurden.
Entfernen Sie die SSH-Konfiguration für cnuc-* in der Datei ~/.ssh/config.
Entfernen Sie die Fingerabdrücke der Compute Engine-VM aus der Datei ~/.ssh/known_hosts.

Projekt löschen

Wenn Sie für dieses Verfahren ein dediziertes Projekt erstellt haben, löschen Sie das Google Cloud-Projekt aus der Google Cloud Console.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

In the Google Cloud console, go to the Manage resources page.

Go to Manage resources

In the project list, select the project that you want to delete, and then click Delete.

In the dialog, type the project ID, and then click Shut down to delete the project.

Manuell

Wenn Sie für dieses Verfahren ein vorhandenes Projekt verwendet haben, gehen Sie so vor:

Heben Sie die Registrierung aller Kubernetes-Cluster mit einem Namen auf, dem cnuc- vorangestellt ist.
Löschen Sie alle Compute Engine-VMs mit einem Namen, dem das Präfix cnuc- vorangestellt ist.
Löschen Sie den Cloud Storage-Bucket mit einem Namen, dem abm-edge-boot vorangestellt ist.
Löschen Sie die Firewallregeln allow-pod-ingress und allow-pod-egress.
Löschen Sie das Secret Manager-Secret install-pub-key.

Nächste Schritte

Sie können diese Anleitung erweitern, indem Sie einen weiteren Edge-Standort hinzufügen. Wenn Sie die Umgebungsvariable GCE_COUNT auf 6 setzen und dieselben Schritte wie in den vorherigen Abschnitten wiederholen, werden drei neue Compute Engine-Instanzen (cnuc-4, cnuc-5, cnuc-6) und ein neuer eigenständiger GKE on Bare Metal-Cluster namens cnuc-4 erstellt.

Sie können auch die Clusterkonfigurationen in Ihrem verzweigten Repository aktualisieren, um selektiv verschiedene Versionen der Point-of-Sale-Anwendung auf die beiden Cluster cnuc-1 und cnuc-4 mit ClusterSelectors anzuwenden.

Weitere Informationen zu den einzelnen Schritten in dieser Anleitung und den betroffenen Skripts finden Sie im Repository anthos-samples.