Canary Deployment v Kubernetes #3: Istio

Použití Istio+Kiali ke spuštění a vizualizaci nasazení Canary

Canary Deployment v Kubernetes #3: Istio

Články v této sérii

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

Kanárské nasazení

Doufáme, že čtete první díl, kde jsme stručně vysvětlili, co jsou nasazení Canary a ukázali, jak je implementovat pomocí standardních zdrojů Kubernetes.

Stejný

A předpokládáme, že přečtením tohoto článku už víte, co je Istio. Pokud ne, můžete si o tom přečíst zde.

Přihláška ke zkouškám

Canary Deployment v Kubernetes #3: Istio

Každý modul obsahuje dva kontejnery: naši aplikaci a istio-proxy.

Použijeme jednoduchou testovací aplikaci s frontend-nginx a backend python pody. Pod nginx jednoduše přesměruje každý požadavek na backend pod a bude fungovat jako proxy. Podrobnosti najdete v následujících yamls:

Spuštění testovací aplikace sami

Pokud chcete následovat můj příklad a sami tuto testovací aplikaci používat, viz projekt readme.

Počáteční nasazení

Když spustíme první nasazení, vidíme, že moduly naší aplikace mají pouze 2 kontejnery, to znamená, že postranní vozík Istio se právě implementuje:

Canary Deployment v Kubernetes #3: Istio

A ve jmenném prostoru vidíme také Istio Gateway Loadbalancer istio-system:

Canary Deployment v Kubernetes #3: Istio

Generování dopravy

Ke generování provozu, který bude přijímán frontendovými moduly a předáván backendovým modulům, použijeme následující IP:

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

Také doplníme frontend.istio-test do našeho souboru hosts.

Zobrazit Mesh přes Kiali

Nainstalovali jsme testovací aplikaci a Istio spolu s Tracing, Grafana, Prometheus a Kiali (podrobnosti viz níže). projekt readme). Proto můžeme Kiali používat prostřednictvím:

istioctl dashboard kiali # admin:admin

Canary Deployment v Kubernetes #3: Istio

Kiali vizualizuje aktuální provoz prostřednictvím sítě Mesh

Jak vidíme, 100 % provozu jde do frontendové služby a poté do frontendových podů s označením v1, protože používáme jednoduchý nginx proxy, který přesměrovává požadavky na backendovou službu, která je zase přesměrovává na backendové pody. se štítkem v1.

Kiali skvěle spolupracuje s Istio a poskytuje krabicové řešení vykreslování Mesh. Prostě skvělé.

Kanárské nasazení

Náš backend již má dvě nasazení k8s, jedno pro v1 a jedno pro v2. Teď jen musíme říct Istiovi, aby přeposlal určité procento požadavků do v2.

Krok 1: 10 %

A vše, co musíme udělat, je upravit 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

Canary Deployment v Kubernetes #3: Istio

Vidíme, že 10 % požadavků je přesměrováno na v2.

Krok 2: 50 %

A teď to stačí zvýšit 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

Canary Deployment v Kubernetes #3: Istio

Krok 3: 100 %

Nyní lze nasazení Canary považovat za dokončené a veškerý provoz je přesměrován na v2:

Canary Deployment v Kubernetes #3: Istio

Testování Canary ručně

Řekněme, že nyní posíláme 2 % všech požadavků na backend v10. Co když chceme ručně otestovat v2, abychom se ujistili, že vše funguje tak, jak očekáváme?

Můžeme přidat speciální pravidlo pro párování 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

Nyní pomocí curl můžeme vynutit požadavek v2 odesláním záhlaví:

Canary Deployment v Kubernetes #3: Istio

Požadavky bez záhlaví budou stále řízeny poměrem 1/10:

Canary Deployment v Kubernetes #3: Istio

Canary pro dvě závislé verze

Nyní zvážíme možnost, kdy máme verzi v2 pro frontend i backend. U obou jsme uvedli, že 10 % provozu by mělo jít do verze 2:

Canary Deployment v Kubernetes #3: Istio

Vidíme, že frontend v1 a v2 oba dopředný provoz v poměru 1/10 k backendu v1 a v2.

Co kdybychom potřebovali přesměrovat provoz z frontend-v2 pouze na backend-v2, protože to není kompatibilní s v1? Za tímto účelem nastavíme pro frontend poměr 1/10, který řídí, jaký provoz se dostane na backend-v2 pomocí vyjednávání 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, co potřebujeme:

Canary Deployment v Kubernetes #3: Istio

Rozdíly od manuálního kanárského přístupu

В první část Nasazení Canary jsme provedli ručně, také pomocí dvou nasazení k8s. Tam jsme řídili poměr požadavků změnou počtu replik. Tento přístup funguje, ale má vážné nevýhody.

Istio umožňuje určit poměr požadavků bez ohledu na počet replik. To například znamená, že můžeme používat HPA (Horizontal Pod Autoscalers) a nemusíme být konfigurováni podle aktuálního stavu nasazení Canary.

Celkový

Istio funguje skvěle a jeho použití spolu s Kiali vytváří velmi silnou kombinaci. Další na mém seznamu zájmů je kombinace Spinnaker s Istio pro automatizaci a analytiku Canary.

Zdroj: www.habr.com

Přidat komentář