ການນຳໃຊ້ Canary ໃນ Kubernetes #2: ການເປີດຕົວ Argo

ພວກເຮົາຈະໃຊ້ຕົວຄວບຄຸມການຕິດຕັ້ງ k8s-native Argo Rollouts ແລະ GitlabCI ເພື່ອເປີດໃຊ້ Canary deployment ກັບ Kubernetes.

https://unsplash.com/photos/V41PulGL1z0

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

• ການນຳໃຊ້ Canary ໃນ Kubernetes #1: Gitlab CI
• (ຫົວ​ຂໍ້​ນີ້)
• ການນຳໃຊ້ Canary ໂດຍໃຊ້ Istio
• ການນຳໃຊ້ Canary ໂດຍໃຊ້ Jenkins-X Istio Flagger

ການນຳໃຊ້ Canary

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

ການເປີດຕົວ Argo

Argo Rollouts ແມ່ນຕົວຄວບຄຸມການຕິດຕັ້ງພື້ນເມືອງ Kubernetes. ມັນສະຫນອງ CRD (Custom Resource Definition) ສໍາລັບ Kubernetes. ຂໍຂອບໃຈກັບມັນ, ພວກເຮົາສາມາດນໍາໃຊ້ຫນ່ວຍງານໃຫມ່: Rollout, ເຊິ່ງຈັດການການໃຊ້ສີຟ້າ-ສີຂຽວ ແລະ canary ທີ່ມີທາງເລືອກໃນການຕັ້ງຄ່າຕ່າງໆ.

ຕົວຄວບຄຸມ Argo Rollouts ທີ່ໃຊ້ໂດຍຊັບພະຍາກອນແບບກຳນົດເອງ Rollout, ອະນຸຍາດໃຫ້ໃຊ້ກົນລະຍຸດເພີ່ມເຕີມເຊັ່ນ: ສີຟ້າ-ສີຂຽວ ແລະ canary ສໍາລັບ Kubernetes. ຊັບພະຍາກອນ Rollout ສະຫນອງຫນ້າທີ່ທຽບເທົ່າ Deployment, ພຽງແຕ່ມີຍຸດທະສາດການນໍາໃຊ້ເພີ່ມເຕີມ.
ຊັບພະຍາກອນ Deployments ມີ​ສອງ​ຍຸດ​ທະ​ສາດ​ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​: RollingUpdate и Recreate. ເຖິງແມ່ນວ່າກົນລະຍຸດເຫຼົ່ານີ້ແມ່ນເຫມາະສົມສໍາລັບກໍລະນີສ່ວນໃຫຍ່, ສໍາລັບການນໍາໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍໃນຂະຫນາດໃຫຍ່ຫຼາຍ, ຍຸດທະສາດເພີ່ມເຕີມແມ່ນຖືກນໍາໃຊ້, ເຊັ່ນ: ສີຂຽວສີຟ້າຫຼື canary, ທີ່ບໍ່ມີຢູ່ໃນຕົວຄວບຄຸມການປັບໃຊ້. ເພື່ອໃຊ້ຍຸດທະສາດເຫຼົ່ານີ້ໃນ Kubernetes, ຜູ້ໃຊ້ຕ້ອງຂຽນສະຄຣິບຢູ່ເທິງສຸດຂອງການນໍາໃຊ້ຂອງພວກເຂົາ. Argo Rollouts Controller ເປີດເຜີຍຍຸດທະສາດເຫຼົ່ານີ້ເປັນພາລາມິເຕີທີ່ງ່າຍດາຍ, ປະກາດ, ກໍານົດໄດ້.
https://argoproj.github.io/argo-rollouts

ຍັງມີ Argo CI, ເຊິ່ງສະຫນອງການໂຕ້ຕອບເວັບໄຊຕ໌ທີ່ສະດວກສໍາລັບການນໍາໃຊ້ກັບ Rollouts, ພວກເຮົາຈະພິຈາລະນາໃນບົດຄວາມຕໍ່ໄປ.

ການຕິດຕັ້ງ Argo Rollouts

ດ້ານເຊີບເວີ

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

