Canary Deployment në Kubernetes #3: Istio

Përdorimi i Istio+Kiali për nisjen dhe visualizimin e Canary deploy

Artikujt e këtij cikli

1. Shpërndarja Canary në Kubernetes #1: Gitlab CI
2. Implementimi Canary në Kubernetes #2: Argo Rollouts
3. (ky artikull)
4. Canary Deployment duke përdorur Jenkins-X Istio Flagger

Shpërndarja Canary

Shpresojmë që keni lexuar pjesën e parë, ku shpjeguam shkurtimisht se çfarë janë deploy-t e Canary dhe tregonim si t'i realizoni duke përdorur burimet standarde të Kubernetes.

Istio

Dhe ne supozojmë se, duke lexuar këtë artikull, tashmë e dini se çfarë është Istio. Nëse jo, mund të lexoni për të këtu.

Aplikacioni për teste

Çdo pod përmban dy kontejnerë: aplikacionin tonë dhe istio-proxy.

Ne do të përdorim një aplikacion të thjeshtë testimi me pod-at frontend-nginx dhe backend në python. Pod-i me nginx do të thjesht të ridrejtojë çdo kërkesë në pod-in me backend dhe do të funksionojë si proxy. Detajet mund të shihni më hollësisht në yamlet e mëposhtme:

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

Nisja e aplikacionit testues vetë

Nëse dëshironi të ndiqni shembullin tim dhe të përdorni këtë aplikacion testimi vetë, shihni readme e projektit.

Deployment-i fillestar

Kur të nisim Deployment-in e parë, shohim që pod-et e aplikacionit tonë kanë vetëm nga 2 kontejnerë, domethënë Istio sidecar akoma po integrohet:

Dhe gjithashtu shohim Istio Gateway Loadbalancer në namespace istio-system:

Krijimi i trafikut

Do të përdorim IP-në e mëposhtme për të gjeneruar trafik, i cili do të pranohet nga pod-et frontend dhe do të ridrejtohet në pod-et backend:

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

Ne gjithashtu do ta shtojmë frontend.istio-test në skedarin tonë hosts.

Shikimi i Mesh-it përmes Kiali

Ne kemi instaluar aplikacionin testues dhe Istio bashkë me Tracing, Grafana, Prometheus dhe Kiali (më shumë shihni readme e projektit). Si rezultat, mund ta përdorim Kiali përmes:

istioctl dashboard kiali # admin:admin

Kiali vizualizon trafikun aktual përmes Mesh-it

Siç shohim, 100% e trafikut shkon në shërbimin frontend, pastaj në pod-in e frontend-it me label v1, pasi po përdorim një nginx-proxy të thjeshtë, i cili ridrejton kërkesat në shërbimin backend, i cili nga ana e tij i ridrejton ato në pod-et backend me label v1.

Kiali punon shkëlqyeshëm bashkë me Istio dhe ofron një zgjidhje të kutisë për vizualizimin e Mesh-it. Thjesht e shkëlqyer.

Shpërndarja Canary

Backend-i ynë tashmë ka dy deployment-e k8s, një për v1 dhe një për v2. Tani duhet thjesht të i themi Istio të ridrejtojë një përqindje të caktuar të kërkesave në v2.

Hapi 1: 10%

Dhe e gjitha që na nevojitet është të rregullojmë pesha e VirtualService në 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

Ne shohim se 10% e kërkesave janë redirectuar në v2.

Hapi 2: 50%

Dhe tani është mjaft e thjeshtë ta rritni atë në 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

Hapi 3: 100%

Tani implementimi Canary mund të konsiderohet i përfunduar dhe i gjithë trafiku redirectohet në v2:

Testimi manual i Canary

Të supozojmë se tani po dërgojmë në backend v2 10% të të gjitha kërkesave. Çfarë nëse dëshirojmë të testojmë në mënyrë manuale v2 për të siguruar se gjithçka funksionon siç e presim?

Mund të shtojmë një rregull të veçantë të përshtatjes, të bazuar në header-at 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

Tani duke përdorur curl mund të kërkojmë me forcë v2 duke dërguar header-in:

Kërkesat pa header ende do të trajtohen në raportin 1/10:

Canary për dy versione të varura

Tani do të shqyrtojmë një rast, ku kemi version v2 si për frontend ashtu edhe për backend. Për të dy do të përcaktojmë se 10% e trafik duhet të shkojë në v2:

Shohim se frontend v1 dhe v2 të dy e transferojnë trafikun në raportin 1/10 në backend v1 dhe v2.

Çfarë nëse do të na duhej të transferonim trafik nga frontend-v2 vetëm në backend-v2, sepse ai nuk është kompatibil me v1? Për këtë do të vendosim raportin 1/10 për frontend, i cili kontrollon se cili trafik kalon në backend-v2 duke përdorur përputhjen sipas 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

Si përfundim merrim atë që na nevojitet:

Dallimet nga qasja manuale e Canary

Në pjesën e parë ne e realizuam Canary deployment manualisht, duke përdorur gjithashtu dy k8s deployments. Aty menaxhonim raportin e kërkesave, duke ndryshuar numrin e replikave. Ky qasje punon, por ka disavantazhe serioze.

Istio ofron mundësinë për të përcaktuar raportin e kërkesave pavarësisht nga numri i replikave. Kjo do të thotë, për shembull, që mund të përdorim HPAs (Horizontal Pod Autoscalers — shkallëzim horizontal të podëve) dhe nuk është e nevojshme ta konfigurojmë në përputhje me gjendjen aktuale të Canary deployment.

Përfundimi

Istio punon shkëlqyeshëm dhe duke e përdorur atë së bashku me Kiali marrim një kombinim shumë të fuqishëm. E ardhshmja në listën time të interesave është kombinimi i Spinnaker me Istio për automatizimin dhe analitikën e Canary.

Burimi: habr.com