🥇Canary Deployment Kuberneteses #3: Istio

Istio+Kiali kasutamine Canary deployde käivitamiseks ja visualiseerimiseks

Selle tsükli artiklid

Canary Deployment Kubernetes'is #1: Gitlab CI
Canary Deployment Kuberneteses #2: Argo Rollouts
(see artikkel)
Canary deployment Jenkins-X Istio Flaggeriga

Canary deploy

Loodame, et olete lugenud esimest osa, kus selgitasime lühidalt, mis on Canary deployd ja näitasime, kuidas seda rakendada Kubernetes'i standardsete ressursside abil.

Istio

Ja me eeldame, et lugedes seda artiklit, te juba teate, mis on Istio. Kui ei, siis võite sellest lugeda siin.

Testimisrakendus

Iga pod sisaldab kahte konteinerit: meie rakenduse ja istio-proxy.

Kasutame lihtsat testimisrakendust podidega frontend-nginx ja backend Pythonis. Nginxiga pod suunab iga päringu backend podile ja töötab kui proxy. Üksikasjadega saab tutvuda järgmistes YAML-failides:

Testimisrakenduse käivitamine iseseisvalt

Kui soovite järgida minu näidet ja kasutada seda testimisrakendust iseseisvalt, vaadake projekti readme.

Esialgne Deployment

Esimese Deployment'i käivitamisel näeme, et meie rakenduse podid sisaldavad vaid kahte konteinerit, st Istio sidecar on alles juurutamisel:

Ja samuti näeme Istio Gateway Loadbalancerit namespacis istio-system:

Liiklus genereerimine

Kasutame järgmist IP-d, et genereerida liiklust, mis hakkab saabuma frontend podidesse ja suunatakse backend podidesse:

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

Lisame samuti frontend.istio-test meie hosts faili.

Mesh'i vaatamine Kiali kaudu

Oleme installinud testimisrakenduse ja Istio koos Tracing, Grafana, Prometheus ja Kiali'ga (lisainfo vaata projekti readme). Seega saame kasutada Kiali't aadressil:

istioctl dashboard kiali # admin:admin

Kiali visualiseerib praegust liiklust läbi Mesh'i

Nagu näeme, suunatakse 100% liiklusest frontend teenusele, seejärel podi frontendiga, millel on label v1, kuna kasutame lihtsat nginx proxy't, mis suunab päringud backend teenusele, mis omakorda suunab need backend podidesse, millel on label v1.

Kiali töötab suurepäraselt koos Istio'ga ja pakub lahendust Mesh'i visualiseerimiseks. Lihtsalt suurepärane.

Canary deploy

Meie backend'il on juba kaks k8s deployment'i, üks v1 jaoks ja üks v2 jaoks. Nüüd peame lihtsalt ütlema Istio'le, et suunata teatud protsent päringutest v2 peale.

Samm 1: 10%

Ja kõik, mida peame tegema, on reguleerida VirtualService'i kaalu 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

Näeme, et 10% päringutest suunatakse v2-le.

Samm 2: 50%

Ja nüüd on lihtsalt vaja suurendada see 50%-ni:

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

Samm 3: 100%

Nüüd võib Canary deploymendi pidada lõpuleviiduks ja kogu liiklus suunatakse v2-le:

Canary testimine käsitsi

Oletame, et praegu suuname backend v2-le 10% kõigist päringutest. Mis siis, kui me tahame käsitsi testida v2, et veenduda, et kõik töötab nagu ootame?

Saame lisada spetsiaalse vastavusreegli, mis põhineb HTTP pealkirjadel:

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

Nüüd saame curliga sunniviisiliselt küsida v2, saates pealkirja:

Pealkirjata päringud suunatakse endiselt suhtega 1/10:

Canary kahe sõltuva versiooni jaoks

Nüüd vaatame olukorda, kus meil on versioon v2 nii frontendis kui backendis. Kummalegi oleme määranud, et 10% liiklusest peaks minema v2-le:

Näeme, et frontend v1 ja v2 suunavad mõlemad liiklust suhtega 1/10 backend v1 ja v2-le.

Aga mis siis, kui peame suunama liikluse frontend-v2-lt ainult backend-v2-le, sest see ei ole ühilduv v1-ga? Selleks määrame 1/10 suhte frontendile, mis kontrollib, milline liiklus jõuab backend-v2-le, kasutades vastavust 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

Saame tulemuse, mida vajame:

Erinevused käsitsi Canary lähenemisest

Uues esimeses osas me tegime käsitsi Canary juurutamist, kasutades kaht k8s juurutust. Seal me juhtisime päringute suhet, muutes replikate arvu. See lähenemine toimib, kuid on tõsiseid puudusi.

Istio võimaldab määrata päringute suhet sõltumata replikate arvust. See tähendab näiteks, et me saame kasutada HPAd (Horizontal Pod Autoscalers — horisontaalne podide skaleerimine) ja seda ei pea seadistama vastavalt praegusele Canary juurutuse olekule.

Kokkuvõte

Istio töötab suurepäraselt ning selle koos Kiali kasutamine annab väga võimsa kombinatsiooni. Järgmine asi, mis mind huvitab, on Spinnakeri ja Istio kombinatsioon automatiseerimise ja Canary-analüütika jaoks.

Allikas: habr.com