שיטות מומלצות לשדרוג אשכולות של Google Distributed Cloud

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

אם יש לכם כמה סביבות כמו test,‏ development ו-production, מומלץ להתחיל עם הסביבה הכי פחות קריטית, כמו test, ולאמת את פונקציית השדרוג. אחרי שמוודאים שהשדרוג בוצע בהצלחה, עוברים לסביבה הבאה. חוזרים על התהליך הזה עד שמשדרגים את סביבות הייצור. הגישה הזו מאפשרת לכם לעבור מנקודה קריטית אחת לשנייה, ולוודא שהשדרוג ועומסי העבודה פועלים בצורה תקינה.

רשימת משימות לשדרוג

מומלץ לפעול לפי כל השיטות המומלצות שמתוארות במאמר הזה. היעזרו ברשימת המשימות הבאה כדי לעקוב אחרי ההתקדמות. כל פריט ברשימה מקושר לקטע במסמך הזה עם מידע נוסף:

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

תכנון השדרוג

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

הערכת משך הזמן הנדרש ותכנון חלון זמן לתחזוקה

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

כדי לחשב אומדן גס לשדרוג, משתמשים בפונקציה 10 minutes * the number of nodes לשדרוג של צומת יחיד בו-זמנית.

לדוגמה, אם יש לכם חמישים צמתים באשכול, זמן השדרוג הכולל יהיה בערך חמש מאות דקות: 10 minutes * 50 nodes = 500 minutes.

בדיקת התאימות של מוצרים אחרים Google Cloud

אם באשכול שלכם פועלים Cloud Service Mesh,‏ סנכרון תצורות או Policy Controller, כדאי לעיין במאמר בנושא תמיכה בגרסאות ושדרוגים ולוודא מהן הגרסאות הנתמכות ב-Google Distributed Cloud לפני השדרוג ואחריו.

בדיקת התאימות מבוססת על אשכול האדמין או המשתמש שבו נפרסו Cloud Service Mesh,‏ סנכרון תצורות או Policy Controller.

בדיקת ניצול המשאבים של האשכול

כדי לוודא שאפשר לפנות את ה-Pods כשמרוקנים את הצומת, ושיש מספיק משאבים באשכול שמשדרגים כדי לנהל את השדרוג, צריך לבדוק את השימוש הנוכחי במשאבים של האשכול. כדי לבדוק את השימוש במשאבים באשכול, משתמשים בלוחות הבקרה בהתאמה אישית ב-Google Cloud Observability.

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

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

משאבי מישור הבקרה של אשכול אדמין

כל הבקרים והמשימות של השדרוג פועלים בצמתים של מישור הבקרה של אשכול האדמין. כדאי לבדוק את צריכת המשאבים של הצמתים האלה במישור הבקרה כדי לראות אילו משאבי מחשוב זמינים. תהליך השדרוג בדרך כלל דורש 1,000 מילי-ליבות של CPU‏ (1,000 mCPU) ו-2 עד 3 גיגה-בייט של זיכרון RAM לכל קבוצה של בקרי מחזור חיים. שימו לב שיחידת ה-CPU‏ 'mCPU' מייצגת אלפית של ליבה, ולכן 1,000 מילי-ליבות שווה לליבה אחת בכל צומת עבור כל קבוצה של בקרי מחזור חיים. כדי לצמצם את משאבי המחשוב הנוספים שנדרשים במהלך שדרוג, כדאי לנסות לשמור על אותה גרסה באשכולות המשתמשים.

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

קלאסטר אדמין אשכול משתמש 1 אשכול משתמש 2
1.13.3 1.13.0 1.13.2

סט של בקרי מחזור חיים נפרס בבקר האדמין לכל גרסה שנמצאת בשימוש. בדוגמה הזו יש שלושה סטים של בקרי מחזור חיים: 1.13.3,‏ 1.13.0 ו-1.13.2. כל קבוצה של בקרי מחזור החיים צורכת סך של 1,000 mCPU ו-3 GiB RAM. צריכת המשאבים הכוללת הנוכחית של בקרי מחזור החיים האלה היא 3,000 mCPU ו-9‎ GiB RAM.

אם משדרגים את אשכול המשתמשים 2 ל-1.13.3, יש עכשיו שתי קבוצות של בקרי מחזור חיים: 1.13.3 ו-1.13.0:

קלאסטר אדמין אשכול משתמש 1 אשכול משתמש 2
1.13.3 1.13.0 1.13.3

בקרים של מחזור החיים צורכים עכשיו סך של 2,000 mCPU ו-6‎ GiB של RAM.

אם מקבץ משתמשים 1 משודרג ל-1.13.3, כל הצי פועל עכשיו באותה גרסה: 1.13.3:

קלאסטר אדמין אשכול משתמש 1 אשכול משתמש 2
1.13.3 1.13.3 1.13.3

עכשיו יש רק קבוצה אחת של בקרי מחזור חיים, שצורכים סך של 1,000 mCPU ו-3 GiB של RAM.

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

קלאסטר אדמין אשכול משתמש 1 אשכול משתמש 2
1.14.0 1.13.3 1.13.3

בדוגמה הזו, שוב, בקרי מחזור החיים צורכים סך של 2,000 mCPU ו-6GiB של RAM עד שכל אשכולות המשתמשים משודרגים לאותה גרסה כמו אשכול האדמין.

