🥇פריסה קנרית ב-Kubernetes #2: השקות ארגו

נשתמש בבקר הפריסה המקורי של Argo Rollouts וב-GitlabCI כדי להפעיל פריסות קנריות ל-Kubernetes

https://unsplash.com/photos/V41PulGL1z0

מאמרים בסדרה זו

פריסה קנרית ב-Kubernetes #1: Gitlab CI
(המאמר הזה)
פריסה קנרית באמצעות Istio
פריסה קנרית באמצעות Jenkins-X Istio Flagger

פריסה קנרית

אנו מקווים שאתה קורא חלק ראשון, שם הסברנו בקצרה מהן פריסות קנריות. הראינו גם כיצד ליישם את זה באמצעות משאבי Kubernetes סטנדרטיים.

השקות ארגו

Argo Rollouts הוא בקר פריסה מקורי של Kubernetes. הוא מספק CRD (הגדרת משאב מותאם אישית) עבור Kubernetes. הודות לו, אנו יכולים להשתמש בישות חדשה: Rollout, המנהלת פריסות כחול-ירוק וקנריות עם אפשרויות תצורה שונות.

בקר Argo Rollouts בשימוש על ידי משאב מותאם אישית Rollout, מאפשר אסטרטגיות פריסה נוספות כגון כחול-ירוק וקנרי עבור Kubernetes. מַשׁאָב Rollout מספק פונקציונליות שווה ערך Deployment, רק עם אסטרטגיות פריסה נוספות.
משאב Deployments יש שתי אסטרטגיות לפריסה: RollingUpdate и Recreate. למרות שאסטרטגיות אלו מתאימות לרוב המקרים, לפריסה לשרתים בקנה מידה גדול מאוד, נעשה שימוש באסטרטגיות נוספות, כגון כחול-ירוק או קנרי, שאינן זמינות בבקר הפריסה. כדי להשתמש באסטרטגיות אלה ב-Kubernetes, המשתמשים היו צריכים לכתוב סקריפטים על הפריסה שלהם. בקר ה-Argo Rollouts חושף את האסטרטגיות הללו כפרמטרים פשוטים, הצהרתיים הניתנים להגדרה.
https://argoproj.github.io/argo-rollouts

יש גם Argo CI, המספק ממשק אינטרנט נוח לשימוש עם Rollouts, נסתכל על זה במאמר הבא.

התקנת ארגו 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

זהו 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, שיכיל את התצורה לגישה kubectl לאשכול שלך.

כאן אתה יכול לקרוא כיצד לקבל אישורים עבור אשכול (Gcloud).

תשתית ימל

בתוך מאגר התשתיות יש לנו שירות:

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 לפריסה קנרית:

10% מהתנועה לקנרית (המתן לאישור ידני)
50% תנועה לקנרי (המתן 2 דקות ואז המשך ל-100%)

ביצוע פריסה ראשונית

לאחר הפריסה הראשונית, המשאבים שלנו ייראו כך:

ואנו מקבלים תשובה רק מהגרסה הראשונה של האפליקציה:

ביצוע פריסה קנרית

שלב 1: 10% תנועה

כדי להתחיל פריסה קנרית, אנחנו רק צריכים לשנות את גרסת התמונה כפי שאנו עושים בדרך כלל עם פריסות:

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% מתחיל:

ופלט האפליקציה:

וסקירת השקה:

הפריסה הקנרית הושלמה.

דוגמאות נוספות עם השקות ארגו

יש כאן דוגמאות נוספות, כגון כיצד להגדיר תצוגות מקדימות של סביבה והשוואות על סמך קנרית:

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

סרטון על Argo Rollouts ו- Argo CI

אני באמת ממליץ על הסרטון הזה, הוא מראה איך ארגו Rollouts ו- Argo CI עובדים יחד:

סך הכל

אני מאוד אוהב את הרעיון של שימוש ב-CRD שמנהלים את היצירה של סוגים נוספים של פריסות או ערכות משוכפלות, תעבורת הפניה מחדש וכו'. העבודה איתם עוברת חלק. בשלב הבא אני רוצה לבדוק את האינטגרציה עם Argo CI.

עם זאת, נראה שיש מיזוג גדול של Argo CI ו-Flux CI, אז אני יכול לחכות עד שהמהדורה החדשה תצא: ארגו Flux.

האם היה לך ניסיון עם Argo Rollouts או Argo CI?

קרא גם מאמרים אחרים בבלוג שלנו:

מקור: www.habr.com

פריסה קנרית ב-Kubernetes #2: השקות ארגו