Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud Service Mesh am Beispiel: Canary-Deployments

In dieser Anleitung wird ein häufiger Anwendungsfall für das Roll-out eines Canary-Deployments mit Cloud Service Mesh mithilfe von Istio-APIs erläutert.

Was ist ein Canary-Deployment?

Bei einem Canary-Deployment wird ein kleiner Prozentsatz des Traffics an eine neue Version eines Mikrodienstes weitergeleitet. Dieser Prozentsatz wird dann nach und nach erhöht, während die alte Version eingestellt und ausgemustert wird. Wenn während dieses Vorgangs ein Fehler auftritt, kann der Traffic wieder auf die frühere Version umgestellt werden. Mit Cloud Service Mesh können Sie Traffic steuern, um Dienste sicher einzuführen.

Online Boutique bereitstellen

Legen Sie den aktuellen Kontext für kubectl auf den Cluster fest, in dem Sie Online Boutique bereitstellen möchten. Der Befehl hängt davon ab, ob Sie Cloud Service Mesh auf einem GKE-Cluster oder einem Kubernetes-Cluster außerhalb von GKE bereitgestellt haben:
GKE in Google Cloud
```
gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION 
```
GKE außerhalb von Google Cloud
```
kubectl config use-context CLUSTER_NAME 
```
Erstellen Sie den Namespace für die Beispielanwendung und das Ingress-Gateway:
```
kubectl create namespace onlineboutique
```
Fügen Sie dem Namespace onlineboutique ein Label hinzu, um Envoy-Proxys automatisch einzufügen. Folgen Sie den Schritten zum Aktivieren der automatischen Sidecar-Einfügung.

Stellen Sie die Beispielanwendung bereit. In dieser Anleitung stellen Sie die Mikrodienst-Demo-Anwendung "Online Boutique" bereit.

kubectl apply \
-n onlineboutique \
-f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-samples/main/docs/shared/online-boutique/kubernetes-manifests.yaml

Fügen Sie dem Deployment productcatalog das Label version=v1 hinzu. Dazu führen Sie diesen Befehl aus:

kubectl patch deployments/productcatalogservice -p '{"spec":{"template":{"metadata":{"labels":{"version":"v1"}}}}}' \
-n onlineboutique

Rufen Sie die von Ihnen bereitgestellten Dienste auf:

kubectl get pods -n onlineboutique

Erwartete Ausgabe:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-85598d856b-m84m6               2/2     Running   0          2m7s
cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s

Ein 2/2 in der Spalte READY gibt an, dass ein Pod ausgeführt wird und ein Envoy-Proxy erfolgreich eingefügt wurde.

Stellen Sie VirtualService und DestinationRule für v1 von productcatalog bereit:

 kubectl apply -f destination-vs-v1.yaml -n onlineboutique

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: productcatalogservice
spec:
  host: productcatalogservice
  subsets:
  - labels:
      version: v1
    name: v1
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productcatalogservice
spec:
  hosts:
  - productcatalogservice
  http:
  - route:
    - destination:
        host: productcatalogservice
        subset: v1

Beachten Sie, dass in den Ressourcen nur v1 vorhanden ist.

Rufen Sie die Anwendung in Ihrem Browser mithilfe der externen IP-Adresse Ihres Ingress-Gateways auf:
```
kubectl get services -n GATEWAY_NAMESPACE
```

Im nächsten Abschnitt lernen Sie die Cloud Service Mesh-UI kennen und erfahren, wie Sie Messwerte aufrufen.

Dienste in der Google Cloud Console ansehen

Rufen Sie in der Google Cloud Console die Seite GKE Enterprise-Dienste auf.

Zu den Google Kubernetes Engine (GKE) Enterprise Edition-Diensten
Standardmäßig werden die Dienste in der Ansicht Liste angezeigt.

In der Tabellenübersicht können Sie alle Dienste und wichtigen Messwerte auf einen Blick sehen.
Klicken Sie oben rechts auf Topologie. Hier können Sie Ihre Dienste und deren Interaktion miteinander ansehen.