ໃນ turnip ໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາ (ເບິ່ງຂ້າງລຸ່ມນີ້) ພວກເຮົາໄດ້ເພີ່ມ install.yaml ເປັນ i/k8s/argo-rollouts/install.yaml ແລ້ວ. ວິທີນີ້ GitlabCI ຈະຕິດຕັ້ງມັນເຂົ້າໄປໃນກຸ່ມ.

ດ້ານລູກຄ້າ (ປລັກອິນ kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

ຄໍາຮ້ອງສະຫມັກຕົວຢ່າງ

ມັນເປັນການປະຕິບັດທີ່ດີທີ່ຈະມີ repositories ແຍກຕ່າງຫາກສໍາລັບລະຫັດຄໍາຮ້ອງສະຫມັກແລະໂຄງສ້າງພື້ນຖານ.

Repository ສໍາລັບຄໍາຮ້ອງສະຫມັກ

Kim Wuestkamp/k8s-deployment-example-app

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

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

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

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

ໃນບ່ອນເກັບມ້ຽນນີ້ພວກເຮົາຈະໃຊ້ GitlabCI ສໍາລັບການນໍາໃຊ້ກັບ Kubernetes, .gitlab-ci.yml ມີລັກສະນະນີ້:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy 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).

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

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

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

ແລະ rollout.yaml​:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout ເຮັດວຽກຄືກັນກັບ Deployment. ຖ້າພວກເຮົາບໍ່ໄດ້ກໍານົດຍຸດທະສາດການປັບປຸງ (ເຊັ່ນ canary ທີ່ນີ້) ມັນຈະປະຕິບັດຄືກັບການເລີ່ມຕົ້ນການເລື່ອນການປັບປຸງ.

ພວກເຮົາກໍານົດສອງຂັ້ນຕອນໃນ yaml ສໍາລັບການນໍາໃຊ້ canary:

1. 10% ຂອງ​ການ​ຈະ​ລາ​ຈອນ Canary (ລໍ​ຖ້າ​ສໍາ​ລັບ​ຄູ່​ມື OK​)
2. 50% ການຈະລາຈອນໄປ canary (ລໍຖ້າ 2 ນາທີຫຼັງຈາກນັ້ນສືບຕໍ່ 100%)

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

ຫຼັງ​ຈາກ​ການ​ນໍາ​ໃຊ້​ໃນ​ເບື້ອງ​ຕົ້ນ​, ຊັບ​ພະ​ຍາ​ກອນ​ຂອງ​ພວກ​ເຮົາ​ຈະ​ມີ​ລັກ​ສະ​ນະ​ດັ່ງ​ນີ້​:

ແລະພວກເຮົາໄດ້ຮັບການຕອບຮັບພຽງແຕ່ຈາກສະບັບທໍາອິດຂອງຄໍາຮ້ອງສະຫມັກ:

ປະຕິບັດການສົ່ງ Canary

ຂັ້ນຕອນທີ 1: 10% ການຈະລາຈອນ

ເພື່ອເລີ່ມຕົ້ນການນຳໃຊ້ canary, ພວກເຮົາພຽງແຕ່ຕ້ອງການປ່ຽນເວີຊັນຮູບພາບດັ່ງທີ່ພວກເຮົາມັກເຮັດກັບການນຳໃຊ້:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

ແລະພວກເຮົາຊຸກຍູ້ການປ່ຽນແປງ, ດັ່ງນັ້ນ Gitlab CI ປະຕິບັດແລະພວກເຮົາເຫັນການປ່ຽນແປງ:

ດຽວນີ້ຖ້າພວກເຮົາເຂົ້າເຖິງການບໍລິການ:

ຍິ່ງໃຫຍ່! ພວກເຮົາຢູ່ໃນກາງຂອງການປະຕິບັດ canary ຂອງພວກເຮົາ. ພວກເຮົາສາມາດເບິ່ງຄວາມຄືບຫນ້າໂດຍການແລ່ນ:

kubectl argo rollouts get rollout rollout-canary

ຂັ້ນຕອນທີ 2: 50% ການຈະລາຈອນ:

ຕອນນີ້ໃຫ້ເຮົາກ້າວໄປສູ່ຂັ້ນຕອນຕໍ່ໄປ: ການປ່ຽນເສັ້ນທາງ 50% ຂອງການຈະລາຈອນ. ພວກເຮົາໄດ້ຕັ້ງຄ່າຂັ້ນຕອນນີ້ໃຫ້ດໍາເນີນການດ້ວຍຕົນເອງ:

