Anthos Service Mesh 1.8 ist abgelaufen und wird nicht mehr unterstützt. Siehe Upgraden von früheren Versionen.

Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Verfügbare Versionen

Anwendung für Anthos Service Mesh vorbereiten

Anthos Service Mesh ist ein leistungsstarkes Tool für die Verwaltung und das Monitoring verteilter Anwendungen. Damit Sie Anthos Service Mesh optimal nutzen können, ist es hilfreich, die zugrunde liegenden Abstraktionen zu verstehen, einschließlich Container und Kubernetes. Diese Anleitung führt Sie vom Quellcode zu einem in GKE ausgeführten Container. Am Ende sind Sie bereit für die Installation von Anthos Service Mesh.

Wenn Sie mit den Konzepten von Kubernetes und Service Mesh bereits vertraut sind, können Sie diese Anleitung überspringen und direkt die Installationsanleitungen für Anthos Service Mesh lesen.

Lernziele

In dieser Anleitung erwartet Sie Folgendes:

Einfache „Hello World“-Anwendung für mehrere Services kennenlernen
Anwendung aus der Quelle ausführen
Anwendung containerisieren
Kubernetes-Cluster erstellen
Container im Cluster bereitstellen

Hinweise

Aktivieren Sie die Anthos Service Mesh API mit den folgenden Schritten:

Rufen Sie in der Google Cloud Console die Seite Kubernetes Engine auf.
Erstellen Sie ein Projekt oder wählen Sie eins aus.
Warten Sie, bis die API und die zugehörigen Dienste aktiviert worden sind. Dieser Vorgang kann einige Minuten dauern.

Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

Sie können diese Anleitung mit Cloud Shell ausführen, die eine virtuelle g1-small Google Compute Engine-Maschine (VM) bereitstellt, auf der ein Debian-basiertes Linux-Betriebssystem ausgeführt wird. Sie können aber auch Ihren eigenen Computer unter Linux oder macOS verwenden.

Option A: Cloud Shell verwenden

Cloud Shell bietet folgende Vorteile:

Die Entwicklungsumgebungen Python 2 und Python 3 (einschließlich virtualenv) sind fertig eingerichtet.
Die in dieser Anleitung verwendeten gcloud-, docker-, git- und kubectl-Befehlszeilentools sind bereits installiert.
Es stehen verschiedene Texteditoren zur Auswahl:
- Code-Editor, auf den Sie zugreifen, indem Sie oben im Cloud Shell-Fenster auf klicken.
- Emacs, Vim oder Nano, auf die Sie in Cloud Shell über die Befehlszeile zugreifen.

So verwenden Sie Cloud Shell:

Öffnen Sie die Google Cloud Console.
Klicken Sie im oberen Bereich des Google Cloud Console-Fensters auf Cloud Shell aktivieren.

Im unteren Bereich der Google Cloud Console wird ein neues Feld mit einer Cloud Shell-Sitzung und einer Befehlszeilen-Eingabeaufforderung geöffnet.

Option B: Befehlszeilentools lokal verwenden

Wenn Sie diese Anleitung lieber auf Ihrem Linux- oder macOS-Computer ausführen möchten, müssen Sie Folgendes tun:

Richten Sie eine Entwicklungsumgebung für Python 3 und Python 2 ein.
Installieren Sie die Google Cloud CLI.
Installieren Sie außerdem kubectl für die Befehlszeile, die Sie zur Kommunikation mit Kubernetes verwenden.
```
gcloud components install kubectl
```
Installieren Sie Docker Community Edition (CE). Sie verwenden das docker-Befehlszeilentool, um Container-Images der Beispielanwendung zu erstellen.
Installieren Sie das Tool Git Source Control, damit Sie die Beispielanwendung von GitHub herunterladen können.

Beispielcode herunterladen

Laden Sie den Quellcode helloserver herunter:

git clone https://github.com/GoogleCloudPlatform/istio-samples

