העברת צמתים למצב תחזוקה

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

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

איך זה עובד

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

במקום להשתמש במצב תחזוקה, אפשר להשתמש באופן ידני בפקודות Kubernetes כמו kubectl cordon ו-kubectl drain בצומת ספציפי.

כשמשתמשים בתהליך של מצב תחזוקה, Google Distributed Cloud מבצע את הפעולות הבאות:

1.29

• ‫Google Distributed Cloud מוסיף את הbaremetal.cluster.gke.io/maintenance:NoSchedule taint לצמתים שצוינו כדי למנוע תזמון של פודים חדשים בצומת.

• ב-Google Distributed Cloud, המערכת משתמשת ב-Eviction API כדי להוציא כל Pod. בשיטה הזו של ניקוי הצמתים מתחשבים ב-PodDisruptionBudgets (תקציבים להפרעות ב-Pod). אתם יכולים להגדיר PDBs כדי להגן על עומסי העבודה על ידי ציון רמת הפרעה נסבלת עבור קבוצה של Pod באמצעות השדות minAvailable ו-maxUnavailable. ניקוי הצמתים בדרך הזו מספק הגנה טובה יותר מפני הפרעות בעומסי העבודה. ניקוי צמתים שמבוסס על הוצאה זמין כ-GA לגרסה 1.29.

• מוגדר פסק זמן של 20 דקות כדי לוודא שהצמתים לא ייתקעו בהמתנה להפסקת הפעולה של הפודים. יכול להיות שפודים לא ייעצרו אם הם מוגדרים לסבול את כל הכתמים או אם יש להם finalizers. מערכת Google Distributed Cloud מנסה לעצור את כל הפודים, אבל אם חלף הזמן הקצוב לתפוגה, הצומת עובר למצב תחזוקה. ההגדרה הזו מונעת מ-pods פועלים לחסום שדרוגים.

‫1.28 ומטה

• ‫Google Distributed Cloud מוסיף את הbaremetal.cluster.gke.io/maintenance:NoSchedule taint לצמתים שצוינו כדי למנוע תזמון של פודים חדשים בצומת.

• ‫Google Distributed Cloud מוסיף את התג baremetal.cluster.gke.io/maintenance:NoExecute. בתגובה לתג NoExecute, ‏ Google Distributed Cloud kube-scheduler מפסיק את הפודים ומרוקן את הצומת. בשיטה הזו של ריקון צמתים לא מתבצעת התחשבות ב-PDB.

• מוגדר פסק זמן של 20 דקות כדי לוודא שהצמתים לא ייתקעו בהמתנה להפסקת הפעולה של הפודים. יכול להיות שפודים לא ייעצרו אם הם מוגדרים לסבול את כל הכתמים או אם יש להם finalizers. מערכת Google Distributed Cloud מנסה לעצור את כל הפודים, אבל אם חלף הזמן הקצוב לתפוגה, הצומת עובר למצב תחזוקה. ההגדרה הזו מונעת מ-pods פועלים לחסום שדרוגים.

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

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

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

• ‫1.29: GA
• ‫1.28: לא זמין
• ‫1.16: לא זמין

סדר ניקוז

לפני גרסה 1.29, תהליך ניקוי הצמתים שמבוסס על כתמי צבע שמתבצע ב-Google Distributed Cloud kube-scheduler לא משתמש באלגוריתם מסוים כדי לנקות את הפודים מצומת. בתהליך ניקוי הצמתים שמבוסס על פינוי, הפודים מפונים בסדר מסוים לפי העדיפות. העדיפות לפינוי משויכת לקריטריונים ספציפיים של פודים, כמו שמוצג בטבלה הבאה:

סדר ניקוז	קריטריונים ל-Podcast (חייבים להתאים לכולם) וגם
1	מערכת Kubernetes מוציאה משימוש (evict) פודים שעומדים בקריטריונים הבאים: תרמילי שינה ללא spec.prorityClassName ‫Pods שלא תואמים לשם של אף ממשק ידוע לאחסון קונטיינרים (CSI) ‫Pods שלא שייכים ל-DaemonSet
2	מערכת Kubernetes מוציאה משימוש (evict) פודים שעומדים בקריטריונים הבאים: ‫Pods ששייכים ל-DaemonSet ל-Pods אין PriorityClass ‫Pods שלא תואמים לשם של אף ממשק ידוע לאחסון קונטיינרים (CSI)
3	מערכת Kubernetes מוציאה משימוש (evict) פודים שעומדים בקריטריונים הבאים: טבליות עם Spec.ProrityClassName ‫Pods שלא תואמים לשם של אף ממשק ידוע לאחסון קונטיינרים (CSI) צו הפינוי של פודים תואמים מבוסס על PriorityClass.value, מהנמוך לגבוה.
4	מחכים עד ש-CSI ינקה את נקודות הצירוף של PV/PVC אחרי שכל הפודים יפונו. משתמשים בערך Node.Status.VolumesInUse כדי לציין שכל הכרכים נוקו.
5	מערכת Kubernetes מפנה (evicts) את הפודים שעומדים בקריטריונים הבאים: ‫Pods שתואמים לשם ידוע של Container Storage Interface ‏ (CSI) עדיין צריך לרוקן את הפודים האלה, כי kubelet לא מספק תאימות לשדרוג במקום.

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

המועד האחרון להפסקת השימוש בשיטה מבוססת-הסרה

כשמעבירים צמתים למצב תחזוקה, המערכת אוכפת פסק זמן של 20 דקות (1,200 שניות) לניקוי הצמתים. כשפסק הזמן מסתיים, כל ה-Pods שלא תומכים במצב תחזוקה מפונים והצומת מועבר למצב תחזוקה. החל מגרסה 1.16, אפשר להוסיף את ההערה baremetal.cluster.gke.io/maintenance-mode-deadline-seconds למשאב האשכול כדי לשנות את משך פסק הזמן. לדוגמה, כדי לשנות את פסק הזמן ל-10 דקות, מוסיפים את ההערה baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "600" למשאב האשכול.

לפעמים, תהליך הניקוי שמבוסס על פינוי חורג מהמועד האחרון שצוין על ידי maintenance-mode-deadline-seconds. אם תרמילי Pod נתקעים במצב סיום אחרי שהמועד האחרון חלף, אל תשתמשו ב-kubectl עם הדגלים --grace-period=0 --force כדי למחוק אותם בכוח, כי זה עלול לגרום להשחתת נתונים או לבעיות של פיצול מוח באפליקציות עם שמירת מצב. במקום זאת, הפעילו מחדש את הצמתים עם תרמילי Pod תקועים עם שמירת מצב.

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה כדי לקבל מידע נוסף על מקורות תמיכה, כולל:

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

השבתה של ניקוז צמתים מבוסס-הוצאה

התכונה 'הפסקת פעילות של צמתים על סמך פינוי' מופעלת כברירת מחדל באשכולות בגרסה משנית 1.29 ואילך, או באשכולות שמשודרגים לגרסה משנית 1.29 ואילך. אם ניקוי הצמתים שמבוסס על הוצאת פודים גורם לבעיות בשדרוגי האשכול או בתחזוקת האשכול, אפשר לחזור לניקוי הצמתים שמבוסס על כתמי צבע על ידי הוספת ההערה baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: "" למשאב האשכול.

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

העברת צומת למצב תחזוקה

בוחרים את הצמתים שרוצים להעביר למצב תחזוקה על ידי ציון טווחי כתובות IP לצמתים שנבחרו בקטע maintenanceBlocks בקובץ התצורה של האשכול. הצמתים שבוחרים צריכים להיות במצב מוכן ולפעול באשכול.

כדי להעביר צמתים למצב תחזוקה:

1. עורכים את קובץ ההגדרות של האשכול כדי לבחור את הצמתים שרוצים להעביר למצב תחזוקה.

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

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.
   • ‫CLUSTER_NAME: שם האשכול.

