Uvedba Canary v Kubernetes #3: Istio

Uporaba Istio+Kiali za zagon in vizualizacijo uvedbe Canary

Članki v tej seriji

1. Uvedba Canary v Kubernetes #1: Gitlab CI
2. Uvedba Canary v Kubernetes #2: Uvedbe Argo
3. (Ta članek)
4. Uvedba Canary z uporabo Jenkins-X Istio Flagger

Canary Deployment

Upamo, da berete prvi del, kjer smo na kratko razložili, kaj so Canary uvedbe in pokazali, kako jih implementirati s standardnimi viri Kubernetes.

Istio

Predvidevamo, da z branjem tega članka že veste, kaj je Istio. Če ne, potem lahko preberete o tem tukaj.

Vloga za teste

Vsak pod vsebuje dva vsebnika: našo aplikacijo in istio-proxy.

Uporabili bomo preprosto preskusno aplikacijo s frontend-nginx in backend python pods. Pod nginx bo preprosto preusmeril vsako zahtevo v zaledni pod in deloval kot proxy. Podrobnosti najdete v naslednjih datotekah yaml:

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

Izvajanje testne aplikacije sami

Če želite slediti mojemu zgledu in sami uporabiti to testno aplikacijo, glejte projekt readme.

Začetna uvedba

Ko zaženemo prvo uvedbo, vidimo, da imajo sklopi naše aplikacije samo 2 vsebnika, kar pomeni, da se stranska prikolica Istio šele izvaja:

V imenskem prostoru vidimo tudi Istio Gateway Loadbalancer istio-system:

Generiranje prometa

Naslednji IP bomo uporabili za ustvarjanje prometa, ki ga bodo prejeli sprednji moduli in ga posredovali zalednim modulom:

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

Dodali bomo tudi frontend.istio-test v našo datoteko gostiteljev.

Oglejte si mrežo prek Kialija

Namestili smo testno aplikacijo in Istio skupaj s Tracing, Grafana, Prometheus in Kiali (za podrobnosti glejte spodaj). projekt readme). Zato lahko Kiali uporabljamo prek:

istioctl dashboard kiali # admin:admin

Kiali vizualizira trenutni promet skozi Mesh

Kot lahko vidimo, gre 100 % prometa v čelno storitev, nato v čelne pode z oznako v1, saj uporabljamo preprost proxy nginx, ki preusmeri zahteve v zaledno storitev, ta pa jih preusmeri na zaledne pode. z oznako v1.

Kiali odlično deluje z Istio in ponuja rešitev za upodabljanje Mesh v škatli. Res super.

Canary Deployment

Naše zaledje že ima dve uvedbi k8s, eno za v1 in eno za v2. Zdaj moramo reči Istio, naj posreduje določen odstotek zahtev v v2.

1. korak: 10 %

In vse, kar moramo storiti, je prilagoditi težo 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

Vidimo, da je 10 % zahtev preusmerjenih na v2.

2. korak: 50 %

In zdaj je dovolj 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

3. korak: 100 %

Zdaj se lahko šteje, da je uvedba Canary dokončana in ves promet je preusmerjen na v2:

Ročno testiranje Canaryja

Recimo, da zdaj pošljemo 2 % vseh zahtev v zaledje v10. Kaj pa, če želimo ročno preizkusiti v2, da se prepričamo, da vse deluje, kot pričakujemo?

Dodamo lahko posebno pravilo ujemanja na podlagi glav 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

Zdaj lahko z uporabo curl vsilimo zahtevo v2 tako, da pošljemo glavo:

Za zahteve brez glave bo še vedno veljalo razmerje 1/10:

Canary za dve odvisni različici

Zdaj bomo razmislili o možnosti, kjer imamo različico v2 za sprednji in zadnji del. Za oba smo določili, da mora 10 % prometa iti na v2:

Vidimo, da sprednji del v1 in v2 posredujeta promet v razmerju 1/10 proti zalednemu delu v1 in v2.

Kaj pa, če bi morali posredovati promet iz frontend-v2 samo v backend-v2, ker ni združljiv z v1? Da bi to naredili, bomo nastavili razmerje 1/10 za sprednji del, ki nadzoruje, kakšen promet pride do zaledja-v2 z uporabo pogajanj 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

Kot rezultat dobimo tisto, kar potrebujemo:

Razlike od ročnega Canary pristopa

В 1. del Razmestitev Canaryja smo izvedli ročno, prav tako z uporabo dveh uvedb k8s. Tam smo razmerje zahtev nadzirali s spreminjanjem števila replik. Ta pristop deluje, vendar ima resne pomanjkljivosti.

Istio omogoča ugotavljanje razmerja zahtev ne glede na število replik. To na primer pomeni, da lahko uporabljamo HPA (Horizontal Pod Autoscalers) in jih ni treba konfigurirati glede na trenutno stanje uvedbe Canary.

Skupaj

Istio deluje odlično in njegova uporaba skupaj s Kiali je zelo močna kombinacija. Naslednji na seznamu mojih zanimanj je kombinacija Spinnakerja z Istio za avtomatizacijo in analitiko Canary.

Vir: www.habr.com