Version 1.14. This version is no longer supported. For information about how to upgrade to version 1.15, see Upgrading Anthos on bare metal in the 1.15 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

Google Distributed Cloud Virtual für 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 Management 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 Edge-Geräten bereitgestellt werden, und eine beispielhafte Point-of-Sale-Anwendung als Edge-Arbeitslast. GKE on Bare Metal und Config Management bieten zentrale Verwaltung und Kontrolle für Ihren Edge-Cluster. Config Management 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 des Unternehmens und dem Kunden. Softwaresysteme in Geschäften müssen ihre Arbeitslasten ausführen, zeitnah Updates erhalten und kritische Messwerte vom zentralen Verwaltungssystem des Unternehmens isolieren. Darüber hinaus müssen diese Softwaresysteme so konzipiert werden, dass sie in Zukunft auf weitere Standorte ausgeweitet werden können. Während GKE on Bare Metal alle diese Anforderungen an Geschäftssoftwaresysteme erfüllt, ermöglicht das Edge-Profil einen wichtigen Anwendungsfall: Bereitstellungen in Umgebungen mit begrenzten Hardwareressourcen, z. B. in einer Einzelhandelsfiliale.

Das folgende Diagramm zeigt eine GKE on Bare Metal-Bereitstellung, die das Edge-Profil in einem Einzelhandelsgeschäft verwendet:

Zeigt eine GKE on Bare Metal-Bereitstellung, die das Edge-Profil in einem Einzelhandel verwendet — Eine GKE on Bare Metal-Bereitstellung in einem Einzelhandel

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 Speicher hat außerdem drei physische Hardwaregeräte mit den Bezeichnungen Node 1, Node 2 und Node 3. Alle diese Geräte sind mit einem zentralen Netzwerk-Switch verbunden. Somit sind die drei Rechengeräte über ein Layer-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 konfiguriert, um Hochverfügbarkeit zu gewährleisten.

Das Diagramm zeigt außerdem die folgenden Schlüsselkomponenten, 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 Management-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 Management und den verschiedenen Nomenklaturen finden Sie in der Dokumentation zu Config Management.
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 Aktualisierungen aus den Quell-Repositories ab. Dieses Verhalten wird durch die Pfeile dargestellt, die die beiden Repositories im Diagramm mit den Config Management-Komponenten im Cluster Google Distributed Cloud Virtual for Bare Metal verbinden, der auf den Geräten ausgeführt wird.
Eine weitere wichtige Komponente, die als Teil des Clusters dargestellt wird, ist die VM-Laufzeit in Google Distributed Cloud. Mit der VM-Laufzeit in Google Distributed Cloud können vorhandene VM-basierte Arbeitslasten im Cluster ohne Containerisierung ausgeführt werden. In der Dokumentation zur VM-Laufzeit in Google Distributed Cloud wird erläutert, wie Sie sie aktivieren und Ihre VM-Arbeitslasten im Cluster bereitstellen.
Die mit Anwendung gekennzeichnete Komponente gibt Software an, die vom Einzelhandelsgeschäft im Cluster bereitgestellt wird. Ein Beispiel für eine solche Anwendung ist die in den Kiosken eines Einzelhandelsgeschäfts sichtbare Point-of-Sale-Anwendung.

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

Im folgenden Diagramm sehen Sie alles, was Sie in dieser Anleitung in Google Cloud einrichten. Dieses Diagramm korreliert mit dem Diagramm des Einzelhandelsgeschäfts 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.