Öffnen Sie das Verzeichnis mit dem Beispielcode:
```
cd istio-samples/sample-apps/helloserver
```

Anwendung für mehrere Services kennenlernen

Die Beispielanwendung ist in Python geschrieben und besteht aus zwei Komponenten, die mit REST kommunizieren:

server: Ein einfacher Server mit einem GET-Endpunkt (/), der „Hello World“ an die Console ausgibt.
loadgen: Ein Skript, das Traffic an server mit einer konfigurierbaren Anzahl von Anfragen pro Sekunde (RPS) sendet.

Beispielanwendung

Anwendung aus der Quelle ausführen

Um sich mit der Beispielanwendung vertraut zu machen, führen Sie sie in Cloud Shell oder auf Ihrem Computer aus.

Führen Sie im Verzeichnis sample-apps/helloserver den Befehl server aus:
```
python3 server/server.py
```
Beim Start zeigt server Folgendes an:
```
INFO:root:Starting server...
```
Öffnen Sie ein anderes Terminalfenster, damit Sie Anfragen an server senden können. Wenn Sie Cloud Shell verwenden, klicken Sie auf , um eine weitere Sitzung zu öffnen.
Senden Sie eine Anfrage an server:
```
curl http://localhost:8080
```
Der server antwortet:
```
Hello World!
```
Wechseln Sie von dem Verzeichnis, in das Sie den Beispielcode heruntergeladen haben, in das Verzeichnis, das loadgen enthält:
```
cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/loadgen
```

Erstellen Sie die folgenden Umgebungsvariablen:

export SERVER_ADDR=http://localhost:8080
export REQUESTS_PER_SECOND=5

Starten Sie virtualenv:
```
virtualenv --python python3 env
```
Aktivieren Sie die virtuelle Umgebung:
```
source env/bin/activate
```
Installieren Sie die Anforderungen für loadgen:
```
pip3 install -r requirements.txt
```
Führen Sie loadgen aus:
```
python3 loadgen.py
```
Beim Start gibt loadgen eine Meldung wie diese aus:
```
Starting loadgen: 2019-05-20 10:44:12.448415
5 request(s) complete to http://localhost:8080
```
Im anderen Terminalfenster schreibt server Nachrichten wie diese in die Console:
```
127.0.0.1 - - [21/Jun/2019 14:22:01] "GET / HTTP/1.1" 200 -
INFO:root:GET request,
Path: /
Headers:
Host: localhost:8080
User-Agent: python-requests/2.22.0
Accept-Encoding: gzip, deflate
Accept: */*
```
Aus Netzwerksicht wird die gesamte Anwendung jetzt auf demselben Host ausgeführt (entweder auf Ihrem lokalen Computer oder auf der Cloud Shell-VM). Daher können Sie mit localhost Anfragen an server senden.
Zum Beenden von loadgen und server geben Sie in jedem Terminalfenster Ctrl-c ein.
Deaktivieren Sie im Terminalfenster loadgen die virtuelle Umgebung:
```
deactivate
```

Anwendung containerisieren

Um die Anwendung in GKE auszuführen, müssen Sie die Beispielanwendung (server und loadgen) in containers packen. Mit einem Container können Sie eine Anwendung so verpacken, dass sie von der zugrunde liegenden Umgebung isoliert ist.

Zum Containerisieren der Anwendung benötigen Sie ein Dockerfile. Ein Dockerfile ist eine Textdatei, in der die Befehle definiert sind, die zum Erstellen des Quellcodes der Anwendung und der Abhängigkeiten in einem Docker-Image erforderlich sind. Nachdem Sie das Image erstellt haben, laden Sie es in ein Container-Registry wie Docker Hub oder Container Registry hoch.

Im Beispiel wird ein Dockerfile für server und loadgen mit allen Befehlen verwendet, die zum Erstellen der Images erforderlich sind. Im Folgenden finden Sie das Dockerfile für den server:

