ການນຳໃຊ້ Canary ໃນ Kubernetes #3: Istio

ໃຊ້ Istio+Kiali ເພື່ອເປີດຕົວ ແລະສະແດງພາບການນຳໃຊ້ Canary

ບົດຄວາມໃນຊຸດນີ້

1. ການນຳໃຊ້ Canary ໃນ Kubernetes #1: Gitlab CI
2. ການນຳໃຊ້ Canary ໃນ Kubernetes #2: ການເປີດຕົວ Argo
3. (ຫົວ​ຂໍ້​ນີ້)
4. ການນຳໃຊ້ Canary ໂດຍໃຊ້ Jenkins-X Istio Flagger

ການນຳໃຊ້ Canary

ພວກເຮົາຫວັງວ່າທ່ານຈະອ່ານ ສ່ວນທໍາອິດ, ບ່ອນທີ່ພວກເຮົາໄດ້ອະທິບາຍສັ້ນໆວ່າການນໍາໃຊ້ Canary ແມ່ນຫຍັງແລະສະແດງໃຫ້ເຫັນວິທີການປະຕິບັດພວກມັນໂດຍໃຊ້ຊັບພະຍາກອນ Kubernetes ມາດຕະຖານ.

ອິຊິໂອ

ແລະພວກເຮົາສົມມຸດວ່າໂດຍການອ່ານບົດຄວາມນີ້ທ່ານຮູ້ແລ້ວວ່າ Istio ແມ່ນຫຍັງ. ຖ້າບໍ່, ຫຼັງຈາກນັ້ນທ່ານສາມາດອ່ານກ່ຽວກັບມັນ ທີ່ນີ້.

ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ສໍາ​ລັບ​ການ​ທົດ​ສອບ​

ແຕ່ລະຝັກປະກອບດ້ວຍສອງບັນຈຸ: ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາແລະ istio-proxy.

ພວກເຮົາຈະນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກການທົດສອບທີ່ງ່າຍດາຍທີ່ມີ frontend-nginx ແລະ backend python pods. ຝັກ nginx ພຽງແຕ່ຈະປ່ຽນເສັ້ນທາງແຕ່ລະຄໍາຮ້ອງຂໍໄປຫາ backend pod ແລະເຮັດວຽກເປັນຕົວແທນ. ລາຍ​ລະ​ອຽດ​ສາ​ມາດ​ພົບ​ເຫັນ​ຢູ່​ໃນ yamls ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

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

ແລ່ນຄໍາຮ້ອງສະຫມັກການທົດສອບຕົວທ່ານເອງ

ຖ້າທ່ານຕ້ອງການປະຕິບັດຕາມຕົວຢ່າງຂອງຂ້ອຍແລະໃຊ້ຄໍາຮ້ອງສະຫມັກການທົດສອບນີ້ຕົວທ່ານເອງ, ເບິ່ງ ໂຄງການ readme.

ການນຳໃຊ້ໃນເບື້ອງຕົ້ນ

ເມື່ອພວກເຮົາເປີດຕົວ Deployment ຄັ້ງທໍາອິດ, ພວກເຮົາເຫັນວ່າ pods ຂອງຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາມີພຽງແຕ່ 2 containers, ນັ້ນແມ່ນ, Istio sidecar ກໍາລັງຖືກປະຕິບັດ:

ແລະພວກເຮົາຍັງເຫັນ Istio Gateway Loadbalancer ໃນ namespace istio-system:

ການຜະລິດການຈະລາຈອນ

ພວກເຮົາຈະໃຊ້ IP ຕໍ່ໄປນີ້ເພື່ອສ້າງການຈະລາຈອນທີ່ຈະໄດ້ຮັບການຮັບໂດຍພອດຫນ້າດ້ານຫນ້າແລະສົ່ງຕໍ່ກັບ pods ດ້ານຫລັງ:

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

ພວກເຮົາຍັງຈະເພີ່ມ frontend.istio-test ກັບໄຟລ໌ເຈົ້າພາບຂອງພວກເຮົາ.

