ב-Google Distributed Cloud, היקף הכשלים באשכולות מוגבל על ידי תעדוף של פונקציונליות שקריטית להמשכיות העסקית. כדי לתעדף את פתרון הבעיות ולצמצם את זמן ההשבתה במהלך אירוע, חשוב להבין איך השיבושים משפיעים על ביצוע עומסי העבודה, על ניהול עומסי העבודה ועל פעולות במחזור החיים.
קטגוריות של פונקציונליות עיקרית
הפונקציונליות העיקרית של Google Distributed Cloud כוללת את הקטגוריות הבאות:
- הרצת עומסי עבודה: עומסי עבודה קיימים יכולים להמשיך לפעול. זה השיקול הכי חשוב לשמירה על המשכיות עסקית. גם אם יש בעיה באשכול, יכול להיות שעומסי העבודה הקיימים ימשיכו לפעול בלי הפרעה.
- ניהול עומסי עבודה: אתם יכולים ליצור, לעדכן ולמחוק עומסי עבודה. זהו השיקול השני בחשיבותו להרחבת עומסי העבודה כשהתנועה גדלה, גם אם יש בעיה באשכול.
- ניהול אשכולות של משתמשים: אתם יכולים לנהל צמתים, לעדכן, לשדרג ולמחוק אשכולות של משתמשים. השיקול הזה פחות חשוב מהשיקולים שקשורים למחזור החיים של האפליקציה. אם יש קיבולת זמינה בצמתים הקיימים, חוסר היכולת לשנות את אשכולות המשתמשים לא משפיע על עומסי העבודה של המשתמשים.
- ניהול אשכולות אדמין: אתם יכולים לעדכן ולשדרג את אשכול האדמין.
- בפריסות שבהן משתמשים באשכולות נפרדים של אדמינים ומשתמשים, זה השיקול הכי פחות חשוב כי אשכול האדמינים לא מארח עומסי עבודה של משתמשים. אם יש בעיה באשכול האדמין, עומסי העבודה של האפליקציה באשכולות אחרים ממשיכים לפעול ללא הפרעה.
- אם אתם משתמשים במודלים אחרים של פריסה, כמו היברידית או עצמאית, אשכול האדמין מריץ עומסי עבודה של אפליקציות. אם יש בעיה באשכול האדמין ומישור הבקרה מושבת, אי אפשר לנהל את עומסי העבודה של האפליקציה או את הרכיבים של אשכול המשתמש.
בקטעים הבאים נשתמש בקטגוריות האלה של פונקציונליות עיקרית כדי לתאר את ההשפעה של סוגים ספציפיים של תרחישי כשל. כשיש שיבוש כחלק מתרחיש של כשל, משך השיבוש (סדר הגודל) מצוין גם הוא, כשאפשר.
כשלים בצמתים
יכול להיות שצומת ב-Google Distributed Cloud יפסיק לפעול או שלא תהיה אליו גישה ברשת. בהתאם למאגר הצמתים ולאשכול שהמכונה שנכשלה שייכת אליהם, יש כמה מצבי כשל שונים.
צומת במישור הבקרה
בטבלה הבאה מתוארת ההתנהגות של צמתים שהם חלק ממישור הבקרה ב-Google Distributed Cloud:
| הרצת עומסי עבודה (workloads) | ניהול עומסי עבודה | ניהול אשכולות של משתמשים | ניהול אשכולות אדמין | |
|---|---|---|---|---|
| הפרעה (משך זמן) | בלי הפרעות | שיבוש אפשרי (לא ידוע) | שיבוש אפשרי (לא ידוע) | שיבוש אפשרי (לא ידוע) |
| הסבר | — | אם הכשל בצומת משפיע על צומת מישור הבקרה היחיד באשכול משתמשים ללא זמינות גבוהה (HA), או אם הוא משפיע על לפחות חצי מצומתי מישור הבקרה באשכול משתמשים עם זמינות גבוהה, יש שיבוש. הקוורום של מישור הבקרה של אשכול המשתמש אבד. | אם הכשל בצומת משפיע על צומת מישור הבקרה היחיד באשכול אדמין שאינו HA, או אם הוא משפיע על לפחות חצי מצומתי מישור הבקרה באשכול אדמין HA, יש שיבוש. הקוורום של מישור הבקרה באשכול האדמין אבד. | אם הכשל בצומת משפיע על צומת מישור הבקרה היחיד באשכול אדמין שאינו HA, או אם הוא משפיע על לפחות חצי מצומתי מישור הבקרה באשכול אדמין HA, יש שיבוש. הקוורום של מישור הבקרה באשכול האדמין אבד. |
| שחזור | — | מידע נוסף זמין במאמר איך להתאושש מאובדן קוורום. | מידע נוסף זמין במאמר איך להתאושש מאובדן קוורום. | מידע נוסף זמין במאמר איך להתאושש מאובדן קוורום. |
| מניעה | — | כדי לצמצם את הסיכוי לשיבושים, פורסים אשכולות משתמשים במצב HA. | פריסת אשכולות אדמין במצב HA כדי לצמצם את האפשרות לשיבושים. | כדי לצמצם את האפשרות לשיבושים, פורסים אשכולות אדמין במצב HA. |
צומת של מאזן עומסים
בטבלה הבאה מתוארת ההתנהגות של צמתים שמארחים את מאזני העומסים ב-Google Distributed Cloud. ההנחיות האלה רלוונטיות רק למאזני עומסים מקובצים עם מצב שכבה 2. באיזון עומסים ידני, עיינו במצבי הכשל של מאזני העומסים החיצוניים:
| הרצת עומסי עבודה (workloads) | ניהול עומסי עבודה | ניהול אשכולות של משתמשים | ניהול אשכולות אדמין | |
|---|---|---|---|---|
| הפרעה (משך זמן) | שיבוש אפשרי (משתנה) | שיבוש אפשרי (משתנה) | שיבוש אפשרי (משתנה) | שיבוש אפשרי (משתנה) |
| הסבר | אם עומסי עבודה חיצוניים מסתמכים על מאזן העומסים של מישור הנתונים כדי לתקשר עם עומסי עבודה באשכול, ויש לכם רק צומת אחד של מאזן עומסים, תהיה הפרעה. | כתובת ה-IP הווירטואלית של מישור הבקרה של אשכול המשתמש נמצאת בצומת אחד של מאזן העומסים. אם מאגר הצמתים של מאזן העומסים של אשכול המשתמשים הוא לא HA, תהיה הפרעה. | כתובת ה-IP הווירטואלית של מישור הבקרה של אשכול האדמין נמצאת בצומת אחד של מאזן העומסים. אם מאגר הצמתים של מאזן העומסים באשכול הניהול הוא לא HA, תהיה הפרעה. | כתובת ה-IP הווירטואלית של מישור הבקרה של אשכול האדמין נמצאת בצומת אחד של מאזן העומסים. אם מאגר הצמתים של מאזן העומסים באשכול הניהול הוא לא HA, תהיה הפרעה. |
| שחזור | אם יש כמה צמתים של מאזן עומסים, מעבר לגיבוי בעת כשל של MetalLB מתרחש תוך כמה שניות. אם לא, כדאי לפרוס צמתים נוספים של מאזן עומסים. |
אם מדובר בזמינות גבוהה, יתירות הכשל היא אוטומטית ונמשכת כמה שניות. אם לא מדובר בזמינות גבוהה, כדאי לפרוס צמתים נוספים של מאזן עומסים |
אם מדובר בזמינות גבוהה, יתירות הכשל היא אוטומטית ונמשכת כמה שניות. אם לא, כדאי לפרוס צמתים נוספים של מאזן עומסים. |
אם מדובר בזמינות גבוהה, יתירות הכשל היא אוטומטית ונמשכת כמה שניות. אם לא, כדאי לפרוס צמתים נוספים של מאזן עומסים. |
| מניעה | כדי לצמצם את הסיכוי לשיבושים, כדאי לפרוס מאגרי צמתים של מאזן עומסים במצב HA. | כדי לצמצם את הסיכוי לשיבושים, כדאי לפרוס מאגרי צמתים של מאזן עומסים במצב HA. | כדי לצמצם את הסיכוי לשיבושים, כדאי לפרוס מאגרי צמתים של מאזן עומסים במצב HA. | כדי לצמצם את הסיכוי לשיבושים, כדאי לפרוס מאגרי צמתים של מאזן עומסים במצב HA. |
צומת עובד
בטבלה הבאה מתוארת ההתנהגות של צומתי עובדים ב-Google Distributed Cloud:
| הרצת עומסי עבודה (workloads) | ניהול עומסי עבודה | ניהול אשכולות של משתמשים | ניהול אשכולות אדמין | |
|---|---|---|---|---|
| הפרעה (משך זמן) | שיבוש אפשרי (בסדר גודל של שניות) | בלי הפרעות | בלי הפרעות | בלי הפרעות |
| הסבר | ה- אם לאפליקציות של המשתמשים יש קיבולת פנויה לעומסי עבודה והן מפוזרות על פני כמה צמתים, לקוחות שמבצעים ניסיונות חוזרים לא יבחינו בשיבוש. ה- |
— | — | — |
| שחזור | אם אין באשכול קיבולת פנויה, צריך לפרוס עוד צמתים בכמה אזורי כשל ולהעביר את עומסי העבודה שנכשלו לצמתים החדשים. | — | — | — |
| מניעה | לפרוס צמתים שמתפרסים על פני כמה אזורי כשל. כדי לצמצם את הסיכוי לשיבושים, פורסים עומסי עבודה עם כמה רפליקות שפרוסות על פני כמה אזורי כשל. |
— | — | — |
כשל באחסון
יכול להיות שהאחסון ב-Google Distributed Cloud יפסיק לפעול או שלא תהיה גישה אליו ברשת. בהתאם לאחסון שנכשל, יש כמה מצבי כשל שונים.
etcd
התוכן של הספריות /var/lib/etcd ו-/var/lib/etcd-events עלול להיפגם אם הצומת נכבה באופן לא תקין או אם יש כשל בסיסי באחסון. בטבלה הבאה מתוארת ההתנהגות של הפונקציונליות העיקרית בעקבות כשלים ב-etcd:
| הרצת עומסי עבודה (workloads) | ניהול עומסי עבודה | ניהול אשכולות של משתמשים | ניהול אשכולות אדמין | |
|---|---|---|---|---|
| הפרעה (משך זמן) | בלי הפרעות | שיבוש אפשרי (לא ידוע) | שיבוש אפשרי (לא ידוע) | שיבוש אפשרי (לא ידוע) |
| הסבר | אם עומסי העבודה הקיימים לא מסתמכים על מישור הבקרה של Kubernetes, הם ממשיכים לפעול ללא הפרעה. | אם etcd נכשל באשכול משתמשים עם מישור בקרה יחיד, או נכשל בלפחות חצי מהצמתים של מישור הבקרה באשכול משתמשים עם זמינות גבוהה, יש שיבוש. הקוורום של מישור הבקרה של אשכול המשתמש אבד. |
אם etcd נכשל באשכול אדמין עם מישור בקרה יחיד, או אם הוא נכשל בלפחות חצי מהצמתים של מישור הבקרה באשכול אדמין עם זמינות גבוהה, יש שיבוש. הקוורום של מישור הבקרה של אשכול האדמין אבד. |
אם etcd נכשל באשכול אדמין עם מישור בקרה יחיד, או אם הוא נכשל בלפחות חצי מצומתי מישור הבקרה באשכול אדמין עם זמינות גבוהה, תהיה הפרעה. הקוורום של מישור הבקרה של אשכול האדמין אבד. |
| שחזור | — | מידע נוסף זמין במאמר איך להתאושש מאובדן קוורום. | מידע נוסף זמין במאמר איך להתאושש מאובדן קוורום. | מידע נוסף זמין במאמר איך להתאושש מאובדן קוורום. |
| מניעה | — | כדי לצמצם את הסיכוי להפרעות, כדאי לפרוס אשכולות משתמשים במצב HA. | כדי לצמצם את הסיכוי להפרעות, כדאי לפרוס אשכולות אדמין במצב HA. | כדי לצמצם את הסיכוי להפרעות, כדאי לפרוס אשכולות אדמין במצב HA. |
בקשת המשתמש PersistentVolume
בטבלה הבאה מתוארת ההתנהגות של הפונקציונליות העיקרית כתוצאה מכשל של PersistentVolume:
| הרצת עומסי עבודה (workloads) | ניהול עומסי עבודה | ניהול אשכולות של משתמשים | ניהול אשכולות אדמין | |
|---|---|---|---|---|
| הפרעה (משך זמן) | שיבוש אפשרי (לא ידוע) | בלי הפרעות | בלי הפרעות | בלי הפרעות |
| הסבר | עומסי העבודה שמשתמשים ב-PersistentVolume שנכשל |
— | — | — |
| שחזור | — | — | — | — |
| מניעה | כדי לצמצם את הסיכוי להפרעה, פורסים את עומס העבודה של המשתמש במצב HA. | — | — | — |
דיסק פגום של Fluent Bit
פגיעה בדיסק של Fluent Bit לא משפיעה על פונקציונליות עיקרית, אבל משפיעה על היכולת לאסוף ולבדוק יומנים ב- Google Cloud.
לפעמים אפשר לראות את האירוע SIGSEGV ביומנים של stackdriver-log-forwarder. יכול להיות שהשגיאה הזו נגרמת בגלל יומנים פגומים שנשמרו במאגר הנתונים בדיסק.
ל-Fluent Bit יש מנגנון לסינון ולהסרה של הנתונים הפגומים. התכונה הזו זמינה בגרסת fluent-bit (v1.8.3) שמשמשת ב-Google Distributed Cloud.
מתוך LoadBalancer אינינגים של המגיש
אם כל כתובות ה-IP במאגרים שהוקצו תפוסות כרגע, שירותי LoadBalancer חדשים שנוצרו לא יכולים לקבל כתובת IP של LoadBalancer. התרחיש הזה משפיע על היכולת של לקוחות השירות לתקשר עם שירותי LoadBalancer.
כדי להתאושש מהמצב הזה, מקצים עוד כתובות IP למאגר הכתובות על ידי שינוי המשאב המותאם אישית של האשכול.
תפוגת התוקף של האישור
במהלך ההתקנה של האשכול, Google Distributed Cloud יוצרת רשות אישורים (CA) עם חתימה עצמית. התוקף של ה-CA הוא ל-10 שנים, והוא אחראי ליצירת אישורים שתוקפם פג אחרי שנה. כדי למנוע השבתה של האשכול, צריך להחליף את האישורים באופן קבוע. הדרך המומלצת להחלפת אישורים היא לשדרג את האשכול. אם אתם לא יכולים לשדרג את האשכול, אתם יכולים לבצע רוטציה של רשות אישורים על פי דרישה. למידע נוסף על אישורי אשכולות, ראו אישורי PKI ודרישות במסמכי התיעוד של Kubernetes.
אם פג התוקף של אישורי האשכול, צריך לחדש אותם ידנית.
| הרצת עומסי עבודה (workloads) | ניהול עומסי עבודה | ניהול אשכולות של משתמשים | ניהול אשכולות אדמין | |
|---|---|---|---|---|
| הפרעה (משך זמן) | בלי הפרעות | שיבוש אפשרי (לא ידוע) | שיבוש אפשרי (לא ידוע) | שיבוש אפשרי (לא ידוע) |
| הסבר | אם עומסי העבודה של המשתמשים לא מתקשרים עם הרכיבים של מישור הבקרה של Kubernetes, לא יהיו שיבושים. | אם תוקף רשויות האישורים של אשכולות המשתמשים יפוג, תהיה הפרעה. | אם פג התוקף של רשויות האישורים של אשכולות האדמין, תהיה הפרעה. | אם תוקף רשויות האישורים של אשכולות המשתמשים יפוג, תהיה הפרעה. |
| שחזור | — | פועלים לפי השלבים לחידוש ידני של אישורים באשכול המשתמש. |
פועלים לפי השלבים לחידוש ידני של אישורים באשכול המשתמש. |
פועלים לפי השלבים לחידוש ידני של אישורים באשכול המשתמש. |
| מניעה | הגדירו מעקב אחרי תפוגת התוקף של האישורים. ברשימת המדדים אפשר למצוא דוגמה למדד kubelet_certificate_manager_server_expiration_seconds. |
|||
שדרוגים שנכשלו
| הרצת עומסי עבודה (workloads) | ניהול עומסי עבודה | ניהול אשכולות של משתמשים | ניהול אשכולות אדמין | |
|---|---|---|---|---|
| הפרעה (משך זמן) | בלי הפרעות | בלי הפרעות | שיבוש אפשרי (לא ידוע) | שיבוש אפשרי (לא ידוע) |
| הסבר | אם השדרוג נכשל במישור הבקרה של אשכול המשתמש, עומסי העבודה הקיימים לא יופרעו. אם השדרוג נכשל בצומת עובד מסוים, עומסי העבודה בצומת הזה ינוקזו ויועברו לצמתים תקינים אחרים, אם יש בהם קיבולת נוספת. |
השדרוג ייפסק אם השדרוג של אחד מהצמתים במישור הבקרה ייכשל. האשכול עדיין פועל אם השדרוג נכשל, בתנאי שאשכול המשתמש הוא HA. | אם השדרוג נכשל במישור הבקרה של אשכול האדמין, תהיה הפרעה עד שהשדרוג יסתיים. | אם השדרוג נכשל במישור הבקרה של אשכול האדמין, תהיה הפרעה עד שהשדרוג יסתיים. |
| שחזור | — | — | אפשר לנסות שוב לשדרג. למידע נוסף, קראו את המאמר אבחון בעיות בשדרוג והמשך השדרוג. | אפשר לנסות שוב לשדרג. למידע נוסף, קראו את המאמר אבחון בעיות בשדרוג והמשך השדרוג. |
| מניעה | — | — | מידע נוסף זמין במאמר יצירת גיבוי לפני שדרוג. | מידע נוסף זמין במאמר יצירת גיבוי לפני שדרוג. |
המאמרים הבאים
למידע נוסף על בעיות מוכרות במוצר ודרכים לעקיפת הבעיה, ראו בעיות מוכרות ב-Google Distributed Cloud.
אם אתם צריכים עזרה נוספת, תוכלו לפנות אל Cloud Customer Care. במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על מקורות המידע לתמיכה, כולל:
- הדרישות לפתיחת בקשת תמיכה.
- כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, יומנים ומדדים.
- רכיבים נתמכים.