Implementazione Canary in Kubernetes #3: Istio

Utilizendu Istio + Kiali per lancià è visualizà una implementazione Canary

Articuli in questa serie

1. Implementazione di Canary in Kubernetes #1: Gitlab CI
2. Implementazione di Canary in Kubernetes #2: Argo Rollouts
3. (Stu articulu)
4. Implementazione di Canary cù Jenkins-X Istio Flagger

Impiegazione Canaria

Speremu chì leghjite prima parte, induve avemu spiegatu brevemente ciò chì sò i dispiegamenti di Canary è hà dimustratu cumu implementà cù e risorse standard di Kubernetes.

Istio

È assumemu chì leghjendu stu articulu sapete digià ciò chì Istio hè. Se no, allora pudete leghje nantu à questu ccà.

Applicazione per i testi

Ogni pod cuntene dui cuntenituri: a nostra applicazione è istio-proxy.

Useremu una applicazione di prova simplice cù frontend-nginx è pods python backend. U pod nginx ridirezzione solu ogni dumanda à u pod backend è travaglià cum'è un proxy. I dettagli ponu esse truvati in i seguenti yamls:

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

Eseguisce l'applicazione di prova sè stessu

Se vulete seguità u mo esempiu è aduprà sta applicazione di prova sè stessu, vede leggimi u prughjettu.

Impiegazione iniziale

Quandu avemu lanciatu u primu Deployment, vedemu chì i pods di a nostra applicazione anu solu cuntenituri 2, vale à dì, Istio sidecar hè solu implementatu:

È vedemu ancu Istio Gateway Loadbalancer in u namespace istio-system:

Generazione di trafficu

Adupremu a seguente IP per generà trafficu chì serà ricevutu da i pods frontend è trasmessi à i pods backend:

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

Avemu ancu aghjunghje frontend.istio-test à u nostru schedariu hosts.

Vede Mesh via Kiali

Avemu installatu l'applicazione di prova è Istio cù Tracing, Grafana, Prometheus è Kiali (vede sottu per i dettagli). leggimi u prughjettu). Dunque pudemu usà Kiali via:

istioctl dashboard kiali # admin:admin

Kiali visualizeghja u trafficu attuale attraversu Mesh

Comu pudemu vede, u 100% di u trafficu va à u serviziu di frontend, dopu à i pods di frontend cù l'etichetta v1, postu chì usemu un proxy nginx simplice chì redirige e dumande à u serviziu di backend, chì à u turnu li redirige à i pods backend. cù l'etichetta v1.

Kiali funziona bè cù Istio è furnisce una suluzione di rendering Mesh in scatula. Solu fantasticu.

Impiegazione Canaria

U nostru backend hà digià duie implementazioni k8s, una per v1 è una per v2. Avà basta à dì à Istio per trasmette un certu percentinu di richieste à v2.

Passu 1: 10%

È tuttu ciò chì avemu bisognu di fà hè aghjustà u pesu di u VirtualService 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

Avemu vistu chì u 10% di e dumande sò rediretti à v2.

Passu 2: 50%

È avà hè abbastanza solu per aumentà à 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

Passu 3: 100%

Avà l'implementazione di Canary pò esse cunsiderata cumpleta è tuttu u trafficu hè ridirettu à v2:

Testing Canary manualmente

Diciamu chì avà mandemu u 2% di tutte e dumande à u backend v10. E se vulemu pruvà manualmente v2 per assicurà chì tuttu funziona cum'è l'aspettemu?

Pudemu aghjunghje una regula di currispundenza speciale basatu annantu à l'intestazione HTTP:

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

Avà usendu curl pudemu furzà una dumanda v2 mandendu l'intestazione:

E dumande senza header seranu sempre guidate da u rapportu 1/10:

Canary per duie versioni dipendente

Avà cunsideremu l'opzione induve avemu a versione v2 per u frontend è u backend. Per i dui, avemu specificatu chì u 10% di u trafficu deve andà à v2:

Avemu vistu chì u frontend v1 è v2 sò tramindui u trafficu di trasmissioni in un rapportu di 1/10 à u backend v1 è v2.

E se avemu bisognu di trasmette u trafficu da frontend-v2 solu à backend-v2 perchè ùn hè micca cumpatibile cù v1? Per fà questu, stabiliremu un rapportu 1/10 per u frontend, chì cuntrolla ciò chì u trafficu ghjunghje à u backend-v2 utilizendu a negoziazione. 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

In u risultatu, avemu ciò chì avemu bisognu:

Differenze da l'approcciu manuale di Canari

В a prima parte Avemu realizatu l'implementazione di Canary manualmente, utilizendu ancu duie implementazioni k8s. Quì avemu cuntrullatu u rapportu di e dumande cambiendu u numeru di rèpliche. Stu approcciu funziona, ma hà serii inconvenienti.

Istio permette di determinà u rapportu di e dumande indipendentemente da u numeru di rèpliche. Questu significa, per esempiu, chì pudemu usà HPAs (Horizontal Pod Autoscalers) è ùn anu micca bisognu di cunfigurazione secondu u statu attuale di l'implementazione Canary.

U risultatu

Istio travaglia assai è usannu lu inseme cù Kiali face per una cumminazzioni assai putenti. In seguitu nantu à a mo lista di interessi hè cumminendu Spinnaker cù Istio per l'automatizazione è l'analisi Canary.

Source: www.habr.com