הכנה למעבר מ-Standard ל-Autopilot

בדף הזה מפורטים שיקולים והמלצות שיעזרו לכם להעביר עומסי עבודה מאשכולות Standard של Google Kubernetes Engine ‏ (GKE) לאשכולות Autopilot עם שיבושים מינימליים בשירותים. הדף הזה מיועד לאדמינים של אשכולות שכבר החליטו לבצע מיגרציה ל-Autopilot. אם אתם צריכים מידע נוסף לפני שתחליטו לבצע מיגרציה, תוכלו לעיין במאמרים בחירת מצב פעולה של GKE והשוואה בין GKE Autopilot לבין GKE Standard.

איך ההעברה פועלת

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

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

כדי להתכונן להעברה מוצלחת ולבצע אותה, תצטרכו לבצע את המשימות הבאות ברמה גבוהה:

  1. מריצים בדיקה לפני טיסה באשכול הקיים מסוג Standard כדי לוודא שהוא תואם ל-Autopilot.
  2. במקרה הצורך, משנים את מניפסטים של עומסי העבודה כך שיהיו תואמים ל-Autopilot.
  3. מבצעים הרצה יבשה כדי לוודא שעומסי העבודה פועלים בצורה תקינה ב-Autopilot.
  4. מתכננים ויוצרים את אשכול Autopilot.
  5. אם רלוונטי, מעדכנים את כלי התשתית כקוד.
  6. מבצעים את ההעברה.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שיש לכם אשכול קיים מסוג Standard עם עומסי עבודה פעילים.
  • כדי לבצע הרצות יבשות, צריך לוודא שיש לכם אשכול Autopilot ללא עומסי עבודה. כדי ליצור אשכול חדש של Autopilot, אפשר לעיין במאמר בנושא יצירת אשכול Autopilot.

הפעלת רכיב הבדיקה לפני טיסה באשכול

ב-GKE בגרסה 1.31.6-gke.1027000 ואילך, רכיב הבדיקה לפני הפעלה של Autopilot מושבת כברירת מחדל. כדי להריץ את הבדיקה באשכול, צריך להפעיל את רכיב הבדיקה לפני ההפעלה. אם האשכול שלכם מריץ גרסת GKE קודמת ל-1.31.6-gke.1027000, דלגו לקטע הבא.

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

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-autopilot-compatibility-auditing

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של אשכול Standard.
    • ‫LOCATION: המיקום של אשכול Standard, למשל us-central1.

    פעולת העדכון נמשכת עד 30 דקות.

הרצת בדיקה לפני טיסה באשכול רגיל

‫Google Cloud CLI ו-Google Kubernetes Engine API מספקים כלי לביצוע בדיקה לפני הפעלה שמאמת את המפרטים של עומסי העבודה הרגילים שפועלים כדי לזהות אי-תאימויות עם אשכולות Autopilot. הכלי הזה זמין ב-GKE מגרסה 1.26 ואילך.

  • כדי להשתמש בכלי הזה בשורת הפקודה, מריצים את הפקודה הבאה:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME

מחליפים את CLUSTER_NAME בשם של אשכול Standard. אפשר גם להוסיף --format=json לפקודה הזו כדי לקבל את הפלט בקובץ JSON.

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

תוצאות של כלי בדיקה לפני טיסה
Passed עומס העבודה יפעל כצפוי ללא צורך בהגדרה של Autopilot.
Passed with optional configuration

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

לדוגמה, אם עומס העבודה שלכם פעל במכונות N2 במצב רגיל, ‏ GKE יחיל את סוג המחשוב לשימוש כללי במצב Autopilot. אפשר גם לשנות את עומס העבודה כדי לבקש את מחלקת המחשוב המאוזנת, שמגובה על ידי מכונות N2.
Additional configuration required

עומס העבודה לא יפעל ב-Autopilot אלא אם תבצעו שינוי בהגדרות.

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