אם לצמתי מישור הבקרה אין משאבי מחשוב נוספים במהלך השדרוג, יכול להיות שתראו את ה-Pods כמו anthos-cluster-operator,‏ capi-controller-manager,‏ cap-controller-manager או cap-kubeadm-bootstraper במצב Pending. כדי לפתור את הבעיה, צריך לשדרג חלק מאשכולות המשתמשים לאותה גרסה כדי לאחד את הגרסאות ולהקטין את מספר בקרי מחזור החיים שנמצאים בשימוש. אם השדרוג כבר נתקע, אפשר גם להשתמש ב-kubectl edit deployment כדי לערוך את הפריסות שממתינות להפעלה ולהקטין את בקשות ה-CPU וה-RAM כדי שיתאימו למישור הבקרה של אשכול הניהול.

בטבלה הבאה מפורטות הדרישות של משאבי מחשוב לתרחישי שדרוג שונים:

אשכול נדרשים משאבים של אשכול אדמין
שדרוג אשכול משתמשים שדרוג לאותה גרסה של אשכולות אחרים: לא רלוונטי

שדרוג לגרסה שונה של אשכולות אחרים של אדמין או משתמשים: ‫1,000 mCPU ו-3‎ GiB RAM

באשכולות משתמשים באשכול היברידי יש את אותן דרישות משאבים.
שדרוג של אשכול אדמין (עם אשכול משתמשים) ‫1,000 mCPU ו-3 GiB RAM
שדרוג אשכול היברידי (ללא אשכול משתמשים) עלייה של 1,000 mCPU ו-3 GiB RAM. המשאבים מוחזרים אחרי השימוש.
עצמאי עלייה של 200 mCPU ו-1 GiB RAM. המשאבים מוחזרים אחרי השימוש.

גיבוי אשכולות

לפני שמתחילים בשדרוג, מגבים את האשכולות באמצעות הפקודה bmctl backup cluster.

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

איך מוודאים שהאשכולות מוגדרים ופועלים כמו שצריך

כדי לבדוק את תקינות האשכול לפני השדרוג, מריצים את הפקודה bmctl check cluster באשכול. הפקודה מריצה בדיקות מתקדמות, למשל כדי לזהות צמתים שלא הוגדרו בצורה נכונה או שיש בהם יחידות Pod שנמצאות במצב תקוע.

כשמריצים את הפקודה bmctl upgrade cluster כדי לשדרג את האשכולות, מתבצעות כמה בדיקות לפני ההפעלה. אם הבדיקות האלה לא יצליחו, תהליך השדרוג ייעצר. מומלץ לזהות ולתקן את הבעיות האלה באופן יזום באמצעות הפקודה bmctl check cluster, במקום להסתמך על בדיקות לפני הפעלה שנועדו להגן על אשכולות מפני נזק אפשרי.

בדיקת פריסות של עומסי עבודה של משתמשים

יש שני תחומים שצריך להתייחס אליהם כשמדובר בעומסי עבודה של משתמשים: הוצאה משימוש ותאימות ל-API.

הפסקת הפעילות של עומס עבודה

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

כדי למנוע שדרוג תקוע, תהליך ההוצאה משימוש של שדרוג עד לגרסה 1.36 לא מתחשב בתקציבי שיבוש של פודים (PDB). יכול להיות שעומסי העבודה יפעלו במצב פגום, והרפליקה עם הכי פחות נתונים תהיה total replica number - concurrent upgrade number.

תאימות ל-API

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

אם אתם משתמשים ב-Cloud Service Mesh, ב-סנכרון תצורות או ב-Policy Controller, כדאי לבדוק אם הגרסה המותקנת תואמת לגרסה החדשה של Google Distributed Cloud. מידע על תאימות גרסאות זמין במאמר תמיכה בגרסאות ובשדרוגים.

בדיקת השימוש ב-Webhooks

בודקים אם יש ב-cluster ווּבְּהוּקים, במיוחד משאבי Pod למטרות ביקורת כמו Policy Controller. תהליך הניקוי במהלך שדרוג האשכול עלול לשבש את שירות ה-webhook של Policy Controller, ולגרום לשדרוג להיתקע או להימשך זמן רב. מומלץ להשבית זמנית את ה-webhook האלה או להשתמש בפריסה עם זמינות גבוהה (HA).

בדיקת השימוש בתכונות בגרסת טרום-השקה (Preview)

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

מידע על שינויים שעלולים לגרום לכשל שקשור לשדרוג מופיע בנתוני הגרסה.

בדיקת הסטטוס של SELinux

אם רוצים להפעיל את SELinux כדי לאבטח את הקונטיינרים, צריך לוודא ש-SELinux מופעל במצב Enforced בכל המכונות המארחות. החל מגרסה 1.9.0 ואילך של Google Distributed Cloud, אפשר להפעיל או להשבית את SELinux לפני או אחרי יצירת אשכול או שדרוג אשכול. ‫SELinux מופעל כברירת מחדל ב-Red Hat Enterprise Linux ‏ (RHEL). אם SELinux מושבת במכונות המארחות שלכם או שאתם לא בטוחים, תוכלו לקרוא את המאמר אבטחת הקונטיינרים באמצעות SELinux כדי להבין איך להפעיל אותו.

‫Google Distributed Cloud תומך ב-SELinux רק במערכות RHEL.

לא לשנות את הגדרת הצפיפות של ה-Pod

‫Google Distributed Cloud תומך בהגדרה של עד 250 פודים לכל צומת עם nodeConfig.PodDensity.MaxPodsPerNode. אפשר להגדיר את צפיפות הפודים רק במהלך יצירת האשכול. אי אפשר לעדכן את הגדרות צפיפות הפודים באשכולות קיימים. אל תנסו לשנות את הגדרת צפיפות ה-pod במהלך שדרוג.

מוודאים שצמתים של מישור הבקרה ואיזון העומסים לא נמצאים במצב תחזוקה

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

המאמרים הבאים