ກັບໄປຫາບໍລິການຈຸລະພາກກັບ Istio. ພາກທີ 2

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

ພວກເຮົາຍັງເຕືອນທ່ານວ່າບົດຄວາມໃຊ້ການຕັ້ງຄ່າ (manifests ສໍາລັບ Kubernetes ແລະ Istio) ຈາກ repository ວິຊາສະເພາະ.

ການຄຸ້ມຄອງການຈະລາຈອນ

ດ້ວຍ Istio, ຄວາມສາມາດໃໝ່ປະກົດຢູ່ໃນກຸ່ມເພື່ອສະໜອງ:

• ກຳນົດເສັ້ນທາງການຮ້ອງຂໍແບບໄດນາມິກ: canary rollouts, ການທົດສອບ A/B;
• ການດຸ່ນດ່ຽງການໂຫຼດ: ງ່າຍດາຍແລະສອດຄ່ອງ, ອີງໃສ່ hashes;
• ການ​ຟື້ນ​ຕົວ​ຫຼັງ​ຈາກ​ການ​ຫຼຸດ​ລົງ​: timeouts, retries, circuit breakers;
• ແຊກຂໍ້ບົກພ່ອງ: ການຊັກຊ້າ, ການຮ້ອງຂໍຫຼຸດລົງ, ແລະອື່ນໆ.

ໃນຂະນະທີ່ບົດຄວາມຍັງສືບຕໍ່, ຄວາມສາມາດເຫຼົ່ານີ້ຈະຖືກສະແດງໂດຍນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ເລືອກເປັນຕົວຢ່າງແລະແນວຄວາມຄິດໃຫມ່ຈະຖືກນໍາໄປນໍາ. ແນວຄວາມຄິດດັ່ງກ່າວທໍາອິດຈະເປັນ DestinationRules (ເຊັ່ນ: ກົດລະບຽບກ່ຽວກັບຜູ້ຮັບການຈະລາຈອນ/ຄໍາຮ້ອງຂໍ - ປະມານ transl.), ດ້ວຍການຊ່ວຍເຫຼືອທີ່ພວກເຮົາເປີດໃຊ້ການທົດສອບ A/B.

ການທົດສອບ A/B: ກົດລະບຽບປາຍທາງໃນການປະຕິບັດ

ການທົດສອບ A/B ຖືກນໍາໃຊ້ໃນກໍລະນີທີ່ມີສອງຮຸ່ນຂອງແອັບພລິເຄຊັນ (ໂດຍປົກກະຕິພວກມັນມີຄວາມແຕກຕ່າງກັນທາງສາຍຕາ) ແລະພວກເຮົາບໍ່ແນ່ໃຈວ່າອັນໃດຈະປັບປຸງປະສົບການຂອງຜູ້ໃຊ້. ດັ່ງນັ້ນ, ພວກເຮົາດໍາເນີນການທັງສອງສະບັບພ້ອມໆກັນແລະເກັບກໍາ metrics.

ເພື່ອປັບໃຊ້ເວີຊັນທີສອງຂອງ frontend, ຕ້ອງການສໍາລັບການສະແດງການທົດສອບ A/B, ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

ການ​ນໍາ​ໃຊ້ manifest ສໍາ​ລັບ​ສະ​ບັບ​ສີ​ຂຽວ​ແຕກ​ຕ່າງ​ກັນ​ຢູ່​ໃນ​ສອງ​ບ່ອນ​:

1. ຮູບພາບແມ່ນອີງໃສ່ແທັກທີ່ແຕກຕ່າງກັນ - istio-green,
2. ຝັກມີປ້າຍຊື່ version: green.

