Google Cloud הודיעה כי שירות ה-GKE שלה מציע כעת שדרוגי מישור בקרה (control-plane) בשני שלבים הזמינים לשימוש כללי (generally-available), מה שמאפשר ללקוחות להפריד בין שדרוג הבינארי של התוכנה לבין הגירת פורמט הנתונים, ולשמור על חלון זמן לביצוע rollback במהלך שינויי גרסה משנית (minor version).

למה GKE היה זקוק למסלול בטוח יותר

שדרוג מישור בקרה של Kubernetes מגרסה משנית אחת למתקדמת יותר תמיד נשא סיכון. מעבר מגרסה 1.33 ל-1.34 לא רק מחליף בינאריים, אלא גם כותב מחדש את מבני הנתונים שבבסיס המערכת. אם הגרסה החדשה מכילה באג, לא ניתן פשוט לבצע rollback לאשכול; מנהלי המערכת חייבים לשחזר snapshots ישנים של מסד הנתונים או לבנות מחדש את כל ה-cluster, תהליך גוזל זמן וחשוף לטעויות.

איך עובד שדרוג דו-שלבי

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

  • שלב 1 – שדרוג בינארי (emulated mode). GKE מחליף את הבינאריים של מישור הבקרה לגרסה היעד תוך שמירה על פורמט הנתונים הישן. מכיוון שלא נכתבים מבני נתונים חדשים, ה-cluster נשאר בטוח לביצוע rollback לאורך שלב זה.
  • שלב 2 – סיום (Finalization). לאחר תקופת המתנה הניתנת להגדרה, GKE ממיר את הנתונים השמורים לפורמט החדש. ברגע שההמרה הזו מסתיימת, ביצוע rollback ידרוש את אותה מאמץ של שחזור snapshot שהתהליך הדו-שלבי נועד למנוע.

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

חלון ה-soak בפועל

GKE מנטר באופן אוטומטי מדדי בריאות מרכזיים במהלך תקופת ה-soak — שיהוי (latency) של ה-API, שיעורי שגיאות ובריאות ה-pods. אם השירות מזהה חריגות, הוא עוצר את הפריסה (rollout), ומותיר את ה-cluster במצב של בינאריים בלבד, שבו עדיין ניתן לבצע rollback. גוגל מציינת שיעור הצלחה של 99.999% לשדרוגים העוקבים אחר דפוס זה.

עבור אשכולות המשתמשים בתכונת ה-auto-upgrade של GKE, הפלטפורמה מנהלת את כל הרצף הדו-שלבי ללא התערבות ידנית. משתמשים המעדיפים שליטה מלאה יכולים להפעיל את התהליך באמצעות ה-Cloud CLI או Terraform.

הרצת שדרוג ידני דו-שלבי

שדרוג ידני טיפוסי עם חלון בטיחות של 48 שעות נראה כך:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

כדי לבדוק את הסטטוס הנוכחי:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

אם מתגלה תקלה במהלך תקופת ה-soak, מנהל המערכת יכול להוציא פקודת rollback ולחזור לגרסה הקודמת ללא אובדן נתונים. כאשר ה-cluster מתגלה כיציב, ניתן להשלים את השדרוג מוקדם יותר באמצעות הפקודה complete-control-plane-upgrade.

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

  • התכונה חלה על אשכולות GKE המריצים גרסה 1.33 ומעלה.
  • ניתן לשדרג רק גרסה משנית אחת בכל פעם; דילוג על גרסאות אינו נתמך.
  • גם אשכולות Autopilot וגם אשכולות אזוריים (regional clusters) נותרים זמינים לאורך כל התהליך הדו-שלבי.

חסרונות פוטנציאליים

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

מה לעקוב אחריו בהמשך

גוגל לא חשפה מפת דרכים להרחבת המודל הדו-שלבי לשדרוגי גרסה ראשית (major versions), אשר עדיין דורשים יצירה מחדש של ה-cluster במקרים רבים. משקיפים יחפשו הודעות על רשתות בטיחות דומות לשדרוגי node-pools ועל כל אינטגרציה עם צינורות (pipelines) CI/CD של צד שלישי שיוכלו להפוך את בדיקות חלון ה-soak לאוטומטיות.

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