Canary Deployment v Kubernetes #3: Istio

Použitie Istio+Kiali na spustenie a vizualizáciu Canary nasadenia

Články v tejto sérii

1. Canary nasadenie v Kubernetes #1: Gitlab CI
2. Canary nasadenie v Kubernetes #2: Argo Rollouts
3. (tento článok)
4. Canary nasadenie pomocou Jenkins-X Istio Flagger

Canary nasadenie

Dúfame, že ste čítali prvú časť, kde sme stručne vysvetlili, čo sú Canary nasadenia a ukázali, ako ich realizovať pomocou štandardných zdrojov Kubernetes.

Istio

A predpokladáme, že čítaním tohto článku už viete, čo je Istio. Ak nie, môžete si o ňom prečítať tu.

Aplikácia na testovanie

Každý pod obsahuje dva kontajnery: našu aplikáciu a istio-proxy.

Budeme používať jednoduchú testovaciu aplikáciu s podmi frontend-nginx a backend na python. Pod s nginx jednoducho presmeruje každý požiadavok na pod s backendom a bude fungovať ako proxy. Podrobnosti si môžete pozrieť v nasledujúcich yaml súboroch:

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

Spustenie testovacej aplikácie samostatne

Ak chcete ísť podľa môjho príkladu a použiť túto testovaciu aplikáciu samostatne, pozrite sa na readme projektu.

Počiatočné nasadenie

Pri spustení prvého nasadenia vidíme, že pody našej aplikácie majú po dva kontajnery, to znamená, že Istio sidecar sa zatiaľ len implementuje:

A tiež vidíme Istio Gateway Loadbalancer v namespace istio-system:

Vytvorenie prevádzky

Budeme používať nasledujúcu IP adresu na generovanie prevádzky, ktorá bude prijímaná frontend podmi a presmerovaná na backend pody:

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

Takisto pridáme frontend.istio-test do nášho hosts súboru.

Prehľad Meshu cez Kiali

Nainštalovali sme testovaciu aplikáciu a Istio spolu s Tracing, Grafana, Prometheus a Kiali (podrobnosti pozri readme projektu). Preto môžeme používať Kiali cez:

istioctl dashboard kiali # admin:admin

Kiali vizualizuje aktuálnu prevádzku cez Mesh

Ako vidíme, 100% prevádzky ide na frontend službu, potom na pod frontendu s label v1, pretože používame jednoduchý nginx-proxy, ktorý presmerováva požiadavky na backend službu, ktorá ich následne presmerováva na backend pody s label v1.

Kiali funguje skvele spolu s Istio a poskytuje hotové riešenie na vizualizáciu Mesh. Jednoducho úžasné.

Canary nasadenie

Náš backend už má dva k8s nasadenia, jedno pre v1 a jedno pre v2. Teraz musíme len povedať Istio, aby presmerovalo určitý percentuálny podiel požiadaviek na v2.

Krok 1: 10%

A všetko, čo musíme urobiť, je nastaviť váhu VirtualService na 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

Vidíme, že 10% požiadaviek je presmerovaných na v2.

Krok 2: 50%

A teraz stačí jednoducho zvýšiť jeho hodnotu 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

Krok 3: 100%

Teraz môže byť Canary deployment považovaný za dokončený a celý prenos je presmerovaný na v2:

Manuálne testovanie Canary

Predpokladajme, že momentálne posielame na backend v2 10% zo všetkých požiadaviek. Čo ak chceme manuálne otestovať v2, aby sme sa uistili, že všetko funguje tak, ako očakávame?

Môžeme pridať osobitné pravidlo, ktoré je založené na HTTP hlavičkách:

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

Teraz môžeme pomocou curl nútene požiadať o v2 zaslaním hlavičky:

Požiadavky bez hlavičky budú stále riadené pomerom 1/10:

Canary pre dve závislé verzie

Teraz sa pozrieme na variant, kde máme verziu v2 a pre frontend a backend. Pre obidve sme nastavili, že 10% prenosu by malo ísť na v2:

Vidíme, že frontend v1 a v2 oba presmerovávajú prenos v pomere 1/10 na backend v1 a v2.

A čo ak by sme potrebovali presmerovať prenos z frontend-v2 len na backend-v2, pretože nie je kompatibilný s v1? Na to nastavíme pomer 1/10 pre frontend, ktorý kontroluje, aký prenos sa dostane na backend-v2, pomocou zgodového 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

V dôsledku toho dostaneme, čo potrebujeme:

Rozdiely od manuálneho prístupu Canary

V prvej časti vykonávali sme deploy Canary ručne, pričom sme tiež používali dva nasadenia k8s. Tam sme riadili pomer požiadaviek, meniac počet replik. Tento prístup funguje, ale má vážne nevýhody.

Istio umožňuje definovať pomer požiadaviek bez ohľadu na počet replik. To znamená, že napríklad môžeme použiť HPA (Horizontal Pod Autoscaler – horizontálne skálovanie podov) a jeho nemusíme konfigurovať podľa aktuálneho stavu deploy Canary.

Záver

Istio funguje skvele a jeho používanie spolu s Kiali nám dáva veľmi silnú kombináciu. Ďalšou vecou, o ktorú mám záujem, je kombinácia Spinnaker s Istio na automatizáciu a analýzu Canary.

Zdroj: habr.com