ເບິ່ງ Mesh ຜ່ານ Kiali

ພວກເຮົາໄດ້ຕິດຕັ້ງຄໍາຮ້ອງສະຫມັກການທົດສອບແລະ Istio ພ້ອມກັບ Tracing, Grafana, Prometheus ແລະ Kiali (ເບິ່ງຂ້າງລຸ່ມນີ້ສໍາລັບລາຍລະອຽດ). ໂຄງການ readme). ດັ່ງນັ້ນພວກເຮົາສາມາດນໍາໃຊ້ Kiali ຜ່ານ:

istioctl dashboard kiali # admin:admin

Kiali ເບິ່ງເຫັນສະພາບຈະລາຈອນໃນປະຈຸບັນຜ່ານ Mesh

ດັ່ງທີ່ພວກເຮົາສາມາດເຫັນໄດ້, 100% ຂອງການຈາລະຈອນໄປຫາການບໍລິການດ້ານຫນ້າ, ຫຼັງຈາກນັ້ນໄປຫາ pods frontend ທີ່ມີປ້າຍ v1, ເນື່ອງຈາກວ່າພວກເຮົາກໍາລັງໃຊ້ nginx proxy ງ່າຍດາຍທີ່ປ່ຽນເສັ້ນທາງການຮ້ອງຂໍໄປຫາບໍລິການ backend, ເຊິ່ງເຮັດໃຫ້ພວກເຂົາປ່ຽນເສັ້ນທາງ backend pods. ກັບປ້າຍ v1.

Kiali ເຮັດວຽກໄດ້ດີກັບ Istio ແລະສະຫນອງການແກ້ໄຂການສະແດງຜົນ Mesh ແບບກ່ອງ. ຍິ່ງໃຫຍ່.

ການນຳໃຊ້ Canary

backend ຂອງພວກເຮົາມີການນຳໃຊ້ k8s ສອງອັນແລ້ວ, ອັນໜຶ່ງສຳລັບ v1 ແລະອີກອັນໜຶ່ງສຳລັບ v2. ຕອນນີ້ພວກເຮົາພຽງແຕ່ຕ້ອງການບອກ Istio ໃຫ້ສົ່ງຕໍ່ອັດຕາສ່ວນທີ່ແນ່ນອນຂອງການຮ້ອງຂໍໃຫ້ກັບ v2.

ຂັ້ນຕອນທີ 1: 10%

ແລະທັງຫມົດທີ່ພວກເຮົາຕ້ອງເຮັດຄືການປັບນ້ໍາຫນັກຂອງ VirtualService ໃນ 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

ພວກເຮົາເຫັນວ່າ 10% ຂອງການຮ້ອງຂໍຖືກໂອນໄປຫາ v2.

ຂັ້ນຕອນທີ 2: 50%

ແລະໃນປັດຈຸບັນມັນພຽງພໍທີ່ຈະເພີ່ມມັນເຖິງ 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

ຂັ້ນຕອນທີ 3: 100%

ຕອນນີ້ການນຳໃຊ້ Canary ສາມາດຖືວ່າສຳເລັດແລ້ວ ແລະຈະລາຈອນທັງໝົດຖືກປ່ຽນເສັ້ນທາງໄປຫາ v2:

ການທົດສອບ Canary ດ້ວຍຕົນເອງ

ສົມມຸດວ່າພວກເຮົາສົ່ງ 2% ຂອງການຮ້ອງຂໍທັງຫມົດໄປຫາ v10 backend. ຈະເປັນແນວໃດຖ້າພວກເຮົາຕ້ອງການທົດສອບ v2 ດ້ວຍຕົນເອງເພື່ອໃຫ້ແນ່ໃຈວ່າທຸກຢ່າງເຮັດວຽກຕາມທີ່ພວກເຮົາຄາດຫວັງ?

ພວກເຮົາສາມາດເພີ່ມກົດລະບຽບການຈັບຄູ່ພິເສດໂດຍອີງໃສ່ສ່ວນຫົວ 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

