Diese Seite wurde von der Cloud Translation API übersetzt.

Lernpfad: Skalierbare Anwendungen – Cluster erstellen

Diese Reihe von Anleitungen richtet sich an IT-Administratoren und Operatoren, die moderne Anwendungsumgebungen, die in Google Kubernetes Engine (GKE) ausgeführt werden, bereitstellen, ausführen und verwalten möchten. In diesen Anleitungen erfahren Sie, wie Sie Monitoring und Benachrichtigungen konfigurieren, Arbeitslasten skalieren und Fehler simulieren – und zwar anhand der Beispiel-Mikrodienstanwendung „Cymbal Bank“:

Cluster erstellen und Beispielanwendung bereitstellen (diese Anleitung)
Umgebungen mit Google Cloud Managed Service for Prometheus überwachen
Arbeitslasten skalieren
Fehler simulieren
Änderungsmanagement zentralisieren

Übersicht und Ziele

Cymbal Bank verwendet Python und Java, um die verschiedenen Dienste auszuführen, und enthält ein PostgreSQL-Backend. Sie müssen keine Erfahrung mit diesen Sprachen oder Datenbankplattformen haben, um die Reihe der Anleitungen durchzugehen, da Cymbal Bank nur eine Beispielanwendung ist, die zeigt, wie GKE die Anforderungen Ihres Unternehmens erfüllen kann.

In dieser Anleitung erfahren Sie, wie Sie einen einzelnen GKE-Cluster erstellen und eine auf Mikrodiensten basierende Beispielanwendung namens „Cymbal Bank“ in einem GKE-Cluster bereitstellen. Sie lernen, wie Sie die folgenden Aufgaben ausführen:

Erstellen Sie einen GKE-Cluster, der Autopilot verwendet.
Stellen Sie eine auf Mikrodiensten basierende Beispielanwendung namens „Cymbal Bank“ bereit.
Sehen Sie sich in der Google Cloud Console die von der Cymbal Bank-Beispielanwendung verwendeten GKE-Ressourcen an.

Cluster erstellen

Nachdem Sie alle erforderlichen Schritte in den vorherigen Abschnitten abgeschlossen haben, können Sie jetzt einen GKE-Cluster erstellen und eine Beispielanwendung bereitstellen.

GKE ist ein verwalteter Kubernetes-Dienst, mit dem Sie containerisierte Anwendungen bereitstellen und betreiben können. Eine GKE-Umgebung besteht aus Knoten, bei denen es sich um virtuelle Compute Engine-Maschinen (VMs) handelt, die zusammen einen Cluster bilden.

Sie erstellen nun einen GKE-Cluster, den Sie in den restlichen Anleitungen dieser Reihe verwenden werden:
```
gcloud container clusters create-auto scalable-apps \
  --project=PROJECT_ID \
  --location=CONTROL_PLANE_LOCATION
```
Ersetzen Sie dabei Folgendes:
- PROJECT_ID durch die automatisch generierte ID des Projekts ersetzen, das Sie im vorherigen Abschnitt erstellt haben. Die Projekt-ID unterscheidet sich oft vom Projektnamen. Ihr Projekt könnte beispielsweise scalable-apps sein, Ihre Projekt-ID jedoch scalable-apps-567123.
- CONTROL_PLANE_LOCATION: die Compute Engine-Region der Steuerungsebene des Clusters. Geben Sie eine Region an, z. B. us-central1.
Es dauert einige Minuten, bis der Cluster erstellt ist und geprüft wurde, ob alles richtig funktioniert.

In diesen Anleitungen verwenden Sie Cluster im Autopilot-Modus sowie einige Standard-IP-Adressbereiche, wenn Sie Cluster erstellen. Für die Produktionsbereitstellung Ihrer eigenen Anwendungen ist eine sorgfältigere IP-Adressplanung erforderlich. Im Autopilot-Modus verwaltet Google Ihre Clusterkonfiguration, einschließlich Autoskalierung, Sicherheit und andere vorkonfigurierte Einstellungen. Cluster im Autopilot-Modus sind für die Ausführung der meisten Produktionsarbeitslasten optimiert und Rechenressourcen bereitstellen, die auf Ihren Kubernetes-Manifesten basieren.

Cymbal Bank bereitstellen