עומס העבודה לא יפעל ב-Autopilot כי הוא משתמש בפונקציונליות שלא נתמכת ב-Autopilot.

לדוגמה, אשכולות Autopilot דוחים Pods עם הרשאות (privileged: true במפרט של ה-Pod) כדי לשפר את מצב האבטחה שמוגדר כברירת מחדל. הדרך היחידה להפעיל את האפליקציה הזו ב-Autopilot היא להסיר את הגדרת ההרשאות.

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

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

ההבדל הכי חשוב בין Autopilot לבין Standard הוא שהגדרת התשתית ב-Autopilot מתבצעת באופן אוטומטי על סמך מפרט עומס העבודה. אמצעי בקרה לתזמון ב-Kubernetes, כמו node taints ו-tolerations, מתווספים אוטומטית לעומסי העבודה הפעילים. במקרה הצורך, צריך לשנות גם את ההגדרות של התשתית כקוד, כמו תרשימי Helm או שכבות-על של Kustomize, כך שיתאימו.

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

שינויים נפוצים בהגדרות של Autopilot
הגדרת מחשוב וארכיטקטורה

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

פרטים נוספים זמינים במאמר בנושא סוגי מחשוב ב-Autopilot.
מאיצים

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

פרטים נוספים זמינים במאמר בנושא פריסת עומסי עבודה של GPU ב-Autopilot.
בקשות למשאבים

בכל עומסי העבודה של Autopilot צריך לציין ערכים עבור resources.requests במפרט של ה-Pod. GKE משתמש בערכים האלה כדי להקצות גדלים מתאימים של מכונות להרצת ה-Pods. אם משמיטים בקשות כלשהן, טייס אוטומטי מחיל אוטומטית בקשות ברירת מחדל ספציפיות, ומחיל ערכי מינימום ומקסימום ספציפיים בהתאם לסוג המחשוב או לבקשת החומרה של עומס העבודה.

פרטים נוספים זמינים במאמר בנושא בקשות למשאבים ב-Autopilot.
עומסי עבודה עמידים בכשלים ב-VMs במודל Spot

אם עומסי העבודה שלכם פועלים במכונות וירטואליות מסוג Spot ב-Standard, אתם יכולים לבקש Spot Pods בהגדרות של עומס העבודה על ידי הגדרת node selector ל-cloud.google.com/gke-spot=true.

פרטים נוספים זמינים במאמר בנושא Spot Pods.

ביצוע הרצה יבשה באשכול Autopilot בשלב ההכנה

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

שורת הפקודה

מריצים את הפקודה הבאה:

kubectl create --dry-run=server -f=PATH_TO_MANIFEST

מחליפים את הערך ב-PATH_TO_MANIFEST בנתיב למניפסט של עומס העבודה ששיניתם.

סביבת פיתוח משולבת (IDE)

אם משתמשים בכלי Cloud Shell Editor, הפקודה להרצה יבשה מוטמעת בו ומופעלת בכל המניפסטים הפתוחים. אם אתם משתמשים ב-Visual Studio Code או ב-Intellij IDE, אתם יכולים להתקין את התוסף Cloud Code כדי להריץ אוטומטית את ההרצה היבשה על כל קובץ מניפסט פתוח.

בחלונית Problems בסביבת הפיתוח המשולבת (IDE) מוצגות בעיות שזוהו בהרצה היבשה, כמו בדוגמה הבאה שבה מוצגת הרצה יבשה שנכשלה עבור מניפסט שצוין בו privileged: true.

פלט של הרצת ניסיון ב-Visual Studio Code למניפסט בשם application.yaml. ההודעה היא: נכשלה ההרצה היבשה של השרת בהקשר הנוכחי: בקשת ה-webhook של הגישה נדחתה.

תכנון אשכול היעד של Autopilot

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

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