Die Abbildung zeigt die Architektur der Point-of-Sale-Anwendung und wie sie in einem Google Distributed Cloud Virtual for Bare Metal-Cluster bereitgestellt wird, der auf Compute Engine-VMs ausgeführt wird. — Eine Beispielanwendung, die in einem Google Distributed Cloud Virtual for Bare Metal-Cluster bereitgestellt 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. Für diese Anleitung richten Sie jedoch keinen externen Load-Balancer ein. Stattdessen verwenden Sie den gebündelten MetalLB-Load-Balancer, der mit GKE on Bare Metal installiert ist. Der gebündelte MetalLB-Load-Balancer erfordert eine Layer-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 Google Distributed Cloud Virtual for 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 innerhalb des Clusters dar. Alle Komponenten in diesem Kubernetes-Namespace bilden die Point-of-Sale-Anwendung, die im Anthos-Cluster bereitgestellt wird. Die Point-of-Sale-Anwendung umfasst drei Mikrodienste: den API-Server, das Inventar und die 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 Anthos-Clusters kann von außerhalb der VMs nicht direkt erreicht werden. Das Diagramm zeigt einen NGINX-Reverse-Proxy, der so konfiguriert ist, dass er in den VMs ausgeführt wird, um den von den Compute Engine-VMs eingehenden Traffic an den Load-Balancer weiterzuleiten. Dies ist nur eine Problemumgehung für die Zwecke dieser Anleitung, in denen die Edge-Knoten mit 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 Google Distributed Cloud Virtual for Bare Metal-Cluster in der emulierten Edge-Infrastruktur.
Verbinden Sie den Cluster und registrieren Sie ihn bei Google Cloud.
Stellen Sie eine Beispielarbeitslast für eine Kassenanwendung im Anthos-Cluster bereit.
Verwenden Sie die Google Cloud Console, um die Kassenanwendung zu verifizieren und zu überwachen, die am Edge-Standort ausgeführt wird.
Verwenden Sie Config Management, um die Point-of-Sale-Anwendung zu aktualisieren, die auf dem Anthos-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.

Repository verzweigen und klonen

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 Management 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, das in der Config Management-Konfiguration verwendet werden soll. Dies ist erforderlich, damit sich die Config Management-Komponenten im Cluster bei Ihrem GitHub-Konto authentifizieren können, wenn versucht wird, neue Änderungen zu synchronisieren.
1. Wählen Sie nur den Bereich public_repo aus.
2. Speichern Sie das von Ihnen erstellte Zugriffstoken an einem sicheren Ort, um es später zu verwenden.
Erstellen Sie einen Fork des Repositorys anthos-samples in Ihrem eigenen GitHub-Konto:
1. Rufen Sie das Repository anthos-samples auf.
2. Klicken Sie rechts oben auf 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 anthos-Beispiel-Repositorys weitergeleitet.
Öffnen Sie ein Terminal in der lokalen Umgebung.
Klonen Sie den Fork des Repositorys 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 der Fork 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 Zugriff auf das Internet und die folgenden installierten 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 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 Cloud Key Management Service-Schlüsselbund und -Schlüssel für die SSH-Verschlüsselung mit privaten Schlüsseln eingerichtet.

./scripts/create-primary-gsa.sh

Ein Teil des Skripts ist unten zu sehen. Klicken Sie auf den Link View on GitHub, um das gesamte Skript zu sehen.

anthos-bm-edge-deployment/scripts/create-primary-gsa.sh

Auf GitHub ansehen

# ...
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 beziehen Sie sie ein. Prüfen Sie nach dem Erstellen 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 wird. Beachten Sie, dass die aktualisierten Zeilen hervorgehoben sind:

anthos-bm-edge-deployment/templates/envrc.example

Auf GitHub ansehen

# 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 on Bare Metal mit Ansible installieren

Das in dieser Anleitung verwendete Skript erstellt Google Distributed Cloud Virtual für Bare-Metal-Cluster in Gruppen von drei Compute Engine-Instanzen. Die Anzahl der erstellten Cluster wird durch die Umgebungsvariable GCE_COUNT gesteuert. Sie legen beispielsweise die Umgebungsvariable GCE_COUNT auf 6 fest, um zwei Google Distributed Cloud Virtual for Bare Metal-Cluster mit jeweils 3 VM-Instanzen zu erstellen. Standardmäßig ist die Umgebungsvariable GCE_COUNT 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 aus die Installation ausgelöst wird. Der Cluster erhält auch den gleichen 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 Google Distributed Cloud Virtual for Bare Metal-Cluster namens cnuc-1.
Registriert den Cluster cnuc-1 bei Google Cloud.
Config Management wird im cnuc-1-Cluster installiert.
Konfiguriert Config Management für die Synchronisierung mit den Clusterkonfigurationen unter anthos-bm-edge-deployment/acm-config-sink in Ihrem Fork-Repository.
Generiert den Login token für den Cluster.

