ການນຳໃຊ້ Canary ໃນ Kubernetes #1: Gitlab CI

ພວກເຮົາຈະໃຊ້ Gitlab CI ແລະຄູ່ມື GitOps ເພື່ອປະຕິບັດແລະນໍາໃຊ້ Canary deployment ໃນ Kubernetes

ບົດຄວາມຈາກຊຸດນີ້:

• (ຫົວ​ຂໍ້​ນີ້)
• ການນຳໃຊ້ Canary ໂດຍໃຊ້ ArgoCI
• ການນຳໃຊ້ Canary ໂດຍໃຊ້ Istio
• ການນຳໃຊ້ Canary ໂດຍໃຊ້ Jenkins-X Istio Flagger

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

https://www.norberteder.com/canary-deployment/

ການນຳໃຊ້ Canary

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

ການນຳໃຊ້ Kubernetes (ການອັບເດດແບບມ້ວນ)

ຍຸດທະສາດເລີ່ມຕົ້ນສໍາລັບ Kubernetes Deployment ແມ່ນ rolling-update, ບ່ອນທີ່ມີຈໍານວນ pods ທີ່ແນ່ນອນໄດ້ຖືກເປີດຕົວດ້ວຍຮູບພາບຮຸ່ນໃຫມ່. ຖ້າພວກມັນຖືກສ້າງຂື້ນໂດຍບໍ່ມີບັນຫາ, ຝັກທີ່ມີຮູບພາບເກົ່າຖືກຢຸດເຊົາ, ແລະຝັກໃຫມ່ກໍ່ຖືກສ້າງຂື້ນໃນຂະຫນານ.

GitOps

ພວກເຮົາໃຊ້ GitOps ໃນຕົວຢ່າງນີ້ເພາະວ່າພວກເຮົາ:

• ການນໍາໃຊ້ Git ເປັນແຫຼ່ງດຽວຂອງຄວາມຈິງ
• ພວກເຮົາໃຊ້ Git Operations ສໍາລັບການກໍ່ສ້າງແລະການນໍາໃຊ້ (ບໍ່ມີຄໍາສັ່ງອື່ນນອກເຫນືອຈາກ git tag / merge ແມ່ນຈໍາເປັນ)

ຕົວຢ່າງ:

ຂໍໃຫ້ປະຕິບັດການປະຕິບັດທີ່ດີ - ມີບ່ອນເກັບມ້ຽນຫນຶ່ງສໍາລັບລະຫັດຄໍາຮ້ອງສະຫມັກແລະຫນຶ່ງສໍາລັບໂຄງສ້າງພື້ນຖານ.

ຄັງ​ເກັບ​ຂໍ້​ມູນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​

ນີ້ແມ່ນ API Python+Flask ທີ່ງ່າຍດາຍຫຼາຍທີ່ສົ່ງຜົນຕອບແທນເປັນ JSON. ພວກເຮົາຈະສ້າງຊຸດຜ່ານ GitlabCI ແລະຊຸກດັນໃຫ້ຜົນໄດ້ຮັບໄປຫາ Gitlab Registry. ໃນ​ການ​ຈົດ​ທະ​ບຽນ​ພວກ​ເຮົາ​ມີ​ສອງ​ສະ​ບັບ​ອອກ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​:

• wuestkamp/k8s-deployment-example-app:v1
• wuestkamp/k8s-deployment-example-app:v2

ຄວາມແຕກຕ່າງພຽງແຕ່ລະຫວ່າງພວກມັນແມ່ນການປ່ຽນແປງໃນໄຟລ໌ JSON ທີ່ສົ່ງຄືນ. ພວກ​ເຮົາ​ນໍາ​ໃຊ້​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ນີ້​ເພື່ອ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ໄດ້​ຢ່າງ​ງ່າຍ​ດາຍ​ທີ່​ເປັນ​ໄປ​ໄດ້​ວ່າ​ສະ​ບັບ​ທີ່​ພວກ​ເຮົາ​ກໍາ​ລັງ​ສື່​ສານ​ກັບ​.