ໃນປັດຈຸບັນການນໍາໃຊ້ curl ພວກເຮົາສາມາດບັງຄັບຄໍາຮ້ອງຂໍ v2 ໂດຍການສົ່ງ header:

ການຮ້ອງຂໍທີ່ບໍ່ມີສ່ວນຫົວຈະຍັງຄົງຖືກຂັບເຄື່ອນໂດຍອັດຕາສ່ວນ 1/10:

Canary ສໍາລັບສອງສະບັບທີ່ຂຶ້ນກັບ

ໃນປັດຈຸບັນພວກເຮົາຈະພິຈາລະນາທາງເລືອກທີ່ພວກເຮົາມີສະບັບ v2 ສໍາລັບທັງ frontend ແລະ backend. ສໍາລັບທັງສອງ, ພວກເຮົາກໍານົດວ່າ 10% ຂອງການຈະລາຈອນຄວນໄປຫາ v2:

ພວກເຮົາເຫັນວ່າ frontend v1 ແລະ v2 ທັງສອງການຈະລາຈອນຕໍ່ຫນ້າໃນອັດຕາສ່ວນ 1/10 ກັບ backend v1 ແລະ v2.

ຈະເປັນແນວໃດຖ້າພວກເຮົາຕ້ອງການສົ່ງຕໍ່ການຈະລາຈອນຈາກ frontend-v2 ໄປຫາ backend-v2 ເທົ່ານັ້ນເພາະວ່າມັນບໍ່ເຫມາະສົມກັບ v1? ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຈະກໍານົດອັດຕາສ່ວນ 1/10 ສໍາລັບ frontend, ເຊິ່ງຄວບຄຸມສິ່ງທີ່ການຈະລາຈອນໄປຫາ backend-v2 ໂດຍໃຊ້ການເຈລະຈາ. 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

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບສິ່ງທີ່ພວກເຮົາຕ້ອງການ:

ຄວາມແຕກຕ່າງຈາກວິທີການ Canary ຄູ່ມື

В ສ່ວນທໍາອິດ ພວກ​ເຮົາ​ໄດ້​ປະ​ຕິ​ບັດ​ການ​ນໍາ​ໃຊ້ Canary ດ້ວຍ​ຕົນ​ເອງ, ຍັງ​ການ​ນໍາ​ໃຊ້​ສອງ k8s. ຢູ່ທີ່ນັ້ນພວກເຮົາໄດ້ຄວບຄຸມອັດຕາສ່ວນການຮ້ອງຂໍໂດຍການປ່ຽນແປງຈໍານວນຂອງ replicas. ວິທີການນີ້ເຮັດວຽກ, ແຕ່ມີຂໍ້ບົກຜ່ອງທີ່ຮ້າຍແຮງ.

Istio ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະກໍານົດອັດຕາສ່ວນຂອງການຮ້ອງຂໍໂດຍບໍ່ຄໍານຶງເຖິງຈໍານວນຂອງ replicas. ນີ້ຫມາຍຄວາມວ່າ, ສໍາລັບການຍົກຕົວຢ່າງ, ພວກເຮົາສາມາດນໍາໃຊ້ HPAs (Horizontal Pod Autoscalers) ແລະບໍ່ຈໍາເປັນຕ້ອງ configured ຕາມສະຖານະປະຈຸບັນຂອງການນໍາໃຊ້ Canary.

ຜົນໄດ້ຮັບ

Istio ເຮັດວຽກໄດ້ດີແລະໃຊ້ມັນຮ່ວມກັນກັບ Kiali ເຮັດໃຫ້ການປະສົມປະສານທີ່ມີປະສິດທິພາບຫຼາຍ. ຕໍ່ໄປໃນບັນຊີລາຍຊື່ຄວາມສົນໃຈຂອງຂ້ອຍແມ່ນການລວມ Spinnaker ກັບ Istio ສໍາລັບອັດຕະໂນມັດແລະການວິເຄາະ Canary.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com