Canary Deployment i Kubernetes #3: Istio

Bruke Istio+Kiali til å starte og visualisere en Kanariøy-distribusjon

Artikler i denne serien

1. Canary Deployment i Kubernetes #1: Gitlab CI
2. Canary-distribusjon i Kubernetes #2: Argo-utrullinger
3. (Denne artikkelen)
4. Canary Deployment med Jenkins-X Istio Flagger

Kanariøyeutplassering

Vi håper du leser første del, hvor vi kort forklarte hva Canary-distribusjoner er og viste hvordan de implementeres ved å bruke standard Kubernetes-ressurser.

Samme

Og vi antar at ved å lese denne artikkelen vet du allerede hva Istio er. Hvis ikke, kan du lese om det her.

Søknad om prøver

Hver pod inneholder to beholdere: vår applikasjon og istio-proxy.

Vi vil bruke en enkel testapplikasjon med frontend-nginx og backend python pods. Nginx-poden vil ganske enkelt omdirigere hver forespørsel til backend-poden og fungere som en proxy. Detaljer finner du i følgende yamls:

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

Kjører testapplikasjonen selv

Hvis du vil følge mitt eksempel og bruke denne testapplikasjonen selv, se prosjekt readme.

Innledende distribusjon

Når vi lanserer den første distribusjonen, ser vi at podene til applikasjonen vår bare har 2 containere, det vil si at Istio-sidevognen akkurat blir implementert:

Og vi ser også Istio Gateway Loadbalancer i navneområdet istio-system:

Trafikkgenerering

Vi vil bruke følgende IP for å generere trafikk som vil bli mottatt av frontend-podene og videresendt til backend-podene:

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

Vi vil også legge til frontend.istio-test til vertsfilen vår.

Se Mesh via Kiali

Vi installerte testapplikasjonen og Istio sammen med Tracing, Grafana, Prometheus og Kiali (se nedenfor for detaljer). prosjekt readme). Derfor kan vi bruke Kiali via:

istioctl dashboard kiali # admin:admin

Kiali visualiserer gjeldende trafikk gjennom Mesh

Som vi kan se går 100 % av trafikken til frontend-tjenesten, deretter til frontend-podene med label v1, siden vi bruker en enkel nginx-proxy som omdirigerer forespørsler til backend-tjenesten, som igjen omdirigerer dem til backend-podene med etikett v1.

Kiali fungerer utmerket med Istio og gir en mesh-gjengivelsesløsning. Bare flott.

Kanariøyeutplassering

Backend vår har allerede to k8s-distribusjoner, en for v1 og en for v2. Nå trenger vi bare å fortelle Istio å videresende en viss prosentandel av forespørslene til v2.

Trinn 1: 10 %

Og alt vi trenger å gjøre er å justere vekten på VirtualService 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

Vi ser at 10 % av forespørslene blir omdirigert til v2.

Trinn 2: 50 %

Og nå er det nok bare å øke den til 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

Trinn 3: 100 %

Nå kan Canary-distribusjon anses som fullført, og all trafikk blir omdirigert til v2:

Tester Canary manuelt

La oss si at vi nå sender 2 % av alle forespørsler til v10-backend. Hva om vi ønsker å teste v2 manuelt for å sikre at alt fungerer som vi forventer?

Vi kan legge til en spesiell samsvarsregel basert på HTTP-overskrifter:

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

Ved å bruke curl kan vi tvinge en v2-forespørsel ved å sende overskriften:

Forespørsler uten overskrift vil fortsatt bli drevet av forholdet 1/10:

Canary for to avhengige versjoner

Nå skal vi vurdere alternativet der vi har versjon v2 for både frontend og backend. For begge spesifiserte vi at 10 % av trafikken skulle gå til v2:

Vi ser at frontend v1 og v2 begge forover trafikk i et forhold på 1/10 til backend v1 og v2.

Hva om vi trengte å videresende trafikk fra frontend-v2 bare til backend-v2 fordi den ikke er kompatibel med v1? For å gjøre dette vil vi sette et 1/10-forhold for frontend, som kontrollerer hvilken trafikk som kommer til backend-v2 ved å bruke forhandling 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

Som et resultat får vi det vi trenger:

Forskjeller fra den manuelle kanariske tilnærmingen

В første del Vi utførte Canary-distribusjon manuelt, også ved å bruke to k8s-distribusjoner. Der kontrollerte vi forholdet mellom forespørsler ved å endre antall replikaer. Denne tilnærmingen fungerer, men har alvorlige ulemper.

Istio gjør det mulig å bestemme forholdet mellom forespørsler uavhengig av antall replikaer. Dette betyr for eksempel at vi kan bruke HPA-er (Horizontal Pod Autoscalers) og ikke trenger å konfigureres i henhold til gjeldende tilstand for Canary-distribusjonen.

Total

Istio fungerer utmerket og å bruke den sammen med Kiali gir en veldig kraftig kombinasjon. Neste på min liste over interesser er å kombinere Spinnaker med Istio for automatisering og Canary analytics.

Kilde: www.habr.com