Canary Deployment i Kubernetes #3: Istio

Brug af Istio+Kiali til at starte og visualisere en kanarisk installation

Artikler i denne serie

1. Canary Deployment i Kubernetes #1: Gitlab CI
2. Canary-udrulning i Kubernetes #2: Argo-udrulning
3. (Denne artikel)
4. Canary Deployment ved hjælp af Jenkins-X Istio Flagger

Kanariske indsættelse

Vi håber du læser med første del, hvor vi kort forklarede, hvad Canary-implementeringer er og viste, hvordan man implementerer dem ved hjælp af standard Kubernetes-ressourcer.

Samme

Og vi antager, at du ved at læse denne artikel allerede ved, hvad Istio er. Hvis ikke, så kan du læse om det her.

Ansøgning om prøver

Hver pod indeholder to beholdere: vores applikation og istio-proxy.

Vi vil bruge en simpel testapplikation med frontend-nginx og backend python pods. nginx-poden omdirigerer simpelthen hver anmodning til backend-poden og fungerer som en proxy. Detaljer kan findes i følgende yamls:

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

Kører selv testapplikationen

Hvis du vil følge mit eksempel og selv bruge denne testapplikation, se projekt readme.

Indledende implementering

Når vi lancerer den første Deployment, ser vi, at pods af vores applikation kun har 2 containere, det vil sige, Istio sidevogn er lige ved at blive implementeret:

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

Trafikgenerering

Vi vil bruge følgende IP til at generere trafik, der modtages af frontend-pods og videresendes til backend-pods:

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

Vi vil også tilføje frontend.istio-test til vores værtsfil.

Se Mesh via Kiali

Vi installerede testapplikationen og Istio sammen med Tracing, Grafana, Prometheus og Kiali (se nedenfor for detaljer). projekt readme). Derfor kan vi bruge Kiali via:

istioctl dashboard kiali # admin:admin

Kiali visualiserer den aktuelle trafik gennem Mesh

Som vi kan se, går 100 % af trafikken til frontend-tjenesten og derefter til frontend-pods med label v1, da vi bruger en simpel nginx-proxy, der omdirigerer anmodninger til backend-tjenesten, som igen omdirigerer dem til backend-pods med label v1.

Kiali fungerer godt med Istio og giver en mesh-gengivelsesløsning i æske. Bare fantastisk.

Kanariske indsættelse

Vores backend har allerede to k8s-implementeringer, en til v1 og en til v2. Nu skal vi bare fortælle Istio at videresende en vis procentdel af anmodninger til v2.

Trin 1: 10 %

Og alt, hvad vi skal gøre, er at justere vægten af ​​VirtualService ind 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 % af anmodningerne omdirigeres til v2.

Trin 2: 50 %

Og nu er det nok bare at øge 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

Trin 3: 100 %

Nu kan Canary-implementeringen betragtes som afsluttet, og al trafik omdirigeres til v2:

Tester Canary manuelt

Lad os sige, at vi nu sender 2 % af alle anmodninger til v10-backend. Hvad hvis vi manuelt vil teste v2 for at sikre, at alt fungerer, som vi forventer?

Vi kan tilføje en speciel matchningsregel baseret på HTTP-headere:

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 ved at bruge curl kan vi tvinge en v2-anmodning ved at sende headeren:

Anmodninger uden overskrift vil stadig blive drevet af forholdet 1/10:

Canary til to afhængige versioner

Nu vil vi overveje muligheden, hvor vi har version v2 til både frontend og backend. For begge specificerede vi, at 10 % af trafikken skulle gå til v2:

Vi ser, at frontend v1 og v2 både fremadgående trafik i et forhold på 1/10 til backend v1 og v2.

Hvad hvis vi kun skulle videresende trafik fra frontend-v2 til backend-v2, fordi den ikke er kompatibel med v1? For at gøre dette vil vi indstille et 1/10-forhold for frontend, som styrer, hvilken trafik der kommer til backend-v2 ved hjælp af 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 har brug for:

Forskelle fra den manuelle kanariske tilgang

В den første del Vi udførte Canary-implementering manuelt, også ved at bruge to k8s-installationer. Der kontrollerede vi forholdet mellem anmodninger ved at ændre antallet af replikaer. Denne tilgang virker, men har alvorlige ulemper.

Istio gør det muligt at bestemme forholdet mellem anmodninger uanset antallet af replikaer. Det betyder for eksempel, at vi kan bruge HPA'er (Horizontal Pod Autoscalers) og ikke behøver at være konfigureret i henhold til den aktuelle tilstand af Canary-udrulningen.

Total

Istio fungerer fantastisk, og at bruge det sammen med Kiali giver en meget kraftfuld kombination. Det næste på min liste over interesser er at kombinere Spinnaker med Istio til automatisering og kanariske analyser.

Kilde: www.habr.com