Canary Deployment i Kubernetes #3: Istio

Använder Istio+Kiali för att starta och visualisera en kanariefåge

Artiklar i denna serie

1. Canary Deployment i Kubernetes #1: Gitlab CI
2. Canary-distribution i Kubernetes #2: Argo-utrullningar
3. (Denna artikel)
4. Canary Deployment med Jenkins-X Istio Flagger

Kanarieöarnas utbyggnad

Vi hoppas att du läser första delen, där vi kortfattat förklarade vad Canary-distributioner är och visade hur man implementerar dem med standard Kubernetes-resurser.

Samma

Och vi antar att genom att läsa den här artikeln vet du redan vad Istio är. Om inte, så kan du läsa om det här.

Ansökan om prov

Varje pod innehåller två behållare: vår applikation och istio-proxy.

Vi kommer att använda en enkel testapplikation med frontend-nginx och backend python pods. nginx-podden omdirigerar helt enkelt varje begäran till backend-podden och fungerar som en proxy. Detaljer kan hittas i följande yamls:

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

Kör testapplikationen själv

Om du vill följa mitt exempel och själv använda denna testapplikation, se projekt readme.

Initial distribution

När vi lanserar den första implementeringen ser vi att poddarna i vår applikation bara har 2 behållare, det vill säga Istio sidovagn håller just på att implementeras:

Och vi ser också Istio Gateway Loadbalancer i namnutrymmet istio-system:

Trafikgenerering

Vi kommer att använda följande IP för att generera trafik som kommer att tas emot av frontend-podarna och vidarebefordras till backend-podarna:

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

Vi kommer också att lägga till frontend.istio-test till vår hosts-fil.

Se Mesh via Kiali

Vi installerade testapplikationen och Istio tillsammans med Tracing, Grafana, Prometheus och Kiali (se nedan för detaljer). projekt readme). Därför kan vi använda Kiali via:

istioctl dashboard kiali # admin:admin

Kiali visualiserar aktuell trafik genom Mesh

Som vi kan se går 100 % av trafiken till frontend-tjänsten, sedan till frontend-poddarna med etiketten v1, eftersom vi använder en enkel nginx-proxy som omdirigerar förfrågningar till backend-tjänsten, som i sin tur omdirigerar dem till backend-podarna med etikett v1.

Kiali fungerar utmärkt med Istio och tillhandahåller en boxad Mesh-renderingslösning. Bara bra.

Kanarieöarnas utbyggnad

Vår backend har redan två k8s-distributioner, en för v1 och en för v2. Nu behöver vi bara berätta för Istio att vidarebefordra en viss procentandel av förfrågningarna till v2.

Steg 1: 10 %

Och allt vi behöver göra är att justera vikten 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 att 10 % av förfrågningarna omdirigeras till v2.

Steg 2: 50 %

Och nu räcker det bara att öka den till 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

Steg 3: 100 %

Nu kan Canary-distributionen anses vara klar och all trafik omdirigeras till v2:

Testar Canary manuellt

Låt oss säga att vi nu skickar 2 % av alla förfrågningar till v10-backend. Vad händer om vi vill testa v2 manuellt för att se till att allt fungerar som vi förväntar oss?

Vi kan lägga till en speciell matchningsregel baserad på HTTP-rubriker:

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 genom att använda curl kan vi tvinga fram en v2-förfrågan genom att skicka rubriken:

Förfrågningar utan rubrik kommer fortfarande att drivas av förhållandet 1/10:

Canary för två beroende versioner

Nu ska vi överväga alternativet där vi har version v2 för både frontend och backend. För båda specificerade vi att 10 % av trafiken skulle gå till v2:

Vi ser att frontend v1 och v2 båda framåt trafik i ett förhållande av 1/10 till backend v1 och v2.

Tänk om vi behövde vidarebefordra trafik från frontend-v2 endast till backend-v2 eftersom det inte är kompatibelt med v1? För att göra detta kommer vi att ställa in ett 1/10-förhållande för frontend, som styr vilken trafik som kommer till backend-v2 med förhandling 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 ett resultat får vi det vi behöver:

Skillnader från den manuella kanariefågemetoden

В den första delen Vi utförde Canary-distribution manuellt, även med två k8s-distributioner. Där kontrollerade vi förhållandet mellan förfrågningar genom att ändra antalet repliker. Detta tillvägagångssätt fungerar, men har allvarliga nackdelar.

Istio gör det möjligt att bestämma förhållandet mellan förfrågningar oavsett antalet repliker. Detta innebär till exempel att vi kan använda HPAs (Horizontal Pod Autoscalers) och inte behöver konfigureras enligt det aktuella läget för Canary-utbyggnaden.

Totalt

Istio fungerar utmärkt och att använda den tillsammans med Kiali ger en mycket kraftfull kombination. Nästa på min lista över intressen är att kombinera Spinnaker med Istio för automation och Canary-analys.

Källa: will.com