Sie verpacken Anwendungen (auch Arbeitslasten genannt) in Container. Containergruppen werden als Pods auf Ihren Knoten bereitgestellt.

In dieser Anleitungsreihe stellen Sie eine auf Mikrodiensten basierende Beispielanwendung namens „Cymbal Bank“ in einem oder mehreren GKE-Clustern bereit. Cymbal Bank verwendet Python und Java, um die verschiedenen Dienste auszuführen, und enthält ein PostgreSQL-Backend. Sie müssen keine Erfahrung mit diesen Sprachen oder Datenbankplattformen haben, um die Anleitungsserie durchzugehen. Cymbal Bank ist nur eine Beispielanwendung, die zeigt, wie GKE die Anforderungen Ihres Unternehmens ansprechen kann.

Wenn Sie Cymbal Bank als Teil dieser Anleitungen verwenden, werden die folgenden Dienste in Ihrem GKE-Cluster bereitgestellt:

Dienst	Sprache	Beschreibung
`frontend`	Python	Stellt einen HTTP-Server zur Bereitstellung der Website bereit. Enthält eine Anmelde-, eine Registrierungs- und eine Startseite.
`ledger-writer`	Java	Akzeptiert und validiert eingehende Transaktionen, bevor sie in das Verzeichnis geschrieben werden.
`balance-reader`	Java	Stellt einen effizienten lesbaren Cache von Nutzerausgleichen bereit, wie aus `ledger-db` gelesen.
`transaction-history`	Java	Bietet einen effizienten lesbaren Cache früherer Transaktionen, wie aus `ledger-db` gelesen.
`ledger-db`	PostgreSQL	Ledger mit allen Transaktionen. Option zum vorab ausfüllen mit Transaktionen für Demonutzer.
`user-service`	Python	Verwaltet Nutzerkonten und Authentifizierung. Signiert JWTs, die von anderen Diensten zur Authentifizierung verwendet werden.
`contacts`	Python	Speichert eine Liste anderer Konten, die einem Nutzer zugeordnet sind. Wird für das Drop-down-Menü in den Formularen „Zahlung senden“ und „Einzahlungen“ verwendet.
`accounts-db`	PostgreSQL	Datenbank für Nutzerkonten und zugehörige Daten. Option zum vorab ausfüllen mit Demonutzern
`loadgenerator`	Python/Locust	Sendet kontinuierlich Nutzer nachahmende Anfragen an das Frontend. Erstellt regelmäßig neue Konten und simuliert Transaktionen zwischen ihnen.

So stellen Sie Cymbal Bank in Ihrem GKE-Cluster bereit:

Cymbal Bank verwendet JSON-Web-Tokens (JWTs) für die Nutzerauthentifizierung. Für JWTs werden asymmetrische Schlüsselpaare zum Signieren und Überprüfen von Tokens verwendet. In der Cymbal Bank erstellt und signiert userservice Tokens mit einem privaten RSA-Schlüssel, wenn sich ein Nutzer anmeldet. Die anderen Dienste verwenden den entsprechenden öffentlichen Schlüssel, um den Nutzer zu authentifizieren.

Ein RS256-JWT mit einer Stärke von 4.096 Bit erstellen:
```
openssl genrsa -out jwtRS256.key 4096
openssl rsa -in jwtRS256.key -outform PEM -pubout -out jwtRS256.key.pub
```
Laden Sie bei Bedarf die OpenSSL-Tools für Ihre Plattform herunter und installieren Sie sie.
In einem Kubernetes-Secret können sensible Daten wie Schlüssel oder Passwörter gespeichert werden. Arbeitslasten, die in Ihrem Cluster ausgeführt werden, können dann auf das Secret zugreifen, um die sensiblen Daten abzurufen, anstatt dass sie in die Anwendung hartcodiert werden.

Erstellen Sie ein Kubernetes-Secret aus der Schlüsseldatei, die Sie im vorherigen Schritt erstellt haben, damit Cymbal Bank sie für Authentifizierungsanfragen verwenden kann:
```
kubectl create secret generic jwt-key --from-file=./jwtRS256.key --from-file=./jwtRS256.key.pub
```

Stellen Sie Cymbal Bank in Ihrem Cluster bereit. Mit dem folgenden Befehl werden alle Manifestdateien im kubernetes-manifests-Verzeichnis bereitgestellt. Mit jeder Manifestdatei wird einer der Dienste bereitgestellt und konfiguriert:

kubectl apply -f kubernetes-manifests/accounts-db.yaml
kubectl apply -f kubernetes-manifests/balance-reader.yaml
kubectl apply -f kubernetes-manifests/config.yaml
kubectl apply -f kubernetes-manifests/contacts.yaml
kubectl apply -f extras/postgres-hpa/kubernetes-manifests/frontend.yaml
kubectl apply -f kubernetes-manifests/ledger-db.yaml
kubectl apply -f kubernetes-manifests/ledger-writer.yaml
kubectl apply -f extras/postgres-hpa/loadgenerator.yaml
kubectl apply -f kubernetes-manifests/transaction-history.yaml
kubectl apply -f kubernetes-manifests/userservice.yaml

Möglicherweise werden in der kubectl-Ausgabe Meldungen zu Autopilot-Limits angezeigt, wenn die Manifeste auf Ihren Cluster angewendet werden. Autopilot verwendet die in Ihrer Arbeitslastkonfiguration angegebenen Ressourcenanfragen, um die Knoten zu konfigurieren, die Ihre Arbeitslasten ausführen. Autopilot erzwingt Mindest- und maximale Ressourcenanforderungen basierend auf der Compute-Klasse oder der Hardwarekonfiguration, die Ihre Arbeitslasten verwenden. Wenn Sie für einige Container keine Anfragen angeben, weist Autopilot Standardwerte zu, damit diese Container ordnungsgemäß ausgeführt werden.

Sehen Sie sich das folgende Beispielmanifest für den frontend-Service an:

# Copyright 2024 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: v1
kind: Service
metadata:
  labels:
    application: bank-of-anthos
    environment: development
    team: frontend
    tier: web
  name: frontend
spec:
  ports:
    - name: http
      port: 80
      targetPort: 8080
  selector:
    app: frontend
    application: bank-of-anthos
    environment: development
    team: frontend
    tier: web
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    application: bank-of-anthos
    environment: development
    team: frontend
    tier: web
  name: frontend
spec:
  selector:
    matchLabels:
      app: frontend
      application: bank-of-anthos
      environment: development
      team: frontend
      tier: web
  template:
    metadata:
      annotations:
        proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
      labels:
        app: frontend
        application: bank-of-anthos
        environment: development
        team: frontend
        tier: web
    spec:
      containers:
        - env:
            - name: VERSION
              value: v0.6.7
            - name: PORT
              value: "8080"
            - name: ENABLE_TRACING
              value: "true"
            - name: SCHEME
              value: http
            - name: LOG_LEVEL
              value: info
            - name: DEFAULT_USERNAME
              valueFrom:
                configMapKeyRef:
                  key: DEMO_LOGIN_USERNAME
                  name: demo-data-config
            - name: DEFAULT_PASSWORD
              valueFrom:
                configMapKeyRef:
                  key: DEMO_LOGIN_PASSWORD
                  name: demo-data-config
            - name: REGISTERED_OAUTH_CLIENT_ID
              valueFrom:
                configMapKeyRef:
                  key: DEMO_OAUTH_CLIENT_ID
                  name: oauth-config
                  optional: true
            - name: ALLOWED_OAUTH_REDIRECT_URI
              valueFrom:
                configMapKeyRef:
                  key: DEMO_OAUTH_REDIRECT_URI
                  name: oauth-config
                  optional: true
          envFrom:
            - configMapRef:
                name: environment-config
            - configMapRef:
                name: service-api-config
          image: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/frontend:v0.6.7@sha256:6d92f3ce81a389738baf236477c6795831a0802c7a007697d7121f10eab9a2cc
          livenessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 60
            periodSeconds: 15
            timeoutSeconds: 30
          name: front
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
            timeoutSeconds: 10
          resources:
            limits:
              cpu: 250m
              memory: 128Mi
            requests:
              cpu: 100m
              memory: 64Mi
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all
            privileged: false
            readOnlyRootFilesystem: true
          volumeMounts:
            - mountPath: /tmp
              name: tmp
            - mountPath: /tmp/.ssh
              name: publickey
              readOnly: true
      securityContext:
        fsGroup: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        runAsUser: 1000
      serviceAccountName: bank-of-anthos
      terminationGracePeriodSeconds: 5
      volumes:
        - emptyDir: {}
          name: tmp
        - name: publickey
          secret:
            items:
              - key: jwtRS256.key.pub
                path: publickey
            secretName: jwt-key

