Canary Deployment in Kubernetes #3: Istio

Het gebruik van Istio+Kiali voor het draaien en visualiseren van Canary-deployments

Artikelen in deze cyclus

1. Canary Deployment in Kubernetes #1: Gitlab CI
2. Canary Deployment in Kubernetes #2: Argo Rollouts
3. (dit artikel)
4. Canary Deployment met Jenkins-X Istio Flagger

Canary Deployment

We hopen dat je de eerste deel, waar we kort uitlegden wat Canary deployments zijn en hoe je deze kunt implementeren met standaard Kubernetes-resources.

Istio

En we gaan ervan uit dat je, terwijl je dit artikel leest, al weet wat Istio is. Zo niet, dan kun je erover lezen hier.

Applicatie voor testen

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

We gaan een eenvoudige testapplicatie gebruiken met de pods frontend-nginx en backend in Python. De pod met nginx zal eenvoudigweg elke aanvraag omleiden naar de pod met de backend en fungeren als proxy. Details zijn verder te bekijken in de volgende yamls:

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

Het zelf draaien van de testapplicatie

Als je mijn voorbeeld wilt volgen en deze testapplicatie zelf wilt gebruiken, zie readme van het project.

Initiële Deployment

Bij het opstarten van de eerste Deployment zien we dat de pods van onze applicatie slechts 2 containers hebben, dus Istio sidecar wordt voorlopig alleen nog maar geïmplementeerd:

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

Verkeersgeneratie

We gaan het volgende IP gebruiken om verkeer te genereren dat door de frontend-pods wordt ontvangen en doorverwezen 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

We voegen ook frontend.istio-test toe aan ons hosts-bestand.

Bekijk Mesh via Kiali

We hebben de testapplicatie en Istio geïnstalleerd, samen met Tracing, Grafana, Prometheus en Kiali (meer informatie zie readme van het project). Daarom kunnen we Kiali gebruiken via:

istioctl dashboard kiali # admin:admin

Kiali visualiseert het huidige verkeer door Mesh

Zoals we zien, komt 100% van het verkeer binnen op de frontend-service, daarna op de frontend-pod met label v1, aangezien we een eenvoudige nginx-proxy gebruiken die aanvragen doorverwijst naar de backend-service, die vervolgens deze doorverwijst naar de backend-pods met label v1.

Kiali werkt uitstekend samen met Istio en biedt een out-of-the-box oplossing voor het visualiseren van Mesh. Geweldig.

Canary Deployment

Onze backend heeft al twee k8s-deployments, één voor v1 en één voor v2. Nu moeten we gewoon Istio vertellen om een bepaald percentage van de aanvragen naar v2 door te verwijzen.

Stap 1: 10%

En alles wat we hoeven te doen, is het gewicht van VirtualService te regelen in 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 eenvoudig 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-uitrol als voltooid worden beschouwd en wordt al het verkeer omgeleid naar v2:

Handmatig testen van Canary

Stel dat we momenteel 10% van alle verzoeken naar backend v2 sturen. Wat als we v2 handmatig willen testen om er zeker van te zijn dat alles werkt zoals we verwachten?

We kunnen een speciale overeenkomstige regel toevoegen, gebaseerd op 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 kunnen we met curl v2 dwingen aan te vragen door de header te verzenden:

Verzoeken zonder header worden nog steeds beheerd volgens de verhouding 1/10:

Canary voor twee afhankelijk versies

Laten we nu een scenario bekijken waar we versie v2 hebben voor zowel de frontend als de backend. Voor beiden hebben we aangegeven dat 10% van het verkeer naar v2 moet gaan:

We zien dat zowel frontend v1 als v2 verkeer doorsturen volgens de verhouding 1/10 naar backend v1 en v2.

Wat als we het verkeer van frontend-v2 alleen naar backend-v2 moeten doorsturen, omdat het niet compatibel is met v1? Hiervoor stellen we de verhouding 1/10 in voor de frontend, die bepaalt welk verkeer naar backend-v2 gaat met behulp van een overeenkomst op 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

Uiteindelijk krijgen we wat we nodig hebben:

Verschillen met de handmatige Canary-aanpak

In het eerste deel We voerden Canary deployment handmatig uit, waarbij we ook twee k8s-deployments gebruikten. Daar beheerden we de verhouding van verzoeken door het aantal replica's aan te passen. Deze aanpak werkt, maar heeft aanzienlijke nadelen.

Istio maakt het mogelijk om de verhouding van verzoeken te bepalen, ongeacht het aantal replica's. Dit betekent bijvoorbeeld dat we HPAs (Horizontal Pod Autoscalers) kunnen gebruiken en dat deze niet afgestemd hoeven te worden op de huidige staat van de Canary-deployment.

Conclusie

Istio werkt fantastisch en door het samen met Kiali te gebruiken, krijgen we een zeer krachtige combinatie. De volgende in mijn lijst van interesses is de combinatie van Spinnaker met Istio voor automatisering en Canary-analyse.

Bron: habr.com