הכנה למעבר מ-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. מבצעים את ההעברה.

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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 ו-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 במצב Standard, ‏ 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. אם אתם צריכים סוגים אחרים של מכונות, במפרט של עומס העבודה צריך לבקש סוג מחשוב, כדי שמצב אוטומטי ימקם את ה-Pods האלה בצמתים שמשתמשים בסוגים או בארכיטקטורות ספציפיים של מכונות.

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

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

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

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

פרטים נוספים זמינים במאמר בנושא בקשות למשאבים ב-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. ההודעה היא: Failed server dry-run apply on current-context: admission webhook denied the request.

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

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

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

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

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

יצירת אשכול Autopilot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השלמת ההעברה

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

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

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

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

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

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

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

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

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

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

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

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