ຍຸດທະສາດການນຳໃຊ້ໃນ Kubernetes: ມ້ວນ, ສ້າງໃໝ່, ສີຟ້າ/ສີຂຽວ, Canary, ມືດ (ການທົດສອບ A/B)

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

ແຜນວາດແມ່ນເອົາມາຈາກ ການທົບທວນຄືນອີກ ຍຸດທະສາດການເປີດຕົວທີ່ສ້າງຂຶ້ນໃນ Container Solutions

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

ການນຳໃຊ້ທີ່ສັ້ນກວ່າ ແລະ ເລື້ອຍໆມີຜົນປະໂຫຍດຕໍ່ໄປນີ້:

• ເວລາໃນການຕະຫຼາດແມ່ນຫຼຸດລົງ.
• ຄຸນສົມບັດໃໝ່ເຂົ້າເຖິງຜູ້ໃຊ້ໄດ້ໄວຂຶ້ນ.
• ຄວາມຄິດເຫັນຂອງຜູ້ໃຊ້ເຂົ້າເຖິງທີມງານພັດທະນາໄວຂຶ້ນ. ນີ້ຫມາຍຄວາມວ່າທີມງານສາມາດເພີ່ມຄຸນສົມບັດແລະແກ້ໄຂບັນຫາໄດ້ໄວຂຶ້ນ.
• ຈັນຍາບັນຂອງນັກພັດທະນາເພີ່ມຂຶ້ນ: ຄຸນສົມບັດເພີ່ມເຕີມໃນການພັດທະນາແມ່ນມີຄວາມມ່ວນຫຼາຍທີ່ຈະເຮັດວຽກຮ່ວມກັບ.

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

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

ຍຸດທະສາດການຈັດຕັ້ງປະຕິບັດ

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

Rolling (ຄ່ອຍໆ, "rolling" deployment)

ນີ້ແມ່ນຍຸດທະສາດການນຳໃຊ້ມາດຕະຖານໃນ Kubernetes. ມັນເທື່ອລະກ້າວ, ຫນຶ່ງເທື່ອລະກ້າວ, ແທນທີ່ຝັກດ້ວຍຄໍາຮ້ອງສະຫມັກຮຸ່ນເກົ່າດ້ວຍຝັກທີ່ມີຮຸ່ນໃຫມ່ - ໂດຍບໍ່ມີການຢຸດຊົ່ວຄາວຂອງກຸ່ມ.

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

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

ຕົວກໍານົດການອັບເດດ rollover ສາມາດຖືກກໍານົດໄວ້ໃນໄຟລ໌ manifest:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

ສ້າງໃໝ່

ໃນການນຳໃຊ້ແບບງ່າຍດາຍທີ່ສຸດນີ້, ຝັກເກົ່າຖືກຂ້າທັງໝົດໃນຄັ້ງດຽວ ແລະ ແທນທີ່ດ້ວຍອັນໃໝ່:

Manifest ທີ່ສອດຄ້ອງກັນມີລັກສະນະຄ້າຍຄືນີ້:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

ສີຟ້າ/ສີຂຽວ (ການນຳໃຊ້ສີຟ້າ-ສີຂຽວ)

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

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

ຫຼັງ​ຈາກ​ການ​ທົດ​ສອບ​ສະ​ບັບ​ສີ​ຟ້າ (ໃຫມ່​) ແລະ​ການ​ປ່ອຍ​ມັນ​ໄດ້​ຮັບ​ການ​ອະ​ນຸ​ມັດ​, ການ​ບໍ​ລິ​ການ​ສະ​ຫຼັບ​ກັບ​ມັນ​, ແລະ​ສະ​ບັບ​ສີ​ຂຽວ (ເກົ່າ​) folded​:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary (ການ​ນໍາ​ໃຊ້ canary​)

