Versione 1.14

Anthos Service Mesh per esempio: deployment canary

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Cos'è un deployment canary?

Un deployment canary esegue il routing di una piccola percentuale di traffico a una nuova versione di un microservizio, per consentirti di implementare gradualmente l'intera base utenti, eliminando gradualmente e ritirando la versione precedente. Se si verifica un problema durante questo processo, il traffico può essere ripristinato alla versione precedente. Con Anthos Service Mesh, puoi instradare il traffico per garantire che i nuovi servizi vengano introdotti in modo sicuro.

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

Costi

Questo tutorial utilizza 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 beneficiare di una prova gratuita.

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

Prima di iniziare

Esegui il deployment di Boutique online

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

    gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION
    
  2. Crea lo spazio dei nomi per l'applicazione di esempio e il gateway in entrata:

    kubectl create namespace onlineboutique
    
  3. Assegna un'etichetta allo spazio dei nomi onlineboutique per inserire automaticamente i proxy Envoy. Segui la procedura per attivare l'inserimento automatico delle sidecar.

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

    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 dell'applicazione devono essere attivi e in esecuzione, mentre 2/2 nella colonna READY deve essere in esecuzione. Questo indica che i pod hanno un proxy sidecar Envoy inserito correttamente.

  6. 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/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.

  7. Visita l'applicazione nel browser utilizzando l'indirizzo IP esterno del tuo traffico in entrata:

    kubectl get services -n GATEWAY_NAMESPACE
    

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

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

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

    Vai ad Anthos Services

  2. Per impostazione predefinita, vedi i tuoi servizi nella visualizzazione Tabella.

    La Panoramica della tabella ti consente di osservare un riepilogo di tutti i tuoi servizi e delle metriche importanti.

    tutti i carichi di lavoro dei servizi

  3. In alto a destra, fai clic su Topologia. Qui puoi vedere i tuoi servizi e le loro interazioni.

    Puoi espandere i servizi e visualizzare le richieste al secondo per ognuno dei tuoi servizi passando il mouse sopra il cursore.

    topologia dei carichi di lavoro di tutti i servizi

  4. Torna alla Visualizzazione tabella.

  5. Nella tabella Servizi, seleziona productcatalogservice. Verrà visualizzata una panoramica del servizio.

  6. Sul lato sinistro dello schermo, fai clic su Traffico.

  7. Assicurati che il 100% del traffico in entrata verso productcatalogservice sia indirizzato al servizio del carico di lavoro.

    Traffico SVC catalogo prodotti

Nella sezione successiva verrà creata una versione 2 del servizio productcatalog.

Deployment della versione 2 di un servizio

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

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

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

    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 distinti 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

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

    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 della ponderazione indica la suddivisione percentuale del traffico. Il 75% del traffico passerà alla v1 del catalogo dei prodotti e il 25% alla v2.

    Applica il VirtualService:

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

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

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

Osservare la suddivisione del traffico nella console Google Cloud

  1. Torna alla console Google Cloud e vai alla pagina Servizi Anthos Vai ai servizi Anthos

  2. In alto a destra, fai clic su Topologia.

    Espandi il carico di lavoro productcatalogservice. Vedrai i deployment productcatalogservice e productcatalogservice-v2.

    catalogo prodotti svc v1 v2 tpoplogy

  3. Torna alla visualizzazione tabella. Fai clic su productcatalogservice nella tabella Servizi. Torna a Traffico nella barra di navigazione a sinistra.

  4. Tieni presente che il traffico in entrata è suddiviso tra v1 e v2 per la percentuale specificata nel file VirtualService e che sono presenti 2 carichi di lavoro del servizio productcatalog.

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

    Traffico del catalogo dei prodotti svc v1 v2

Implementazione o rollback a una versione

Dopo aver osservato le metriche durante un deployment canary, puoi eseguire l'implementazione nel nuovo servizio o eseguire il rollback al vecchio servizio sfruttando la risorsa VirtualService.

Implementazione

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

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, puoi semplicemente applicare destination-vs-v1.yaml dalla versione precedente. In questo modo, il traffico verrà reindirizzato soltanto alla versione 1 di productcatalogservice.

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 relativi alle risorse utilizzate in questo tutorial, puoi eliminare il progetto o le singole risorse.

Elimina il progetto

  1. In Cloud Shell, elimina il progetto:

    gcloud projects delete PROJECT_ID
    

Elimina le risorse

  • Se vuoi evitare costi 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:

    1. Elimina gli spazi dei nomi dell'applicazione:

      kubectl delete -f namespace onlineboutique
      

      Output previsto:

      namespace "onlineboutique" deleted
      
    2. Elimina le voci del 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