ຄັງ​ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​

ໃນ turnip ນີ້ພວກເຮົາຈະນໍາໃຊ້ຜ່ານ GitlabCI ກັບ Kubernetes, .gitlab-ci.yml ເບິ່ງຄືວ່ານີ້:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

ເພື່ອແລ່ນມັນດ້ວຍຕົວທ່ານເອງ, ທ່ານຈະຕ້ອງມີກຸ່ມ, ທ່ານສາມາດນໍາໃຊ້ Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

ທ່ານຈໍາເປັນຕ້ອງສ້ອມ https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure ແລະສ້າງຕົວແປ KUBECONFIG ໃນ GitlabCI, ເຊິ່ງຈະປະກອບດ້ວຍ config ສໍາລັບການເຂົ້າເຖິງ kubectl ກັບກຸ່ມຂອງທ່ານ.

ທ່ານສາມາດອ່ານກ່ຽວກັບວິທີການຮັບຂໍ້ມູນປະຈໍາຕົວສໍາລັບກຸ່ມ (Gcloud) right here.

ພື້ນຖານໂຄງລ່າງ Yaml

ໃນຄັງເກັບມ້ຽນໂຄງລ່າງພວກເຮົາມີບໍລິການ:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

ແລະ​ການ​ນໍາ​ໃຊ້​ໃນ​ deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

ແລະ​ການ​ນໍາ​ໃຊ້​ອີກ​ປະ​ການ​ຫນຶ່ງ​ໃນ deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

ໃຫ້ສັງເກດວ່າ app-deploy ບໍ່ມີ replicas ໃດກໍານົດເທື່ອ.

ປະຕິບັດການຈັດຕັ້ງປະຕິບັດເບື້ອງຕົ້ນ

ເພື່ອເລີ່ມຕົ້ນການໃຊ້ງານເບື້ອງຕົ້ນ, ທ່ານສາມາດເລີ່ມຕົ້ນທໍ່ GitlabCI ດ້ວຍຕົນເອງໃນສາຂາແມ່ບົດ. ຫຼັງ​ຈາກ​ນັ້ນ kubectl ຄວນ​ຈະ​ອອກ​ແບບ​ຕໍ່​ໄປ​ນີ້​:

ພວກເຮົາເບິ່ງ app deployment with 10 replicas and app-canary with 0. ນອກຈາກນີ້ຍັງມີ LoadBalancer ທີ່ພວກເຮົາສາມາດເຂົ້າເຖິງໄດ້ໂດຍຜ່ານ. curl ຜ່ານ IP ພາຍນອກ:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

ພວກເຮົາເຫັນວ່າຄໍາຮ້ອງສະຫມັກການທົດສອບຂອງພວກເຮົາພຽງແຕ່ກັບຄືນມາ "v1".

ການ​ປະ​ຕິ​ບັດ​ການ​ນໍາ​ໃຊ້ Canary​

ຂັ້ນຕອນທີ 1: ປ່ອຍເວີຊັນໃຫມ່ສໍາລັບຜູ້ໃຊ້ບາງຄົນ

ພວກເຮົາກໍານົດຈໍານວນ replicas ເປັນ 1 ໃນໄຟລ໌ deploy-canary.yaml ແລະຮູບພາບສະບັບໃຫມ່:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

ໃນໄຟລ໌ deploy.yaml ພວກ​ເຮົາ​ໄດ້​ປ່ຽນ​ແປງ​ຈໍາ​ນວນ​ຂອງ replicas ກັບ 9​:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

ພວກເຮົາຍູ້ການປ່ຽນແປງເຫຼົ່ານີ້ໄປຫາບ່ອນເກັບມ້ຽນທີ່ການຕິດຕັ້ງຈະເລີ່ມຕົ້ນ (ຜ່ານ GitlabCI) ແລະເບິ່ງຜົນໄດ້ຮັບ:

ການບໍລິການຂອງພວກເຮົາຈະຊີ້ໃຫ້ເຫັນທັງສອງການນໍາໃຊ້, ເນື່ອງຈາກວ່າທັງສອງມີຕົວເລືອກ app. ເນື່ອງຈາກການສຸ່ມເລີ່ມຕົ້ນຂອງ Kubernetes, ພວກເຮົາຄວນຈະເຫັນການຕອບໂຕ້ທີ່ແຕກຕ່າງກັນສໍາລັບ ~10% ຂອງຄໍາຮ້ອງຂໍ:

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

~10% ຂອງ​ຜູ້​ໃຊ້​ກາຍ​ເປັນ​ຄວາມ​ຄຸ້ນ​ເຄີຍ​ກັບ​ສະ​ບັບ​ໃຫມ່​ແລະ​ບໍ່​ຕັ້ງ​ໃຈ​ທົດ​ສອບ​ມັນ​. ໃນປັດຈຸບັນແມ່ນເວລາທີ່ຈະກວດສອບຄວາມຜິດພາດໃນບັນທຶກແລະການຕິດຕາມຂໍ້ມູນເພື່ອຊອກຫາບັນຫາ.

ຂັ້ນ​ຕອນ​ທີ 2​: ປ່ອຍ​ສະ​ບັບ​ໃຫມ່​ກັບ​ຜູ້​ໃຊ້​ທັງ​ຫມົດ​

ພວກ​ເຮົາ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ວ່າ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ເປັນ​ໄປ​ດ້ວຍ​ດີ​ແລະ​ໃນ​ປັດ​ຈຸ​ບັນ​ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ອອກ​ສະ​ບັບ​ໃຫມ່​ໃຫ້​ຜູ້​ຊົມ​ໃຊ້​ທັງ​ຫມົດ​. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາພຽງແຕ່ປັບປຸງ deploy.yaml ການຕິດຕັ້ງສະບັບໃຫມ່ຂອງຮູບພາບແລະຈໍານວນຂອງ replicas ເທົ່າກັບ 10. ໃນ deploy-canary.yaml ພວກເຮົາກໍານົດຈໍານວນຂອງ replicas ກັບຄືນໄປບ່ອນ 0. ຫຼັງຈາກ deployment, ຜົນໄດ້ຮັບຈະເປັນດັ່ງຕໍ່ໄປນີ້:

ເພື່ອສະຫຼຸບ

ສຳ ລັບຂ້ອຍ, ການເຮັດວຽກການ ນຳ ໃຊ້ດ້ວຍຕົນເອງດ້ວຍວິທີນີ້ຈະຊ່ວຍໃຫ້ເຂົ້າໃຈວ່າມັນສາມາດຕັ້ງຄ່າໄດ້ງ່າຍໂດຍໃຊ້ k8s. ເນື່ອງຈາກ Kubernetes ອະນຸຍາດໃຫ້ທ່ານອັບເດດທຸກຢ່າງຜ່ານ API, ຂັ້ນຕອນເຫຼົ່ານີ້ສາມາດອັດຕະໂນມັດຜ່ານສະຄຣິບ.

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

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

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

• ການເຄື່ອນຍ້າຍຈາກ ClickHouse ໂດຍບໍ່ມີການອະນຸຍາດໄປຫາ ClickHouse ດ້ວຍການອະນຸຍາດນໍາໄປສູ່ຫຍັງ?
• ການກໍ່ສ້າງໂມດູນແບບເຄື່ອນໄຫວສໍາລັບ Nginx
• ອັບເດດ nxs-build-tools - ຜູ້ຊ່ວຍໃນການສ້າງແພັກເກັດ deb ແລະ rpm
• ການແນະນໍາການອະນຸຍາດ Kubernetes ຂອງກົງສຸນ Hashicorp
• ສິ່ງທີ່ພວກເຮົາຕ້ອງປະເຊີນໃນເວລາທີ່ໃຊ້ Csync2 utility
• Telegram bot ສໍາລັບ Redmine. ວິທີການເຮັດໃຫ້ຊີວິດງ່າຍສໍາລັບຕົວທ່ານເອງແລະຄົນອື່ນ

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