Canary rollouts ແມ່ນຄ້າຍຄືກັນກັບ rollouts ສີຟ້າສີຂຽວ, ແຕ່ມີການຄວບຄຸມແລະການນໍາໃຊ້ທີ່ດີກວ່າ ກ້າວ ໜ້າ ຂັ້ນຕອນໂດຍຂັ້ນຕອນ. ປະເພດນີ້ປະກອບມີຍຸດທະສາດທີ່ແຕກຕ່າງກັນ, ລວມທັງການເປີດຕົວ " stealth" ແລະການທົດສອບ A / B.

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

ເຖິງແມ່ນວ່າຍຸດທະສາດນີ້ສາມາດຖືກປະຕິບັດໄດ້ສະເພາະແຕ່ໃຊ້ Kubernetes, ການປ່ຽນຝັກເກົ່າກັບອັນໃຫມ່, ມັນສະດວກກວ່າແລະງ່າຍດາຍກວ່າທີ່ຈະໃຊ້ຕາຫນ່າງບໍລິການເຊັ່ນ Istio.

ຕົວຢ່າງ, ທ່ານອາດຈະມີສອງ manifest ທີ່ແຕກຕ່າງກັນໃນ Git: manifest ປົກກະຕິທີ່ມີ tag 0.1.0 ແລະ canary manifest ກັບ tag 0.2.0. ໂດຍການປ່ຽນແປງນ້ໍາຫນັກໃນ Istio virtual gateway manifest, ທ່ານສາມາດຄວບຄຸມການແຜ່ກະຈາຍຂອງການຈະລາຈອນລະຫວ່າງສອງການນໍາໃຊ້ເຫຼົ່ານີ້:

ສໍາລັບຄໍາແນະນໍາຂັ້ນຕອນໂດຍຂັ້ນຕອນເພື່ອປະຕິບັດການປະຕິບັດ canary ໂດຍໃຊ້ Istio, ເບິ່ງ GitOps Workflows ກັບ Istio. (ຫມາຍ​ເຫດ​. ແປ.: ພວກເຮົາຍັງໄດ້ແປເອກະສານກ່ຽວກັບ canary rollouts ເຂົ້າໄປໃນ Istio ທີ່ນີ້.)

ການນຳໃຊ້ Canary ກັບ Weaveworks Flagger

Weaveworks Flagger ຊ່ວຍໃຫ້ທ່ານສາມາດຈັດການ canary rollouts ໄດ້ຢ່າງງ່າຍດາຍແລະມີປະສິດທິພາບ.

Flagger automates ເຮັດວຽກກັບເຂົາເຈົ້າ. ມັນໃຊ້ Istio ຫຼື AWS App Mesh ເພື່ອປ່ຽນເສັ້ນທາງແລະປ່ຽນການຈະລາຈອນ, ແລະຕົວຊີ້ວັດ Prometheus ເພື່ອວິເຄາະຜົນໄດ້ຮັບ. ນອກຈາກນັ້ນ, ການວິເຄາະການນໍາໃຊ້ canary ສາມາດໄດ້ຮັບການເສີມດ້ວຍ webhooks ເພື່ອດໍາເນີນການທົດສອບການຍອມຮັບ, ການທົດສອບການໂຫຼດ, ແລະປະເພດອື່ນໆຂອງການກວດສອບ.

ອີງຕາມການໃຊ້ງານ Kubernetes ແລະ, ຖ້າຈໍາເປັນ, ການຈັດລຽງຕາມແນວນອນຂອງ pods (HPA), Flagger ຈະສ້າງຊຸດຂອງວັດຖຸ (ການໃຊ້ງານ Kubernetes, ບໍລິການ ClusterIP ແລະ Istio ຫຼື App Mesh virtual services) ເພື່ອວິເຄາະ ແລະປະຕິບັດການນຳໃຊ້ canary:

