Vendosja e Kanarinave në Kubernetes #3: Istio

Përdorimi i Istio+Kiali për të nisur dhe vizualizuar një vendosje Canary

Artikuj në këtë seri

1. Vendosja e Kanarinave në Kubernetes #1: Gitlab CI
2. Vendosja e Kanarinave në Kubernetes #2: Argo Rollouts
3. (Ky artikull)
4. Zbatimi i Kanarit duke përdorur Jenkins-X Istio Flagger

Vendosja e Kanarinave

Shpresojmë ta lexoni pjesa e pare, ku shpjeguam shkurtimisht se çfarë janë vendosjet e Canary dhe treguam se si t'i zbatojmë ato duke përdorur burimet standarde të Kubernetes.

Istio

Dhe supozojmë se duke lexuar këtë artikull tashmë e dini se çfarë është Istio. Nëse jo, atëherë mund të lexoni për të këtu.

Aplikimi për teste

Çdo pod përmban dy kontejnerë: aplikacionin tonë dhe istio-proxy.

Ne do të përdorim një aplikacion të thjeshtë testimi me pods frontend-nginx dhe backend python. Nginx pod thjesht do të ridrejtojë çdo kërkesë në podin e fundit dhe do të funksionojë si një përfaqësues. Detajet mund t'i gjeni në yamlët e mëposhtëm:

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

Duke ekzekutuar vetë aplikacionin e testimit

Nëse dëshironi të ndiqni shembullin tim dhe të përdorni vetë këtë aplikacion testimi, shihni projekt readme.

Vendosja fillestare

Kur lëshojmë Deployment-in e parë, shohim që pod-et e aplikacionit tonë kanë vetëm 2 kontejnerë, domethënë, Istio sidecar sapo po zbatohet:

Dhe ne gjithashtu shohim Istio Gateway Loadbalancer në hapësirën e emrave istio-system:

Gjenerimi i trafikut

Ne do të përdorim IP-në e mëposhtme për të gjeneruar trafik që do të merret nga pod-et e përparme dhe do të përcillet në pod-et e fundit:

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

Ne gjithashtu do të shtojmë frontend.istio-test në skedarin tonë të hosteve.

Shiko Mesh nëpërmjet Kiali

Ne instaluam aplikacionin e testimit dhe Istio së bashku me Tracing, Grafana, Prometheus dhe Kiali (shih më poshtë për detaje). projekt readme). Prandaj, ne mund të përdorim Kiali nëpërmjet:

istioctl dashboard kiali # admin:admin

Kiali vizualizon trafikun aktual përmes Mesh

Siç mund ta shohim, 100% e trafikut shkon në shërbimin frontend, pastaj në pods frontend me etiketën v1, pasi ne po përdorim një proxy të thjeshtë nginx që ridrejton kërkesat në shërbimin e backend, i cili nga ana tjetër i ridrejton ato në pods-et e fundit. me etiketën v1.

Kiali funksionon shkëlqyeshëm me Istio dhe ofron një zgjidhje për paraqitjen e rrjetës në kuti. Thjesht fantastike.

Vendosja e Kanarinave

Backend-i ynë tashmë ka dy vendosje të k8s, një për v1 dhe një për v2. Tani vetëm duhet t'i themi Istio që të përcjellë një përqindje të caktuar kërkesash te v2.

Hapi 1: 10%

Dhe gjithçka që duhet të bëjmë është të rregullojmë peshën e 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

Ne shohim që 10% e kërkesave janë ridrejtuar në v2.

Hapi 2: 50%

Dhe tani është e mjaftueshme vetëm për ta rritur atë në 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

Hapi 3: 100%

Tani vendosja e Canary mund të konsiderohet e plotë dhe i gjithë trafiku ridrejtohet në v2:

Testimi i Canary me dorë

Le të themi se tani dërgojmë 2% të të gjitha kërkesave në backend-in v10. Po sikur të duam të testojmë manualisht v2 për t'u siguruar që gjithçka funksionon siç presim?

Ne mund të shtojmë një rregull të veçantë përputhjeje bazuar në kokat e 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

Tani duke përdorur curl ne mund të detyrojmë një kërkesë v2 duke dërguar kokën:

Kërkesat pa titull do të drejtohen ende nga raporti 1/10:

Kanari për dy versione të varura

Tani do të shqyrtojmë opsionin ku kemi versionin v2 si për frontend ashtu edhe për backend. Për të dyja, ne specifikuam që 10% e trafikut duhet të shkojë në v2:

Ne shohim që frontend v1 dhe v2 të dy trafikun përpara në një raport prej 1/10 me pjesën e pasme v1 dhe v2.

Po sikur të na duhej të përcillnim trafikun nga frontend-v2 vetëm në backend-v2 sepse nuk është i pajtueshëm me v1? Për ta bërë këtë, ne do të vendosim një raport 1/10 për frontend, i cili kontrollon se çfarë trafiku arrin në backend-v2 duke përdorur negociatat 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

Si rezultat, marrim atë që na nevojitet:

Dallimet nga qasja manuale Canary

В Pjesa e parë Ne kryem vendosjen Canary manualisht, duke përdorur gjithashtu dy vendosje k8s. Aty kontrolluam raportin e kërkesave duke ndryshuar numrin e kopjeve. Kjo qasje funksionon, por ka disavantazhe serioze.

Istio bën të mundur përcaktimin e raportit të kërkesave pavarësisht nga numri i kopjeve. Kjo do të thotë, për shembull, që ne mund të përdorim HPA (Horizontal Pod Autoscalers) dhe nuk kemi nevojë të konfigurohemi sipas gjendjes aktuale të vendosjes së Kanarit.

Total

Istio funksionon shkëlqyeshëm dhe përdorimi i tij së bashku me Kiali bën një kombinim shumë të fuqishëm. Tjetra në listën time të interesave është kombinimi i Spinnaker me Istio për automatizimin dhe analitikën Canary.

Burimi: www.habr.com