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

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

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

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

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

תכנון השדרוג

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

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

כברירת מחדל, כל מאגרי הצמתים משודרגים במקביל. אבל בתוך כל מאגר צמתים, הצמתים משודרגים ברצף כי צריך לנקז כל צומת וליצור אותו מחדש. לכן, משך הזמן הכולל לשדרוג תלוי במספר הצמתים במאגר הצמתים הגדול ביותר. כדי לחשב הערכה גסה לזמן השדרוג, מכפילים 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 מציין שלפחות פוד אחד צריך להיות זמין תמיד. הזמינות הזו הופכת לקריטית במהלך שדרוגים, כשמתבצע ניקוז של הצמתים.

בודקים אם יש הזמנות 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 פנויה אחת לכל אשכול המשתמשים, המגבלה הזו מאטה את תהליך השדרוג ל-VM אחד בכל פעם, גם כשמשתמשים בכמה מאגרי צמתים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מערכת 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). בהגדרה הזו, המערכת יוצרת ומגדירה שתי מכונות וירטואליות של מאזן עומסים כדי שניתן יהיה לבצע יתירות כשל למכונה הווירטואלית השנייה.

כדי להגדיל את הזמינות של השירות (כלומר, של שרת Kubernetes API), מומלץ להשתמש תמיד בצמד HA לפני אשכול האדמין. למידע נוסף על Seesaw ועל הגדרת HA שלו, אפשר לעיין במסמכים של גרסה 1.16 בנושא איזון עומסים בחבילה עם 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 במזהה הפרויקט של פרויקט המארח של הצי.

    כשמגדירים את --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 מוסרים מצומת. במהלך התהליך נוצרת מכונה וירטואלית חדשה לכל צומת עובד שרוקן, והיא מתווספת לאשכול. אחרי הניקוז, צמתי העובדים מוסרים מהמלאי של VMware. במהלך התהליך הזה, כל עומס עבודה שפועל בצמתים האלה נעצר ומופעל מחדש בצמתים זמינים אחרים באשכול.

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

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

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

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

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

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

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

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

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

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

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

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