Dieses Manifest für den frontend-Dienst fordert 100m CPUs und 64Mi an und legt Limits von 250m CPUs und 128Mi pro Pod fest.

Wenn Sie eine Arbeitslast in einem Autopilot-Cluster bereitstellen, prüft GKE die Arbeitslastkonfiguration anhand der zulässigen Mindest- und Höchstwerte für die ausgewählte Compute-Klasse oder Hardwarekonfiguration (wie z. B. GPUs). Wenn Ihre Anfragen unter dem Mindestwert liegen, ändert Autopilot Ihre Arbeitslastkonfiguration automatisch, um Ihre Anfragen innerhalb des zulässigen Bereichs zu bringen. Diese Meldungen weisen darauf hin, dass die entsprechenden Limits automatisch zugewiesen werden.

Warten Sie, bis die Pods bereit sind. Prüfen Sie mit kubectl den Status der Pods:

kubectl get pods

Die STATUS-Spalte wechselt von Pending zu ContainerCreating. Es dauert einige Minuten, bis alle Pods den Running-Status haben, wie in der folgenden Beispielausgabe zu sehen:

NAME                                  READY   STATUS    RESTARTS   AGE
accounts-db-6f589464bc-6r7b7          1/1     Running   0          99s
balancereader-797bf6d7c5-8xvp6        1/1     Running   0          99s
contacts-769c4fb556-25pg2             1/1     Running   0          98s
frontend-7c96b54f6b-zkdbz             1/1     Running   0          98s
ledger-db-5b78474d4f-p6xcb            1/1     Running   0          98s
ledgerwriter-84bf44b95d-65mqf         1/1     Running   0          97s
loadgenerator-559667b6ff-4zsvb        1/1     Running   0          97s
transactionhistory-5569754896-z94cn   1/1     Running   0          97s
userservice-78dc876bff-pdhtl          1/1     Running   0          96s

Wenn alle Pods den Running-Status haben, fahren Sie mit dem nächsten Schritt fort. Auch hier dauert es einige Minuten, bis alle Pods den Status Running haben. Es ist normal, dass einige Pods den 0/1-Status READY melden, bis die Cymbal-Bank bereit ist, Traffic korrekt zu verarbeiten.

Der frontend-Dienst stellt einen HTTP-Server für die Bereitstellung der Website der Cymbal Bank bereit, einschließlich der Anmelde-, Registrierungs- und Startseite. Ein Ingress-Objekt definiert Regeln zum Weiterleiten von HTTP(S)-Traffic an Anwendungen, die in einem Cluster ausgeführt werden, mithilfe eines Google Cloud HTTP(S)-Load-Balancers.

Rufen Sie die externe IP-Adresse für den frontend-Ingress ab:
```
kubectl get ingress frontend | awk '{print $4}'
```
Öffnen Sie im Fenster eines Webbrowsers die IP-Adresse, die in der Ausgabe des kubectl get ingress-Befehls angezeigt wird, um auf Ihre Cymbal Bank-Instanz zuzugreifen.

Die Standardanmeldedaten werden automatisch eingefügt. Sie können sich also in der App anmelden und einige der Beispieltransaktionen und ‑guthaben ansehen. Sie müssen nichts weiter tun, als zu prüfen, ob Cymbal-Bank ordnungsgemäß funktioniert. Es kann ein bis zwei Minuten dauern, bis alle Dienste richtig kommunizieren und Sie sich anmelden können.

Bereitstellung untersuchen

Nachdem Sie einen GKE-Cluster erstellt und Arbeitslasten bereitgestellt haben, müssen Sie möglicherweise Einstellungen ändern oder die Leistung Ihrer Anwendung überprüfen. In diesem Abschnitt erfahren Sie, wie Sie in der Google Cloud -Konsole die Ressourcen prüfen, die zu Ihrem Cluster und der Cymbal Bank-Beispielanwendung gehören.

Cluster

In dieser Anleitung haben Sie einen GKE-Cluster erstellt und die Cymbal Bank-Arbeitslasten bereitgestellt.

Rufen Sie in der Google Cloud Console auf der Seite „Google Kubernetes Engine“ die Seite Cluster auf.

