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

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

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

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

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

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

תכנון השדרוג

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

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

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

כדי לחשב הערכה גסה של השדרוג, השתמשו ב-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 millicores של מעבד (‎1,000 mCPU) ו-‎2-3 GiB 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,000mCPU ו-3GiB RAM. צריכת המשאבים הכוללת הנוכחית של בקרי מחזור החיים האלה היא ‎3,000 mCPU ו-‎9 GiB RAM.

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

אשכול אדמין אשכול משתמשים 1 אשכול משתמשים 2
1.13.3 1.13.0 1.13.3

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

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

אשכול אדמין אשכול משתמשים 1 אשכול משתמשים 2
1.13.3 1.13.3 1.13.3

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

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

אשכול אדמין אשכול משתמשים 1 אשכול משתמשים 2
1.14.0 1.13.3 1.13.3

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

אם לצמתים של מישור הבקרה אין משאבי מחשוב נוספים במהלך השדרוג, יכול להיות שפודים כמו 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,000mCPU ו-3GiB RAM. המשאבים מוחזרים אחרי השימוש.
עצמאי ‫200mCPU ו-1GiB RAM. המשאבים מוחזרים אחרי השימוש.

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

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

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

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

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

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

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

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

ניקוז עומסי עבודה

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

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

תאימות ל-API

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

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

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

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

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

תכונות בגרסת 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.

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

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

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

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

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