2. מוסיפים את הקטע maintenanceBlocks לקובץ ההגדרות של האשכול כדי לציין כתובת IP אחת או טווח כתובות לצמתים שרוצים להעביר למצב תחזוקה.

   בדוגמה הבאה אפשר לראות איך בוחרים כמה צמתים על ידי ציון טווח של כתובות IP:

   metadata:
     name: my-cluster
     namespace: cluster-my-cluster
   spec:
     maintenanceBlocks:
       cidrBlocks:
       - 172.16.128.1-172.16.128.64
   

3. שומרים את ההגדרות המעודכנות של האשכול ומחילים אותן.

   מערכת Google Distributed Cloud מתחילה להעביר את הצמתים למצב תחזוקה.

4. מריצים את הפקודה הבאה כדי לקבל את הסטטוס של הצמתים באשכול:

   kubectl get nodes --kubeconfig=KUBECONFIG

   הפלט אמור להיראות כך:

   NAME                STATUS   ROLES           AGE     VERSION
   user-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
   user-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600
   

   הערה: עדיין אפשר לתזמן את הצמתים, אבל הדחיות מונעות תזמון של Podים (ללא טולרנטיות מתאימה) בצומת.

5. מריצים את הפקודה הבאה כדי לקבל את מספר הצמתים במצב תחזוקה:

   kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG 
   

   התגובה אמורה להיות דומה לדוגמה הבאה:

   NAME   READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
   np1    3       0             0         1                  0
   

   UNDERMAINTENANCE העמודה הזו בדוגמה מראה שצומת אחד נמצא במצב תחזוקה.

   בנוסף, מערכת Google Distributed Cloud מוסיפה את ה-taints הבאים לצמתים כשהם עוברים למצב תחזוקה:

   • baremetal.cluster.gke.io/maintenance:NoExecute
   • baremetal.cluster.gke.io/maintenance:NoSchedule

הסרת צומת ממצב תחזוקה

כדי להסיר צמתים ממצב תחזוקה:

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

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

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול.
   • ‫CLUSTER_NAME: שם האשכול.

2. אפשר לערוך את כתובות ה-IP כדי להסיר צמתים ספציפיים ממצב תחזוקה, או להסיר את הקטע maintenanceBlocks כדי להסיר את כל הצמתים ממצב תחזוקה.

3. שומרים את ההגדרות המעודכנות של האשכול ומחילים אותן.

4. אפשר להשתמש בפקודות kubectl כדי לבדוק את הסטטוס של הצמתים.

כיבוי והפעלה מחדש של אשכול

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

כיבוי אשכול

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

1. בודקים את הסטטוס של כל צמתי האשכול:

   kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
   

   מחליפים את הערך CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של האשכול.

   הפלט אמור להיראות כך:

   NAME        STATUS   ROLES           AGE    VERSION
   control-0   Ready    control-plane   202d   v1.27.4-gke.1600
   control-1   Ready    control-plane   202d   v1.27.4-gke.1600
   control-2   Ready    control-plane   202d   v1.27.4-gke.1600
   worker-0    Ready    worker          202d   v1.27.4-gke.1600
   worker-1    Ready    worker          202d   v1.27.4-gke.1600
   worker-2    Ready    worker          202d   v1.27.4-gke.1600
   worker-3    Ready    worker          202d   v1.27.4-gke.1600
   worker-4    Ready    worker          154d   v1.27.4-gke.1600
   worker-5    Ready    worker          154d   v1.27.4-gke.1600
   worker-6    Ready    worker          154d   v1.27.4-gke.1600
   worker-7    Ready    worker          154d   v1.27.4-gke.1600
   worker-8    Ready    worker          154d   v1.27.4-gke.1600
   worker-9    Ready    worker          154d   v1.27.4-gke.1600
   

   אם הערך של STATUS עבור צומת מסוים הוא לא Ready, מומלץ מאוד לפתור את הבעיה בצומת ולהמשיך רק כשכל הצמתים הם Ready.

2. אם משביתים אשכול משתמשים, צריך לבדוק את הסטטוס של הצמתים באשכול האדמין:

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   מחליפים את ADMIN_KUBECONFIG בנתיב של קובץ ה-kubeconfig של האשכול המנהל.

   השלבים הבאים תלויים באשכול הניהול. אם הערך STATUS של צומת מסוים הוא לא Ready, מומלץ מאוד לפתור את הבעיה בצומת ולהמשיך רק כשכל הצמתים הם Ready.

