Canary Deployment sa Kubernetes #3: Istio

Gamit ang Istio+Kiali para ilunsad at i-visualize ang isang Canary deployment

Mga artikulo sa seryeng ito

1. Canary Deployment sa Kubernetes #1: Gitlab CI
2. Canary Deployment sa Kubernetes #2: Argo Rollouts
3. (Ang artikulong ito)
4. Canary Deployment gamit ang Jenkins-X Istio Flagger

Pag-deploy ng Canary

Sana basahin niyo unang parte, kung saan maikli naming ipinaliwanag kung ano ang mga Canary deployment at ipinakita kung paano ipatupad ang mga ito gamit ang mga karaniwang mapagkukunan ng Kubernetes.

Istio

At ipinapalagay namin na sa pagbabasa ng artikulong ito ay alam mo na kung ano ang Istio. Kung hindi, maaari mong basahin ang tungkol dito dito.

Aplikasyon para sa mga pagsusulit

Ang bawat pod ay naglalaman ng dalawang container: ang aming application at istio-proxy.

Gagamit kami ng simpleng application ng pagsubok na may frontend-nginx at backend python pods. Ire-redirect lang ng nginx pod ang bawat kahilingan sa backend pod at gagana bilang proxy. Ang mga detalye ay matatagpuan sa mga sumusunod na yaml:

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

Ang pagpapatakbo ng application ng pagsubok sa iyong sarili

Kung gusto mong sundin ang aking halimbawa at gamitin ang pagsubok na application na ito sa iyong sarili, tingnan readme ng proyekto.

Paunang Deployment

Kapag inilunsad namin ang unang Deployment, nakita namin na ang mga pod ng aming application ay mayroon lamang 2 container, iyon ay, Istio sidecar ay ipinapatupad pa lang:

At nakikita rin natin ang Istio Gateway Loadbalancer sa namespace istio-system:

Pagbuo ng trapiko

Gagamitin namin ang sumusunod na IP upang bumuo ng trapiko na matatanggap ng mga frontend pod at ipapasa sa mga backend pod:

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

Magdadagdag din kami frontend.istio-test sa aming host file.

Tingnan ang Mesh sa pamamagitan ng Kiali

Na-install namin ang test application at Istio kasama ang Tracing, Grafana, Prometheus at Kiali (tingnan sa ibaba para sa mga detalye). readme ng proyekto). Samakatuwid maaari naming gamitin ang Kiali sa pamamagitan ng:

istioctl dashboard kiali # admin:admin

Nakikita ni Kiali ang kasalukuyang trapiko sa pamamagitan ng Mesh

Tulad ng nakikita natin, 100% ng trapiko ay napupunta sa serbisyo sa frontend, pagkatapos ay sa mga frontend pod na may label na v1, dahil gumagamit kami ng isang simpleng nginx proxy na nagre-redirect ng mga kahilingan sa serbisyo ng backend, na nagre-redirect sa kanila sa mga backend pod. may label na v1.

Mahusay na gumagana ang Kiali sa Istio at nagbibigay ng isang boxed Mesh rendering solution. Ang galing lang.

Pag-deploy ng Canary

Ang aming backend ay mayroon nang dalawang k8s deployment, isa para sa v1 at isa para sa v2. Ngayon kailangan lang nating sabihin kay Istio na ipasa ang isang partikular na porsyento ng mga kahilingan sa v2.

Hakbang 1: 10%

At ang kailangan lang nating gawin ay ayusin ang bigat ng VirtualService sa 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

Nakita namin na 10% ng mga kahilingan ay na-redirect sa v2.

Hakbang 2: 50%

At ngayon ay sapat na upang madagdagan lamang ito sa 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

Hakbang 3: 100%

Ngayon ang pag-deploy ng Canary ay maaaring ituring na kumpleto at ang lahat ng trapiko ay na-redirect sa v2:

Manu-manong pagsubok sa Canary

Sabihin nating nagpapadala na kami ngayon ng 2% ng lahat ng kahilingan sa v10 backend. Paano kung gusto naming manu-manong subukan ang v2 para matiyak na gumagana ang lahat gaya ng inaasahan namin?

Maaari kaming magdagdag ng espesyal na panuntunan sa pagtutugma batay sa mga header ng 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

Ngayon gamit ang curl maaari nating pilitin ang isang v2 na kahilingan sa pamamagitan ng pagpapadala ng header:

Ang mga kahilingang walang header ay hihikayat pa rin ng 1/10 ratio:

Canary para sa dalawang umaasa na bersyon

Ngayon ay isasaalang-alang namin ang opsyon kung saan mayroon kaming bersyon v2 para sa parehong frontend at backend. Para sa pareho, tinukoy namin na ang 10% ng trapiko ay dapat pumunta sa v2:

Nakikita namin na ang frontend v1 at v2 ay parehong pasulong na trapiko sa ratio na 1/10 sa backend v1 at v2.

Paano kung kailangan naming ipasa ang trapiko mula sa frontend-v2 hanggang backend-v2 lang dahil hindi ito tugma sa v1? Para magawa ito, magtatakda kami ng 1/10 ratio para sa frontend, na kumokontrol sa kung ano ang mararating ng trapiko sa backend-v2 gamit ang negosasyon 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

Bilang resulta, nakukuha namin ang kailangan namin:

Mga pagkakaiba mula sa manu-manong diskarte sa Canary

В ang unang bahagi Manu-mano kaming nagsagawa ng Canary deployment, gamit din ang dalawang k8s deployment. Doon namin kinokontrol ang ratio ng mga kahilingan sa pamamagitan ng pagbabago ng bilang ng mga replika. Gumagana ang diskarteng ito, ngunit may mga seryosong disbentaha.

Ginagawang posible ng Istio na matukoy ang ratio ng mga kahilingan anuman ang bilang ng mga replika. Nangangahulugan ito, halimbawa, na maaari naming gamitin ang mga HPA (Horizontal Pod Autoscalers) at hindi kailangang i-configure ayon sa kasalukuyang estado ng pag-deploy ng Canary.

Kabuuan

Mahusay na gumagana ang Istio at ang paggamit nito kasama ang Kiali ay gumagawa para sa isang napakalakas na kumbinasyon. Ang susunod sa aking listahan ng mga interes ay ang pagsasama ng Spinnaker sa Istio para sa automation at Canary analytics.

Pinagmulan: www.habr.com