Panyebaran Kanaria di Kubernetes # 3: Istio

Nganggo Istio + Kiali pikeun ngaluncurkeun sareng ngabayangkeun panyebaran Canary

Artikel dina séri ieu

1. Panyebaran Kanaria di Kubernetes # 1: Gitlab CI
2. Panyebaran Kanaria di Kubernetes # 2: Argo Rollouts
3. (Artikel ieu)
4. deployment Kanaria maké Jenkins-X Istio Flagger

Panyebaran Kanaria

Kami ngarepkeun anjeun maca bagian kahiji, dimana urang sakeudeung ngajelaskeun naon panyebaran Canary sareng nunjukkeun kumaha nerapkeunana nganggo sumber daya Kubernetes standar.

Istio

Sareng urang nganggap yén ku maca tulisan ieu anjeun parantos terang naon Istio. Lamun henteu, mangka anjeun bisa maca ngeunaan eta di dieu.

Aplikasi pikeun tés

Unggal pod ngandung dua wadah: aplikasi kami sareng istio-proxy.

Urang bakal ngagunakeun aplikasi test basajan kalawan frontend-nginx na backend python pods. The nginx pod ngan saukur bakal alihan unggal pamundut ka backend pod tur dianggo salaku proxy a. Rincian tiasa dipendakan dina yamls ieu:

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

Ngajalankeun aplikasi tés sorangan

Upami anjeun hoyong nuturkeun conto kuring sareng nganggo aplikasi uji ieu nyalira, tingali proyék readme.

Panyebaran Awal

Nalika kami ngaluncurkeun Panyebaran anu munggaran, urang ningali yén pods tina aplikasi kami ngan ukur gaduh 2 wadah, nyaéta, sidecar Istio nembé dilaksanakeun:

Sarta kami ogé ningali Istio gateway Loadbalancer dina spasi ngaran istio-system:

Generasi lalulintas

Kami bakal nganggo IP di handap ieu pikeun ngahasilkeun lalu lintas anu bakal ditampi ku pods frontend sareng diteruskeun ka pods backend:

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

Urang ogé bakal nambahan frontend.istio-test kana file host urang.

Témbongkeun bolong via Kiali

Kami masang aplikasi tés sareng Istio sareng Tracing, Grafana, Prometheus sareng Kiali (tingali di handap pikeun detil). proyék readme). Ku sabab kitu urang tiasa nganggo Kiali via:

istioctl dashboard kiali # admin:admin

Kiali visualizes lalulintas ayeuna ngaliwatan Mesh

Sakumaha anu urang tingali, 100% tina lalu lintas angkat ka layanan frontend, teras ka pods frontend kalayan labél v1, sabab kami nganggo proxy nginx saderhana anu alihan pamundut ka jasa backend, anu gilirannana alihan ka pod backend. kalawan labél v1.

Kiali dianggo hébat sareng Istio sareng nyayogikeun solusi rendering bolong kotak. Hebat euy.

Panyebaran Kanaria

backend kami geus boga dua deployments k8s, hiji keur v1 sarta hiji keur v2. Ayeuna urang ngan ukur kedah nyarioskeun ka Istio pikeun neraskeun persentase tinangtu pamundut ka v2.

Lengkah 1: 10%

Sareng anu kedah urang laksanakeun nyaéta nyaluyukeun beurat VirtualService di 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

Kami ningali yén 10% tina pamundut dialihkeun ka v2.

Lengkah 2: 50%

Sareng ayeuna cukup ngan ukur ningkatkeun kana 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

Lengkah 3: 100%

Ayeuna panyebaran Canary tiasa dianggap lengkep sareng sadaya lalu lintas dialihkeun ka v2:

Nguji Canary sacara manual

Hayu urang ayeuna ngirim 2% sadaya requests ka v10 backend. Kumaha upami urang hoyong nguji v2 sacara manual pikeun mastikeun yén sadayana jalan sakumaha anu urang ngarepkeun?

Urang bisa nambahkeun aturan cocog husus dumasar kana headers 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

Ayeuna nganggo curl urang tiasa maksakeun pamundut v2 ku ngirim lulugu:

Paménta tanpa lulugu masih bakal didorong ku rasio 1/10:

Kanaria pikeun dua versi gumantung

Ayeuna urang bakal mertimbangkeun pilihan dimana urang gaduh versi v2 pikeun frontend sareng backend. Pikeun duanana, kami netepkeun yén 10% tina lalu lintas kedah angkat ka v2:

Kami ningali yén frontend v1 sareng v2 duanana maju lalu lintas dina nisbah 1/10 ka backend v1 sareng v2.

Kumaha upami urang kedah neraskeun lalu lintas ti frontend-v2 ngan ka backend-v2 sabab henteu cocog sareng v1? Jang ngalampahkeun ieu, urang bakal nangtukeun rasio 1/10 pikeun frontend nu, nu ngatur naon lalulintas meunang ka backend-v2 maké badami. 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

Hasilna, urang meunang naon urang kudu:

Béda tina pendekatan Kanaria manual

В bagian kahiji Urang ngalaksanakeun Canary deployment sacara manual, ogé ngagunakeun dua deployments k8s. Di dinya urang ngadalikeun babandingan requests ku cara ngarobah jumlah réplika. pendekatan ieu jalan, tapi boga drawbacks serius.

Istio ngamungkinkeun pikeun nangtukeun babandingan requests paduli jumlah réplika. Ieu hartosna, contona, urang tiasa nganggo HPAs (Horizontal Pod Autoscalers) sareng henteu kedah dikonpigurasikeun dumasar kana kaayaan panyebaran Kanaria ayeuna.

hasil

Istio tiasa dianggo saé sareng dianggo sareng Kiali ngajantenkeun kombinasi anu kuat pisan. Salajengna dina daptar kapentingan kuring nyaéta ngagabungkeun Spinnaker sareng Istio pikeun automation sareng analytics Canary.

sumber: www.habr.com