Nasadenie Canary v Kubernetes #3: Istio

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

Nasadenie Canary v Kubernetes #3: Istio

Články v tejto sérii

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

Kanárske nasadenie

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

Istio

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

Prihláška na testy

Nasadenie Canary v Kubernetes #3: Istio

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

Použijeme jednoduchú testovaciu aplikáciu s frontend-nginx a backend python pods. Pod nginx jednoducho presmeruje každú požiadavku na backend pod a bude fungovať ako proxy. Podrobnosti nájdete v nasledujúcich yamls:

Spustenie testovacej aplikácie sami

Ak chcete nasledovať môj príklad a sami použiť túto testovaciu aplikáciu, viď projekt readme.

Počiatočné nasadenie

Keď spustíme prvé nasadenie, vidíme, že moduly našej aplikácie majú iba 2 kontajnery, to znamená, že sajdkár Istio sa práve implementuje:

Nasadenie Canary v Kubernetes #3: Istio

A v mennom priestore vidíme aj Istio Gateway Loadbalancer istio-system:

Nasadenie Canary v Kubernetes #3: Istio

Generovanie dopravy

Na generovanie návštevnosti, ktorá bude prijímaná frontendovými modulmi a preposlaná do backendových modulov, použijeme nasledujúcu adresu IP:

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

Tiež pridáme frontend.istio-test do súboru našich hostiteľov.

Zobraziť sieť cez Kiali

Nainštalovali sme testovaciu aplikáciu a Istio spolu s Tracing, Grafana, Prometheus a Kiali (podrobnosti nájdete nižšie). projekt readme). Preto môžeme Kiali použiť cez:

istioctl dashboard kiali # admin:admin

Nasadenie Canary v Kubernetes #3: Istio

Kiali vizualizuje aktuálnu premávku cez Mesh

Ako vidíme, 100 % návštevnosti smeruje do frontendovej služby, potom do frontendových modulov s označením v1, pretože používame jednoduchý nginx proxy, ktorý presmeruje požiadavky na backendovú službu, ktorá ich následne presmeruje na backendové moduly. s označením v1.

Kiali funguje skvele s Istio a poskytuje krabicové riešenie vykresľovania Mesh. Proste skvelé.

Kanárske nasadenie

Náš backend už má dve nasadenia k8s, jedno pre v1 a jedno pre v2. Teraz musíme povedať Istiovi, aby postúpil určité percento žiadostí do verzie 2.

Krok 1: 10 %

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

Nasadenie Canary v Kubernetes #3: Istio

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

Krok 2: 50 %

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

Nasadenie Canary v Kubernetes #3: Istio

Krok 3: 100 %

Teraz možno nasadenie Canary považovať za dokončené a všetka prevádzka je presmerovaná na verziu 2:

Nasadenie Canary v Kubernetes #3: Istio

Manuálne testovanie Canary

Допустим, сейчас мы отправляем на бэкэнд v2 10% от всех запросов. Что, если мы хотим вручную протестировать v2, чтобы убедиться, что все работает как мы ожидаем?

Môžeme pridať špeciálne pravidlo zhody založené na hlavičkách 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

Teraz pomocou curl môžeme vynútiť požiadavku v2 odoslaním hlavičky:

Nasadenie Canary v Kubernetes #3: Istio

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

Nasadenie Canary v Kubernetes #3: Istio

Canary pre dve závislé verzie

Teraz zvážime možnosť, kde máme verziu v2 pre frontend aj backend. Pre obe sme určili, že 10 % návštevnosti by malo smerovať na verziu 2:

Nasadenie Canary v Kubernetes #3: Istio

Vidíme, že frontend v1 a v2 obe doprednej prevádzky v pomere 1/10 k backend v1 a v2.

Čo keby sme potrebovali presmerovať návštevnosť z frontend-v2 iba na backend-v2, pretože to nie je kompatibilné s v1? Aby sme to dosiahli, nastavíme pre frontend pomer 1/10, ktorý riadi, aký prenos sa dostane na backend-v2 pomocou vyjednávania 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 to, čo potrebujeme:

Nasadenie Canary v Kubernetes #3: Istio

Rozdiely od manuálneho kanárskeho prístupu

В prvá časť Nasadenie Canary sme vykonali manuálne, aj pomocou dvoch nasadení k8s. Tam sme riadili pomer požiadaviek zmenou počtu replík. Tento prístup funguje, ale má vážne nevýhody.

Istio umožňuje určiť pomer požiadaviek bez ohľadu na počet replík. To znamená, že napríklad môžeme použiť HPA (Horizontal Pod Autoscalers) a nemusíme byť konfigurovaní podľa aktuálneho stavu nasadenia Canary.

Celkový

Istio funguje skvele a jeho použitie spolu s Kiali vytvára veľmi silnú kombináciu. Ďalej na mojom zozname záujmov je kombinácia Spinnaker s Istio pre automatizáciu a Canary analytics.

Zdroj: hab.com

Pridať komentár