Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Cloud Service Mesh tramite esempi: deployment canary

In questo tutorial, esamini uno scenario d'uso comune: l'implementazione di un deployment canary con Cloud Service Mesh utilizzando le API Istio.

Che cos'è un deployment canary?

Un deployment canary indirizza una piccola percentuale di traffico a una nuova versione di un microservizio, quindi aumenta gradualmente questa percentuale eliminando e ritirando la versione precedente. Se qualcosa va storto durante questo processo, il traffico può essere riportato alla versione precedente. Con Cloud Service Mesh puoi indirizzare il traffico per garantire l'introduzione sicura di nuovi servizi.

Esegui il deployment di Online Boutique

Imposta il contesto corrente per kubectl sul cluster in cui prevedi di eseguire il deployment di Online Boutique. Il comando dipende dal fatto che tu abbia eseguito il provisioning di Cloud Service Mesh su un cluster GKE o su un cluster Kubernetes al di fuori di GKE:
GKE su Google Cloud
```
gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION 
```
GKE al di fuori di Google Cloud
```
kubectl config use-context CLUSTER_NAME 
```
Crea lo spazio dei nomi per l'applicazione di esempio e il gateway in entrata:
```
kubectl create namespace onlineboutique
```
Etichetta lo spazio dei nomi onlineboutique per inserire automaticamente i proxy Envoy. Segui i passaggi su come attivare l'inserimento automatico di sidecar.

Esegui il deployment dell'app di esempio. Per questo tutorial, esegui il deployment di Online Boutique, un'app demo di microservizi.

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

Aggiungi un'etichetta version=v1 al deployment productcatalog eseguendo il comando seguente:

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

Visualizza i servizi di cui hai eseguito il deployment:

kubectl get pods -n onlineboutique

Output previsto:

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

Un 2/2 nella colonna READY indica che un pod è attivo e in esecuzione con un proxy Envoy inserito correttamente.

Esegui il deployment di VirtualService e DestinationRule per la versione 1 di productcatalog:

 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

Tieni presente che nelle risorse è presente solo v1.

Visita l'applicazione nel browser utilizzando l'indirizzo IP esterno del gateway in entrata:
```
kubectl get services -n GATEWAY_NAMESPACE
```

La sezione successiva illustra l'interfaccia utente di Cloud Service Mesh e mostra come visualizzare le metriche.

Visualizzare i servizi nella console Google Cloud

Nella console Google Cloud , vai alla pagina Servizi di Google Kubernetes Engine (GKE) Enterprise.

Vai a Servizi di Google Kubernetes Engine (GKE) Enterprise
Per impostazione predefinita, i servizi vengono visualizzati nella visualizzazione Elenco.

La panoramica della tabella ti consente di osservare tutti i tuoi servizi, nonché le metriche importanti a colpo d'occhio.
In alto a destra, fai clic su Topologia. Qui puoi visualizzare i tuoi servizi e la loro interazione reciproca.

Puoi espandere Servizi e visualizzare le Richieste al secondo per ciascun servizio passando il cursore sopra di essi.
Torna alla visualizzazione tabella.
Nella tabella Servizi, seleziona productcatalogservice. Viene visualizzata una panoramica del tuo servizio.
Sul lato sinistro dello schermo, fai clic su Traffico.
Assicurati che il 100% del traffico in entrata a productcatalogservice venga indirizzato al servizio del workload.

La sezione successiva descrive la creazione di una versione 2 del servizio productcatalog.

Esegui il deployment della versione 2 di un servizio

Per questo tutorial, productcatalogservice-v2 introduce una latenza di 3 secondi nelle richieste con il campo EXTRA_LATENCY. In questo modo viene simulata una regressione nella nuova versione del servizio.

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

Applica questa risorsa allo spazio dei nomi onlineboutique.

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

Controlla i pod dell'applicazione.

kubectl get pods -n onlineboutique

Output previsto:

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

Tieni presente che ora sono elencati due productcatalogservices.

Utilizza DestinationRule per specificare i sottoinsiemi di un servizio. In questo scenario, esiste un sottoinsieme per la versione 1 e poi un sottoinsieme separato per la versione 2 di 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
```
Prendi nota del campo labels. Le versioni di productcatalogservice si distinguono dopo che il traffico viene indirizzato da VirtualService.

Applica DestinationRule:
```
kubectl apply -f destination-v1-v2.yaml -n onlineboutique
```

Suddividi il traffico tra v1 e v2

Utilizza VirtualService per definire una piccola percentuale del traffico da indirizzare alla versione 2 di productcatalogservice.

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

Il campo sottoinsieme indica la versione, mentre il campo ponderazione indica la suddivisione percentuale del traffico. Il 75% del traffico va alla versione 1 di productcatalog e il 25% alla versione 2.

Applica VirtualService:

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

Se visiti l'EXTERNAL_IP dell'ingresso del cluster, dovresti notare che periodicamente il caricamento del frontend è più lento.

Nella sezione successiva, esplora la suddivisione del traffico nella console Google Cloud .

Osserva la suddivisione del traffico nella console Google Cloud

Torna alla console Google Cloud e vai alla pagina Servizi GKE Enterprise. Vai a GKE Enterprise Services
In alto a destra, fai clic su Topologia.

Espandi il carico di lavoro productcatalogservice e prendi nota dei deployment productcatalogservice e productcatalogservice-v2.
Torna alla visualizzazione tabella.
Fai clic su productcatalogservice nella tabella Servizi.
Torna a Traffico nella barra di navigazione a sinistra.
Tieni presente che il traffico in entrata è suddiviso tra v1 e v2 in base alla percentuale specificata nel file VirtualService e che esistono due workload del servizio productcatalog.

Sul lato destro della pagina, vengono visualizzate le sezioni Richieste, Tasso di errore e Metriche di latenza. Con Cloud Service Mesh, ogni servizio ha queste metriche delineate per fornirti metriche di osservabilità.

Nota: potrebbe essere necessario un po' di tempo prima che venga visualizzata la suddivisione effettiva 75-25, poiché il traffico nel tempo viene reindirizzato al servizio v2.

Implementare o eseguire il rollback a una versione

Dopo aver osservato le metriche durante un deployment canary, puoi completare il lancio della nuova versione del servizio o eseguire il rollback alla versione originale del servizio sfruttando la risorsa VirtualService.

Implementazione

Una volta soddisfatto del comportamento di un servizio v2, puoi aumentare gradualmente la percentuale di traffico indirizzato al servizio v2. Alla fine, il traffico può essere indirizzato al 100% al nuovo servizio nella risorsa VirtualService che hai creato sopra rimuovendo la suddivisione del traffico da questa risorsa.

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

Per indirizzare tutto il traffico alla versione 2 di productcatalogservice:

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

Rollback

Se devi eseguire il rollback al servizio v1, applica destination-vs-v1.yaml precedente. In questo modo il traffico viene indirizzato solo alla versione 1 di productcatalogservice.

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

Per indirizzare tutto il traffico alla versione 1 di productcatalogservice:

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