איפוס של צומת שנכשל ב-Google Distributed Cloud

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

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

איפוס הצמתים

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

כשמאפסים צומת ומעדכנים את האשכול, הפעולות הבאות מתבצעות:

1. הצומת מתאפס, בדומה ל-kubeadm reset, והמכונה חוזרת למצב שלפני ההתקנה.
2. ההפניות הקשורות לצומת מוסרות מהמשאבים המותאמים אישית של מאגר הצמתים והאשכול.

בחלק מהפקודות הבאות bmctl לאיפוס צמתים, הפרמטר --force מציין אם צריך לדלג על פקודות האיפוס (שלב 1). אם משתמשים בפרמטר --force, הפקודה bmctl מבצעת רק את שלב ההסרה (שלב 2) ולא מריצה את פקודות האיפוס.

הסרת צומת עובד

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

1. מנסים לאפס את הצומת בצורה נקייה. אחרי איפוס הצומת, הוא מוסר מהאשכול:

   bmctl reset nodes \
       --addresses COMMA_SEPARATED_IPS \
       --cluster CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

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

   • ‫COMMA_SEPARATED_IP: כתובות ה-IP של הצמתים שרוצים לאפס, למשל 10.200.0.8,10.200.0.9.
   • ‫CLUSTER_NAME: השם של אשכול היעד שמכיל את הצמתים שנכשלו.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

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

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

   bmctl reset nodes \
       --addresses COMMA_SEPARATED_IPS \
       --cluster CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG \
       --force
   

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

3. אם הסרתם את הצומת בכוח מאשכול הצמתים בשלב הקודם, מריצים שוב את הפקודה bmctl reset כדי לאפס את הצמתים:

   bmctl reset nodes \
       --addresses COMMA_SEPARATED_IPS \
       --cluster CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

הסרה של צומת יחיד של מישור הבקרה

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

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

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

1. מנסים לאפס את הצומת בצורה נקייה. אחרי איפוס הצומת, הוא מוסר מהאשכול:

   bmctl reset nodes \
       --addresses COMMA_SEPARATED_IPS \
       --cluster CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

   מחליפים את הערכים הבאים:

   • ‫COMMA_SEPARATED_IP: כתובות ה-IP של הצמתים שרוצים לאפס, למשל 10.200.0.8,10.200.0.9.
   • ‫CLUSTER_NAME: השם של אשכול היעד שמכיל את הצמתים שנכשלו.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

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

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

   bmctl reset nodes \
     --addresses COMMA_SEPARATED_IPS \
     --cluster CLUSTER_NAME \
     --kubeconfig ADMIN_KUBECONFIG \
     --force
   

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

3. אם הסרתם את הצומת בכוח מאשכול הצמתים בשלב הקודם, מריצים שוב את הפקודה bmctl reset כדי לאפס את הצמתים:

   bmctl reset nodes \
     --addresses COMMA_SEPARATED_IPS \
     --cluster CLUSTER_NAME \
     --kubeconfig ADMIN_KUBECONFIG
   

   איפוס צומת כשאין גישה למישור הבקרה

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

bmctl reset nodes \
    --addresses NODE_IP_ADDRESSES \
    --ssh-private-key-path SSH_PRIVATE_KEY_PATH \
    --login-user LOGIN_USER \
    --gcr-service-account-key AR_SERVICE_ACCOUNT_KEY

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

• ‫NODE_IP_ADDRESSES: רשימה מופרדת בפסיקים של כתובות IP של צמתים, אחת לכל צומת שאתם מאפסים.

• ‫SSH_PRIVATE_KEY_PATH: הנתיב של קובץ המפתח הפרטי של SSH.

• ‫LOGIN_USER: שם המשתמש שמשמש לגישת SUDO ללא סיסמה למכונות הצמתים. אלא אם מציינים במפורש שם משתמש שאינו משתמש root לגישה לצומת בהגדרת האשכול (nodeAccess.loginUser), נעשה שימוש ב-root.

• ‫AR_SERVICE_ACCOUNT_KEY: הנתיב של קובץ מפתח ה-JSON של חשבון השירות של Artifact Registry.

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

הקוורום אבד במישור הבקרה של HA

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

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

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

   bmctl restore --control-plane-node CONTROL_PLANE_NODE \
       --cluster CLUSTER_NAME \
       [--kubeconfig KUBECONFIG_FILE]
   

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

   • ‫CONTROL_PLANE_NODE: כתובות ה-IP של צומת תקין שנשאר חלק מהאשכול.
   • ‫CLUSTER_NAME: השם של אשכול היעד שמכיל את הצמתים שנכשלו.
   • ‫KUBECONFIG_FILE: אם משחזרים אשכול משתמשים, הנתיב לקובץ kubeconfig של אשכול המשתמשים.

2. אחרי שמשחזרים את הצמתים שנכשלו, מריצים את הפקודה bmctl reset כדי לאפס את הצמתים:

   bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      [--kubeconfig KUBECONFIG_FILE]
   

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

   • ‫COMMA_SEPARATED_IP: כתובות ה-IP של הצמתים שרוצים לאפס, למשל 10.200.0.8,10.200.0.9.
   • ‫CLUSTER_NAME: השם של אשכול היעד שמכיל את הצמתים שנכשלו.
   • ‫KUBECONFIG_FILE: הנתיב לקובץ kubeconfig של אשכול האדמין.

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

התהליך הזה מטפל רק בתוכנית התאוששות מאסון (DR) עבור פריסת HA של מישור הבקרה עם 3 צמתים. התהליך הזה לא תומך בשחזור של הגדרות HA עם 5 צמתים או יותר.

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

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

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

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