Anwendung für Cloud Service Mesh vorbereiten

Beispielcode herunterladen

1. Laden Sie den Quellcode helloserver herunter:

   git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
   

2. Öffnen Sie das Verzeichnis mit dem Beispielcode:

   cd anthos-service-mesh-samples/docs/helloserver
   

Anwendung mit mehreren Diensten entdecken

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 Konsole ausgibt.
• loadgen: Ein Skript, das Traffic an server mit einer konfigurierbaren Anzahl von Anfragen pro Sekunde (RPS) sendet.

Anwendung aus der Quelle ausführen

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

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

2. Öffnen Sie ein anderes Terminalfenster, damit Sie Anfragen an server senden können. Klicken Sie auf add, um eine weitere Sitzung zu öffnen.

3. Senden Sie eine Anfrage an server:

   curl http://localhost:8080
   

   Der server antwortet:

   Hello World!
   

4. Wechseln Sie von dem Verzeichnis, in das Sie den Beispielcode heruntergeladen haben, in das Verzeichnis, das loadgen enthält:

   cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/loadgen

5. Erstellen Sie die folgenden Umgebungsvariablen:

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

6. Starten Sie virtualenv:

   virtualenv --python python3 env
   

7. Aktivieren Sie die virtuelle Umgebung:

   source env/bin/activate
   

8. Installieren Sie die Anforderungen für loadgen:

   pip3 install -r requirements.txt
   

9. 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 Konsole:

   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. Daher können Sie mit localhost Anfragen an server senden.

10. Zum Beenden von loadgen und server geben Sie in jedem Terminalfenster Ctrl-c ein.

11. 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 Container 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.13-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.* /usr/local/lib/

# 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

1. Legen Sie die folgenden Umgebungsvariablen fest: Ersetzen Sie PROJECT_ID durch die ID IhresGoogle 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.

2. Legen Sie das Standardprojekt für die Google Cloud CLI fest. Google Cloud

   gcloud config set project $PROJECT_ID

3. Legen Sie die Standardzone für die Google Cloud CLI fest:

   gcloud config set compute/zone us-central1-b
   

4. Achten Sie darauf, dass der Container Registry-Service in IhremGoogle Cloud -Projekt aktiviert ist.

   gcloud services enable containerregistry.googleapis.com
   

server containerisieren

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

   cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/

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

3. Laden Sie das Image in Container Registry hoch.

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

loadgen containerisieren

1. Wechseln Sie zu dem Verzeichnis, in dem sich das Beispiel loadgen befindet:

   cd ../loadgen
   

2. Erstellen Sie das Image:

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

3. 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 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:

1. 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 im ProjektGoogle Cloud und in der Zone, die Sie zuvor festgelegt haben, ein Cluster erstellt. Zur Ausführung von Cloud 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
   

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

3. 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:

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 Dienste in einer Cloud Shell-VM 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.

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

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

   cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/

2. Öffnen Sie server.yaml in einem Texteditor.

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

4. Speichern und schließen Sie server.yaml.

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

6. Wechseln Sie zu dem Verzeichnis, in dem sich loadgen befindet.

   cd ../loadgen
   

7. Öffnen Sie loadgen.yaml in einem Texteditor.

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

9. Speichern Sie die Datei loadgen.yaml und schließen Sie den Texteditor.

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

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

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

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

14. Senden Sie eine Anfrage an hellosvc. Ersetzen Sie EXTERNAL_IP durch die externe IP-Adresse Ihrer hellosvc:

    curl http://EXTERNAL_IP
    

Bereit für Cloud 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?

Cloud Service Mesh kann Ihnen Antworten auf diese Fragen geben. Cloud Service Mesh ist eine von Google Cloudverwaltete Version des Open-Source-Projekts Istio. Cloud 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.

Da die Envoy-Proxys in ihren eigenen Containern ausgeführt werden, können Sie Cloud 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 Cloud 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 Diensten müssen benannt werden: Obwohl Sie in GKE unbenannte Dienstports definieren können, müssen Sie bei Cloud 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 Cloud Service Mesh, z. B. zum Aufteilen des Traffics zwischen Versionen desselben Service.

Cloud Service Mesh installieren.

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