Sie können Services maximieren und die Requests per second (Anfragen pro Sekunde) für jeden Ihrer Dienste aufrufen, indem Sie den Mauszeiger darauf bewegen.
Kehren Sie zur Tabellenansicht zurück.
Wählen Sie in der Tabelle der Dienste die Option productcatalogservice aus. Daraufhin wird eine Übersicht über den Dienst angezeigt.
Klicken Sie auf der linken Seite des Bildschirms auf Traffic.
100 % des eingehenden Traffics zu productcatalogservice werden an den Arbeitslastdienst weitergeleitet.

Im nächsten Abschnitt wird die Erstellung einer v2 des Dienstes productcatalog beschrieben.

v2 eines Dienstes bereitstellen

In dieser Anleitung führt productcatalogservice-v2 mit dem Feld EXTRA_LATENCY eine Latenz von 3 Sekunden in Anfragen ein. Dadurch wird eine Regression in der neuen Version des Dienstes simuliert.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: productcatalogservice-v2
spec:
  selector:
    matchLabels:
      app: productcatalogservice
  template:
    metadata:
      labels:
        app: productcatalogservice
        version: v2
    spec:
      containers:
      - env:
        - name: PORT
          value: '3550'
        - name: EXTRA_LATENCY
          value: 3s
        name: server
        image: gcr.io/google-samples/microservices-demo/productcatalogservice:v0.3.6
        livenessProbe:
          exec:
            command: ["/bin/grpc_health_probe", "-addr=:3550"]
        ports:
        - containerPort: 3550
        readinessProbe:
          exec:
            command: ["/bin/grpc_health_probe", "-addr=:3550"]
        resources:
          limits:
            cpu: 200m
            memory: 128Mi
          requests:
            cpu: 100m
            memory: 64Mi
      terminationGracePeriodSeconds: 5

Wenden Sie diese Ressource auf den Namespace onlineboutique an.

kubectl apply -f productcatalog-v2.yaml -n onlineboutique

Prüfen Sie die Anwendungs-Pods.

kubectl get pods -n onlineboutique

Erwartete Ausgabe:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-85598d856b-8wqfd                  2/2     Running   0          25h
cartservice-c77f6b866-7jwcr                 2/2     Running   0          25h
checkoutservice-654c47f4b6-n8c6x            2/2     Running   0          25h
currencyservice-59bc889674-l5xw2            2/2     Running   0          25h
emailservice-5b9fff7cb8-jjr89               2/2     Running   0          25h
frontend-77b88cc7cb-bwtk4                   2/2     Running   0          25h
loadgenerator-6958f5bc8b-lqmnw              2/2     Running   0          25h
paymentservice-68dd9755bb-dckrj             2/2     Running   0          25h
productcatalogservice-84f95c95ff-ddhjv      2/2     Running   0          25h
productcatalogservice-v2-6df4cf5475-9lwjb   2/2     Running   0          8s
recommendationservice-64dc9dfbc8-7s7cx      2/2     Running   0          25h
redis-cart-5b569cd47-vw7lw                  2/2     Running   0          25h
shippingservice-5488d5b6cb-dj5gd            2/2     Running   0          25h

Beachten Sie, dass jetzt zwei productcatalogservices aufgeführt sind.

Mit DestinationRule werden die Teilmengen eines Dienstes angegeben. In diesem Szenario gibt es eine Teilmenge für v1 und dann eine separate Teilmenge für v2 von productcatalogservice.
```
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: productcatalogservice
spec:
  host: productcatalogservice
  subsets:
  - labels:
      version: v1
    name: v1
  - labels:
      version: v2
    name: v2
```
Beachten Sie das Feld labels. Die Versionen von productcatalogservice werden unterschieden, nachdem der Traffic von VirtualService weitergeleitet wurde.

Wenden Sie den DestinationRule an:
```
kubectl apply -f destination-v1-v2.yaml -n onlineboutique
```