3. בודקים את תקינות האשכול שרוצים להשבית:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫CLUSTER_NAME: שם האשכול שבודקים.

   • ‫ADMIN_KUBECONFIG: הנתיב של קובץ ה-kubeconfig של האשכול לניהול.

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

4. עבור האשכול שאתם משביתים, מוודאים שכל ה-Pods‏ etcd פועלים:

   kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
       -l component=etcd
   

   מחליפים את הערך CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של האשכול.

   הפלט אמור להיראות כך:

   NAMESPACE     NAME                   READY   STATUS    RESTARTS   AGE
   kube-system   etcd-control-0-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-1-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-2-admin   1/1     Running   0          2d22h
   

   אם הערך של STATUS עבור פוד מסוים הוא לא Running, מומלץ מאוד לפתור את הבעיה בפוד ולהמשיך רק כשכל הפודים הם Running.

5. מבצעים גיבוי כמו שמתואר במאמר גיבוי של אשכול.

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

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

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

7. מעבירים את הצמתים של מישור הבקרה למצב תחזוקה.

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

8. מכבים את צמתי האשכול ברצף הבא:

   1. צומתי עובד
   2. צמתים של מאזן עומסים במישור הבקרה

   3. צמתים של מישור הבקרה, החל מהצמתים העוקבים של etcd ועד לצומת המוביל של etcd

      אם יש לכם אשכול זמינות גבוהה (HA), אתם יכולים למצוא את ה-etcd leader באמצעות SSH כדי להתחבר לכל צומת של מישור הבקרה ולהריץ את הפקודה הבאה etcdctl:

      ETCDCTL_API=3 etcdctl \
          --cacert /etc/kubernetes/pki/etcd/ca.crt \
          --cert /etc/kubernetes/pki/etcd/server.crt \
          --key /etc/kubernetes/pki/etcd/server.key \
          --write-out=table endpoint status
      

      התשובה כוללת עמודה IS LEADER, שמחזירה true אם הצומת הוא ה-etcd leader.

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

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

הפעלה מחדש של האשכול

כדי להפעיל מחדש אשכול שהושבת לחלוטין, פועלים לפי השלבים הבאים.

1. מפעילים את מכונות הצמתים בסדר הפוך לסדר הכיבוי.

2. מסירים את הצמתים של מישור הבקרה ממצב תחזוקה.

   הוראות מפורטות מופיעות במאמר הסרת צומת ממצב תחזוקה.

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

3. הסרת צמתי עובדים ממצב תחזוקה.

4. מריצים בדיקות תקינות של האשכול כדי לוודא שהוא פועל בצורה תקינה:

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

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

מצב חיוב ותחזוקה

החיוב על Google Distributed Cloud מבוסס על מספר המעבדים הווירטואליים (vCPU) שיש לאשכול שלכם עבור צמתים שיכולים להריץ עומסי עבודה. כשמעבירים צומת למצב תחזוקה, נוספים לצומת NoExecute ו-NoSchedule taints, אבל הם לא משביתים את החיוב. אחרי שמכניסים צומת למצב תחזוקה, צריך להגדיר את הצומת (kubectl cordon NODE_NAME) כך שלא ניתן יהיה לתזמן בו פעולות. אחרי שמסמנים צומת כצומת שלא ניתן לתזמן, הצומת והמעבדים הווירטואליים שמשויכים אליו לא נכללים בחיוב.

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

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

כמו שמתואר בדף התמחור, אפשר להשתמש ב-kubectl כדי לראות את קיבולת ה-vCPU (שמשמשת לחיוב) של כל אחד מאשכולות המשתמשים. הפקודה לא מתייחסת לשאלה אם אפשר לתזמן את הצומת או לא, היא מספקת רק ספירה של vCPU לכל צומת.

כדי לזהות את מספר המעבדים הווירטואליים לכל צומת באשכול המשתמשים:

kubectl get nodes \
    --kubeconfig USER_KUBECONFIG \
    -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
    {.status.capacity.cpu}{\"\n\"}{end}"

מחליפים את USER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול המשתמשים.