Distribuzione di Canary in Kubernetes #3: Istio

Utilizzo di Istio+Kiali per avviare e visualizzare una distribuzione Canary

Articoli di questa serie

1. Distribuzione Canary in Kubernetes #1: Gitlab CI
2. Distribuzione di Canary in Kubernetes #2: implementazioni di Argo
3. (Questo articolo)
4. Distribuzione Canary utilizzando Jenkins-X Istio Flagger

Distribuzione Canarie

Speriamo che tu legga la prima parte, in cui abbiamo spiegato brevemente cosa sono le distribuzioni Canary e mostrato come implementarle utilizzando le risorse Kubernetes standard.

Istio

E diamo per scontato che leggendo questo articolo tu sappia già cos’è Istio. In caso contrario, puoi leggerlo qui.

Domanda di test

Ogni pod contiene due contenitori: la nostra applicazione e istio-proxy.

Utilizzeremo una semplice applicazione di test con pod Python frontend-nginx e backend. Il pod nginx reindirizzerà semplicemente ogni richiesta al pod backend e funzionerà come proxy. I dettagli possono essere trovati nei seguenti yaml:

• frontend.yaml
• backend.yaml
• istio.yaml

Esegui tu stesso l'applicazione di prova

Se vuoi seguire il mio esempio e utilizzare tu stesso questa applicazione di prova, vedi leggimi del progetto.

Distribuzione iniziale

Quando lanciamo il primo Deployment, vediamo che i pod della nostra applicazione hanno solo 2 container, cioè il sidecar Istio è appena in fase di implementazione:

E vediamo anche Istio Gateway Loadbalancer nello spazio dei nomi istio-system:

Generazione di traffico

Utilizzeremo il seguente IP per generare traffico che verrà ricevuto dai pod frontend e inoltrato ai pod backend:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Aggiungeremo anche frontend.istio-test nel nostro file host.

Visualizza Mesh tramite Kiali

Abbiamo installato l'applicazione di test e Istio insieme a Tracing, Grafana, Prometheus e Kiali (vedi sotto per i dettagli). leggimi del progetto). Pertanto possiamo utilizzare Kiali tramite:

istioctl dashboard kiali # admin:admin

Kiali visualizza il traffico attuale attraverso Mesh

Come possiamo vedere, il 100% del traffico va al servizio frontend, quindi ai pod frontend con etichetta v1, poiché stiamo utilizzando un semplice proxy nginx che reindirizza le richieste al servizio backend, che a sua volta le reindirizza ai pod backend con etichetta v1.

Kiali funziona alla grande con Istio e fornisce una soluzione di rendering Mesh boxed. Semplicemente fantastico.

Distribuzione Canarie

Il nostro backend ha già due implementazioni k8, una per v1 e una per v2. Ora dobbiamo solo dire a Istio di inoltrare una certa percentuale di richieste alla v2.

Passaggio 1: 10%

E tutto ciò che dobbiamo fare è adattare il peso di VirtualService istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Vediamo che il 10% delle richieste viene reindirizzato alla v2.

Passaggio 2: 50%

E ora basta aumentarlo al 50%:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

Passaggio 3: 100%

Ora la distribuzione di Canary può essere considerata completa e tutto il traffico viene reindirizzato alla v2:

Testare Canary manualmente

Diciamo che ora inviamo il 2% di tutte le richieste al backend v10. Cosa succede se vogliamo testare manualmente la v2 per assicurarci che tutto funzioni come previsto?

Possiamo aggiungere una regola di corrispondenza speciale basata sulle intestazioni HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Ora usando curl possiamo forzare una richiesta v2 inviando l'intestazione:

Le richieste senza intestazione saranno comunque guidate dal rapporto 1/10:

Canary per due versioni dipendenti

Ora considereremo l'opzione in cui abbiamo la versione v2 sia per il frontend che per il backend. Per entrambi abbiamo specificato che il 10% del traffico dovrebbe andare alla v2:

Vediamo che il frontend v1 e v2 inoltrano entrambi il traffico con un rapporto di 1/10 rispetto al backend v1 e v2.

Cosa succederebbe se avessimo bisogno di inoltrare il traffico dal frontend-v2 solo al backend-v2 perché non è compatibile con v1? Per fare ciò, imposteremo un rapporto 1/10 per il frontend, che controlla quale traffico arriva al backend-v2 utilizzando la negoziazione sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

Di conseguenza, otteniamo ciò di cui abbiamo bisogno:

Differenze rispetto all'approccio manuale Canary

В la prima parte Abbiamo eseguito manualmente la distribuzione Canary, utilizzando anche due distribuzioni k8. Lì abbiamo controllato il rapporto delle richieste modificando il numero di repliche. Questo approccio funziona, ma presenta seri inconvenienti.

Istio consente di determinare il rapporto delle richieste indipendentemente dal numero di repliche. Ciò significa, ad esempio, che possiamo utilizzare HPA (Horizontal Pod Autoscaler) e non è necessario configurarli in base allo stato attuale della distribuzione Canary.

risultato

Istio funziona alla grande e usarlo insieme a Kiali costituisce una combinazione molto potente. Il prossimo passo nella mia lista di interessi è la combinazione di Spinnaker con Istio per l'automazione e l'analisi Canary.

Fonte: habr.com