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 implementacija pomoću Jenkins-X Istio Flaggera

Canary raspoređivanje

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

Istio

A pretpostavljamo da čitajući ovaj članak već znate što je Istio. Ako ne, onda možete čitati o tome здесь.

Prijava za testove

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

Koristit ćemo jednostavnu testnu aplikaciju s frontend-nginx i backend python podovima. Nginx pod će jednostavno preusmjeriti svaki zahtjev na backend pod i raditi kao proxy. Detalji se mogu pronaći u sljedećim yamlovima:

• sučelje.yaml
• backend.yaml
• istio.yaml

Samostalno pokretanje testne aplikacije

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

Početno postavljanje

Kada pokrenemo prvu implementaciju, vidimo da podovi naše aplikacije imaju samo 2 spremnika, odnosno Istio sidecar se upravo implementira:

I također vidimo Istio Gateway Loadbalancer u prostoru imena istio-system:

Generiranje prometa

Koristit ćemo sljedeću IP adresu za generiranje prometa koji će primati prednji moduli i proslijeđivati ​​pozadinskim modulima:

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

Također ćemo dodati frontend.istio-test u našu host datoteku.

Pogledajte Mesh putem Kialija

Instalirali smo testnu aplikaciju i Istio zajedno s Tracingom, Grafanom, Prometheusom i Kialijem (pogledajte detalje u nastavku). projekt readme). Stoga Kiali možemo koristiti putem:

istioctl dashboard kiali # admin:admin

Kiali vizualizira trenutni promet kroz Mesh

Kao što vidimo, 100% prometa ide na frontend uslugu, zatim na frontend podove s oznakom v1, budući da koristimo jednostavan nginx proxy koji preusmjerava zahtjeve na pozadinsku uslugu, koja ih zauzvrat preusmjerava na pozadinske podove. s oznakom v1.

Kiali odlično funkcionira s Istiom i pruža rješenje za iscrtavanje Mesh mreže u kutiji. Baš odlično.

Canary raspoređivanje

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

1. korak: 10%

Sve što trebamo učiniti je prilagoditi 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.

2. korak: 50%

A sada je dovoljno samo povećati 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

3. korak: 100%

Sada se Canary implementacija može smatrati završenom i sav promet preusmjeren je na v2:

Ručno testiranje Canaryja

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

Možemo dodati posebno pravilo podudaranja na temelju 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 ovisne verzije

Sada ćemo razmotriti opciju gdje imamo verziju v2 i za frontend i za backend. Za oba smo odredili da 10% prometa treba ići na v2:

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

Što ako trebamo proslijediti promet s frontend-v2 samo na backend-v2 jer nije kompatibilan s v1? Da bismo to učinili, postavit ćemo omjer 1/10 za sučelje, koje 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 toga, dobivamo ono što nam je potrebno:

Razlike od ručnog Canary pristupa

В prvi dio Ručno smo izvršili implementaciju Canarya, također koristeći dva k8s rasporeda. Tamo smo promjenom broja replika kontrolirali omjer zahtjeva. Ovaj pristup funkcionira, ali ima ozbiljne nedostatke.

Istio omogućuje određivanje omjera zahtjeva neovisno o broju replika. To znači, na primjer, da možemo koristiti HPA (Horizontal Pod Autoscalers) i da ne moramo biti konfigurirani prema trenutnom stanju implementacije Canarya.

Ukupan

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

Izvor: www.habr.com