ເນື່ອງຈາກການຈັດຕັ້ງປະຕິບັດທັງສອງມີປ້າຍຊື່ app: sa-frontend,ການຮ້ອງຂໍເສັ້ນທາງໂດຍການບໍລິການ virtual sa-external-services ສໍາລັບການບໍລິການ sa-frontend, ຈະຖືກໂອນໄປຫາທຸກຕົວຢ່າງຂອງມັນແລະການໂຫຼດຈະຖືກແຈກຢາຍຜ່ານ ສູດການຄິດໄລ່ຮອບ-ໂຣບິນ, ຊຶ່ງຈະນໍາໄປສູ່ສະຖານະການດັ່ງຕໍ່ໄປນີ້:

ບໍ່ພົບໄຟລ໌ທີ່ຮ້ອງຂໍ

ບໍ່ພົບໄຟລ໌ເຫຼົ່ານີ້ເນື່ອງຈາກພວກມັນຖືກຕັ້ງຊື່ແຕກຕ່າງກັນໃນເວີຊັນຕ່າງໆຂອງແອັບພລິເຄຊັນ. ໃຫ້ແນ່ໃຈວ່ານີ້:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

ນີ້ຫມາຍຄວາມວ່າ index.html, ການຮ້ອງຂໍສະບັບຫນຶ່ງຂອງໄຟລ໌ຄົງທີ່, ສາມາດຖືກສົ່ງໂດຍ load balancer ກັບ pods ທີ່ມີສະບັບທີ່ແຕກຕ່າງກັນ, ບ່ອນທີ່, ສໍາລັບເຫດຜົນຈະແຈ້ງ, ໄຟລ໌ດັ່ງກ່າວບໍ່ມີ. ດັ່ງນັ້ນ, ເພື່ອໃຫ້ຄໍາຮ້ອງສະຫມັກເຮັດວຽກ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກໍານົດຂໍ້ຈໍາກັດ: "ເວີຊັນດຽວກັນຂອງແອັບພລິເຄຊັນທີ່ໃຫ້ບໍລິການ index.html ຄວນໃຫ້ບໍລິການຕາມຄໍາຮ້ອງຂໍຕໍ່ໄປ".

ພວກເຮົາຈະໄປທີ່ນັ້ນດ້ວຍການດຸ່ນດ່ຽງການໂຫຼດທີ່ອີງໃສ່ hash ທີ່ສອດຄ່ອງ (Consistent Hash Loadbalancing)... ໃນ​ກໍ​ລະ​ນີ​ນີ້ ການຮ້ອງຂໍຈາກລູກຄ້າດຽວກັນຖືກສົ່ງໄປຫາຕົວຢ່າງ backend ດຽວກັນ, ສໍາລັບຄຸນສົມບັດທີ່ກໍານົດໄວ້ລ່ວງຫນ້າຖືກນໍາໃຊ້ - ຕົວຢ່າງ, ຫົວ HTTP. ປະຕິບັດໂດຍໃຊ້ DestinationRules.

ກົດລະບຽບປາຍທາງ

ຫລັງຈາກ ການບໍລິການ Virtual ສົ່ງຄໍາຮ້ອງຂໍໄປຫາບໍລິການທີ່ຕ້ອງການ, ໂດຍໃຊ້ DestinationRules ພວກເຮົາສາມາດກໍານົດນະໂຍບາຍທີ່ຈະນໍາໃຊ້ກັບການຈະລາຈອນທີ່ກໍານົດສໍາລັບຕົວຢ່າງຂອງການບໍລິການນີ້:

ການຄຸ້ມຄອງການຈະລາຈອນກັບຊັບພະຍາກອນ Istio

Примечание: ຜົນກະທົບຂອງຊັບພະຍາກອນ Istio ໃນການຈະລາຈອນເຄືອຂ່າຍຖືກນໍາສະເຫນີຢູ່ທີ່ນີ້ໃນວິທີທີ່ງ່າຍຕໍ່ການເຂົ້າໃຈ. ເພື່ອໃຫ້ມີຄວາມຊັດເຈນ, ການຕັດສິນໃຈວ່າຕົວຢ່າງໃດທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍແມ່ນເຮັດໂດຍ Envoy ໃນ Ingress Gateway ທີ່ໄດ້ກໍານົດໄວ້ໃນ CRD.

