שיטות מומלצות לשדרוג אשכולות של Google Distributed Cloud

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

אם יש לכם כמה סביבות כמו test,‏ development ו-production, מומלץ להתחיל עם הסביבה הכי פחות קריטית, כמו test, ולאמת את פונקציית השדרוג. אחרי שמוודאים שהשדרוג בוצע בהצלחה, עוברים לסביבה הבאה. חוזרים על התהליך הזה עד שמשדרגים את סביבות הייצור. הגישה הזו מאפשרת לכם לעבור מנקודה קריטית אחת לשנייה, ולוודא שהשדרוג ועומסי העבודה פועלים בצורה תקינה.

רשימת משימות לשדרוג

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

תכנון השדרוג

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

הערכת משך הזמן שנדרש והגדרת חלון זמן לתחזוקה

כברירת מחדל, כל מאגרי הצמתים משודרגים במקביל. אבל בכל מאגר צמתים, הצמתים משודרגים ברצף כי צריך לנקז כל צומת וליצור אותו מחדש. לכן, משך הזמן הכולל לשדרוג תלוי במספר הצמתים במאגר הצמתים הגדול ביותר. כדי לחשב הערכה גסה לזמן השדרוג, מכפילים 15 דקות במספר הצמתים במאגר הצמתים הגדול ביותר. לדוגמה, אם יש לכם 10 צמתים במאגר הגדול ביותר, זמן השדרוג הכולל יהיה בערך 15 * 10 = 150 דקות או שעתיים וחצי.

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

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

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

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

גיבוי של אשכול המשתמשים ואשכול האדמינים

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

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

ב-Google Distributed Cloud מגרסה 1.8 ואילך, אפשר להגדיר גיבוי אוטומטי באמצעות clusterBackup.datastore בקובץ ההגדרות של אשכול הניהול. כדי להפעיל את התכונה הזו באשכול קיים, עורכים את קובץ ההגדרות של אשכול האדמין ומוסיפים את השדה clusterBackup.datastore, ואז מריצים את הפקודה gkectl update admin.

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

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

בדיקת השימוש ב-PodDisruptionBudgets

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

  1. כדי לבדוק אילו PDB מוגדרים באשכול, משתמשים בפקודה kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

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

    בדוגמה הבאה של פלט מוצגים מאגרי PDB בשמות istio-ingress, istiod ו-kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

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

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

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

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

בדיקת כתובות ה-IP הזמינות

השיקולים הבאים לגבי כתובות IP רלוונטיים לשדרוגים של אשכולות משתמשים ואשכולות אדמין שאינם HA (כלומר, אשכולות אדמין שאין להם זמינות גבוהה):

  • תהליך השדרוג של האשכול יוצר צומת חדש ומרוקן את המשאבים לפני שהוא מוחק את הצומת הישן. מומלץ שתמיד יהיו לכם N+1 כתובות IP לאשכול, כאשר N הוא מספר הצמתים באשכול. ההמלצה הזו רלוונטית רק לאשכולות אדמין שאינם HA (שיש להם רק צומת אחד של מישור הבקרה) ולאשכולות משתמשים.

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

    • כשמשדרגים אשכולות אדמין שאינם HA, מוסיפים את כתובת ה-IP הנוספת לקובץ של בלוק כתובות ה-IP שמשמש את אשכול האדמין. הנתיב לקובץ הזה צריך להיות מצוין בשדה network.ipMode.ipBlockFilePath בקובץ התצורה של אשכול הניהול.
    • כשמשדרגים אשכולות משתמשים, מוסיפים את כתובת ה-IP הנוספת בקובץ ה-IP block שמשמש את אשכול המשתמשים. הנתיב לקובץ הזה צריך להיות מצוין בשדה network.ipMode.ipBlockFilePath של קובץ התצורה של אשכול המשתמשים.

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

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

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

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

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

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

בדיקת ניצול האשכול