בנוסף, כדאי לשים לב לנקודות הבאות:

  • אשכולות Autopilot הם אשכולות מקוריים של VPC, ולכן לא מומלץ לבצע מיגרציה לאשכולות Autopilot מאשכולות Standard מבוססי-נתיבים.
  • מומלץ להשתמש באותו VPC או ב-VPC דומה לאשכול Autopilot ולאשכול Standard, כולל כל כללי חומת האש והגדרות ה-VPC בהתאמה אישית.
  • אשכולות Autopilot משתמשים ב-GKE Dataplane V2 ותומכים רק ב-Cilium NetworkPolicies. אין תמיכה ב-Calico NetworkPolicies.
  • אם רוצים להשתמש בהסוואת כתובת IP ב-Autopilot, צריך להשתמש במדיניות NAT ליציאה.
  • מציינים את טווח ה-IPv4 הראשי של האשכול במהלך יצירת האשכול, עם גודל טווח זהה לזה של אשכול רגיל.
  • כדאי לקרוא על ההבדלים במכסות בין המצבים, במיוחד אם יש לכם אשכולות גדולים.
  • מידע על המספר המקסימלי של פודים לכל צומת ב-Autopilot, ששונה מהמספר המקסימלי ב-Standard. החשיבות של זה גדולה יותר אם אתם משתמשים לעיתים קרובות בזיקה לצומת או ל-Pod.
  • כל אשכולות Autopilot משתמשים ב-Cloud DNS.

יצירת אשכול Autopilot

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

עדכון כלי התשתית כקוד

ספקי התשתית כקוד הבאים תומכים ב-Autopilot:

קוראים את התיעוד של הספק המועדף ומשנים את ההגדרות.

בחירת גישה להעברה

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

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

בעומסי עבודה של Passed ו-Passed with optional configuration, אפשר גם להשתמש ב-Backup for GKE כדי להעביר את כל עומסי העבודה לאשכול Autopilot. עדיין צריך לעדכן את צינור הנתונים ואת קובצי המניפסט במעלה הזרם כדי לטרגט את אשכול Autopilot. לשלבים ברמה גבוהה, אפשר לעיין במאמר העברת כל עומסי העבודה באמצעות גיבוי ל-GKE.
עם שמירת מצב
  • עבר
  • עבר עם הגדרה אופציונלית

אפשר להשתמש באחת מהשיטות הבאות:

  • גיבוי ל-GKE: אפשר להשתמש בגיבוי ל-GKE כדי להעביר עומסי עבודה עם שמירת מצב לאשכול Autopilot, תוך שמירה על הקשרים הקיימים של PersistentVolume. לשלבים ברמה גבוהה, אפשר לעיין במאמר העברת כל עומסי העבודה באמצעות גיבוי ל-GKE. יש תמיכה בהעברה בין אזורים.
  • ידני: מעבירים את עומסי העבודה עם שמירת הנתונים באופן ידני. הגישה הזו מחייבת תכנון קפדני יותר של PersistentVolumes ושל דיסקים ב-Compute Engine. הוראות כלליות מפורטות במאמר העברה ידנית של עומסי עבודה עם שמירת מצב. אין תמיכה בהעברה בין אזורים.
נדרשת הגדרה נוספת צריך לעדכן את קובצי המניפסט של Kubernetes ולפרוס מחדש ב-Autopilot במהלך השבתה מתוזמנת. הוראות כלליות מפורטות במאמר העברה ידנית של עומסי עבודה עם שמירת מצב.

שלבים כלליים להעברה

לפני שמתחילים בהעברה, צריך לוודא שפתרתם את כל התוצאות Incompatible או Additional configuration required מבדיקת ההכנה להעברה. אם תפרסו עומסי עבודה עם התוצאות האלה ב-Autopilot בלי לבצע שינויים, עומסי העבודה ייכשלו.

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

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

העברת כל עומסי העבודה באמצעות גיבוי ל-GKE