kubectl argo rollouts promote rollout-canary # continue to step 2

ແລະຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໄດ້ກັບຄືນ 50% ຂອງການຕອບສະຫນອງຈາກສະບັບໃຫມ່:

ແລະການທົບທວນຄືນການເປີດຕົວ:

ອັດສະຈັນ.

ຂັ້ນຕອນທີ 3: 100% ການຈະລາຈອນ:

ພວກ​ເຮົາ​ຕັ້ງ​ມັນ​ຂຶ້ນ​ເພື່ອ​ວ່າ​ຫຼັງ​ຈາກ 2 ນາ​ທີ​, ຂັ້ນ​ຕອນ 50% ຈະ​ສິ້ນ​ສຸດ​ລົງ​ອັດ​ຕະ​ໂນ​ມັດ​ແລະ​ຂັ້ນ​ຕອນ 100​% ຈະ​ເລີ່ມ​ຕົ້ນ​:

ແລະ​ຜົນ​ຜະ​ລິດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​:

ແລະການທົບທວນຄືນການເປີດຕົວ:

ການນຳໃຊ້ Canary ສຳເລັດແລ້ວ.

ຕົວຢ່າງເພີ່ມເຕີມກັບ Argo Rollouts

ມີຕົວຢ່າງເພີ່ມເຕີມຢູ່ທີ່ນີ້, ເຊັ່ນ: ວິທີການຕັ້ງຕົວຢ່າງສະພາບແວດລ້ອມແລະການປຽບທຽບໂດຍອີງໃສ່ canary:

https://github.com/argoproj/argo-rollouts/tree/master/examples

ວິດີໂອກ່ຽວກັບ Argo Rollouts ແລະ Argo CI

ຂ້ອຍຂໍແນະນໍາວິດີໂອນີ້ແທ້ໆ, ມັນສະແດງໃຫ້ເຫັນວ່າ Argo Rollouts ແລະ Argo CI ເຮັດວຽກຮ່ວມກັນແນວໃດ:

ຜົນໄດ້ຮັບ

ຂ້າພະເຈົ້າກໍ່ມັກແນວຄວາມຄິດຂອງການນໍາໃຊ້ CRDs ທີ່ຈັດການການສ້າງປະເພດຂອງການນໍາໃຊ້ເພີ່ມເຕີມຫຼື replicasets, redirect traffic, ແລະອື່ນໆ. ການ​ເຮັດ​ວຽກ​ກັບ​ເຂົາ​ເຈົ້າ​ເປັນ​ໄປ​ໄດ້​ກ້ຽງ​. ຕໍ່ໄປຂ້າພະເຈົ້າຢາກຈະທົດສອບການເຊື່ອມໂຍງກັບ Argo CI.

ຢ່າງໃດກໍຕາມ, ເບິ່ງຄືວ່າມີການລວມຕົວໃຫຍ່ຂອງ Argo CI ແລະ Flux CI ຈະມາເຖິງ, ດັ່ງນັ້ນຂ້ອຍອາດຈະລໍຖ້າຈົນກ່ວາການປ່ອຍໃຫມ່ອອກມາ: Argo Flux.

ທ່ານເຄີຍມີປະສົບການກັບ Argo Rollouts ຫຼື Argo CI ບໍ?

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

• ການນຳໃຊ້ສີຟ້າ-ສີຂຽວຂອງແອັບພລິເຄຊັນພາກຮຽນ spring ກັບເຊີບເວີເວັບ Nginx
• Kubernetes: ເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍໃນການຕັ້ງຄ່າການຈັດການຊັບພະຍາກອນຂອງລະບົບ?
• ການແນະນໍາການອະນຸຍາດ Kubernetes ຂອງກົງສຸນ Hashicorp
• ທໍ່ Tekton - Kubernetes-native pipelines
• ການກໍ່ສ້າງໂມດູນແບບເຄື່ອນໄຫວສໍາລັບ Nginx
• Telegram bot ສໍາລັບ Redmine. ວິທີການເຮັດໃຫ້ຊີວິດງ່າຍສໍາລັບຕົວທ່ານເອງແລະຄົນອື່ນ

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