Canary-implementatie in Kubernetes #3: Istio

Istio+Kiali gebruiken om een ​​Canary-implementatie te starten en te visualiseren

Artikelen in deze serie

1. Canary-implementatie in Kubernetes #1: Gitlab CI
2. Canary-implementatie in Kubernetes #2: Argo-implementaties
3. (Dit artikel)
4. Canary-implementatie met Jenkins-X Istio Flagger

Canarische inzet

Wij hopen dat je leest eerste deel, waar we kort hebben uitgelegd wat Canary-implementaties zijn en hebben laten zien hoe we deze kunnen implementeren met behulp van standaard Kubernetes-bronnen.

Istio

En we gaan ervan uit dat je door het lezen van dit artikel al weet wat Istio is. Zo niet, dan kunt u erover lezen hier.

Aanvraag voor testen

Elke pod bevat twee containers: onze applicatie en istio-proxy.

We zullen een eenvoudige testapplicatie gebruiken met frontend-nginx en backend python pods. De nginx-pod zal elk verzoek eenvoudigweg doorsturen naar de backend-pod en als proxy werken. Details zijn te vinden in de volgende yamls:

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

Zelf de testapplicatie uitvoeren

Als je mijn voorbeeld wilt volgen en deze testapplicatie zelf wilt gebruiken, zie dan project leesmij.

Initiële implementatie

Wanneer we de eerste implementatie lanceren, zien we dat de pods van onze applicatie slechts 2 containers hebben, dat wil zeggen dat de Istio-zijspan net wordt geïmplementeerd:

En ook Istio Gateway Loadbalancer zien we terug in de naamruimte istio-system:

Verkeer genereren

We zullen het volgende IP-adres gebruiken om verkeer te genereren dat door de frontend-pods wordt ontvangen en doorgestuurd naar de backend-pods:

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

Wij zullen ook toevoegen frontend.istio-test naar ons hosts-bestand.

Bekijk Mesh via Kiali

We hebben de testapplicatie en Istio geïnstalleerd samen met Tracing, Grafana, Prometheus en Kiali (zie hieronder voor details). project leesmij). Daarom kunnen wij Kiali gebruiken via:

istioctl dashboard kiali # admin:admin

Kiali visualiseert het huidige verkeer via Mesh

Zoals we kunnen zien, gaat 100% van het verkeer naar de frontend-service en vervolgens naar de frontend-pods met label v1, omdat we een eenvoudige nginx-proxy gebruiken die verzoeken omleidt naar de backend-service, die ze op zijn beurt doorstuurt naar de backend-pods met etiket v1.

Kiali werkt prima met Istio en biedt een Mesh-renderingoplossing in boxvorm. Gewoon geweldig.

Canarische inzet

Onze backend heeft al twee k8s-implementaties, één voor v1 en één voor v2. Nu hoeven we Istio alleen maar te vertellen dat hij een bepaald percentage van de verzoeken moet doorsturen naar v2.

Stap 1: 10%

En het enige dat we hoeven te doen is het gewicht van de VirtualService aanpassen 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

We zien dat 10% van de verzoeken wordt omgeleid naar v2.

Stap 2: 50%

En nu is het voldoende om het naar 50% te verhogen:

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%

Nu kan de Canary-implementatie als voltooid worden beschouwd en wordt al het verkeer omgeleid naar v2:

Kanarie handmatig testen

Laten we zeggen dat we nu 2% van alle verzoeken naar de v10-backend sturen. Wat als we v2 handmatig willen testen om er zeker van te zijn dat alles werkt zoals we verwachten?

We kunnen een speciale matchingregel toevoegen op basis van HTTP-headers:

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

Nu we curl gebruiken, kunnen we een v2-verzoek forceren door de header te verzenden:

Verzoeken zonder header worden nog steeds gebaseerd op de verhouding 1/10:

Canarische voor twee afhankelijke versies

Nu zullen we de optie overwegen waarbij we versie v2 hebben voor zowel frontend als backend. Voor beide hebben we gespecificeerd dat 10% van het verkeer naar v2 moet gaan:

We zien dat frontend v1 en v2 beide verkeer doorsturen in een verhouding van 1/10 naar backend v1 en v2.

Wat als we verkeer alleen van frontend-v2 naar backend-v2 moesten doorsturen omdat het niet compatibel is met v1? Om dit te doen, zullen we een verhouding van 1/10 instellen voor de frontend, die bepaalt welk verkeer naar de backend-v2 gaat met behulp 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

Als resultaat krijgen we wat we nodig hebben:

Verschillen met de handmatige Canarische aanpak

В het eerste deel We hebben de Canary-implementatie handmatig uitgevoerd, ook met behulp van twee k8s-implementaties. Daar controleerden we de verhouding van verzoeken door het aantal replica’s te wijzigen. Deze aanpak werkt, maar heeft ernstige nadelen.

Istio maakt het mogelijk om de verhouding van aanvragen te bepalen, ongeacht het aantal replica’s. Dit betekent bijvoorbeeld dat we HPA's (Horizontal Pod Autoscalers) kunnen gebruiken en niet hoeven te worden geconfigureerd volgens de huidige status van de Canary-implementatie.

Totaal

Istio werkt prima en het gebruik ervan samen met Kiali zorgt voor een zeer krachtige combinatie. De volgende op mijn interesselijst is het combineren van Spinnaker met Istio voor automatisering en Canary-analyses.

Bron: www.habr.com