אם כל עומסי העבודה (עם שמירת מצב ובלי שמירת מצב) שפועלים באשכול Standard שלכם תואמים ל-Autopilot, וכלי הבדיקה המקדימה מחזיר Passed או Passed with optional configuration לכל עומס עבודה, אתם יכולים להשתמש ב-Backup for GKE כדי לגבות את כל המצב של אשכול Standard ועומסי העבודה שלכם, ולשחזר את הגיבוי באשכול Autopilot.

היתרונות של הגישה הזו:

  • אתם יכולים להעביר את כל עומסי העבודה ממצב Standard למצב Autopilot עם הגדרה מינימלית.
  • אתם יכולים להעביר עומסי עבודה ללא מצב (stateless) ועומסי עבודה עם מצב (stateful) ולשמור על הקשרים בין עומסי העבודה, וגם על PersistentVolumes משויכים.
  • החזרה לגרסה קודמת היא אינטואיטיבית ומנוהלת על ידי Google. אפשר לבטל את כל ההעברה או לבטל באופן סלקטיבי עומסי עבודה ספציפיים.
  • אפשר להעביר עומסי עבודה עם שמירת מצב בין Google Cloud אזורים. העברה ידנית של עומסי עבודה עם שמירת מצב יכולה להתבצע רק באותו אזור.

כשמשתמשים בשיטה הזו, GKE מחיל את הגדרות ברירת המחדל של Autopilot על עומסי עבודה שקיבלו תוצאה של Passed with optional configuration מהכלי לבדיקה לפני הפעלה. לפני שמעבירים את עומסי העבודה האלה, חשוב לוודא שהגדרות ברירת המחדל האלה מתאימות לכם.

העברה ידנית של עומסי עבודה (workloads) ללא מצב (stateless) ללא זמן השבתה

כדי להעביר עומסי עבודה ללא מצב (stateless) בלי להשבית את השירותים, צריך לרשום את אשכולות המקור והיעד ל-GKE Fleet ולהשתמש בשירותים מרובי-אשכולות וב-Ingress מרובה-אשכולות כדי לוודא שעומסי העבודה יישארו זמינים במהלך המיגרציה.

  1. מפעילים שירותים מרובי אשכולות ותעבורת נתונים נכנסת (ingress) של אשכול מרובה באשכול המקור ובאשכול היעד. הוראות מופיעות במאמרים הגדרת שירותים מרובי-אשכולות והגדרת Multi Cluster Ingress.
  2. אם יש לכם תלות בקצה העורפי, כמו עומס עבודה של מסד נתונים, תוכלו לייצא את השירותים האלה מהאשכול הרגיל באמצעות שירותים מרובי-אשכולות. כך עומסי העבודה באשכול Autopilot יכולים לגשת לתלות באשכול Standard. הוראות מפורטות מופיעות במאמר בנושא רישום שירות לייצוא.
  3. פריסת Ingress מרובה אשכולות ושירות מרובה אשכולות כדי לשלוט בתעבורת נתונים נכנסת בין אשכולות. מגדירים את שירות מרובה האשכולות כך שישלח תעבורה רק לאשכול Standard. הוראות מפורטות זמינות במאמר בנושא פריסת Ingress בכמה אשכולות.
  4. פורסים את עומסי העבודה (workloads) בלי שמירת מצב עם מניפסטים מעודכנים לאשכול Autopilot. שירותים מרובי אשכולות שמייצאים מתאימים אוטומטית ושולחים תנועה לעומסי העבודה התואמים עם שמירת מצב.
  5. מעדכנים את השירות מרובה האשכולות כדי להפנות תנועה נכנסת לאשכול Autopilot. הוראות מפורטות מופיעות במאמר בנושא בחירת אשכול.

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