ດ້ວຍກົດລະບຽບປາຍທາງ, ພວກເຮົາສາມາດຕັ້ງຄ່າການດຸ່ນດ່ຽງການໂຫຼດເພື່ອໃຊ້ hashes ທີ່ສອດຄ່ອງ ແລະຮັບປະກັນວ່າບໍລິການດຽວກັນຕອບສະຫນອງກັບຜູ້ໃຊ້ດຽວກັນ. ການຕັ້ງຄ່າຕໍ່ໄປນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດບັນລຸໄດ້ (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - hash ຈະຖືກສ້າງຂື້ນໂດຍອີງໃສ່ເນື້ອໃນຂອງ HTTP header version.

ນຳໃຊ້ການຕັ້ງຄ່າດ້ວຍຄຳສັ່ງຕໍ່ໄປນີ້:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

ຕອນນີ້ດໍາເນີນການຄໍາສັ່ງຂ້າງລຸ່ມນີ້ແລະໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຮັບໄຟລ໌ທີ່ຖືກຕ້ອງເມື່ອທ່ານລະບຸສ່ວນຫົວ version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

Примечание: ເພື່ອເພີ່ມມູນຄ່າທີ່ແຕກຕ່າງກັນໃນສ່ວນຫົວແລະທົດສອບຜົນໄດ້ຮັບໂດຍກົງໃນຕົວທ່ອງເວັບ, ທ່ານສາມາດນໍາໃຊ້ ສ່ວນຂະຫຍາຍນີ້ ກັບ Chrome (ຫຼື ກັບນີ້ ສໍາລັບ Firefox - ປະມານ. ແປ.).

ໂດຍທົ່ວໄປ, DestinationRules ມີຄວາມສາມາດເພີ່ມເຕີມໃນພື້ນທີ່ຂອງການດຸ່ນດ່ຽງການໂຫຼດ - ກວດເບິ່ງລາຍລະອຽດໃນ ເອກະສານທາງການ.

ກ່ອນທີ່ຈະສຶກສາ VirtualService ຕື່ມອີກ, ໃຫ້ລຶບ "ເວີຊັ່ນສີຂຽວ" ຂອງແອັບພລິເຄຊັນແລະກົດລະບຽບການສັນຈອນທີ່ສອດຄ້ອງກັນໂດຍການແລ່ນຄໍາສັ່ງຕໍ່ໄປນີ້:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

Mirroring: ບໍລິການ virtual ໃນການປະຕິບັດ

ການຮົ່ມ (“ການ​ປ້ອງ​ກັນ”) ຫຼື mirroring ("ການສະທ້ອນ") ໃຊ້ໃນກໍລະນີທີ່ພວກເຮົາຕ້ອງການທົດສອບການປ່ຽນແປງໃນການຜະລິດໂດຍບໍ່ມີຜົນກະທົບຕໍ່ຜູ້ໃຊ້ສຸດທ້າຍ: ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາເຮັດຊ້ໍາ ("ກະຈົກ") ການຮ້ອງຂໍກັບຕົວຢ່າງທີສອງທີ່ມີການປ່ຽນແປງທີ່ຕ້ອງການ, ແລະເບິ່ງຜົນສະທ້ອນ. ເວົ້າງ່າຍໆ, ນີ້ແມ່ນເວລາທີ່ເພື່ອນຮ່ວມງານຂອງທ່ານເລືອກເອົາບັນຫາທີ່ສໍາຄັນທີ່ສຸດແລະເຮັດໃຫ້ການຮ້ອງຂໍດຶງໃນຮູບແບບຂອງຂີ້ຝຸ່ນກ້ອນໃຫຍ່ທີ່ບໍ່ມີໃຜສາມາດທົບທວນຄືນໄດ້.

ເພື່ອທົດສອບສະຖານະການນີ້ໃນການປະຕິບັດ, ໃຫ້ສ້າງຕົວຢ່າງທີສອງຂອງ SA-Logic ກັບແມງໄມ້ (buggy) ໂດຍ​ການ​ແລ່ນ​ຄໍາ​ສັ່ງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

ແລະຕອນນີ້ໃຫ້ດໍາເນີນການຄໍາສັ່ງເພື່ອໃຫ້ແນ່ໃຈວ່າທຸກຕົວຢ່າງທີ່ມີ app=sa-logic ພວກເຂົາຍັງມີປ້າຍຊື່ທີ່ມີລຸ້ນທີ່ສອດຄ້ອງກັນ:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

ການບໍລິການ sa-logic ເປົ້າໝາຍຝັກທີ່ມີປ້າຍຊື່ app=sa-logic, ດັ່ງນັ້ນການຮ້ອງຂໍທັງຫມົດຈະຖືກແຈກຢາຍໃນບັນດາຕົວຢ່າງທັງຫມົດ:

... ແຕ່ພວກເຮົາຕ້ອງການການຮ້ອງຂໍໃຫ້ຖືກສົ່ງໄປຫາ v1 instances ແລະ mirrored ກັບ v2 instances:

ພວກເຮົາຈະບັນລຸໄດ້ໂດຍຜ່ານ VirtualService ປະສົມປະສານກັບ DestinationRule, ບ່ອນທີ່ກົດລະບຽບຈະກໍານົດຊຸດຍ່ອຍແລະເສັ້ນທາງຂອງ VirtualService ໄປຫາຊຸດຍ່ອຍສະເພາະ.

ການກໍານົດຍ່ອຍໃນກົດລະບຽບປາຍທາງ

ຊຸດຍ່ອຍ (ຊຸດຍ່ອຍ) ຖືກກໍານົດໂດຍການຕັ້ງຄ່າຕໍ່ໄປນີ້ (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. ເຈົ້າພາບ (host) ກໍານົດວ່າກົດລະບຽບນີ້ໃຊ້ກັບກໍລະນີທີ່ເສັ້ນທາງໄປສູ່ການບໍລິການເທົ່ານັ້ນ sa-logic;
2. ຫົວຂໍ້ (name) subsets ຖືກນໍາໃຊ້ໃນເວລາທີ່ routing ກັບ subset instances;
3. ປ້າຍກຳກັບ (label) ກຳນົດຄູ່ຄີ-ຄ່າທີ່ instances ຕ້ອງກົງກັນເພື່ອກາຍເປັນສ່ວນຫນຶ່ງຂອງຊຸດຍ່ອຍ.

ນຳໃຊ້ການຕັ້ງຄ່າດ້ວຍຄຳສັ່ງຕໍ່ໄປນີ້:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

ໃນປັດຈຸບັນທີ່ຊຸດຍ່ອຍໄດ້ຖືກກໍານົດ, ພວກເຮົາສາມາດສືບຕໍ່ແລະກໍາຫນົດຄ່າ VirtualService ເພື່ອນໍາໃຊ້ກົດລະບຽບການຮ້ອງຂໍເພື່ອ sa-logic ເພື່ອໃຫ້ພວກເຂົາ:

1. ຖືກສົ່ງໄປຫາຊຸດຍ່ອຍ v1,
2. ສະທ້ອນກັບຊຸດຍ່ອຍ v2.

manifesto ຕໍ່ໄປນີ້ອະນຸຍາດໃຫ້ທ່ານບັນລຸແຜນການຂອງທ່ານ (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

ບໍ່​ມີ​ຄໍາ​ອະ​ທິ​ບາຍ​ທີ່​ຈໍາ​ເປັນ​ຢູ່​ທີ່​ນີ້​, ສະ​ນັ້ນ​ໃຫ້​ພວກ​ເຮົາ​ເບິ່ງ​ໃນ​ການ​ປະ​ຕິ​ບັດ​:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

ໃຫ້ເພີ່ມການໂຫຼດໂດຍການໂທຫາຄໍາສັ່ງຕໍ່ໄປນີ້:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

ໃຫ້ເບິ່ງຜົນໄດ້ຮັບໃນ Grafana, ບ່ອນທີ່ທ່ານສາມາດເບິ່ງວ່າສະບັບທີ່ມີແມງໄມ້ (.buggy) ລົ້ມເຫລວສໍາລັບ ~ 60% ຂອງການຮ້ອງຂໍ, ແຕ່ຄວາມລົ້ມເຫລວເຫຼົ່ານີ້ບໍ່ມີຜົນຕໍ່ຜູ້ໃຊ້ສຸດທ້າຍຍ້ອນວ່າພວກເຂົາຖືກຕອບສະຫນອງໂດຍການບໍລິການທີ່ເຮັດວຽກ.

ຄໍາຕອບທີ່ປະສົບຜົນສໍາເລັດຂອງການບໍລິການ sa-logic ຮຸ່ນທີ່ແຕກຕ່າງກັນ

ທີ່ນີ້ພວກເຮົາທໍາອິດໄດ້ເຫັນວິທີການ VirtualService ຖືກນໍາໃຊ້ກັບ Envoys ຂອງການບໍລິການຂອງພວກເຮົາ: ເມື່ອ sa-web-app ເຮັດ​ໃຫ້​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ sa-logic, ມັນຜ່ານ sidecar Envoy, ເຊິ່ງ - ຜ່ານ VirtualService - ຖືກຕັ້ງຄ່າເພື່ອສົ່ງເສັ້ນທາງການຮ້ອງຂໍໄປຫາຊຸດຍ່ອຍ v1 ແລະສະທ້ອນຄໍາຮ້ອງຂໍໄປຫາຊຸດຍ່ອຍ v2 ຂອງການບໍລິການ. sa-logic.

ຂ້ອຍຮູ້, ເຈົ້າອາດຈະຄິດແລ້ວວ່າການບໍລິການ Virtual ແມ່ນງ່າຍດາຍ. ໃນພາກຕໍ່ໄປ, ພວກເຮົາຈະຂະຫຍາຍມັນໂດຍກ່າວວ່າພວກເຂົາຍັງຍິ່ງໃຫຍ່ແທ້ໆ.

Canary rollouts

Canary Deployment ແມ່ນຂັ້ນຕອນການເປີດຕົວແອັບພລິເຄຊັນເວີຊັນໃໝ່ໃຫ້ກັບຜູ້ໃຊ້ຈຳນວນໜ້ອຍໜຶ່ງ. ມັນຖືກນໍາໃຊ້ເພື່ອໃຫ້ແນ່ໃຈວ່າບໍ່ມີບັນຫາໃດໆໃນການປ່ອຍຕົວແລະພຽງແຕ່ຫຼັງຈາກນັ້ນ, ຫມັ້ນໃຈໃນຄຸນນະພາບ (ການປ່ອຍອອກມາ), ແຈກຢາຍມັນໃຫ້ກັບຜູ້ໃຊ້ອື່ນໆ.оຜູ້ຊົມໃຫຍ່ກວ່າ.

ເພື່ອສະແດງໃຫ້ເຫັນການເປີດຕົວ canary, ພວກເຮົາຈະສືບຕໍ່ເຮັດວຽກກັບຊຸດຍ່ອຍ buggy у sa-logic.

ບໍ່ໃຫ້ເສຍເວລາໃນເລື່ອງເລັກໆນ້ອຍໆ ແລະສົ່ງຜູ້ໃຊ້ 20% ໄປຫາເວີຊັນທີ່ມີຂໍ້ບົກພ່ອງ (ອັນນີ້ຈະສະແດງເຖິງການເປີດຕົວ canary ຂອງພວກເຮົາ), ແລະ 80% ທີ່ຍັງເຫຼືອແມ່ນໃຫ້ບໍລິການປົກກະຕິ. ເພື່ອເຮັດສິ່ງນີ້, ໃຫ້ໃຊ້ VirtualService ຕໍ່ໄປນີ້ (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 ແມ່ນ​ນ​້​ໍ​າ (weight), ເຊິ່ງກໍານົດອັດຕາສ່ວນຂອງຄໍາຮ້ອງຂໍທີ່ຈະຖືກນໍາໄປຫາຜູ້ຮັບຫຼືຊຸດຍ່ອຍຂອງຜູ້ຮັບ.

ໃຫ້ອັບເດດການຕັ້ງຄ່າ VirtualService ທີ່ຜ່ານມາສໍາລັບ sa-logic ດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... ແລະ​ພວກ​ເຮົາ​ຈະ​ເຫັນ​ໃນ​ທັນ​ທີ​ວ່າ​ບາງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ນໍາ​ໄປ​ສູ່​ຄວາມ​ລົ້ມ​ເຫຼວ​:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices ເປີດໃຊ້ canary rollouts: ໃນກໍລະນີນີ້, ພວກເຮົາໄດ້ຮັດແຄບຜົນກະທົບທີ່ອາດເກີດຂື້ນຂອງບັນຫາກັບ 20% ຂອງພື້ນຖານຜູ້ໃຊ້. ອັດສະຈັນ! ໃນປັດຈຸບັນ, ໃນທຸກໆກໍລະນີໃນເວລາທີ່ພວກເຮົາບໍ່ແນ່ໃຈວ່າລະຫັດຂອງພວກເຮົາ (ໃນຄໍາສັບຕ່າງໆອື່ນໆ - ສະເຫມີ ...), ພວກເຮົາສາມາດນໍາໃຊ້ mirroring ແລະ canary rollouts.

ໝົດເວລາ ແລະພະຍາຍາມໃໝ່

ແຕ່ຂໍ້ບົກພ່ອງບໍ່ສະເຫມີໄປສິ້ນສຸດໃນລະຫັດ. ໃນບັນຊີລາຍຊື່ຈາກ "8 ຄວາມເຂົ້າໃຈຜິດກ່ຽວກັບຄອມພິວເຕີ້ແຈກຢາຍ"ໃນສະຖານທີ່ທໍາອິດແມ່ນຄວາມເຊື່ອທີ່ຜິດພາດວ່າ "ເຄືອຂ່າຍແມ່ນເຊື່ອຖືໄດ້." ໃນຄວາມເປັນຈິງ, ເຄືອຂ່າຍ ບໍ່ ເຊື່ອຖືໄດ້, ແລະດ້ວຍເຫດຜົນນີ້, ພວກເຮົາຕ້ອງການເວລາໝົດເວລາ (ໝົດເວລາ) ແລະພະຍາຍາມອີກຄັ້ງ (ພະຍາຍາມ).

ສໍາ​ລັບ​ການ​ສາ​ທິດ​ພວກ​ເຮົາ​ຈະ​ສືບ​ຕໍ່​ນໍາ​ໃຊ້​ສະ​ບັບ​ບັນ​ຫາ​ດຽວ​ກັນ​ sa-logic (buggy), ແລະພວກເຮົາຈະຈໍາລອງຄວາມບໍ່ຫນ້າເຊື່ອຖືຂອງເຄືອຂ່າຍທີ່ມີຄວາມລົ້ມເຫຼວແບບສຸ່ມ.

ໃຫ້ການບໍລິການຂອງພວກເຮົາກັບແມງໄມ້ມີໂອກາດ 1/3 ໃຊ້ເວລາດົນເກີນໄປທີ່ຈະຕອບສະຫນອງ, 1/3 ໂອກາດທີ່ຈະສິ້ນສຸດດ້ວຍຄວາມຜິດພາດຂອງເຄື່ອງແມ່ຂ່າຍພາຍໃນ, ແລະໂອກາດ 1/3 ຂອງການກັບຄືນຫນ້າຢ່າງສໍາເລັດຜົນ.

ເພື່ອຫຼຸດຜ່ອນຜົນກະທົບຂອງບັນຫາດັ່ງກ່າວແລະເຮັດໃຫ້ຊີວິດດີຂຶ້ນສໍາລັບຜູ້ໃຊ້, ພວກເຮົາສາມາດ:

1. ເພີ່ມການໝົດເວລາຖ້າການບໍລິການໃຊ້ເວລາດົນກວ່າ 8 ວິນາທີເພື່ອຕອບສະໜອງ,
2. ລອງອີກຄັ້ງຖ້າການຮ້ອງຂໍລົ້ມເຫລວ.

ສໍາລັບການປະຕິບັດ, ພວກເຮົາຈະນໍາໃຊ້ຄໍານິຍາມຊັບພະຍາກອນຕໍ່ໄປນີ້ (sa-logic-retries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. ເວລາຫມົດເວລາສໍາລັບການຮ້ອງຂໍແມ່ນຖືກກໍານົດເປັນ 8 ວິນາທີ;
2. ການຮ້ອງຂໍແມ່ນ retried 3 ເທື່ອ;
3. ແລະຄວາມພະຍາຍາມແຕ່ລະຄົນແມ່ນຖືວ່າບໍ່ສໍາເລັດຖ້າເວລາຕອບສະຫນອງເກີນ 3 ວິນາທີ.

ນີ້ແມ່ນການເພີ່ມປະສິດທິພາບເພາະວ່າຜູ້ໃຊ້ຈະບໍ່ຈໍາເປັນຕ້ອງລໍຖ້າຫຼາຍກວ່າ 8 ວິນາທີແລະພວກເຮົາຈະພະຍາຍາມໃຫມ່ສາມຄັ້ງເພື່ອໃຫ້ມີການຕອບສະຫນອງໃນກໍລະນີຂອງຄວາມລົ້ມເຫລວ, ເພີ່ມໂອກາດຂອງການຕອບສະຫນອງທີ່ປະສົບຜົນສໍາເລັດ.

ນຳໃຊ້ການຕັ້ງຄ່າທີ່ອັບເດດແລ້ວດ້ວຍຄຳສັ່ງຕໍ່ໄປນີ້:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

ແລະກວດເບິ່ງໃນກາຟ Grafana ວ່າຈໍານວນຄໍາຕອບທີ່ປະສົບຜົນສໍາເລັດໄດ້ເພີ່ມຂຶ້ນຂ້າງເທິງ:

ການປັບປຸງສະຖິຕິການຕອບໂຕ້ທີ່ປະສົບຜົນສໍາເລັດຫຼັງຈາກເພີ່ມການຫມົດເວລາແລະການພະຍາຍາມໃຫມ່

ກ່ອນທີ່ຈະກ້າວໄປສູ່ພາກຕໍ່ໄປ (ຫຼືແທນທີ່ຈະ, ໃນສ່ວນຕໍ່ໄປຂອງບົດຄວາມ, ເພາະວ່າໃນນີ້ຈະບໍ່ມີການທົດລອງປະຕິບັດຫຼາຍ - ປະມານ. transl.), ລຶບ sa-logic-buggy ແລະ VirtualService ໂດຍການແລ່ນຄຳສັ່ງຕໍ່ໄປນີ້:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

ຊຸດຕົວຕັດວົງຈອນ ແລະ ຮູບແບບ Bulkhead

ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບສອງຮູບແບບທີ່ສໍາຄັນໃນສະຖາປັດຕະຍະກໍາຈຸລະພາກທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດບັນລຸການຟື້ນຕົວດ້ວຍຕົນເອງ (ການ​ປິ່ນ​ປົວ​ດ້ວຍ​ຕົນ​ເອງ​) ການບໍລິການ.

Circuit Breaker ("ເຄື່ອງຕັດວົງຈອນ") ຖືກນໍາໃຊ້ເພື່ອຢຸດການຮ້ອງຂໍທີ່ເຂົ້າມາໃນຕົວຢ່າງຂອງການບໍລິການທີ່ຖືວ່າບໍ່ດີແລະຟື້ນຟູມັນໃນຂະນະທີ່ຄໍາຮ້ອງຂໍຂອງລູກຄ້າຖືກໂອນໄປຫາຕົວຢ່າງທີ່ມີສຸຂະພາບດີຂອງການບໍລິການນັ້ນ (ເຊິ່ງເພີ່ມອັດຕາສ່ວນຂອງການຕອບສະຫນອງທີ່ປະສົບຜົນສໍາເລັດ). (ຫມາຍເຫດ: ລາຍລະອຽດເພີ່ມເຕີມຂອງຮູບແບບສາມາດພົບໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ, ທີ່ນີ້.)

Bulkhead ("ພາ​ທິ​ຊັນ​"​) isolates ຄວາມລົ້ມເຫຼວຂອງການບໍລິການຈາກຜົນກະທົບຕໍ່ລະບົບທັງຫມົດ. ຕົວຢ່າງເຊັ່ນ, ການບໍລິການ B ຖືກທໍາລາຍແລະການບໍລິການອື່ນ (ລູກຄ້າຂອງບໍລິການ B) ເຮັດຄໍາຮ້ອງຂໍໃຫ້ກັບບໍລິການ B, ເຊິ່ງເຮັດໃຫ້ມັນຫມົດໄປໃນກຸ່ມກະທູ້ຂອງມັນແລະບໍ່ສາມາດໃຫ້ບໍລິການຄໍາຮ້ອງຂໍອື່ນໄດ້ (ເຖິງແມ່ນວ່າພວກເຂົາບໍ່ໄດ້ມາຈາກບໍລິການ B). (ຫມາຍເຫດ: ລາຍລະອຽດເພີ່ມເຕີມຂອງຮູບແບບສາມາດພົບໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ, ທີ່ນີ້.)

ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ຍົກ​ເວັ້ນ​ລາຍ​ລະ​ອຽດ​ການ​ປະ​ຕິ​ບັດ​ຂອງ​ຮູບ​ແບບ​ເຫຼົ່າ​ນີ້​ເພາະ​ວ່າ​ພວກ​ເຂົາ​ເຈົ້າ​ແມ່ນ​ງ່າຍ​ທີ່​ຈະ​ຊອກ​ຫາ​ໃນ​ ເອກະສານທາງການ, ແລະຂ້ອຍກໍ່ຕ້ອງການສະແດງໃຫ້ເຫັນການຢືນຢັນແລະການອະນຸຍາດ, ເຊິ່ງຈະຖືກປຶກສາຫາລືໃນສ່ວນຕໍ່ໄປຂອງບົດຄວາມ.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• "ກັບຄືນໄປບ່ອນບໍລິການຈຸລະພາກກັບ Istio": ພາກ​ທີ 1 (ການ​ນໍາ​ສະ​ເຫນີ​ກ່ຽວ​ກັບ​ລັກ​ສະ​ນະ​ຕົ້ນ​ຕໍ​), ພາກ​ທີ 3 (ການ​ກວດ​ສອບ​ແລະ​ອະ​ນຸ​ຍາດ​);
• «Conduit - ຕາຫນ່າງການບໍລິການທີ່ມີນ້ໍາຫນັກເບົາສໍາລັບ Kubernetes"
• «ຕາໜ່າງບໍລິການແມ່ນຫຍັງ ແລະເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງການມັນ [ສຳລັບແອັບພລິເຄຊັນຄລາວກັບບໍລິການຈຸລະພາກ]?".

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