Kanarie-ontplooiing in Kubernetes #3: Istio

Gebruik Istio+Kiali om 'n Kanariese ontplooiing te begin en te visualiseer

Artikels in hierdie reeks

1. Kanarie-ontplooiing in Kubernetes #1: Gitlab CI
2. Kanarie-ontplooiing in Kubernetes #2: Argo-ontplooiing
3. (Hierdie artikel)
4. Kanarie-ontplooiing met behulp van Jenkins-X Istio Flagger

Kanarie-ontplooiing

Ons hoop jy lees eerste deel, waar ons kortliks verduidelik het wat Kanariese ontplooiings is en gewys het hoe om dit te implementeer met behulp van standaard Kubernetes-hulpbronne.

Istio

En ons neem aan dat deur hierdie artikel te lees, jy reeds weet wat Istio is. Indien nie, dan kan jy daaroor lees hier.

Aansoek om toetse

Elke peul bevat twee houers: ons toepassing en istio-proxy.

Ons sal 'n eenvoudige toetstoepassing gebruik met frontend-nginx en backend python peule. Die nginx-pod sal eenvoudig elke versoek na die backend-pod herlei en as 'n instaanbediener werk. Besonderhede kan gevind word in die volgende yamls:

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

Begin die toetstoepassing self

As jy my voorbeeld wil volg en self hierdie toetstoepassing wil gebruik, sien projek lees my.

Aanvanklike ontplooiing

Wanneer ons die eerste ontplooiing bekendstel, sien ons dat die peule van ons toepassing slegs 2 houers het, dit wil sê, Istio-syspan word pas geïmplementeer:

En ons sien ook Istio Gateway Loadbalancer in die naamruimte istio-system:

Verkeer generasie

Ons sal die volgende IP gebruik om verkeer te genereer wat deur die frontend-peule ontvang en na die backend-peule aangestuur sal word:

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

Ons sal ook byvoeg frontend.istio-test na ons gashere-lêer.

Bekyk Mesh via Kiali

Ons het die toetstoepassing en Istio saam met Tracing, Grafana, Prometheus en Kiali geïnstalleer (sien hieronder vir besonderhede). projek lees my). Daarom kan ons Kiali gebruik via:

istioctl dashboard kiali # admin:admin

Kiali visualiseer huidige verkeer deur Mesh

Soos ons kan sien, gaan 100% van die verkeer na die frontend-diens, dan na die frontend-peule met etiket v1, aangesien ons 'n eenvoudige nginx-instaanbediener gebruik wat versoeke na die backend-diens herlei, wat hulle weer na die backend-peule herlei. met etiket v1.

Kiali werk uitstekend saam met Istio en bied 'n doos Mesh-weergawe-oplossing. Net wonderlik.

Kanarie-ontplooiing

Ons agterkant het reeds twee k8s-ontplooiings, een vir v1 en een vir v2. Nou moet ons net vir Istio sê om 'n sekere persentasie versoeke aan te stuur na v2.

Stap 1: 10%

En al wat ons hoef te doen is om die gewig van die VirtualService aan te pas 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

Ons sien dat 10% van versoeke na v2 herlei word.

Stap 2: 50%

En nou is dit net genoeg om dit tot 50% te verhoog:

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

Stap 3: 100%

Nou kan Canary-ontplooiing as voltooi beskou word en alle verkeer word herlei na v2:

Toets Kanarie met die hand

Kom ons sê ons stuur nou 2% van alle versoeke na die v10 backend. Wat as ons v2 handmatig wil toets om seker te maak alles werk soos ons verwag?

Ons kan 'n spesiale pasreël byvoeg gebaseer op HTTP-opskrifte:

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

Met behulp van krul kan ons 'n v2-versoek afdwing deur die kopskrif te stuur:

Versoeke sonder 'n kopskrif sal steeds deur die 1/10-verhouding gedryf word:

Kanarie vir twee afhanklike weergawes

Nou sal ons die opsie oorweeg waar ons weergawe v2 vir beide frontend en backend het. Vir albei het ons gespesifiseer dat 10% van die verkeer na v2 moet gaan:

Ons sien dat frontend v1 en v2 beide vorentoe verkeer teen 'n verhouding van 1/10 tot backend v1 en v2.

Wat as ons verkeer van frontend-v2 net na backend-v2 moes aanstuur omdat dit nie met v1 versoenbaar is nie? Om dit te doen, sal ons 'n 1/10-verhouding vir die frontend stel, wat beheer watter verkeer na die backend-v2 kom deur middel van onderhandeling 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

As gevolg hiervan kry ons wat ons nodig het:

Verskille van die manuele Kanariese benadering

В die eerste deel Ons het Canary-ontplooiing met die hand uitgevoer, ook met behulp van twee k8s-ontplooiings. Daar het ons die verhouding van versoeke beheer deur die aantal replikas te verander. Hierdie benadering werk, maar het ernstige nadele.

Istio maak dit moontlik om die verhouding van versoeke te bepaal ongeag die aantal replikas. Dit beteken byvoorbeeld dat ons HPA's (Horizontal Pod Autoscalers) kan gebruik en hoef nie volgens die huidige toestand van die Kanariese ontplooiing gekonfigureer te word nie.

Totale

Istio werk uitstekend en om dit saam met Kiali te gebruik, sorg vir 'n baie kragtige kombinasie. Volgende op my lys van belangstellings is die kombinasie van Spinnaker met Istio vir outomatisering en Kanariese analise.

Bron: will.com