ການ​ປະ​ຕິ​ບັດ loop ການ​ຄວບ​ຄຸມ​ (ວົງ​ການ​ຄວບ​ຄຸມ​),Flagger ຄ່ອຍໆປ່ຽນການຈະລາຈອນໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງ canary, ໃນຂະນະທີ່ການວັດແທກການປະຕິບັດທີ່ສໍາຄັນເຊັ່ນ: ເປີເຊັນຂອງຄໍາຮ້ອງຂໍ HTTP ທີ່ປະສົບຜົນສໍາເລັດ, ໄລຍະເວລາການຮ້ອງຂໍສະເລ່ຍ, ແລະສຸຂະພາບຂອງຝັກ. ອີງຕາມການວິເຄາະ KPI (ຕົວຊີ້ວັດການປະຕິບັດທີ່ສໍາຄັນ), canary ອາດຈະເຕີບໂຕຫຼືລົ້ມລົງແລະຜົນໄດ້ຮັບຂອງການວິເຄາະໄດ້ຖືກຈັດພີມມາໃນ Slack. ລາຍລະອຽດແລະການສາທິດຂະບວນການນີ້ສາມາດພົບເຫັນຢູ່ໃນເອກະສານ ການຈັດສົ່ງແບບກ້າວຫນ້າສໍາລັບ App Mesh.

ຊ້ໍາ (ເຊື່ອງໄວ້) ຫຼື A/B ນຳໃຊ້

ການປະຕິບັດ stealth ແມ່ນການປ່ຽນແປງອື່ນຂອງຍຸດທະສາດ canary (ຊຶ່ງ, ໂດຍວິທີທາງການ, Flagger ຍັງສາມາດເຮັດວຽກຮ່ວມກັບ). ຄວາມແຕກຕ່າງລະຫວ່າງການຕິດຕັ້ງ stealth ແລະ canary ແມ່ນວ່າການຕິດຕັ້ງ stealth ຈັດການກັບ frontend ແທນທີ່ຈະ backend ຄືກັບ canary deployments.

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

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

ການຕິດຕັ້ງທຸງ ແລະ A/B

ນອກເຫນືອຈາກການກໍານົດເສັ້ນທາງໂດຍອີງໃສ່ນ້ໍາຫນັກ, Flagger ຍັງສາມາດສົ່ງການຈະລາຈອນໄປຫາເຄື່ອງແມ່ຂ່າຍ canary ໂດຍອີງໃສ່ຕົວກໍານົດ HTTP. ໃນການທົດສອບ A/B, ທ່ານສາມາດໃຊ້ສ່ວນຫົວ HTTP ຫຼື cookies ເພື່ອແນໃສ່ກຸ່ມຜູ້ໃຊ້ສະເພາະ. ນີ້ແມ່ນປະສິດທິພາບໂດຍສະເພາະໃນກໍລະນີຂອງຄໍາຮ້ອງສະຫມັກ frontend ທີ່ຕ້ອງການ session binding ກັບເຄື່ອງແມ່ຂ່າຍ (ຄວາມສຳພັນຂອງເຊດຊັນ). ຂໍ້ມູນເພີ່ມເຕີມສາມາດພົບໄດ້ໃນເອກະສານ Flagger.

ຜູ້ຂຽນສະແດງຄວາມກະຕັນຍູ Stefan Prodan, ວິສະວະກອນ Weaveworks (ແລະຜູ້ສ້າງ Flagger), ສໍາລັບຮູບແບບການປະຕິບັດທີ່ຫນ້າປະຫລາດໃຈທັງຫມົດເຫຼົ່ານີ້.

PS ຈາກນັກແປ

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

• «ພາບລວມແລະການປຽບທຽບຕົວຄວບຄຸມ Ingress ສໍາລັບ Kubernetes"
• «werf - ເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes (ພາບລວມແລະບົດລາຍງານວິດີໂອ)"
• «ການກໍ່ສ້າງແລະນໍາໃຊ້ບໍລິການຈຸລະພາກທີ່ຄ້າຍຄືກັນກັບ werf ແລະ GitLab CI"
• «GitOps ແມ່ນຫຍັງ?".

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