Führen Sie die folgenden Schritte aus, um die Installation 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 wie Ansible, Python und Google Cloud CLI.

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

Wenn der Build erfolgreich ausgeführt wird, ergibt sich eine Ausgabe wie diese:

...
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. Wenn dieses Skript erfolgreich abgeschlossen wurde, 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, erhalten Sie 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, erhalten Sie 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 beim GKE on Bare Metal-Cluster anmelden

Nachdem das Ansible-Playbook vollständig ausgeführt wurde, wird ein eigenständiges Google Distributed Cloud Virtual for Bare Metal-Cluster auf den Compute Engine-VMs installiert. Dieser Cluster wird über den Connect-Agent auch 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 GKE-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 verwenden Sie das kopierte Token, um sich beim Cluster cnuc-1 anzumelden.

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 Login.

Rufen Sie in der Google Cloud Console die Seite Config Management (Konfigurationsverwaltung) auf, um den Status der Konfigurationsspezifikation zu prüfen. Prüfen Sie, ob der Status Synchronisiert lautet. Der Status Synched gibt an, dass Ihre GitHub-Konfigurationen von Config Management erfolgreich mit dem bereitgestellten Cluster cnuc-1 synchronisiert wurden.

Zur Seite „Config Management“

Proxy für externen Traffic konfigurieren

Der in den vorherigen Schritten installierte Google Distributed Cloud Virtual for 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 einen Reverse-Proxy-Dienst auf dem Administratorhost (cnuc-1) 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-Balancer-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 die Berichte „aktiv (wird ausgeführt)“ 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 zur Administrator-Workstation:
```
exit
```
Beenden Sie die Shell-Sitzung in den Docker-Container. Wenn Sie die Administratorinstanz beenden, befinden Sie sich noch im Docker-Container, der für die Installation verwendet wurde:
```
exit
```

Auf die Kassenanwendung zugreifen

Mit der Einrichtung des externen Proxys können Sie auf die Anwendung zugreifen, die im GKE-Cluster ausgeführt wird. So greifen Sie auf die Beispiel-Point-of-Sale-Anwendung zu:

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:

Config Management zum Aktualisieren des API-Servers verwenden

Sie können die Beispielanwendung auf eine neuere Version aktualisieren, indem Sie die Konfigurationsdateien im Root-Repository aktualisieren. Config Management erkennt die Aktualisierungen und nimmt automatisch die Änderungen an Ihrem Cluster vor. In diesem Beispiel ist das Root-Repository das Repository anthos-samples, 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 ein Upgrade 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 die Bereitstellung befindet sich in der Datei unter anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.

anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml

Auf GitHub ansehen
```
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 hinzu, führen Sie einen Commit durch und übertragen Sie die Änderungen in das verzweigte Repository:
```
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 (Konfigurationsverwaltung) 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. Die Version im Titel enthält „V2“. Dies bedeutet, dass Ihre Anwendungsänderung bereitgestellt wurde, wie im folgenden Beispiel-Screenshot gezeigt:

Möglicherweise müssen Sie den Browsertab neu laden, 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.

Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

Zur Seite „Ressourcen verwalten“

Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.

Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

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 die gleichen Schritte aus den vorherigen Abschnitten noch einmal ausführen, werden drei neue Compute Engine-Instanzen (cnuc-4, cnuc-5, cnuc-6) und ein neuer eigenständiger Cluster von Google Distributed Cloud Virtual for Bare Metal mit dem Namen 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.