FROM python:3.9-slim as base
FROM base as builder
RUN apt-get -qq update \
    && apt-get install -y --no-install-recommends \
        g++ \
    && rm -rf /var/lib/apt/lists/*

# Enable unbuffered logging
FROM base as final
ENV PYTHONUNBUFFERED=1

RUN apt-get -qq update \
    && apt-get install -y --no-install-recommends \
        wget

WORKDIR /helloserver

# Grab packages from builder
COPY --from=builder /usr/local/lib/python3.9/ /usr/local/lib/python3.9/

# Add the application
COPY . .

EXPOSE 8080
ENTRYPOINT [ "python", "server.py" ]

Der Befehl FROM python:3-slim as base weist Docker an, das neueste Python 3-Image als Basis-Image zu verwenden.
Mit dem Befehl COPY . . werden die Quelldateien im aktuellen Arbeitsverzeichnis (in diesem Fall nur server.py) in das Dateisystem des Containers kopiert.
ENTRYPOINT definiert den Befehl, der zum Ausführen des Containers verwendet wird. In diesem Fall entspricht der Befehl fast dem Befehl, mit dem Sie server.py aus dem Quellcode ausgeführt haben.
Der Befehl EXPOSE gibt an, dass server den Port 8080 überwacht. Mit diesem Befehl werden keine Ports freigegeben. Sie dienen jedoch als Dokumentation, die Sie beim Ausführen des Containers zum Öffnen von Port 8080 benötigen.

Containerisierung der Anwendung vorbereiten

Legen Sie die folgenden Umgebungsvariablen fest: Ersetzen Sie dabei PROJECT_ID durch die ID Ihres Google Cloud-Projekts.
```
export PROJECT_ID="PROJECT_ID"
```
```
export GCR_REPO="asm-ready"
```
Sie verwenden den Wert von PROJECT_ID und GCR_REPO, um das Docker-Image beim Erstellen zu kennzeichnen und es in Ihre private Container Registry zu übertragen.
Legen Sie das Google Cloud-Standardprojekt für die Google Cloud CLI fest.
```
gcloud config set project $PROJECT_ID
```
Legen Sie die Standardzone für die Google Cloud CLI fest:
```
gcloud config set compute/zone us-central1-b
```
Achten Sie darauf, dass der Container Registry-Dienst in Ihrem Google Cloud-Projekt aktiviert ist.
```
gcloud services enable containerregistry.googleapis.com
```

`server` containerisieren

Wechseln Sie zu dem Verzeichnis, in dem sich das Beispiel server befindet:

cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/server/

Erstellen Sie das Image mit dem Dockerfile und den Umgebungsvariablen, die Sie zuvor definiert haben:
```
docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1 .
```
Das Flag -t steht für das Docker-Tag. Dies ist der Name des Images, das Sie bei der Bereitstellung des Containers verwenden.

Laden Sie das Image in Container Registry hoch.

docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1

`loadgen` containerisieren

Wechseln Sie zu dem Verzeichnis, in dem sich das Beispiel loadgen befindet:
```
cd ../loadgen
```

Erstellen Sie das Image:

docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1 .

Laden Sie das Image in Container Registry hoch.

docker push gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1

Images auflisten

Rufen Sie eine Liste der Images im Repository ab, um zu bestätigen, dass die Images übertragen wurden:

gcloud container images list --repository gcr.io/$PROJECT_ID/asm-ready

Der Befehl antwortet mit den soeben übertragenen Image-Namen:

NAME
gcr.io/PROJECT_ID/asm-ready/helloserver
gcr.io/PROJECT_ID/asm-ready/loadgen

GKE-Cluster erstellen

Sie können diese Container mit dem Befehl docker run auf der Cloud Shell-VM oder auf Ihrer Workstation ausführen. In der Produktion müssen Sie Container jedoch einheitlich orchestrieren. Beispielsweise benötigen Sie ein System, das dafür sorgt, dass die Container immer ausgeführt werden. Außerdem müssen Sie zusätzliche Instanzen eines Containers horizontal und vertikal installieren können, um Traffic-Spitzen zu bewältigen.

Sie können GKE verwenden, um Containeranwendungen auszuführen. GKE ist eine Plattform zur Containerorchestrierung, die VMs mit einem Cluster verbindet. Jede VM wird als Knoten bezeichnet. GKE-Cluster basieren auf dem Open-Source-Clusterverwaltungssystem Kubernetes. Kubernetes umfasst Mechanismen, die eine Interaktion mit Ihrem Cluster ermöglichen.

So erstellen Sie einen GKE-Cluster:

Erstellen Sie den Cluster:
```
gcloud container clusters create asm-ready \
  --cluster-version latest \
  --machine-type=n1-standard-4 \
  --num-nodes 4
```
Mit dem Befehl gcloud wird ein Cluster im Google Cloud-Projekt und in der Zone erstellt, die Sie zuvor festgelegt haben. Zur Ausführung von Anthos Service Mesh empfehlen wir mindestens vier Knoten und den Maschinentyp n1-standard-4.

Der Befehl zum Erstellen des Clusters dauert einige Minuten. Wenn der Cluster bereit ist, gibt der Befehl eine Meldung wie diese aus:
```
NAME        LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE   NODE_VERSION   NUM_NODES  STATUS
asm-ready  us-central1-b  1.13.5-gke.10   203.0.113.1    n1-standard-2  1.13.5-gke.10  4          RUNNING
```
Geben Sie Anmeldedaten für das kubectl-Befehlszeilentool an, damit Sie es zum Verwalten des Clusters verwenden können:
```
gcloud container clusters get-credentials asm-ready
```

Sie können jetzt kubectl für die Kommunikation mit Kubernetes verwenden. Führen Sie beispielsweise den folgenden Befehl aus, um den Status der Knoten abzurufen:

kubectl get nodes

Der Befehl antwortet mit einer Liste der Knoten, die etwa so aussieht:

NAME                                       STATUS   ROLES    AGE    VERSION
gke-asm-ready-default-pool-dbeb23dc-1vg0   Ready    <none>   99s    v1.13.6-gke.13
gke-asm-ready-default-pool-dbeb23dc-36z5   Ready    <none>   100s   v1.13.6-gke.13
gke-asm-ready-default-pool-dbeb23dc-fj7s   Ready    <none>   99s    v1.13.6-gke.13
gke-asm-ready-default-pool-dbeb23dc-wbjw   Ready    <none>   99s    v1.13.6-gke.13

Grundlegende Kubernetes-Konzepte verstehen

Das folgende Diagramm zeigt die in GKE ausgeführte Anwendung:

Containerisierte Anwendung

Bevor Sie die Container in GKE bereitstellen, sollten Sie sich mit einigen wichtigen Kubernetes-Konzepten vertraut machen. Am Ende dieser Anleitung finden Sie Links zu den einzelnen Konzepten.

Knoten und Cluster: In GKE ist ein Knoten eine VM. Auf anderen Kubernetes-Plattformen kann ein Knoten entweder eine physische oder eine virtuelle Maschine sein. Ein Cluster ist ein Satz von Knoten, die als ein einzelner Computer behandelt werden können, auf dem Sie eine Containeranwendung bereitstellen.
Pods: In Kubernetes werden Container in einem Pod ausgeführt. Ein Pod ist die atomare Einheit in Kubernetes. Ein Pod enthält einen oder mehrere Container. Die Container server und loadgen stellen Sie jeweils in einem eigenen Pod bereit. Wenn ein Pod mehrere Container ausführt (z. B. einen Anwendungsserver und einen Proxyserver), werden die Container als eine Einheit verwaltet und teilen die Ressourcen des Pods.
Deployments: Ein Deployment ist ein Kubernetes-Objekt, das eine Gruppe identischer Pods darstellt. Ein Deployment führt mehrere Replikate der Pods aus, die auf die Knoten eines Clusters verteilt sind. Ein Deployment ersetzt automatisch alle Pods, die fehlschlagen oder nicht mehr reagieren.
Kubernetes-Service: Wenn Sie den Anwendungscode in GKE ausführen, wird das Netzwerk zwischen loadgen und server geändert. Wenn Sie die Services in einer Cloud Shell-VM oder auf Ihrem Computer ausgeführt haben, können Sie Anfragen an die server mit der Adresse localhost:8080 senden. Nach der Bereitstellung in GKE werden die Pods so geplant, dass sie auf den verfügbaren Knoten ausgeführt werden. Standardmäßig können Sie nicht steuern, auf welchem Knoten der Pod ausgeführt wird, sodass die Pods keine stabilen IP-Adressen haben.

Zum Abrufen einer IP-Adresse für den server müssen Sie eine Netzwerkabstraktion auf den Pods definieren, die als Kubernetes-Service bezeichnet wird. Ein Kubernetes-Service stellt einen stabilen Netzwerkendpunkt für eine Reihe von Pods bereit. Es gibt mehrere Service-Typen. Der server verwendet einen LoadBalancer, der eine externe IP-Adresse bereitstellt, sodass Sie server außerhalb des Clusters erreichen können.

Kubernetes umfasst auch ein integriertes DNS-System, das Services DNS-Namen (z. B. helloserver.default.cluster.local) zuweist. Dadurch können Pods im Cluster andere Pods im Cluster mit einer stabilen Adresse erreichen. Sie können diesen DNS-Namen nicht außerhalb des Clusters verwenden, z. B. in Cloud Shell oder auf Ihrem Computer.

Kubernetes-Manifeste

Als Sie die Anwendung aus dem Quellcode ausgeführt haben, haben Sie einen imperativen Befehl verwendet: python3 server.py

Imperativ bedeutet in Verbform: „Tun Sie dies.“

Im Gegensatz dazu verwendet Kubernetes ein deklaratives Modell. Das bedeutet, dass Sie Kubernetes nicht genau mitteilen müssen, was zu tun ist, sondern Kubernetes einen gewünschten Status zuweisen. Beispielsweise werden Pods bei Kubernetes nach Bedarf gestartet und beendet, sodass der tatsächliche Systemstatus dem gewünschten Zustand entspricht.

Sie geben den gewünschten Status in einer Reihe von Manifesten oder YAML-Dateien an. Eine YAML-Datei enthält die Spezifikation für ein oder mehrere Kubernetes-Objekte.

Das Beispiel enthält eine YAML-Datei für server und loadgen. Jede YAML-Datei gibt den gewünschten Status für das Kubernetes-Deployment-Objekt und den Kubernetes-Service an.

Server

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

kind gibt den Typ des Objekts an.
metadata.name gibt den Namen des Deployments an.
Das erste spec-Feld enthält eine Beschreibung des gewünschten Status.
spec.replicas gibt die Anzahl der gewünschten Pods an.
Im Abschnitt spec.template wird eine Pod-Vorlage definiert. In der Spezifikation für die Pods ist das Feld image enthalten. Dies ist der Name des Images, das aus Container Registry abgerufen werden soll.

Der Service ist folgendermaßen definiert:

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

LoadBalancer: Clients senden Anfragen an die IP-Adresse eines Netzwerk-Load-Balancers, der eine stabile IP-Adresse hat und außerhalb des Clusters erreichbar ist.
targetPort: Beachten Sie, dass der Befehl EXPOSE 8080 im Dockerfile keine Ports tatsächlich verfügbar macht. Sie stellen Port 8080 bereit, damit Sie den server-Container außerhalb des Clusters erreichen können. In diesem Fall wird hellosvc.default.cluster.local:80 (Kurzname: hellosvc) dem Port 8080 der helloserver-Pod-IP zugeordnet.
port: Dies ist die Portnummer, die andere Services im Cluster beim Senden von Anfragen verwenden.

Load-Generator

Das Deployment-Objekt in loadgen.yaml entspricht in etwa server.yaml. Ein großer Unterschied besteht darin, dass das Deployment-Objekt einen Abschnitt mit dem Namen env enthält. In diesem Abschnitt werden die Umgebungsvariablen loadgen definiert, die Sie zuvor festgelegt haben, als Sie die Anwendung aus der Quelle ausgeführt haben.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: loadgenerator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: loadgenerator
  template:
    metadata:
      labels:
        app: loadgenerator
    spec:
      containers:
      - env:
        - name: SERVER_ADDR
          value: http://hellosvc:80/
        - name: REQUESTS_PER_SECOND
          value: '10'
        image: gcr.io/google-samples/istio/loadgen:v0.0.1
        imagePullPolicy: Always
        name: main
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
          requests:
            cpu: 300m
            memory: 256Mi
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

Da loadgen keine eingehenden Anfragen akzeptiert, ist das Feld type auf ClusterIP gesetzt. Dieser Typ bietet eine stabile IP-Adresse, die von Services im Cluster verwendet werden kann. Die IP-Adresse wird jedoch externen Clients nicht angezeigt.

apiVersion: v1
kind: Service
metadata:
  name: loadgensvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: loadgenerator
  type: ClusterIP

Container in GKE bereitstellen

Wechseln Sie zu dem Verzeichnis, in dem sich das Beispiel server befindet:

cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/server/

Öffnen Sie server.yaml in einem Texteditor.
Ersetzen Sie den Namen im Feld image durch den Namen des Docker-Images.
```
image: gcr.io/PROJECT_ID/asm-ready/helloserver:v0.0.1
```
Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.
Speichern und schließen Sie server.yaml.
Stellen Sie die YAML-Datei in Kubernetes bereit:
```
kubectl apply -f server.yaml
```
Bei Erfolg gibt der Befehl Folgendes zurück:
```
deployment.apps/helloserver created
service/hellosvc created
```
Wechseln Sie zu dem Verzeichnis, in dem sich loadgen befindet.
```
cd ../loadgen
```
Öffnen Sie loadgen.yaml in einem Texteditor.
Ersetzen Sie den Namen im Feld image durch den Namen des Docker-Images.
```
image: gcr.io/PROJECT_ID/asm-ready/loadgen:v0.0.1
```
Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.
Speichern Sie die Datei loadgen.yaml und schließen Sie den Texteditor.

Stellen Sie die YAML-Datei in Kubernetes bereit:

kubectl apply -f loadgen.yaml

Bei Erfolg gibt der Befehl Folgendes zurück:

deployment.apps/loadgenerator created
service/loadgensvc created

Prüfen Sie den Status der Pods:

kubectl get pods

Der Befehl antwortet mit einem Status wie diesem:

NAME                             READY   STATUS    RESTARTS   AGE
helloserver-69b9576d96-mwtcj     1/1     Running   0          58s
loadgenerator-774dbc46fb-gpbrz   1/1     Running   0          57s

Rufen Sie die Anwendungslogs aus dem Pod loadgen ab. Ersetzen Sie POD_ID durch die ID aus der vorherigen Ausgabe.
```
kubectl logs loadgenerator-POD_ID
```

Rufen Sie die externen IP-Adressen von hellosvc ab:

kubectl get service

Die Befehlsausgabe sieht in etwa so aus:

NAME         TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
hellosvc     LoadBalancer   10.81.15.158   192.0.2.1       80:31127/TCP   33m
kubernetes   ClusterIP      10.81.0.1      <none>          443/TCP        93m
loadgensvc   ClusterIP      10.81.15.155   <none>          80/TCP         4m52s

Senden Sie eine Anfrage an hellosvc. Ersetzen Sie EXTERNAL_IP durch die externe IP-Adresse Ihrer hellosvc:
```
curl http://EXTERNAL_IP
```

Bereit für Anthos Service Mesh

Die Anwendung ist jetzt in GKE bereitgestellt. loadgen verwendet Kubernetes-DNS (hellosvc:80), um Anfragen an den server zu senden. Ebenfalls können Sie Anfragen an server mit einer externen IP-Adresse senden. Kubernetes bietet zwar viele Features, doch fehlen einige Informationen zu den Services:

Wie interagieren die Services? Wie ist die Beziehung zwischen den Services? Wie funktioniert der Traffic zwischen den Services? Sie wissen, dass loadgen Anfragen an server sendet, aber stellen Sie sich vor, dass Sie mit der Anwendung nicht vertraut sind. All diese Fragen lassen sich nicht mit einem Blick auf die Liste der ausgeführten Pods in GKE beantworten.
Messwerte: Wie lange dauert es, bis der server auf eingehende Anfragen antwortet? Wie viele Anfragen pro Sekunde (RPS) gehen an server ein? Gibt es Fehlerantworten?
Sicherheitsinformationen: Ist der Traffic zwischen loadgen und dem server Nur-HTTP oder mTLS?

Anthos Service Mesh kann Ihnen Antworten auf diese Fragen geben. Anthos Service Mesh ist eine von Google Cloud verwaltete Version des Open-Source-Projekts Istio. Anthos Service Mesh funktioniert mit einem Envoy-Sidecar-Proxy in jedem Pod. Der Envoy-Proxy fängt den gesamten ein- und ausgehenden Traffic an die Anwendungscontainer ab. Das bedeutet, dass server und loadgen jeweils einen Envoy-Sidecar-Proxy erhalten und der gesamte Traffic von loadgen zu server über die Envoy-Proxys läuft. Die Verbindungen zwischen diesen Envoy-Proxys bilden das Service Mesh. Diese Service Mesh-Architektur bietet eine Steuerungsebene über Kubernetes.

Service Mesh

Da die Envoy-Proxys in ihren eigenen Containern ausgeführt werden, können Sie Anthos Service Mesh auf einem GKE-Cluster ohne wesentliche Änderungen an Ihrem Anwendungscode installieren. Sie haben jedoch einige wichtige Vorkehrungen getroffen, um Ihre Anwendung für die Verwendung mit Anthos Service Mesh vorzubereiten:

Services für alle Container: Die Deployments server und loadgen sind mit einem Kubernetes-Service verknüpft. Selbst loadgen, das keine eingehenden Anfragen empfängt, hat einen Service.
Ports in Services müssen benannt werden: Obwohl Sie in GKE unbenannte Service-Ports definieren können, müssen Sie bei Anthos Service Mesh einen Namen für einen Port angeben, der mit dem Protokoll des Ports übereinstimmt. In der YAML-Datei heißt der Port für server http, da server das Kommunikationsprotokoll HTTP verwendet. Hätte service gRPC verwendet, würden Sie den Port grpc nennen.
Deployments sind mit Labels versehen: Dies ermöglicht Ihnen die Verwendung der Traffic-Features von Anthos Service Mesh, z. B. zum Aufteilen des Traffics zwischen Versionen desselben Service.

Anthos Service Mesh installieren

Rufen Sie die Installationshandbücher für Anthos Service Mesh auf und folgen Sie der Anleitung zur Installation von Anthos Service Mesh in Ihrem Cluster.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Löschen Sie zum Bereinigen den GKE-Cluster. Durch das Löschen des Clusters werden alle Ressourcen des Containerclusters gelöscht, darunter Compute-Instanzen, Laufwerke und Netzwerkressourcen.

gcloud container clusters delete asm-ready

Nächste Schritte

Weitere Informationen zu den in dieser Anleitung verwendeten Technologien:
Weitere Informationen zu den Tools:
Weitere Informationen zu Kubernetes-Konzepten:
- Cluster
- Knoten
- Pods
- Services
- Deployment