🥇Canary Deployment Kubernetes #3: Istio

Istio+Kiali izmantošana kanāru izvietošanas palaišanai un vizualizēšanai

Šī cikla raksti

Canary Deployment Kubernetes #1: Gitlab CI
Kanāru izvietošana Kubernetes #2: Argo Rollouts
(šis raksts)
Kanāru izvietošana, izmantojot Jenkins-X Istio Flagger

Kanāru izvietošana

Ceram, ka jūs lasījāt pirmo daļu, kurā mēs īsi izskaidrojām, kas ir kanāru izvietojumi un parādījām, kā to īstenot ar standarta Kubernetes resursiem.

Istio

Un mēs pieņemam, ka, lasot šo rakstu, jūs jau zināt, kas ir Istio. Ja nē, varat par to izlasīt šeit.

Testēšanas lietotne

Katrs pods satur divus konteinerus: mūsu lietotne un istio-proxy.

Mēs izmantosim vienkāršu testēšanas lietotni ar pods frontend-nginx un backend uz python. Pods ar nginx vienkārši pāradresēs katru pieprasījumu uz podu ar backend un darbosies kā proxy. Sīkāku informāciju varat skatīt nākamajos yaml failos:

Testēšanas lietotnes palaišana patstāvīgi

Ja vēlaties sekot manam piemēram un izmantot šo testēšanas lietotni patstāvīgi, skatiet projekta lasāmviela.

Sākotnējā izvietošana

Palaižot pirmo izvietošanu, mēs redzam, ka mūsu lietotnes podiem ir tikai 2 konteineri, tātad Istio sidecar vēl tikai tiek iekļauts:

Un mēs arī redzam Istio Gateway Loadbalancer telpā istio-system:

Satiksmes izveide

Mēs izmantosim nākamo IP, lai ģenerētu satiksmi, kuru frontend podi pieņems un novirzīs uz backend podiem:

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

Mēs arī pievienosim frontend.istio-test mūsu hosts failam.

Mreža skatīšana caur Kiali

Mēs esam uzstādījuši testēšanas lietotni un Istio kopā ar Tracing, Grafana, Prometheus un Kiali (sīkāk skat. projekta lasāmviela). Tāpēc mēs varam izmantot Kiali caur:

istioctl dashboard kiali # admin:admin

Kiali vizualizē pašreizējo satiksmi caur Mrežu

Kā redzam, 100% satiksmes nonāk frontend pakalpojumā, pēc tam uz frontend podu ar etiketēm v1, jo mēs izmantojam vienkāršu nginx proxy, kas novirza pieprasījumus uz backend pakalpojumu, kas savukārt novirza tos uz backend podiem ar etiketēm v1.

Kiali lieliski darbojas kopā ar Istio un nodrošina ārkārtīgi labu risinājumu Mrežas vizualizēšanai. Vienkārši lieliski.

Kanāru izvietošana

Mūsu backend jau satur divus k8s izvietojumus, vienu v1 un vienu v2. Tagad mums vienkārši jāsaka Istio novirzīt noteiktu procentu pieprasījumu uz v2.

Solījums 1: 10%

Un viss, kas mums jādara, ir pielāgot VirtualService svarus. 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

Redzam, ka 10% pieprasījumu tiek novirzīti uz v2.

2. solis: 50%

Un tagad pietiekami vienkārši palielināt to līdz 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

3. solis: 100%

Tagad Canary izvietojums var tikt uzskatīts par pabeigtu un viss satiksme tiek novirzīta uz v2:

Canary testēšana manuāli

Pieņemsim, ka mēs tagad uz aizmuguri v2 nosūtām 10% no visiem pieprasījumiem. Ko darīt, ja vēlamies manuāli pārbaudīt v2, lai pārliecinātos, ka viss darbojas kā gaidīts?

Mēs varam pievienot īpašu atbilstošu noteikumu, kas balstīts uz HTTP virsrakstiem:

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

Tagad, izmantojot curl, mēs varam piespiest pieprasīt v2, nosūtot virsrakstu:

Pieprasījumi bez virsraksta joprojām tiks pārvaldīti ar attiecību 1/10:

Canary divām atkarīgām versijām

Tagad mēs aplūkosim gadījumu, kad mums ir versija v2 gan priekšējai, gan aizmugures daļai. Abiem mēs norādījām, ka 10% satiksmes jāiet v2:

Redzam, ka priekšējā versija v1 un v2 abi pārsūta satiksmi attiecībā 1/10 uz aizmugurējo v1 un v2.

Un ko darīt, ja mums vajadzētu pārsūtīt satiksmi no frontend-v2 tikai uz backend-v2, jo tas nav savietojams ar v1? Tādēļ mēs iestatīsim attiecību 1/10 priekšējai daļai, kas kontrolē, kāda satiksme nonāk backend-v2, izmantojot saskaņošanu pēc 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

Rezultātā mēs iegūstam to, kas nepieciešams:

Atšķirības no manuālā Canary pieejas

No pirmajā daļā mēs manuāli veicām Canary izvietojumu, izmantojot divas k8s izvietojumus. Tur mēs pārvaldījām pieprasījumu attiecību, mainot repliku skaitu. Šī pieeja darbojas, taču tai ir nopietnas trūkumus.

Istio ļauj noteikt pieprasījumu attiecību neatkarīgi no repliku skaita. Tas nozīmē, piemēram, ka mēs varam izmantot HPA (Horizontal Pod Autoscalers — horizontālo podu automātisko mērogošanu) un to nav nepieciešams konfigurēt atbilstoši pašreizējai Canary izvietojuma stāvoklim.

Rezultāts

Istio darbojas lieliski, un, izmantojot to kopā ar Kiali, iegūstam ļoti jaudīgu kombināciju. Nākamais manā interešu sarakstā ir kombinācija Spinnaker ar Istio automatizācijas un Canary analīzei.

Avots: habr.com