🥇การติดตั้ง Canary ใน Kubernetes #2: Argo Rollouts

เราจะใช้ตัวควบคุมการปรับใช้ Argo Rollouts แบบเนทีฟ k8s และ GitlabCI เพื่อเรียกใช้การปรับใช้ Canary ไปยัง Kubernetes

https://unsplash.com/photos/V41PulGL1z0

บทความในชุดนี้

การปรับใช้ Canary ใน Kubernetes #1: Gitlab CI
(บทความนี้)
การปรับใช้ Canary โดยใช้ Istio
การปรับใช้ Canary โดยใช้ Jenkins-X Istio Flagger

การปรับใช้นกขมิ้น

เราหวังว่าคุณจะอ่าน ส่วนแรกโดยที่เราอธิบายสั้นๆ ว่า Canary Deployment คืออะไร เรายังแสดงวิธีการนำไปใช้โดยใช้ทรัพยากร Kubernetes มาตรฐานอีกด้วย

การเปิดตัว Argo

Argo Rollouts คือตัวควบคุมการปรับใช้ Kubernetes แบบเนทีฟ โดยมี CRD (ข้อกำหนดทรัพยากรที่กำหนดเอง) สำหรับ Kubernetes ด้วยเหตุนี้ เราจึงสามารถใช้เอนทิตีใหม่ได้: Rolloutซึ่งจัดการการปรับใช้สีน้ำเงินเขียวและคานารีด้วยตัวเลือกการกำหนดค่าที่หลากหลาย

ตัวควบคุม Argo Rollouts ที่ใช้โดยทรัพยากรที่กำหนดเอง Rollout, อนุญาตให้ใช้กลยุทธ์การปรับใช้เพิ่มเติม เช่น สีฟ้า-เขียว และ canary สำหรับ Kubernetes ทรัพยากร Rollout มีฟังก์ชันการทำงานที่เทียบเท่า Deploymentโดยมีกลยุทธ์การใช้งานเพิ่มเติมเท่านั้น
ทรัพยากร Deployments มีสองกลยุทธ์ในการปรับใช้: RollingUpdate и Recreate. แม้ว่ากลยุทธ์เหล่านี้จะเหมาะสำหรับกรณีส่วนใหญ่ แต่สำหรับการปรับใช้กับเซิร์ฟเวอร์ในขนาดใหญ่มาก จะมีการใช้กลยุทธ์เพิ่มเติม เช่น สีน้ำเงินเขียวหรือคานารี ซึ่งไม่มีอยู่ในตัวควบคุมการปรับใช้ หากต้องการใช้กลยุทธ์เหล่านี้ใน 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

ในหัวผักกาดโครงสร้างพื้นฐานของเรา (ดูด้านล่าง) เราได้เพิ่ม install.yaml เป็น i/k8s/argo-rollouts/install.yaml แล้ว วิธีนี้ GitlabCI จะติดตั้งลงในคลัสเตอร์

ฝั่งไคลเอ็นต์ (ปลั๊กอิน kubectl)

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

ตัวอย่างการใช้งาน

แนวปฏิบัติที่ดีที่จะมีที่เก็บแยกต่างหากสำหรับโค้ดแอปพลิเคชันและโครงสร้างพื้นฐาน

พื้นที่เก็บข้อมูลสำหรับแอปพลิเคชัน

Kim Wuestkamp/k8s-deployment-example-app

นี่เป็น Python+Flask API ที่เรียบง่ายมากซึ่งส่งคืนการตอบกลับเป็น JSON เราจะสร้างแพ็คเกจโดยใช้ GitlabCI และผลักผลลัพธ์ไปที่ Gitlab Registry ในรีจิสทรี เรามีเวอร์ชันเผยแพร่ที่แตกต่างกันสองเวอร์ชัน:

wuestkamp/k8s-ปรับใช้-ตัวอย่าง-แอป:v1
wuestkamp/k8s-ปรับใช้-ตัวอย่าง-แอป: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 ซึ่งจะมีการกำหนดค่าสำหรับการเข้าถึง 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:

10% ของการรับส่งข้อมูลไปยังนกขมิ้น (รอการตกลงด้วยตนเอง)
เข้าชม Canary 50% (รอ 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 จึงปรับใช้และเราเห็นการเปลี่ยนแปลง:

ตอนนี้ถ้าเราเข้าถึงบริการ:

ยอดเยี่ยม! เรากำลังอยู่ระหว่างการติดตั้งคานารี เราสามารถเห็นความคืบหน้าได้โดยการรัน:

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

มีตัวอย่างเพิ่มเติมที่นี่ เช่น วิธีการตั้งค่าการแสดงตัวอย่างสภาพแวดล้อมและการเปรียบเทียบตามคานารี:

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

วิดีโอเกี่ยวกับ Argo Rollouts และ Argo CI

ฉันขอแนะนำวิดีโอนี้จริงๆ ซึ่งแสดงให้เห็นว่า Argo Rollouts และ Argo CI ทำงานร่วมกันอย่างไร:

ทั้งหมด

ฉันชอบแนวคิดในการใช้ CRD ที่จัดการการสร้างประเภทเพิ่มเติมของการปรับใช้หรือชุดการจำลอง การรับส่งข้อมูลการเปลี่ยนเส้นทาง ฯลฯ การทำงานร่วมกับพวกเขาเป็นไปอย่างราบรื่น ต่อไป ฉันต้องการทดสอบการผสานรวมกับ Argo CI

อย่างไรก็ตาม ดูเหมือนว่าจะมีการควบรวมกิจการครั้งใหญ่ของ Argo CI และ Flux CI ดังนั้นฉันจึงอาจรอจนกว่ารุ่นใหม่จะออก: อาร์โก้ ฟลักซ์.

คุณเคยมีประสบการณ์กับ Argo Rollouts หรือ Argo CI หรือไม่

อ่านบทความอื่น ๆ ในบล็อกของเราด้วย:

ที่มา: will.com

การปรับใช้ Canary ใน Kubernetes #2: การเปิดตัว Argo