Kanariar Inplementazioa Kubernetes #3: Istio

Istio+Kiali erabiltzea Kanariarren hedapen bat abiarazteko eta ikusteko

Serie honetako artikuluak

1. Kanariar inplementazioa Kubernetes #1: Gitlab CI
2. Kanariar inplementazioa Kubernetes #2: Argo inplementazioak
3. (Artikulu hau)
4. Kanariar Inplementazioa Jenkins-X Istio Flagger erabiliz

Kanariarren hedapena

Irakurtzea espero dugu lehen zatia, non laburki azaldu genuen Canary inplementazioak zer diren eta Kubernetes baliabide estandarrak erabiliz nola inplementatu erakutsi genuen.

Istio

Eta suposatzen dugu artikulu hau irakurrita Istio zer den dagoeneko badakizula. Hala ez bada, horri buruz irakur dezakezu Hemen.

Probak egiteko eskaera

Pod bakoitzak bi edukiontzi ditu: gure aplikazioa eta istio-proxy.

Test aplikazio sinple bat erabiliko dugu frontend-nginx eta backend python podekin. Nginx pod-ak eskaera bakoitza backend podra birbideratuko du eta proxy gisa funtzionatuko du. Xehetasunak honako yaml hauetan aurki daitezke:

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

Proba aplikazioa zuk zeuk exekutatzen

Nire adibidea jarraitu eta proba aplikazio hau zuk zeuk erabili nahi baduzu, ikus proiektua irakur nazazu.

Hasierako hedapena

Lehenengo Inplementazioa abiarazten dugunean, gure aplikazioaren podek 2 edukiontzi baino ez dituztela ikusten dugu, hau da, Istio sidecar inplementatzen ari da:

Eta Istio Gateway Loadbalancer ere ikusten dugu izen-eremuan istio-system:

Trafikoa sortzea

Honako IP hau erabiliko dugu frontend-eko podek jasoko duten trafikoa sortzeko eta backend-eko podetara birbidaltzeko:

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

Guk ere gehituko dugu frontend.istio-test gure ostalari fitxategira.

Ikusi Mesh Kiali bidez

Proba aplikazioa eta Istio instalatu ditugu Tracing, Grafana, Prometheus eta Kiali-rekin batera (ikus behean xehetasunetarako). proiektua irakur nazazu). Beraz, Kiali erabil dezakegu:

istioctl dashboard kiali # admin:admin

Kialik uneko trafikoa Mesh bidez bistaratzen du

Ikus dezakegunez, trafikoaren % 100 frontend zerbitzura doa, gero v1 etiketa duten frontend podetara, eskaerak backend zerbitzura birbideratzen dituen nginx proxy soil bat erabiltzen ari garelako, eta horrek backend podetara birbideratzen ditu. v1 etiketarekin.

Kiali-k oso ondo funtzionatzen du Istio-rekin eta kaxadun Mesh errendatzeko irtenbide bat eskaintzen du. Handia besterik ez.

Kanariarren hedapena

Gure backend-ak dagoeneko bi inplementazio ditu k8s, bat v1erako eta beste bat v2rako. Orain, Istio-ri esan besterik ez diogu eskaeren ehuneko jakin bat v2ra bidaltzeko.

1. urratsa: % 10

Eta egin behar dugun guztia Zerbitzu Birtualaren pisua doitzea da 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

Eskaeren % 10 v2ra birbideratzen dutela ikusten dugu.

2. urratsa: % 50

Eta orain nahikoa da %50era igotzea:

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. urratsa: % 100

Orain Canary inplementazioa amaitutzat jo daiteke eta trafiko guztia v2ra birbideratzen da:

Canary eskuz probatzen

Demagun orain eskaera guztien % 2 v10 backend-era bidaltzen dugula. Zer gertatzen da eskuz v2 probatu nahi badugu, dena espero dugun moduan funtzionatzen duela ziurtatzeko?

HTTP goiburuetan oinarritutako bat etortzeko arau berezi bat gehi dezakegu:

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

Orain curl erabiliz v2 eskaera bat behartu dezakegu goiburua bidaliz:

Goibururik gabeko eskaerek 1/10eko ratioaren arabera jarraituko dute:

Canary menpeko bi bertsioetarako

Orain v2 bertsioa dugun aukera kontuan hartuko dugu frontend-erako eta backenderako. Bietarako, trafikoaren %10 v2ra joan behar dela zehaztu dugu:

Ikusten dugu frontend v1 eta v2 biak bidaltzen duten trafikoa 1/10eko proportzioan backend v1 eta v2.

Zer gertatzen da trafikoa frontend-v2-tik backend-v2-ra soilik birbidali behar bagenu, v1-rekin bateragarria ez delako? Horretarako, 1/10eko ratioa ezarriko dugu frontend-erako, negoziazioa erabiliz backend-v2-ra zer trafiko iristen den kontrolatzen duena. 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

Ondorioz, behar duguna lortzen dugu:

Eskuz Kanariarren ikuspegiarekiko ezberdintasunak

В Lehenengo zatia Canary inplementazioa eskuz egin dugu, bi k8s inplementazio ere erabiliz. Bertan eskaeren ratioa kontrolatu genuen erreplika kopurua aldatuz. Ikuspegi honek funtzionatzen du, baina eragozpen handiak ditu.

Istio-k eskaeren ratioa zehaztea ahalbidetzen du, erreplika kopurua edozein dela ere. Horrek esan nahi du, adibidez, HPAk (Horizontal Pod Autoscalers) erabil ditzakegula eta ez dugula Canary inplementazioaren egungo egoeraren arabera konfiguratu behar.

Guztira

Istio bikain funtzionatzen du eta Kialirekin batera erabiltzeak konbinazio oso indartsua da. Nire interesen zerrendan hurrengo Spinnaker Istio-rekin konbinatzea da automatizaziorako eta Canary analisirako.

Iturria: www.habr.com