Traffic zwischen v1 und v2 aufteilen

Mit VirtualService können Sie einen kleinen Prozentsatz des Traffics definieren, der an v2 von productcatalogservice weitergeleitet wird.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productcatalogservice
spec:
  hosts:
  - productcatalogservice
  http:
  - route:
    - destination:
        host: productcatalogservice
        subset: v1
      weight: 75
    - destination:
        host: productcatalogservice
        subset: v2
      weight: 25

Das Feld "Teilmenge" enthält die Version und das Feld "Gewichtung" die prozentuale Aufteilung des Traffics. 75% des Traffics werden an v1 von productcatalog und 25% an v2 gesendet.

Wenden Sie den VirtualService an:

kubectl apply -f vs-split-traffic.yaml -n onlineboutique

Wenn Sie die EXTERNAL_IP des Cluster-Ingress aufrufen, sehen Sie, dass das Frontend periodisch langsamer geladen wird.

Im nächsten Abschnitt sehen Sie sich die Trafficaufteilung in der Google Cloud -Konsole an.

Trafficaufteilung in der Google Cloud -Konsole beobachten

Kehren Sie zur Google Cloud Console zurück und rufen Sie die Seite „GKE Enterprise-Dienste“ auf. Zu GKE Enterprise-Diensten
Klicken Sie oben rechts auf Topologie.

Maximieren Sie die Arbeitslast productcatalogservice und notieren Sie sich die Deployments productcatalogservice und productcatalogservice-v2.
Kehren Sie zur Tabellenansicht zurück.
Klicken Sie in der Tabelle „Dienste“ auf productcatalogservice.
Kehren Sie in der linken Navigationsleiste zu Traffic zurück.
Beachten Sie, dass der eingehende Traffic zwischen v1 und v2 anhand des in der Datei VirtualService angegebenen Prozentsatzes aufgeteilt wird und zwei Arbeitslasten des Dienstes "productcatalog" vorhanden sind.

Rechts auf der Seite sehen Sie Anfragen, Fehlerrate und Latenzmesswerte. In Cloud Service Mesh werden diese Messwerte für jeden Dienst dargestellt, um Beobachtbarkeitsmesswerte zu ermöglichen.

Hinweis: Es dauert einige Zeit, bis die tatsächliche Aufteilung von 75–25 angezeigt wird, da der Traffic im Laufe der Zeit an den Dienst v2 weitergeleitet wird.

Roll-out oder Rollback zu einer Version

Nachdem Sie die Messwerte während eines Canary-Deployments beobachtet haben, können Sie mithilfe der Ressource VirtualService ein Roll-out der neuen Dienstversion oder ein Rollback zur ursprünglichen Dienstversion ausführen.

Roll-out durchführen

Wenn Sie mit dem Verhalten eines v2-Dienstes zufrieden sind, können Sie den Prozentsatz des Traffics, der an den v2-Dienst weitergeleitet wird, schrittweise erhöhen. Schließlich kann der Traffic zu 100% an den neuen Dienst weitergeleitet werden. Entfernen Sie dazu die Trafficaufteilung aus der VirtualService-Ressource, die Sie oben erstellt haben.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productcatalogservice
spec:
  hosts:
  - productcatalogservice
  http:
  - route:
    - destination:
        host: productcatalogservice
        subset: v2

So leiten Sie den gesamten Traffic an v2 von productcatalogservice weiter:

kubectl apply -f vs-v2.yaml -n onlineboutique

Rollback durchführen

Wenn Sie ein Rollback zum v1-Dienst durchführen müssen, wenden Sie einfach destination-vs-v1.yaml von zuvor an. Dadurch wird der Traffic nur an v1 von productcatalogservice weitergeleitet.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productcatalogservice
spec:
  hosts:
  - productcatalogservice
  http:
  - route:
    - destination:
        host: productcatalogservice
        subset: v1

So leiten Sie den gesamten Traffic an v1 von productcatalogservice weiter:

kubectl apply -f vs-v1.yaml -n onlineboutique