Canary Deployment në Kubernetes #3: Istio

Përdorimi i Istio+Kiali për të nisur dhe vizualizuar Canary deployment-in

Artikujt e këtij cikli

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

Canary Deployment

Shpresojmë se keni lexuar pjesën e parë, ku ne shpjeguam përmbledhtazi çfarë janë Canary deployments dhe treguam si të realizohet me ndihmën e burimeve standarde Kubernetes.

Istio

Dhe supozojmë se, duke lexuar këtë artikull, ju tashmë e dini ç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.

Do të përdorim një aplikacion testues të thjeshtë me pod-e frontend-nginx dhe backend në python. Pod-i me nginx do ta redirektojë çdo kërkesë në pod-in me backend dhe do të funksionojë si një proxy. Detajet mund të shikoni më shumë në yamlat 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 testues vetë, shihni readme projekti.

Deployment-i Fillestar

Kur nisni Deployment-in e parë, shohim se pod-et e aplikacionit tonë kanë vetëm nga 2 kontejnerë, pra Istio sidecar tani vetëm po futet:

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

Krijimi i trafikut

Ne do të përdorim këtë IP për të gjeneruar trafikun, i cili do të pranohet nga pod-et e frontend dhe do të ridrejtohet në pod-et e 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 të shtojmë frontend.istio-test në skedarin tonë hosts.

Për të parë Mesh përmes Kiali

Ne kemi instaluar aplikacionin testues dhe Istio së bashku me Tracing, Grafana, Prometheus dhe Kiali (më shumë në readme projekti). Prandaj, mund të përdorim Kiali përmes:

istioctl dashboard kiali # admin:admin

Kiali vizualizon trafikun aktual përmes Mesh

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

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

Canary Deployment

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

Hapi 1: 10%

Dhe gjithçka që na nevojitet është të rregullojmë peshën 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 po redirektohen në v2.

Hapi 2: 50%

Dhe tani është mjaft e thjeshtë ta rrisim 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 gjithë trafiku redirektohet në v2:

Testimi manual i Canary

Supozoni se tani po dërgojmë në backend v2 10% të të gjitha kërkesave. Çfarë ndodh nëse duam të testojmë manualisht v2 për t'u siguruar që gjithçka funksionon siç e presim?

Mund të shtojmë një rregull të veçantë përkatës, të bazuar në titujt 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 tani duke përdorim curl mund të kërkojmë me forcë v2 duke dërguar titullin:

Kërkesat pa titull akoma do të menaxhohen me raportin 1/10:

Canary për dy versionet e varura

Tani do të shqyrtojmë një rast, ku kemi versionin v2 për frontend dhe backend. Për të dy, kemi specifikuar se 10% e trafikut duhet të shkojë te v2:

Ne shohim që frontend v1 dhe v2 të dy dërgojnë trafik në raportin 1/10 në backend v1 dhe v2.

Çfarë nëse do të na nevojitej të dërgonim trafik nga frontend-v2 vetëm në backend-v2, sepse ai nuk është i pajtueshëm me v1? Për këtë, ne do të vendosim një raport 1/10 për frontend, i cili kontrollon se cilin trafik përfshin 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 në rezultat marrim atë që na nevojitet:

Dallimet nga qasja manuale Canary

Në pjesës së parë ne kemi realizuar depërtim Canary manual, gjithashtu duke përdorur dy implementime k8s. Atje kemi menaxhuar raportin e kërkesave, duke ndryshuar numrin e replikave. Ky qasje funksionon, por ka mangësi të konsiderueshme.

Istio ofron mundësinë për të përcaktuar raportin e kërkesave pavarësisht numrit të replikave. Kjo do të thotë, për shembull, se mund të përdorim HPAs (Horizontal Pod Autoscalers — shkallëzimi horizontal i pod-ëve) dhe nuk është e nevojshme ta konfigurojmë sipas gjendjes aktuale të depërtimit Canary.

Përfundimi

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

Burimi: habr.com