🥇Desfășurarea Canary în Kubernetes #3: Istio

Folosirea Istio+Kiali pentru lansarea și vizualizarea implementării Canary

Articolele acestui ciclu

Canary Deployment în Kubernetes #1: Gitlab CI
Canary Deployment în Kubernetes #2: Argo Rollouts
(acest articol)
Implementarea Canary folosind Jenkins-X Istio Flagger

Canary Deployment

Sperăm că ați citit prima parte, unde am explicat pe scurt ce sunt implementările Canary și am arătat cum să le realizăm folosind resurse standard Kubernetes.

Istio

Și presupunem că citind acest articol, știți deja ce este Istio. Dacă nu, puteți citi despre el aici.

Aplicație pentru teste

Fiecare pod conține două containere: aplicația noastră și istio-proxy.

Vom folosi o aplicație de testare simplă cu poduri frontend-nginx și backend pe python. Podul cu nginx va redirecționa fiecare cerere către podul cu backend și va funcționa ca un proxy. Detaliile pot fi văzute mai în detaliu în următoarele fișiere yaml:

Lansarea aplicației de testare pe cont propriu

Dacă doriți să urmați exemplul meu și să utilizați această aplicație de testare pe cont propriu, consultați readme-ul proiectului.

Implementarea inițială

Când lansăm prima implementare, vedem că podurile aplicației noastre au câte două containere, ceea ce înseamnă că Istio sidecar urmează să fie introdus:

Și de asemenea vedem Istio Gateway Loadbalancer în namespace istio-system:

Crearea traficului

Vom folosi următoarea adresă IP pentru a genera trafic, care va fi primit de podurile frontend și redirecționat către podurile backend:

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

De asemenea, vom adăuga frontend.istio-test în fișierul nostru hosts.

Vizualizarea Mesh prin Kiali

Am instalat aplicația de testare și Istio împreună cu Tracing, Grafana, Prometheus și Kiali (detalii mai jos). Așadar, putem folosi Kiali prin: readme-ul proiectului). Prin urmare, putem folosi Kiali prin:

istioctl dashboard kiali # admin:admin

Kiali vizualizează traficul actual prin Mesh

Așa cum vedem, 100% din trafic ajunge pe serviciul frontend, apoi pe podul frontend cu eticheta v1, deoarece folosim un nginx-proxy simplu, care redirecționează cererile către serviciul backend, care la rândul său le redirecționează către podurile backend cu eticheta v1.

Kiali funcționează perfect împreună cu Istio și oferă o soluție integrată pentru vizualizarea Mesh-ului. Pur și simplu minunat.

Canary Deployment

Backend-ul nostru are deja două implementări k8s, una pentru v1 și una pentru v2. Acum trebuie să-i spunem doar lui Istio să redirecționeze un anumit procent din cereri către v2.

Pasul 1: 10%

Și tot ce trebuie să facem este să ajustăm greutatea VirtualService în 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

Observăm că 10% din cereri sunt redirecționate către v2.

Pasul 2: 50%

Și acum este suficient să-l creștem la 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

Pasul 3: 100%

Acum implementarea Canary se poate considera completă și tot traficul este redirecționat către v2:

Testarea manuală a Canary

Să presupunem că în prezent trimitem către backend v2 10% din toate cererile. Ce se întâmplă dacă dorim să testăm manual v2 pentru a ne asigura că totul funcționează așa cum ne așteptăm?

Putem adăuga o regulă de potrivire specială, bazată pe antetele 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

Acum folosind curl, putem solicita forțat v2 trimițând antetul:

Cereri fără antet vor fi în continuare gestionate în raportul 1/10:

Canary pentru două versiuni dependente

Acum vom lua în considerare un caz în care avem versiunea v2 atât pentru frontend cât și pentru backend. Pentru ambele am specificat că 10% din trafic ar trebui să meargă la v2:

Observăm că frontend v1 și v2 ambele redirecționează traficul în raportul 1/10 către backend v1 și v2.

Și ce s-ar întâmpla dacă am avea nevoie să redirecționăm traficul de la frontend-v2 doar către backend-v2, deoarece acesta nu este compatibil cu v1? Pentru aceasta, vom stabili un raport 1/10 pentru frontend, care controlează ce trafic ajunge la backend-v2 utilizând potrivirea după 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

În rezultat, obținem ceea ce avem nevoie:

Diferente față de abordarea manuală a Canary

În prima parte Am efectuat desfășurarea Canary manual, folosind, de asemenea, două desfășurări k8s. Acolo am gestionat raportul solicitărilor, modificând numărul de replici. Această abordare funcționează, dar are dezavantaje semnificative.

Istio oferă posibilitatea de a defini raportul solicitărilor fără a depinde de numărul de replici. Asta înseamnă, de exemplu, că putem folosi HPAs (Horizontal Pod Autoscalers — scalare orizontală a podurilor) și nu este necesar să-l configurăm în conformitate cu starea actuală a desfășurării Canary.

Rezultatul

Istio funcționează excelent, iar utilizarea sa împreună cu Kiali ne oferă o combinație foarte puternică. Următoarea combinație de interes pe lista mea este combinația Spinnaker cu Istio pentru automatizare și analiză Canary.

Sursa: habr.com