מוודאים שאפשר לפנות את ה-Pods כשמרוקנים את הצומת, ושיש מספיק משאבים באשכול שמשדרגים כדי לנהל את השדרוג. כדי לבדוק את השימוש הנוכחי במשאבים של האשכול, אפשר להשתמש בלוחות בקרה בהתאמה אישית ב-Google Cloud Observability, או ישירות באשכול באמצעות פקודות כמו kubectl top nodes.

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

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

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

בדיקת הניצול של vSphere

בודקים שיש מספיק משאבים בתשתית vSphere הבסיסית. כדי לבדוק את השימוש במשאבים, בוחרים אשכול ב-vCenter ומעיינים בכרטיסייה סיכום.

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

כלל האצבע הוא שקלאסטר vSphere צריך לתמוך במשאבים הנוספים הבאים:

  • ‫+1 מכונה וירטואלית לכל שדרוג של אשכול אדמין
  • ‫+1 מכונה וירטואלית לכל מאגר צמתים לכל שדרוג של אשכול משתמשים

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

  • ‫24 vCPU
  • זיכרון RAM בנפח 96GB
  • נפח האחסון של מכונת ה-VM + 96GB של vSwap

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

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

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

בדיקת התקינות וההגדרות של האשכול

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

  • הפקודה gkectl diagnose: gkectl diagnose מוודאת שכל האשכולות תקינים. הפקודה מריצה בדיקות מתקדמות, למשל כדי לזהות צמתים שלא הוגדרו בצורה נכונה או שיש בהם יחידות Pod שנמצאות במצב תקוע. אם הפקודה gkectl diagnose מציגה אזהרה Cluster unhealthy, צריך לפתור את הבעיות לפני שמנסים לשדרג. מידע נוסף זמין במאמר בנושא אבחון בעיות באשכול.

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

בנוסף, כשמשדרגים אשכולות משתמשים לגרסה 1.29 ומעלה, מומלץ להריץ את הפקודה gkectl upgrade cluster עם הדגל --dry-run. הדגל --dry-run מריץ בדיקות מקדימות אבל לא מתחיל את תהליך השדרוג. בגרסאות קודמות של Google Distributed Cloud מופעלות בדיקות מקדימות, אבל אי אפשר להפעיל אותן בנפרד מהשדרוג. הוספת הדגל --dry-run מאפשרת לכם למצוא ולתקן בעיות שמתגלות בבדיקות המקדימות של אשכול המשתמשים לפני השדרוג.

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

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

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

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

שימוש בצמד מאזני עומסים עם זמינות גבוהה

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

כדי להגדיל את זמינות השירות (כלומר, שרת Kubernetes API), מומלץ להשתמש תמיד בצמד HA לפני אשכול האדמין. למידע נוסף על Seesaw ועל הגדרת HA שלו, אפשר לעיין במסמכים של גרסה 1.16 Bundled load balancing with Seesaw.

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

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

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

קובעים איך לשדרג כל אשכול משתמשים

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

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

בדיקת הגרסאות של אשכולות המשתמשים והאדמינים

gkectl

  • כדי לבדוק את הגרסה של אשכולות משתמשים:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

  • כדי לבדוק את הגרסה של אשכולות אדמין:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

‫CLI של gcloud

במקרה של אשכולות שנרשמו ל-GKE On-Prem API, אפשר להשתמש ב-CLI של gcloud כדי לקבל את הגרסאות של אשכולות משתמשים, מאגרי צמתים באשכול המשתמש ואשכולות אדמין.

  1. מוודאים שמותקנת במחשב הגרסה העדכנית של ה-CLI של gcloud. אם צריך, מעדכנים את הרכיבים של ה-CLI של gcloud:

    gcloud components update

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

  • כדי לבדוק את הגרסה של אשכולות משתמשים:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    מחליפים את PROJECT_ID במזהה הפרויקט של פרויקט המארח של ה-Fleet.

    כשמגדירים את --location=-, המשמעות היא שצריך לרשום את כל האשכולות בכל האזורים. אם צריך לצמצם את הרשימה, מגדירים את --location לאזור שציינתם כשנרשמתם לאשכול.

    הפלט של הפקודה כולל את גרסת האשכול.

  • כדי לבדוק את הגרסה של אשכולות אדמין:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

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

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

