Canary implementacija u Kubernetes #3: Istio

Korištenje Istio+Kiali za pokretanje i vizualizaciju Canary implementacije

Članci u ovoj seriji

1. Canary implementacija u Kubernetes #1: Gitlab CI
2. Canary implementacija u Kubernetes #2: Argo Rollouts
3. (Ovaj članak)
4. Canary Deployment koristeći Jenkins-X Istio Flagger

Canary Deployment

Nadamo se da ste pročitali prvi dio, gdje smo ukratko objasnili šta su Canary implementacije i pokazali kako ih implementirati koristeći standardne Kubernetes resurse.

Istio

Pretpostavljamo da čitajući ovaj članak već znate što je Istio. Ako ne, onda možete pročitati o tome ovdje.

Prijava za testove

Svaki pod sadrži dva kontejnera: našu aplikaciju i istio-proxy.

Koristićemo jednostavnu test aplikaciju sa frontend-nginx i backend python podovima. Nginx pod će jednostavno preusmjeriti svaki zahtjev na backend pod i raditi kao proxy. Detalje možete pronaći u sljedećim yamlovima:

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

Pokrenite testnu aplikaciju sami

Ako želite slijediti moj primjer i sami koristiti ovu testnu aplikaciju, pogledajte project readme.

Initial Deployment

Kada pokrenemo prvi Deployment, vidimo da podovi naše aplikacije imaju samo 2 kontejnera, odnosno Istio sidecar se upravo implementira:

Takođe vidimo Istio Gateway Loadbalancer u imenskom prostoru istio-system:

Generisanje saobraćaja

Koristit ćemo sljedeću IP adresu za generiranje prometa koji će primati frontend podovi i proslijeđivati ​​backend podovima:

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

Takođe ćemo dodati frontend.istio-test u naš fajl hostova.

Pogledajte Mesh preko Kiali

Instalirali smo testnu aplikaciju i Istio zajedno sa Tracingom, Grafanom, Prometheusom i Kialijem (pogledajte dolje za detalje). project readme). Stoga Kiali možemo koristiti putem:

istioctl dashboard kiali # admin:admin

Kiali vizualizira trenutni promet kroz Mesh

Kao što vidimo, 100% saobraćaja ide na frontend servis, zatim na frontend podove sa oznakom v1, pošto koristimo jednostavan nginx proxy koji preusmjerava zahtjeve na backend servis, koji ih zauzvrat preusmjerava na backend podove sa oznakom v1.

Kiali odlično radi s Istiom i nudi rješenje za renderiranje mreže u kutiji. Samo super.

Canary Deployment

Naš backend već ima dvije k8s implementacije, jednu za v1 i jednu za v2. Sada samo trebamo reći Istiu da proslijedi određeni postotak zahtjeva v2.

Korak 1: 10%

I sve što treba da uradimo je da prilagodimo težinu VirtualServicea 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

Vidimo da je 10% zahtjeva preusmjereno na v2.

Korak 2: 50%

A sada je dovoljno samo da ga povećate na 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

Korak 3: 100%

Sada se postavljanje Canaryja može smatrati završenim i sav promet se preusmjerava na v2:

Ručno testiranje Canaryja

Recimo da sada šaljemo 2% svih zahtjeva na v10 backend. Što ako želimo ručno testirati v2 kako bismo bili sigurni da sve radi kako očekujemo?

Možemo dodati posebno pravilo podudaranja na osnovu HTTP zaglavlja:

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

Sada koristeći curl možemo forsirati v2 zahtjev slanjem zaglavlja:

Zahtjevi bez zaglavlja i dalje će biti vođeni omjerom 1/10:

Canary za dvije zavisne verzije

Sada ćemo razmotriti opciju u kojoj imamo verziju v2 i za frontend i za backend. Za oba smo naveli da 10% saobraćaja treba da ide na v2:

Vidimo da frontend v1 i v2 prosljeđuju promet u omjeru 1/10 prema backend v1 i v2.

Što ako bismo trebali proslijediti promet sa frontend-v2 samo na backend-v2 jer nije kompatibilan s v1? Da bismo to učinili, postavit ćemo omjer 1/10 za frontend, koji kontrolira koji promet dolazi do backend-v2 koristeći pregovaranje 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

Kao rezultat, dobijamo ono što nam je potrebno:

Razlike u odnosu na ručni pristup Canary

В prvi deo Izveli smo Canary implementaciju ručno, također koristeći dvije k8s implementacije. Tamo smo kontrolisali odnos zahteva promenom broja replika. Ovaj pristup funkcionira, ali ima ozbiljne nedostatke.

Istio omogućava određivanje omjera zahtjeva bez obzira na broj replika. To znači, na primjer, da možemo koristiti HPA (Horizontal Pod Autoscalers) i da ne moramo biti konfigurirani prema trenutnom stanju Canary implementacije.

Rezultat

Istio radi odlično i korištenje zajedno s Kialijem čini vrlo moćnu kombinaciju. Sljedeće na mojoj listi interesovanja je kombinacija Spinnakera sa Istiom za automatizaciju i Canary analitiku.

izvor: www.habr.com