Canary Deployment i Kubernetes #3: Istio

Använda Istio+Kiali för att initiera och visualisera Canary-deployments

Artiklar i denna cykel

1. Canary Deployment i Kubernetes #1: Gitlab CI
2. Canary Deployment i Kubernetes #2: Argo Rollouts
3. (denna artikel)
4. Canary-deployment med Jenkins-X Istio Flagger

Canary-deployment

Vi hoppas att du har läst den första delen, där vi kort förklarade vad Canary-deployments är och visade hur man genomför dem med standardresurser i Kubernetes.

Istio

Och vi förutsätter att när du läser denna artikel vet du redan vad Istio är. Om inte, kan du läsa om det här.

App för tester

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

Vi kommer att använda en enkel testapplikation med pods frontend-nginx och backend i Python. Podden med nginx kommer bara att omdirigera varje begäran till podden med backend och fungera som en proxy. Detaljer kan ses mer i de följande yaml-filerna:

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

Köra testapplikationen själv

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

Initial Deployment

Vid starten av den första deploymenten ser vi att pods i vår applikation har endast två containrar, vilket innebär att Istio-sidecar för närvarande bara implementeras:

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

Skapa trafik

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

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 i vår hosts-fil.

Visa Mesh via Kiali

Vi har installerat testapplikationen och Istio tillsammans med Tracing, Grafana, Prometheus och Kiali (se mer på readme-filen för projektet). Följaktligen kan vi använda Kiali via:

istioctl dashboard kiali # admin:admin

Kiali visualiserar den aktuella trafiken genom Mesh

Som vi kan se, går 100% av trafiken till frontend-tjänsten, sedan till frontend-poden med etikett v1, eftersom vi använder en enkel nginx-proxy som omdirigerar begärningar till backend-tjänsten, som i sin tur omdirigerar dem till backend-pods med etikett v1.

Kiali fungerar utmärkt tillsammans med Istio och erbjuder en färdig lösning för att visualisera Mesh. Bara fantastiskt.

Canary-deployment

Vår backend har redan två k8s-deployments, en för v1 och en för v2. Nu behöver vi bara säga till Istio att omdirigera en viss procentandel av begärningarna till v2.

Steg 1: 10%

Och allt vi behöver göra är att justera vikten på VirtualService i 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 det tillräckligt enkelt 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 slutförd och all trafik omdirigeras till v2:

Manuell testning av Canary

Anta att vi nu skickar 10 % av alla förfrågningar till backend v2. 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-huvuden:

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 använder vi curl för att tvinga en begäran till v2 genom att skicka huvudet:

Begärningar utan huvudet kommer fortfarande att hanteras enligt förhållandet 1/10:

Canary för två beroende versioner

Nu ska vi se ett scenario där vi har version v2 för både frontend och backend. För båda har vi angett att 10 % av trafiken ska gå till v2:

Vi ser att både frontend v1 och v2 skickar trafik i förhållandet 1/10 till backend v1 och v2.

Vad händer om vi behöver skicka trafik från frontend-v2 endast till backend-v2, eftersom det inte är kompatibelt med v1? För detta kommer vi att ställa in ett förhållande 1/10 för frontend, som kontrollerar vilken trafik som går till backend-v2 med hjälp av matchning baserat på 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 vi får det vi behöver:

Skillnaderna från den manuella Canary-metoden

I första delen Vi utförde Canary-distribution manuellt, också med hjälp av två k8s-distributioner. Där hanterade vi förhållandet mellan förfrågningar genom att ändra antalet repliker. Denna metod fungerar, men har allvarliga nackdelar.

Istio ger möjlighet att definiera förhållandet mellan förfrågningar oavsett antalet repliker. Det betyder till exempel att vi kan använda HPAs (Horizontal Pod Autoscalers — horisontell skalning av pods) och det behöver inte ställas in utifrån det aktuella tillståndet av Canary-distributionen.

Resultat

Istio fungerar utmärkt och genom att använda det tillsammans med Kiali får vi en mycket kraftfull kombination. Nästa på min lista över intressen är kombinationen av Spinnaker med Istio för automatisering och Canary-analys.

Källa: habr.com