העברה ידנית של עומסי עבודה עם שמירת מצב

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

  1. מתחילים את ההשבתה של הסביבה.
  2. משביתים את עומסי העבודה (workloads) עם שמירת מצב.
  3. מוודאים ששיניתם את מניפסטים של עומסי העבודה כדי שיהיו תואמים ל-Autopilot. פרטים נוספים זמינים במאמר שינוי המפרטים של עומס העבודה על סמך תוצאות הבדיקה המקדימה.

  4. פורסים את עומסי העבודה באשכול Autopilot.

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

  6. צריך לעדכן את הרישות בתוך האשכול כדי שעומסי העבודה בלי שמירת מצב יוכלו להמשיך לתקשר עם עומסי העבודה של ה-בק-אנד:

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

בשלב הזה, התנאים הבאים צריכים להתקיים:

  • אתם מריצים את כל עומסי העבודה (workloads) ללא שמירת מצב (stateless) ב-Autopilot.
  • כל עומסי העבודה עם שמירת מצב (stateful) של ה-backend פועלים גם הם ב-Autopilot.
  • עומסי העבודה בלי שמירת מצב ועומסי העבודה עם שמירת מצב יכולים לתקשר ביניהם.
  • שירות מרובה אשכולות מפנה את כל התנועה הנכנסת לאשכול Autopilot.

אחרי שמעבירים את כל עומסי העבודה ואת אובייקטי Kubernetes לאשכול החדש, ממשיכים אל השלמת ההעברה.

אפשרות חלופית: העברה ידנית של כל עומסי העבודה במהלך זמן ההשבתה

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

  1. מתחילים את השעות השקטות.
  2. פורסים את המניפסטים חסרי המצב באשכול Autopilot.
  3. העברה ידנית של עומסי עבודה (workloads) עם שמירת מצב. הוראות מפורטות מופיעות בקטע העברה ידנית של עומסי עבודה עם שמירת מצב.
  4. צריך לשנות את רשומות ה-DNS גם לתעבורה פנימית בין צמתים וגם לתעבורה חיצונית נכנסת, כדי להשתמש בכתובות ה-IP החדשות של השירותים.
  5. סיום זמן ההשבתה.

השלמת ההעברה

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

אופציונלי: ניקוי תכונות של אשכולות מרובים

אם השתמשתם ב-Ingress מרובה אשכולות ובשירותים מרובי אשכולות כדי לבצע את ההעברה, ואתם לא רוצים שאשכול Autopilot יישאר רשום ב-Fleet, אתם צריכים לבצע את הפעולות הבאות:

  1. לתעבורת נתונים נכנסת (ingress) חיצונית, פורסים Ingress ומגדירים אותו לכתובת ה-IP של השירותים שחושפים את עומסי העבודה. הוראות מפורטות מופיעות במאמר בנושא Ingress למאזני עומסים חיצוניים של אפליקציות.
  2. לתעבורה בתוך האשכול, כמו מעומסי עבודה של קצה קדמי לתלות עם שמירת מצב, צריך לעדכן את רשומות ה-DNS של האשכול כדי להשתמש בכתובות ה-IP של השירותים האלה.
  3. מוחקים את משאבי ה-Ingress מרובי האשכולות ואת משאבי השירות מרובי האשכולות שיצרתם במהלך ההעברה.
  4. השבתה של תעבורת נתונים נכנסת (ingress) של אשכול מרובה ושירותים מרובי אשכולות.
  5. ביטול הרישום של אשכול Autopilot ב-Fleet.

מחיקת האשכול הרגיל

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

ביטול של העברה פגומה

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

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

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

    1. מתחילים את השעות השקטות.
    2. העברה ידנית של עומסי עבודה (workloads) עם שמירת מצב לאשכול Standard. הוראות מפורטות מופיעות בקטע העברה ידנית של עומסי עבודה עם שמירת מצב.
    3. מעבירים עומסי עבודה בלי שמירת מצב לאשכול Standard באמצעות המניפסטים המקוריים שגיביתם לפני ההעברה.
    4. פורסים את ה-Ingress באשכול הרגיל ומבצעים מעבר חד של ה-DNS לכתובות ה-IP החדשות של השירותים.
    5. מחיקת אשכול Autopilot.

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