🥇הידיים שלנו לא נועדו לשעמום: שחזור אשכול צריחים ב-K8s

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

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

"הכל אבוד!"

דמיינו שפעם הגדרתם והפעלתם את Rook באשכול K8s שלכם, והוא עובד בצורה מושלמת, אבל ברגע "נפלא" כלשהו, קורה הדבר הבא:

פודים חדשים לא יכולים להעלות תמונות RBD מ-Ceph.
קבוצות כמו lsblk и df הם לא עובדים על צמתי Kubernetes. משמעות הדבר היא אוטומטית שמשהו לא בסדר בתמונות RBD המותקנות על הצמתים. לא ניתן לקרוא אותן, מה שמעיד על כך שהמוניטורים אינם זמינים...
כן, אין צגים תקינים באשכול. יתר על כן, אין אפילו פודי OSD או פוד MGR.

כאשר הפוד התחיל rook-ceph-operatorלא מזמן, הוא נפרס. למה? אופרטור ה-Rook החליט ליצור אשכול חדש... כיצד נוכל כעת לשחזר את האשכול ואת הנתונים שלו?

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

קצת תרגול, או דרך ארוכה

אנחנו נבדוק את הסביבה ונתקן את המסכים שלך.

אז בואו נסתכל על רשימת מפות ה-ConfigMap: יש כאלה הדרושים לגיבוי. rook-ceph-config и rook-config-overrideהם מופיעים כאשר האשכול נפרס בהצלחה.

NBבגרסאות חדשות, לאחר אימוץ יחסי הציבור האלה, ‏ConfigMaps אינם עוד מדד להצלחת פריסת אשכול.

כדי לבצע פעולות נוספות, עלינו לאתחל מחדש את כל השרתים שטחנו תמונות RBD (ls /dev/rbd*). יש לעשות זאת דרך sysrq (או "ברגל" במרכז הנתונים). דרישה זו הכרחית לניתוק RBDs מורכבים, שעבורם אתחול רגיל לא יעבוד (הוא ינסה ללא הצלחה לנתק אותם כרגיל).

קולנוע מתחיל במתקן מעילים, ואשכול Ceph מתחיל במוניטורים. בואו נסתכל עליהם.

Rook מעלה את הישויות הבאות לתוך פוד הניטור:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (a volume populated by a ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (a volume populated by a Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

בואו נראה מה סודי rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

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

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

בואו נזכור. עכשיו בואו נסתכל על מחזיק המפתחות בסתר. rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

מה יש בזה?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

אותו דבר כאן. בואו נראה שוב... הנה סוד, למשל. rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

בסופו של דבר אנו מוצאים עוד כמה סודות ב-ConfigMap. rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

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

כידוע (ראה dataDirHostPath в תיעוד), Rook מאחסן את הנתונים הללו בשני מקומות. אז בואו נלך לצמתים ונסתכל על מחזיקי המפתחות המאוחסנים בספריות המותקנות בפודים עם צגים ו-OSD. לשם כך, נמצא [מחזיקי מפתחות] על הצמתים. /var/lib/rook/mon-a/data/keyring ונראה:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

פִּתְאוֹם כאן הסוד התברר כשונה - לא כמו ב-ConfigMaps.

מה לגבי מחזיק המפתחות של המנהל? גם לנו יש את זה:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

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

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

אנחנו לוקחים את מחזיק המפתחות של הצג מקובץ /var/lib/rook/mon-a/data/keyring (או מגיבוי);
החליפו את מחזיק המפתחות בסתר rook-ceph-mons-keyring;
רשום את מחזיק המפתחות מהמנהל והניטור ב-ConfigMap rook-ceph-mon;
אנו מסירים בקרי פודים עם צגים.

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

נשחזר את תצוגת ה-OSD

בואו נלך לתא rook-operatorאתגר ceph mon dump מראה שכל המסכים נמצאים במקומם, ו ceph -s - שהם נמצאים במניין חוקי. עם זאת, אם מסתכלים על עץ ה-OSD (ceph osd tree), נראה משהו מוזר: תפריטי OSD החלו להופיע, אבל הם ריקים. מסתבר שצריך איכשהו לשחזר גם אותם. אבל איך?

בינתיים, ConfigMaps רכשו את התכונות שהיינו כל כך זקוקים להן. rook-ceph-config и rook-config-override, כמו גם מפות Config רבות אחרות עם שמות כמו rook-ceph-osd-$nodename-configבואו נסתכל עליהם:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

הכל לא בסדר, הכל מעורבב!

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

בואו ננסה שוב לחפור במדריכים. /mnt/osd[1-2] על הקשרים - בתקווה שנוכל לתפוס שם משהו.
בקטלוג /mnt/osd1 ישנן 2 תת-ספריות: osd0 и osd16האחרון הוא בדיוק המזהה שצוין ב-ConfigMap (16)?
בואו נבדוק את המידות ונראה osd0 הרבה יותר osd16.

אנו מגיעים למסקנה ש osd0 - זהו תפריט המסך הנדרש, אשר צוין כ /mnt/osd1 ב-ConfigMap (מכיוון שאנו משתמשים OSD מבוסס ספריות.)

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

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

בואו ניכנס שוב לפוד האופרטורים של Rook ונבדוק את תקינות האשכול... כן, קצת טעינו עם שמות ה-OSD שלנו בכמה צמתים! אין בעיה: התאמנו שוב את ConfigMaps, הסרנו את הספריות הנוספות מ-OSD החדשים, והגענו למצב המיוחל. HEALTH_OK!

בואו נבדוק את התמונות בבריכה:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

הכל במקום - האשכול נשמר!

אני עצלן מדי לעשות גיבויים, או בדרך המהירה

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

אנו מגדילים את פריסת אופרטור ה-Rook לאפס;
אנו מסירים את כל הפריסות מלבד אופרטור ה-Rook;
אנו משחזרים את כל הסודות ואת מפות ה-Config מגיבוי;
שחזור תוכן הספרייה /var/lib/rook/mon-* על הצמתים;
אנו משחזרים (אם אבד פתאום) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
אנו מגדילים את פריסת אופרטור ה-Rook בחזרה ל-1.

טיפים שימושיים

בצע גיבויים!

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

לפני ביצוע עבודת אשכול בקנה מידה גדול הכרוכה באתחול מחדש של שרתים, יש לשנות את קנה המידה של אופרטור Rook לאפס כדי שלא יעשה שום דבר נוסף.
על צגים מראש הוסף nodeAffinity.
שימו לב לנקודה המקדימה הגדרת פסקי זמן ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

במקום מסקנה

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

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