Kanaryske ynset yn Kubernetes #3: Istio

Istio+Kiali brûke om in Kanaryske ynset te starten en te visualisearjen

Artikels yn dizze rige

1. Kanaryske ynset yn Kubernetes #1: Gitlab CI
2. Kanaryske ynset yn Kubernetes # 2: Argo Rollouts
3. (Dit artikel)
4. Kanaryske ynset mei Jenkins-X Istio Flagger

Kanaryske ynset

Wy hoopje dat jo lêze earste diel.

Istio

En wy geane der fan út dat jo troch dit artikel te lêzen al witte wat Istio is. Sa net, dan kinne jo der oer lêze hjir.

Oanfraach foar tests

Elke pod befettet twa konteners: ús applikaasje en istio-proxy.

Wy sille in ienfâldige testapplikaasje brûke mei frontend-nginx en backend python pods. De nginx-pod sil elk fersyk gewoan trochferwize nei de backend-pod en wurkje as proxy. Details kinne fûn wurde yn de folgjende yamls:

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

De testapplikaasje sels útfiere

As jo ​​myn foarbyld wolle folgje en dizze testapplikaasje sels brûke, sjoch projekt readme.

Inisjele ynset

As wy de earste ynset lansearje, sjogge wy dat de pods fan ús applikaasje mar 2 konteners hawwe, dat is, Istio-sidecar wurdt krekt ymplementearre:

En wy sjogge ek Istio Gateway Loadbalancer yn 'e nammeromte istio-system:

Ferkear generaasje

Wy sille de folgjende IP brûke om ferkear te generearjen dat sil wurde ûntfongen troch de frontend pods en trochstjoerd nei de backend pods:

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

Wy sille ek tafoegje frontend.istio-test nei ús hosts-bestân.

Besjoch Mesh fia Kiali

Wy hawwe de testapplikaasje en Istio ynstalleare tegearre mei Tracing, Grafana, Prometheus en Kiali (sjoch hjirûnder foar details). projekt readme). Dêrom kinne wy ​​Kiali brûke fia:

istioctl dashboard kiali # admin:admin

Kiali fisualisearret aktuele ferkear fia Mesh

Sa't wy sjen kinne, giet 100% fan it ferkear nei de frontend-tsjinst, dan nei de frontend-pods mei label v1, om't wy in ienfâldige nginx-proxy brûke dy't fersiken omliedt nei de backend-tsjinst, dy't se op syn beurt omliedt nei de backend-pods mei label v1.

Kiali wurket geweldich mei Istio en leveret in doaze Mesh-rendering-oplossing. Gewoan geweldich.

Kanaryske ynset

Us backend hat al twa k8s-ynset, ien foar v1 en ien foar v2. No moatte wy Istio gewoan fertelle om in bepaald persintaazje oanfragen troch te stjoeren nei v2.

Stap 1: 10%

En alles wat wy hoege te dwaan is it gewicht fan 'e VirtualService yn te passen 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

Wy sjogge dat 10% fan oanfragen wurde omlaat nei v2.

Stap 2: 50%

En no is it genôch om it te ferheegjen nei 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

Stap 3: 100%

No kin de ynset fan Kanaryske as folslein beskôge wurde en al it ferkear wurdt omlaat nei v2:

Testing Canary hânmjittich

Litte wy sizze dat wy no 2% fan alle oanfragen stjoere nei de v10-backend. Wat as wy v2 manuell wolle testen om te soargjen dat alles wurket lykas wy ferwachtsje?

Wy kinne in spesjale oerienkommende regel tafoegje op basis fan HTTP-headers:

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

No mei curl kinne wy ​​​​in v2-fersyk twinge troch de koptekst te stjoeren:

Fersiken sûnder koptekst wurde noch altyd oandreaun troch de 1/10-ferhâlding:

Canary foar twa ôfhinklike ferzjes

No sille wy de opsje beskôgje wêr't wy ferzje v2 hawwe foar sawol frontend as backend. Foar beide hawwe wy spesifisearre dat 10% fan it ferkear nei v2 moat gean:

Wy sjogge dat frontend v1 en v2 beide foarút ferkear yn in ferhâlding fan 1/10 nei backend v1 en v2.

Wat as wy ferkear moatte trochstjoere fan frontend-v2 allinich nei backend-v2, om't it net kompatibel is mei v1? Om dit te dwaan, sille wy in 1/10-ferhâlding ynstelle foar de frontend, dy't kontrolearret hokker ferkear nei de backend-v2 komt mei ûnderhanneling 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

As resultaat krije wy wat wy nedich binne:

Ferskillen fan de hânlieding Kanaryske oanpak

В earste diel Wy hawwe Kanaryske ynset manuell útfierd, ek mei twa k8s-ynset. Dêr hawwe wy de ferhâlding fan oanfragen kontrolearre troch it oantal replika's te feroarjen. Dizze oanpak wurket, mar hat serieuze neidielen.

Istio makket it mooglik om te bepalen de ferhâlding fan fersiken nettsjinsteande it oantal replika's. Dit betsjut bygelyks dat wy HPA's (Horizontal Pod Autoscalers) kinne brûke en net hoege te konfigureare neffens de hjoeddeistige steat fan 'e Kanaryske ynset.

It resultaat

Istio wurket geweldich en it brûken fan it tegearre mei Kiali soarget foar in heul krêftige kombinaasje. Folgjende op myn list fan ynteresses is it kombinearjen fan Spinnaker mei Istio foar automatisearring en Kanaryske analytyk.

Boarne: www.habr.com