Kanaari juurutamine Kubernetesis nr 3: Istio

Istio+Kiali kasutamine Kanaari juurutamise käivitamiseks ja visualiseerimiseks

Selle sarja artiklid

1. Kanaari juurutamine Kubernetesis nr 1: Gitlab CI
2. Kanaari juurutamine Kuberneteses nr 2: Argo levitamine
3. (See artikkel)
4. Kanaari juurutamine Jenkins-X Istio Flaggeri abil

Kanaari juurutamine

Loodame, et loed esimene osa, kus selgitasime lühidalt, mis on Kanaari juurutused, ja näitasime, kuidas neid standardsete Kubernetese ressursside abil rakendada.

Istio

Ja eeldame, et seda artiklit lugedes teate juba, mis on Istio. Kui ei, siis saate selle kohta lugeda siin.

Taotlus testide tegemiseks

Igas kaustas on kaks konteinerit: meie rakendus ja istio-puhverserver.

Kasutame lihtsat testrakendust koos frontend-nginxi ja taustaprogrammi python podidega. Nginxi pod suunab lihtsalt iga päringu taustamoodulisse ja töötab puhverserverina. Üksikasjad leiate järgmistest yamlidest:

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

Testrakenduse ise käivitamine

Kui soovite minu eeskuju järgida ja seda testrakendust ise kasutada, vaadake projekt readme.

Esialgne juurutamine

Kui käivitame esimese juurutuse, näeme, et meie rakenduse poodidel on ainult 2 konteinerit, see tähendab, et Istio külgkorv on alles juurutamisel:

Ja nimeruumis näeme ka Istio Gateway Loadbalancerit istio-system:

Liikluse genereerimine

Kasutame järgmist IP-aadressi, et genereerida liiklust, mis võetakse vastu eesmise kabiinide poolt ja edastatakse taustamoodulitele:

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

Lisame ka frontend.istio-test meie hostide faili.

Vaata võrgusilma Kiali kaudu

Installisime testrakenduse ja Istio koos Tracingu, Grafana, Prometheuse ja Kialiga (vt üksikasju allpool). projekt readme). Seetõttu saame Kiali kasutada järgmiselt:

istioctl dashboard kiali # admin:admin

Kiali visualiseerib praegust liiklust läbi Meshi

Nagu näeme, läheb 100% liiklusest kasutajaliidese teenusesse, seejärel sildiga v1 frontend-poodidesse, kuna me kasutame lihtsat nginxi puhverserverit, mis suunab päringud ümber taustateenusele, mis omakorda suunab need ümber taustamoodulitesse. sildiga v1.

Kiali töötab suurepäraselt koos Istioga ja pakub karbis võrgusilma renderduslahendust. Lihtsalt suurepärane.

Kanaari juurutamine

Meie taustaprogrammil on juba kaks k8s juurutust, üks v1 ja teine ​​v2 jaoks. Nüüd peame lihtsalt ütlema Istiole, et ta edastaks teatud protsendi taotlustest versioonile 2.

1. samm: 10%

Ja kõik, mida me tegema peame, on kohandada 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% taotlustest suunatakse ümber versioonile 2.

2. samm: 50%

Ja nüüd piisab selle suurendamisest 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

3. samm: 100%

Nüüd võib Canary juurutamist lugeda lõpetatuks ja kogu liiklus suunatakse ümber versioonile 2:

Canary käsitsi testimine

Oletame, et saadame nüüd 2% kõigist päringutest v10 taustaprogrammi. Mis siis, kui tahame käsitsi testida versiooni 2, veendumaks, et kõik töötab ootuspäraselt?

Saame lisada spetsiaalse sobitamisreegli, mis põhineb HTTP-päistel:

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 curli kasutades sundida v2 päringut, saates päise:

Päiseta taotlusi juhib endiselt suhe 1/10:

Canary kahe sõltuva versiooni jaoks

Nüüd kaalume võimalust, kus meil on versioon v2 nii esi- kui ka taustaprogrammi jaoks. Mõlema puhul täpsustasime, et 10% liiklusest peaks minema versioonile 2:

Näeme, et kasutajaliidese v1 ja v2 suunavad liiklust edasi vahekorras 1/10 taustaprogrammi v1 ja v2 suhtes.

Mis siis, kui peaksime liikluse edastama frontend-v2-st ainult backend-v2-sse, kuna see ei ühildu v1-ga? Selleks seame kasutajaliidese jaoks suhte 1/10, mis kontrollib läbirääkimiste abil, milline liiklus jõuab taustaprogrammi v2. 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

Selle tulemusena saame selle, mida vajame:

Erinevused manuaalsest Kanaari lähenemisest

В Esimene osa Teostasime Canary juurutamise käsitsi, kasutades ka kahte k8s juurutamist. Seal kontrollisime taotluste suhet, muutes koopiate arvu. See lähenemisviis töötab, kuid sellel on tõsiseid puudusi.

Istio võimaldab määrata päringute suhet sõltumata koopiate arvust. See tähendab näiteks, et saame kasutada HPA-sid (Horizontal Pod Autoscalers) ja neid ei pea konfigureerima vastavalt Canary juurutuse hetkeseisule.

Summaarne

Istio töötab suurepäraselt ja seda koos Kialiga kasutades saab väga võimsa kombinatsiooni. Järgmine minu huvide loendis on Spinnakeri kombineerimine Istioga automatiseerimiseks ja Canary analüütikaks.

Allikas: www.habr.com