ZUR CLUSTERSEITE
Klicken Sie auf den neu bereitgestellten Cluster scalable-apps. Auf der Seite mit den Clusterdetails, die sich öffnet, können Sie grundlegende Clusterdetails sowie die Netzwerk- und Sicherheitskonfigurationen des Clusters ansehen. Im Abschnitt Funktionen können Sie auch sehen, welche GKE-Funktionen in diesem Cluster aktiviert sind.

Beobachtbarkeit

Sie können sich grundlegende Messwerte für den Zustand und die Leistung Ihres Clusters ansehen. Im nächsten Teil dieser Reihe aktivieren Sie Google Cloud Managed Service for Prometheus für ein detaillierteres Monitoring und eine bessere Beobachtbarkeit.

Wählen Sie in derGoogle Cloud Console auf der Seite Cluster der Google Kubernetes Engine Ihren Cluster aus und gehen Sie dann zum Tab Beobachtbarkeit.
Sehen Sie sich einige der Messwertgrafiken an, z. B. für CPU und Arbeitsspeicher. In dieser Ansicht können Sie die Leistung der verschiedenen Teile Ihrer Clusterarbeitslasten überwachen, ohne zusätzliche Monitoringfunktionen bereitstellen zu müssen.
Wenn Sie Logs aufrufen möchten, die von Ihrem Cluster gestreamt werden, wählen Sie den Tab Logs aus. Sie können nach dem Schweregrad der Protokolle filtern oder eigene Filter erstellen, um bestimmte Namespaces, Dienste oder Pods anzuzeigen. Wie bei Pod-Warnungen und ‑Ereignissen kann diese zusammengefasste Ansicht von Logs aus Ihrem Cluster helfen, Probleme schnell über die Google Cloud Konsole zu beheben.

Es ist normal, dass bei der ersten Bereitstellung der Cymbal-Bank Logeinträge angezeigt werden, da einige Dienste noch nicht kommunizieren können.
Wählen Sie den Tab App-Fehler aus. Während Ihre Arbeitslasten ausgeführt werden, können Sie die zusammengefassten Warnungen und Ereignisse in der Google Cloud -Konsole aufrufen. Dieser Ansatz kann helfen, Probleme zu beheben, ohne dass Sie eine Verbindung zum Cluster, zu Knoten oder zu Pods herstellen müssen.

Es ist normal, dass Ereignisse protokolliert werden, wenn die Cymbal-Bank zum ersten Mal bereitgestellt wird, da einige Dienste noch nicht kommunizieren können.

Arbeitslasten

Auf der GKE-Seite der Google Cloud Console finden Sie den Bereich Arbeitslasten mit einer zusammengefassten Ansicht der Arbeitslasten, die auf allen Ihren GKE-Clustern ausgeführt werden.

Rufen Sie in der Google Kubernetes Engine-Konsole Google Cloud die Seite Arbeitslasten auf.

Zur Seite „Arbeitslasten“

Auf dem Tab Übersicht wird eine Liste der Arbeitslasten und Namespaces aus dem GKE-Cluster angezeigt. Sie können nach Namespaces filtern, um zu sehen, welche Arbeitslasten in den einzelnen Namespaces ausgeführt werden.

Dienste und Ingress

Die Ansicht Services und Ingress zeigt die Service- und Ingress-Ressourcen des Projekts an. Ein Service stellt eine Reihe von Pods als Netzwerkdienst mit einem Endpunkt bereit, während ein Ingress den externen Zugriff auf die Dienste in einem Cluster verwaltet.

Rufen Sie in der Google Cloud -Konsole auf der Seite „Google Kubernetes Engine“ die Seite Gateways, Dienste und Ingress auf.

Zur Seite "Gateways, Dienste und Ingress"
Klicken Sie auf den Tab Ingress und suchen Sie nach dem eingehenden Traffic mit dem Namen frontend, um den Cymbal Bank-Ingress zu finden. Ein Ingress verwaltet eingehenden Traffic für Ihre Anwendung. Sie können Informationen zum Load Balancer, zu Ports und zu externen Endpunkten aufrufen.
Klicken Sie auf die IP-Adresse für den frontend-Ingress, z. B. 198.51.100.143:80. Über diese Adresse wird die Cymbal Bank-Weboberfläche geöffnet.