🥇פריסה קנרית ב-Kubernetes #1: Gitlab CI

נשתמש ב-Gitlab CI וב-GitOps ידני כדי ליישם ולהשתמש בפריסה של Canary ב-Kubernetes

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

(המאמר הזה)
פריסה קנרית באמצעות ArgoCI
פריסה קנרית באמצעות Istio
פריסה קנרית באמצעות Jenkins-X Istio Flagger

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

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

פריסה קנרית

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

פריסת Kubernetes (עדכון מתגלגל)

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

GitOps

אנו משתמשים ב-GitOps בדוגמה זו מכיוון שאנו:

שימוש ב-Git כמקור יחיד של אמת
אנו משתמשים ב-Git Operations לבנייה ופריסה (אין צורך בפקודות מלבד תג/מיזוג git)

דוגמה

בוא ניקח תרגול טוב - שיהיה לנו מאגר אחד עבור קוד יישומים ואחד עבור תשתית.

מאגר יישומים

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

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

תשתית ימל

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

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.

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

כדי להתחיל את הפריסה הראשונית, אתה יכול להפעיל את צינור GitlabCI באופן ידני בסניף הראשי. אחרי זה kubectl צריך להוציא את הדברים הבאים:

אנחנו מבינים app פריסה עם 10 העתקים ו-app-canary עם 0. יש גם LoadBalancer שממנו נוכל לגשת דרך curl דרך IP חיצוני:

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

אנו רואים שיישום הבדיקה שלנו מחזיר רק "v1".

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

שלב 1: שחרר גרסה חדשה עבור חלק מהמשתמשים

הגדרנו את מספר העתקים ל-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 שינינו את מספר ההעתקים ל-9:

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

אנו דוחפים את השינויים הללו למאגר שממנו תתחיל הפריסה (דרך GitlabCI) ורואים כתוצאה מכך:

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

המצב הנוכחי של האפליקציה שלנו (GitOps, נלקח מ-Git as a Single Source Of Truth) הוא נוכחות של שתי פריסות עם העתקים פעילים, אחת לכל גרסה.

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

שלב 2: שחרר את הגרסה החדשה לכל המשתמשים

החלטנו שהכל בסדר ועכשיו אנחנו צריכים להפיץ את הגרסה החדשה לכל המשתמשים. לשם כך אנו פשוט מעדכנים deploy.yaml התקנת גרסה חדשה של התמונה ומספר העתקים שווה ל-10. ב deploy-canary.yaml הגדרנו את מספר ההעתקים בחזרה ל-0. לאחר הפריסה, התוצאה תהיה כדלקמן:

הסתכמות

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

דבר נוסף שצריך ליישם הוא נקודת כניסה לבודק (LoadBalancer או דרך Ingress) שדרכה ניתן לגשת רק לגרסה החדשה. ניתן להשתמש בו לגלישה ידנית.

במאמרים עתידיים, נבדוק פתרונות אוטומטיים אחרים שמיישמים את רוב מה שעשינו.

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

מקור: www.habr.com

פריסה קנרית ב-Kubernetes #1: Gitlab CI