בדיקה אם צריך לבצע רוטציה של אישורי CA

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

ההבדלים בין סוגי האשכולות

יש שני סוגים שונים של אשכולות:

  • אשכול משתמשים
  • קלאסטר אדמין

בהתאם לאופן שבו יוצרים אשכול משתמשים, הוא עשוי להכיל גם צמתי עובדים וגם צמתי מישור בקרה (Controlplane V2) או רק צמתי עובדים (kubeception). ב-kubeception, מישור הבקרה של אשכול משתמשים פועל בצומת אחד או יותר באשכול אדמין. בשני המקרים, בגרסה 1.14 ואילך, אפשר לשדרג את רמת הבקרה של אשכול משתמשים בנפרד ממאגרי הצמתים שמריצים את עומסי העבודה.

הבדלים בהשפעה של שדרוגים באשכול משתמשים לעומת שדרוגים באשכול אדמין

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

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

הפרעה באשכול משתמשים

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

תפקיד קלאסטר אדמין אשכול משתמש ללא זמינות גבוהה אשכול משתמש HA
גישה ל-Kubernetes API לא מושפע לא מושפע לא מושפע
עומסי עבודה של משתמשים לא מושפע לא מושפע לא מושפע
PodDisruptionBudgets* לא מושפע לא מושפע לא מושפע
צומת מישור הבקרה לא מושפע השפעה לא מושפע
Pod autoscaler (VMware) לא מושפע לא מושפע לא מושפע
מוסך לא מושפע לא מושפע לא מושפע
התאמה אוטומטית של גודל הצמתים (VMware) לא מושפע לא מושפע לא מושפע
התאמה אופקית של קבוצות Pod לעומס השפעה השפעה לא מושפע
  • ‫* : קובצי PDB עלולים לגרום לשדרוג להיכשל או להיעצר.
  • השפעה: שיבוש בשירות במהלך השדרוג מורגש עד לסיום השדרוג.
  • לא מושפע: יכול להיות שתהיה הפרעה בשירות למשך זמן קצר מאוד, אבל היא כמעט לא מורגשת.

צמתים של מישור הבקרה של אשכול המשתמשים, בין אם הם פועלים באשכול האדמין (kubeception) או באשכול המשתמשים עצמו (Controlplane V2), לא מריצים עומסי עבודה של משתמשים. במהלך שדרוג, הצמתים האלה של רמת הבקרה מתרוקנים ואז מתעדכנים בהתאם.

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

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

כדי לשפר את הזמינות ולצמצם את ההפרעות באשכולות של משתמשי ייצור במהלך שדרוגים, מומלץ להשתמש בשלושה צמתים של מישור הבקרה (מצב זמינות גבוהה).

שיבוש באשכול אדמין

בטבלה הבאה מתוארת ההשפעה של שדרוג אדמין קלאסטר במקום:

תפקיד קלאסטר אדמין אשכול משתמש ללא זמינות גבוהה אשכול משתמש HA
גישה ל-Kubernetes API השפעה השפעה לא מושפע
עומסי עבודה של משתמשים לא מושפע לא מושפע לא מושפע
צומת מישור הבקרה השפעה השפעה לא מושפע
Pod Autoscaler השפעה השפעה לא מושפע
מוסך השפעה השפעה לא מושפע
התאמה אוטומטית לעומס (autoscaling) של צמתים השפעה השפעה לא מושפע
התאמה אופקית של קבוצות Pod לעומס השפעה השפעה לא מושפע
  • השפעה: שיבוש בשירות במהלך השדרוג מורגש עד לסיום השדרוג.
  • לא מושפע: יכול להיות שתהיה הפרעה בשירות למשך זמן קצר מאוד, אבל היא כמעט לא מורגשת.

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