שדרוג אשכול Kubernetes ללא השבתה

תהליך השדרוג עבור אשכול Kubernetes שלך

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

פוסט זה הוא חלק מסדרה בת 4 פוסטים:

1. הפוסט הזה.
2. כיבוי נכון של תרמילים באשכול Kubernetes
3. סיום מושהה של פוד כאשר הוא נמחק
4. כיצד להימנע מזמן השבתה באשכול Kubernetes באמצעות PodDisruptionBudgets

(כ. צפו לתרגומים של שאר המאמרים בסדרה בזמן הקרוב)

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

הגדרת הבעיה

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

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

נתחיל עם שני פודים עם Nginx ו-Service שפועלים בשני צמתי האשכול שלנו של Kubernetes.

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

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

אנו זקוקים לדרך להעברה בחן של תרמילים מצמתים ישנים תוך הבטחה שאף אחד מתהליכי העבודה שלנו אינו פועל בזמן שאנו מבצעים שינויים בצומת. או כשאנחנו עושים החלפה מלאה של האשכול, כמו בדוגמה (כלומר, אנחנו מחליפים תמונות VM), אנחנו רוצים להעביר אפליקציות פועלות מצמתים ישנים לחדשים. בשני המקרים, אנו רוצים למנוע מתרמילים חדשים לתזמן על צמתים ישנים, ולאחר מכן לגרש מהם את כל הפודים הפועלים. כדי להשיג מטרות אלו נוכל להשתמש בפקודה kubectl drain.

הפצה מחדש של כל התרמילים מצומת

פעולת הניקוז מאפשרת לך להפיץ מחדש את כל התרמילים מצומת. במהלך ביצוע ניקוז, הצומת מסומן כבלתי ניתן לתזמון (דגל NoSchedule). זה מונע מלהופיע בו תרמילים חדשים. ואז הניקוז מתחיל לגרש תרמילים מהצומת, מכבה את המיכלים שפועלים כעת על הצומת, שולח אות TERM מיכלים בתרמיל.

למרות kubectl drain יעשה עבודה מצוינת בפינוי תרמילים, ישנם שני גורמים נוספים שעלולים לגרום לכשל בפעולת הניקוז:

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

הימנעות מזמן השבתה

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

• סיום חינני
• ווי מחזור חיים
• PodDisruptionBudgets

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

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

תצורה זו היא דוגמה מינימלית Deployment, המנהלת nginx pods באשכול. בנוסף, התצורה מתארת ​​את המשאב Service, שבו ניתן להשתמש כדי לגשת לתרמי nginx באשכול.

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

לגרסה מיושמת ובדוקה במלואה של עדכוני אשכול Kubernetes לאפס זמן השבתה ב-AWS ומעבר לכך, בקר בכתובת Gruntwork.io.

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

• אפס פריסת זמן השבתה ומסדי נתונים
• Kubernetes: מדוע כל כך חשוב להגדיר את ניהול משאבי המערכת?
• Tekton Pipeline - צינורות מקוריים של Kubernetes
• בניית מודולים דינמיים עבור Nginx
• היכרות עם הרשאת Kubernetes של Hashicorp Consult
• למה הובילה ההגירה מ-ClickHouse ללא הרשאה ל-ClickHouse עם הרשאה?

מקור: www.habr.com