🥇Canary Deployment Kuberneteses #3: Istio

Istio+Kiali kasutamine kanarühma juurutamiseks ja visualiseerimiseks

Selle tsükli artiklid

Canary juurutamine Kuberneteses #1: Gitlab CI
Canary Deployment Kuberneteses #2: Argo Rollouts
(see artikkel)
Kanarühma juurutamine kasutades Jenkins-X Istio Flaggerit

Canary juurutamine

Loodame, et olete lugenud esimest osa, kus me lühidalt selgitasime, mis on kanarühmad ja näitasime, kuidas neid rakendada Kubernetes'i standardlike ressursside abil.

Istio

Oleme eeldanud, et lugedes seda artiklit, te juba tead, mis on Istio. Kui ei, siis saate lugeda selle kohta siit.

Testrakendus

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

Kasutame lihtsat testrakendust podidega frontend-nginx ja backend pythonil. Nginx pod suunab iga päringu backend podi ja töötab proksina. Üksikasju saab vaadata järgmistest yamlist:

Testrakenduse iseseisev käivitamine

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

Algne juurutamine

Esimese juurutamise käivitamisel näeme, et meie rakenduse podidel on vaid 2 konteinerit, see tähendab, et Istio sidecar on alles rakendamisel:

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

Liiklus genereerimine

Kasutame järgmise IP-d, et genereerida liiklust, mille vastavad frontend podid ja suunatakse backend podidele:

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 testrakenduse ja Istio koos Tracing, Grafana, Prometheus ja Kiali-ga (rohkem infot vaata projekti readme). Seega saame Kiali kasutada järgmiselt:

istioctl dashboard kiali # admin:admin

Kiali visualiseerib praegust liiklust Mesh-is

Kuidas me näeme, 100% liiklus jõuab frontend teenusele, seejärel frontend podile, millel on label v1, kuna kasutame lihtsat nginx-proxyt, mis suunab päringud backend teenusele, mis omakorda suunab need backend podidele, millel on label v1.

Kiali töötab suurepäraselt koostöös Istio-ga ja pakub kohandatud lahendust Mesh-i visualiseerimiseks. Lihtsalt suurepärane.

Canary juurutamine

Meie backendil on juba kaks k8s deploymendi, ü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 me peame tegema, on kohandada VirtualService 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%

Nüüd on lihtsalt piisav selle suurendamine 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 juurutamine lugeda lõpetatuks 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 soovime käsitsi testida v2, et veenduda, et kõik töötab ootuspäraselt?

Saame lisada eraldi vastavuse reegli, 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 curl'i abil sundida päringut v2, saates pealkirja:

Ilma pealkirjata päringud haldatakse endiselt suhega 1/10:

Canary kahe sõltuva versiooniga

Nüüd vaatleme olukorda, kus meil on nii frontendil kui backendil versioon v2. Mõlemal oleme määranud, et 10% liiklusest suundub v2:

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

Ent kui me tahaksime suunata frontend-v2 liiklust ainult backend-v2-le, kuna see ei ole ühilduv v1-ga? Selleks määrame frontendile 1/10 suhte, mis kontrollib, milline liiklus satub 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, nagu soovitud:

Erinevused käsitsi Canary lähenemisest

V esimeses osas Käsitsi viisime läbi Canary juurutamise, kasutades kaht k8s juurutust. Seal juhtisime päringute suhet, muutes koopiate arvu. See lähenemine töötab, kuid tal on tõsised puudused.

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

Kokkuvõte

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

Allikas: habr.com