Versione 1.15

Versioni disponibili

1.18 (più recente)
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1
12.1 12.{17{/27.

Anthos Service Mesh per esempio: deployment canary

In questo tutorial, scoprirai un caso d'uso comune per l'implementazione di un deployment canary con Anthos Service Mesh.

Che cos'è un deployment canary?

Un deployment canary instrada una piccola percentuale di traffico a una nuova versione di un microservizio, quindi ti consente di implementare gradualmente l'intera base utenti, eliminando gradualmente e ritirando la versione precedente. Se si verifica un problema durante questo processo, puoi tornare al traffico alla versione precedente. Con Anthos Service Mesh, puoi instradare il traffico per assicurarti che i nuovi servizi vengano introdotti in modo sicuro.

Per saperne di più sui test canary, consulta Strategie di deployment e test delle applicazioni.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Al termine di questo tutorial, puoi evitare i costi continui eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.

Prima di iniziare

Verifica che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare che la fatturazione sia attivata per il tuo progetto.
Installare Anthos Service Mesh gestito* su un cluster GKE.

Nota: questo tutorial funziona anche per Service Anthos Service Mesh tramite asmcli e Kubernetes Service Mesh nel cluster.
Esegui il deployment di un gateway Ingress.

Clona il repository:

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

Esegui il deployment di Boutique online

Imposta il contesto attuale per kubectl sul cluster in cui hai eseguito il deployment della boutique online:

gcloud container clusters get-credentials CLUSTER_NAME  \
--project=PROJECT_ID \
--zone=CLUSTER_LOCATION

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'iniezione automatica di sidecar.

Esegui il deployment dell'app di esempio. Per questo tutorial, eseguirai il deployment di Online Boutique, un'app demo basata su 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 di productcatalog eseguendo il comando seguente:

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

Visualizzare 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

Tutti i pod della tua applicazione devono essere attivi e in esecuzione, con un 2/2 nella colonna READY. Questo indica che per i pod è stato inserito un proxy sidecar Envoy inserito.

Esegui il deployment di VirtualService e DestinationRule per v1 di productcatalog:

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

docs/canary-service/destination-vs-v1.yaml

Visualizza su GitHub

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

Tieni presente che solo v1 è presente nelle risorse.

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

Questa sezione successiva mostra l'interfaccia utente di Anthos Service Mesh e ti mostra come visualizzare le metriche.

Esegui il deployment e visualizza i tuoi servizi nella console Google Cloud

Nella console Google Cloud, vai alla pagina Anthos Services (Servizi Anthos).

Vai ai servizi Anthos
Per impostazione predefinita, i servizi vengono visualizzati nella visualizzazione Tabella.

La panoramica della tabella ti consente di osservare una panoramica di tutti i tuoi servizi, oltre a metriche importanti.
In alto a destra, fai clic su Topologia. Qui puoi visualizzare i tuoi servizi e la loro interazione tra loro.

Puoi espandere i servizi e visualizzare le richieste al secondo per ciascuno dei tuoi servizi passandoci sopra con il cursore.
Torna alla Visualizzazione tabella.
Nella tabella Servizi, seleziona productcatalogservice. Verrà visualizzata una panoramica del servizio.
Sul lato sinistro dello schermo, fai clic su Traffico.
Assicurati che il 100% del traffico in entrata verso productcatalogservice sia diretto al servizio del carico di lavoro.

Nella sezione successiva verrà creata una v2 del servizio productcatalog.

Esegui il deployment della versione 2 di un servizio

Per questo tutorial, productcatalogservice-v2 introdurrà una latenza di 3 secondi nelle richieste con il campo EXTRA_LATENCY.

docs/canary-service/productcatalog-v2.yaml

Visualizza su GitHub

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 onlineboutiquespazio dei nomi.

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

Controlla i pod della tua 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 adesso sono elencati due productcatalogservices.

DestinationRule consente di specificare i sottoinsiemi di un servizio. In questo scenario, esiste un sottoinsieme per la versione 1 e per la versione 2 di productcatalogservice.

docs/canary-service/destination-v1-v2.yaml

Visualizza su GitHub
```
apiVersion: networking.istio.io/v1alpha3
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 vengono distinte dopo che il traffico è stato instradato da VirtualService.

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

Suddividi traffico tra v1 e v2

Un VirtualService è il modo in cui introduci una piccola percentuale del traffico verso la v2 di productcatalogservice.

docs/canary-service/vs-split-traffic.yaml

Visualizza su GitHub
```
apiVersion: networking.istio.io/v1alpha3
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 del sottoinsieme indica la versione, mentre il campo del peso indica la suddivisione percentuale del traffico. Il 75% del traffico passerà alla versione 1 del catalogo dei prodotti, mentre il 25% alla versione 2.

Applica il VirtualService:
```
kubectl apply -f vs-split-traffic.yaml -n onlineboutique
```

Se visiti EXTERNAL_IP del traffico in entrata nel cluster, devi notare che periodicamente il frontend viene caricato più lentamente.

Nella sezione successiva, esplorerai la suddivisione del traffico nella console Google Cloud di Anthos.

Osservare la suddivisione del traffico nella console Google Cloud

Torna alla console Google Cloud e vai alla pagina Servizi Anthos Vai ai servizi Anthos
In alto a destra, fai clic su Topologia.

Espandi il carico di lavoro productcatalogservice. Vedrai productcatalogservice e productcatalogservice-v2 deployment.
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 per la percentuale specificata nel file VirtualService e che il servizio catalogo prodotti è costituito da 2 carichi di lavoro.

Sul lato destro dello schermo, vedrai le metriche Richieste, Tasso di errore e Latenza. Con Anthos Service Mesh, ogni servizio avrà queste metriche descritte per offrirti l'osservabilità.

Nota: la visualizzazione della suddivisione effettiva 75-25 richiederà un po' di tempo, poiché il traffico nel tempo verrà indirizzato al servizio v2.

Implementazione o rollback a una versione

Dopo aver osservato le metriche durante un deployment canary, puoi implementare il nuovo servizio o eseguire il rollback al servizio precedente utilizzando la risorsa VirtualService.

Implementazione

Una volta soddisfatto del comportamento di un servizio v2, aumentalo in modo incrementale al traffico. Alla fine, il traffico può essere indirizzato al 100% verso il nuovo servizio.

docs/canary-service/vs-v2.yaml

Visualizza su GitHub

apiVersion: networking.istio.io/v1alpha3
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

Esegui il rollback

Se devi eseguire il rollback al servizio v1, devi semplicemente applicare l'elemento destination-vs-v1.yaml dalla versione precedente. Il traffico verrà indirizzato solo alla versione 1 di productcatalogservice.

docs/canary-service/vs-v1.yaml

Visualizza su GitHub

apiVersion: networking.istio.io/v1alpha3
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

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Per evitare che al tuo account Google Cloud vengano addebitati costi continui per le risorse utilizzate in questo tutorial, puoi eliminare il progetto o le singole risorse.

Elimina il progetto

In Cloud Shell, elimina il progetto:
```
gcloud projects delete PROJECT_ID
```

Elimina le risorse

Se vuoi evitare addebiti aggiuntivi, elimina il cluster:

gcloud container clusters delete  CLUSTER_NAME  \
--project=PROJECT_ID \
--zone=CLUSTER_LOCATION

Se vuoi mantenere il cluster e rimuovere l'esempio di Boutique online:

Elimina gli spazi dei nomi dell'applicazione:

kubectl delete -f namespace onlineboutique

Output previsto:

namespace "onlineboutique" deleted

Elimina le voci di servizio:

kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/istio-manifests/frontend.yaml -n onlineboutique
kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/istio-manifests/frontend-gateway.yaml -n onlineboutique

Output previsto:

serviceentry.networking.istio.io "allow-egress-googleapis" deleted
serviceentry.networking.istio.io "allow-egress-google-metadata" deleted

Passaggi successivi

Per una guida generale sulla configurazione dei criteri PeerAuthentication, consulta Configurazione della sicurezza dei trasporti.