גיבוי ושחזור של אשכולות באמצעות bmctl

בדף הזה מוסבר איך להשתמש ב-bmctl כדי לגבות ולשחזר אשכולות שנוצרו באמצעות Google Distributed Cloud (תוכנה בלבד) על מתכת חשופה. ההוראות האלה רלוונטיות לכל סוגי האשכולות.

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

מה מגובה ומה לא מגובה

תהליך הגיבוי והשחזור של bmctl נועד להגן על מצב מישור הבקרה.

המערכת מגבה את האובייקטים הבאים:

• מאגר etcd. כל משאבי Kubernetes ואובייקטים בהתאמה אישית שמגדירים את התצורה של האשכול ואת המצב שנבחר (לדוגמה, מפרטים של Pod, פריסות ו-ConfigMaps,‏ Secrets).
• אישורי PKI. אישורים שמשמשים לתקשורת מאובטחת בתוך האשכול.
• קובצי תצורה ומניפסטים של צמתים. הגדרות שקשורות לצמתי האשכול.

המערכת לא מגבה את האובייקטים הבאים:

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

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

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

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

גיבוי אשכול

הפקודה bmctl backup cluster מוסיפה לקובץ tar את פרטי האשכול ממאגר ה-etcd ואת אישורי ה-PKI של האשכול שצוין. מאגר ה-etcd הוא מאגר הגיבוי של Kubernetes לכל נתוני האשכול, והוא מכיל את כל אובייקטי Kubernetes ואת האובייקטים המותאמים אישית שנדרשים לניהול מצב האשכול. אישורי ה-PKI משמשים לאימות באמצעות TLS. הגיבוי של הנתונים האלה מתבצע ממישור הבקרה של האשכול או מאחד ממישורי הבקרה של פריסת זמינות גבוהה (HA).

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

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

הגרסה של bmctl שבה משתמשים לגיבוי אשכול חייבת להיות זהה לגרסה של האשכול המנהל.

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

1. מוודאים שהאשכול פועל בצורה תקינה, עם אישורים תקינים וקישוריות SSH לכל הצמתים.

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

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

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

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

   • ‫CLUSTER_NAME: שם האשכול שמתכננים לגבות.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

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

   kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
   

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

   • ‫CLUSTER_NAME: שם האשכול שרוצים לגבות.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול. כברירת מחדל, מרחבי השמות של האשכולות ב-Google Distributed Cloud הם השם של האשכול עם הקידומת cluster-. לדוגמה, אם שם האשכול הוא test, שם מרחב השמות יהיה cluster-test.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

3. בודקים את הקטע Status בפלט פקודה כדי לראות אם יש Conditions מהסוג Reconciling.

   כפי שמוצג בדוגמה הבאה, סטטוס של False עבור Conditions אלה מציין שהאשכול יציב ומוכן לגיבוי.

   ...
   Status:
     ...
     Cluster State:  Running
     ...
     Control Plane Node Pool Status:
       ...
       Conditions:
         Last Transition Time:  2023-11-03T16:37:15Z
         Observed Generation:   1
         Reason:                ReconciliationCompleted
         Status:                False
         Type:                  Reconciling
     ...
   

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

   bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

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

   • ‫CLUSTER_NAME: שם האשכול שרוצים לגבות.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

   כברירת מחדל, קובץ ה-tar של הגיבוי נשמר בספריית סביבת העבודה (bmctl-workspace כברירת מחדל) בתחנת העבודה של האדמין. קובץ ה-tar נקרא CLUSTER_NAME_backup_TIMESTAMP.tar.gz, כאשר CLUSTER_NAME הוא שם האשכול שמגבים ו-TIMESTAMP הוא התאריך והשעה שבהם הגיבוי בוצע. לדוגמה, אם שם האשכול הוא testuser, קובץ הגיבוי נקרא testuser_backup_2006-01-02T150405Z0700.tar.gz.

   כדי לציין שם ומיקום אחרים לקובץ הגיבוי, משתמשים בדגל --backup-file.

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

שחזור אשכול

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

הערה: כדי לשפר את הביצועים של האשכול, Google Distributed Cloud משתמש במופע etcd נפרד לאחסון אובייקטים של אירועים. לאובייקטים האלה של אירועים יש אורך חיים (TTL) של שעה אחת. פעולת השחזור של האשכול יוצרת מופע חדש וריק של etcd-events, ולכן מאבדים את אובייקטי האירועים הקיימים. עם זאת, אובדן של אובייקטים מסוג Event לא משפיע על פעולת האשכול. צריך להתייחס לאירועים כאל נתונים משלימים בלבד, שמוצגים כמיטב המאמץ.

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

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

כדי לשחזר אשכול:

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

2. מוודאים שחיבור ה-SSH בין הצמתים פועל עם מפתחות ה-SSH שבהם נעשה שימוש בזמן הגיבוי.

   מפתחות ה-SSH האלה משוחזרים כחלק מתהליך השחזור.

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

   מפתחות חשבון השירות האלה מוחזרים לאשכול המשוחזר.

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

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
   

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

   • ‫CLUSTER_NAME: שם האשכול שמשחזרים.
   • ‫BACKUP_FILE: הנתיב והשם של קובץ הגיבוי שבו אתם משתמשים.

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

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
       --kubeconfig ADMIN_KUBECONFIG
   

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

   • ‫CLUSTER_NAME: שם האשכול שמשחזרים.
   • ‫BACKUP_FILE: הנתיב והשם של קובץ הגיבוי שבו אתם משתמשים.
   • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

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

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

1. מריצים את הפקודות הבאות כדי לוודא שהצומת מוכן ושה-pods של המערכת פועלים עם קובץ ה-kubeconfig שנוצר:

   יש שני סוגים של pods של etcd:

   • ‫etcd-HOST_NAME, שמתאים ל-Pod הראשי etcd
   • ‫etcd-events-HOST_NAME, שמתאים ל-Pod‏ etcd-events

   kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
   kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
   

2. כדי לוודא שה-etcd תקין, מריצים את הפקודה הבאה לכל פוד etcd:

   kubectl exec ETCD_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   אם חבר etcd תקין, התגובה אמורה להיראות כך:

   https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms
   

3. לכל Pod‏ etcd-events, מריצים את הפקודה הבאה כדי לוודא שהוא תקין: etcd-events

   kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   אם חבר etcd-events תקין, התגובה אמורה להיראות כך:

   https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms
   

פתרון בעיות

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

לקבלת עזרה נוספת, אפשר לפנות אל התמיכה של Google.

אם נגמר הזיכרון במהלך גיבוי או שחזור

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

ב-Google Distributed Cloud מגרסה 1.13 ואילך אפשר להשתמש בפרמטר --use-disk בפקודת הגיבוי. כדי לשמור על הרשאות הקובץ, הפרמטר הזה משנה את ההרשאות של הקבצים, ולכן המשתמש שמריץ את הפקודה צריך להיות משתמש root (או להשתמש ב-sudo).

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

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

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

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

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

רענון של מפתח SSH אחרי גיבוי גורם לשיבוש בתהליך השחזור

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

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