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

סקירה כללית

בדף הזה מוסבר איך להעביר אשכולות משתמשים מגרסה 1.30 ואילך לתכונות המומלצות הבאות:

• מעבר ל-Dataplane V2 בתור ממשק הרשת של הקונטיינר (CNI).
• העברת אשכולות של משתמשים באמצעות kubeception ל-Controlplane V2.

• מעבירים את ההגדרות של מאזן העומסים:

  • מההגדרות של מאזן העומסים המשולב F5 BIG-IP אל ManualLB

    או

  • ממאזן העומסים המצורף Seesaw ל-MetalLB.

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

שיטות מומלצות

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

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

מידע נוסף על תכנון ההעברה זמין במאמר תכנון העברת אשכולות לתכונות מומלצות.

דרישות

בהעברה הזו:

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

שמירה על כתובת ה-IP של הלקוח ב-Seesaw

אזהרה: אל תעברו ל-MetalLB אם אתם מסתמכים על Seesaw כדי לשמור את כתובת ה-IP של הלקוח. באופן ספציפי, אל תעברו ל-MetalLB אם יש באשכול שירותים שבהם spec.externalTrafficPolicy מוגדר ל-Local.

כדי לבדוק את externalTrafficPolicy, מריצים את הפקודה הבאה:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

אם נתקלתם בבעיה הזו, פנו לתמיכה של Google.

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

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

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

כדי להעריך את משך הזמן שנדרש, סופרים את מספר הפעמים שצריך לעדכן את האשכול. השלבים הכלליים הבאים מראים מתי צריך להריץ את gkectl update cluster כדי לעדכן את האשכול:

1. אם באשכול המשתמשים מופעלת הצפנה תמידית של סודות, צריך להשבית את התכונה ולהריץ את gkectl update cluster.
2. אם באשכול המשתמשים לא הוגדר enableDataplaneV2 או שהוא הוגדר כ-false, צריך לבצע את השינויים בהגדרות ואז להריץ את gkectl update cluster כדי להעביר ל-Dataplane V2.

3. הכנה להעברה של מאזן העומסים ומישור הבקרה:

   1. אם באשכול האדמין מופעל תיקון אוטומטי, צריך להשבית אותו. ואז מריצים את gkectl update admin. העדכון הזה מסתיים במהירות כי הוא לא יוצר מחדש את הצמתים של אשכול האדמין.
   2. אם באשכול המשתמש נעשה שימוש ב-Seesaw, בוחרים מאגר של צמתים שבו ישתמש מאזן העומסים MetalLB, ואז מריצים את gkectl update cluster. העדכון הזה מעדכן רק את הצמתים במאגר הצמתים שנבחר.

4. מבצעים את כל השינויים הנדרשים בהגדרות כדי לעדכן את מאזן העומסים ולעבור ל-Controlplane V2. ואז מריצים את gkectl update cluster.

5. אם השבתתם את ההצפנה התמידית של הסודות, אחרי ההעברה תצטרכו להפעיל מחדש את התכונה ולהריץ את הפקודה gkectl update cluster.

משך הזמן הכולל של ההעברה תלוי במספר הפעמים שצריך להריץ את gkectl cluster update, וזה תלוי בהגדרות שלכם. לדוגמה, נניח שאתם עוברים ל-Dataplane V2, ל-ControlPlane V2 ול-MetalLB. נניח גם שיש 10 צמתים במאגר הצמתים הגדול ביותר ו-3 צמתים במאגר הצמתים שבו MetalLB ישתמש. כדי לחשב את זמן ההעברה המשוער, צריך להוסיף את הנתונים הבאים:

• ‫150 דקות להעברה ל-Dataplane V2, כי 15 דקות * 10 צמתים במאגר הכי גדול = 150 דקות.
• 45 דקות למאגר הצמתים שמשמש את MetalLB, כי 15 דקות כפול 3 צמתים במאגר הצמתים הזה שווה ל-45 דקות.
• ‫150 דקות לעדכון של Controlplane V2 ו-MetalLB, כי 15 דקות כפול 10 צמתים במאגר הכי גדול שווה 150 דקות.

הזמן הכולל של ההעברה הוא בערך 345 דקות, כלומר 5 שעות ו-45 דקות.

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

תכנון זמן ההשבתה במהלך ההעברה

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

• זמן השבתה של מישור הבקרה: הגישה לשרת ה-API של Kubernetes מושפעת במהלך ההעברה. אם אתם עוברים ל-Controlplane V2, מישור הבקרה מושבת באשכולות משתמשים של kubeception בזמן ההעברה של loadBalancer.vips.controlPlaneVIP. בדרך כלל זמן ההשבתה נמשך פחות מ-10 דקות, אבל משך הזמן תלוי בתשתית שלכם.
• זמן השבתה של עומס העבודה: כתובות ה-IP הווירטואליות (VIP) שמשמשות את השירותים מסוג LoadBalancer לא זמינות. זה קורה רק במהלך העברה מ-Seesaw ל-MetalLB. תהליך ההעברה של MetalLB יפסיק את החיבורים לרשת לכל כתובות ה-VIP באשכול המשתמשים של שירותי Kubernetes מסוג LoadBalancer למשך שתיים עד עשר דקות. אחרי שההעברה מסתיימת, החיבורים פועלים שוב.

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

מאת	אל	גישה ל-Kubernetes API	עומסי עבודה של משתמשים
אשכול Kubeception שמשתמש ב-Calico, שבו הערך של enableDataplaneV2 לא מוגדר או מוגדר כ-false	אשכול Kubeception עם Dataplane V2	אין השפעה	אין השפעה
אשכול Kubeception, שבו enableControlplaneV2 לא מוגדר או מוגדר ל-false עם MetalLB או ManualLB	אשכול Controlplane V2 עם אותו סוג של מאזן עומסים	מושפעים	אין השפעה
אשכול Kubeception עם loadBalancer.kind: "F5BigIP"	אשכול Controlplane V2 עם הגדרת איזון עומסים ידני	מושפעים	אין השפעה
אשכול Kubeception עם loadBalancer.kind: "Seesaw"	אשכול Controlplane V2 עם MetalLB	מושפעים	מושפעים

• מושפע: יש הפרעה משמעותית בשירות במהלך ההעברה.
• לא מושפע: אין הפרעה לשירות או שהיא כמעט לא מורגשת.

הכנה להעברה

כדי שההעברה תתבצע בהצלחה, צריך לבצע את השלבים בקטעים הבאים.

הקצאת כתובות IP חדשות

אם אתם עוברים ל-Controlplane V2, הקצו כתובות IP סטטיות חדשות באותו VLAN כמו צומתי העובדים (הצמתים במאגרי הצמתים).

• צריך כתובת IP אחת ל-loadBalancer.vips.controlPlaneVIP.

• מקצים כתובת IP אחת לכל צומת במישור הבקרה. מספר כתובות ה-IP שצריך להקצות תלוי בשאלה אם אשכול המשתמשים יהיה בזמינות גבוהה (HA) או לא.

  • ללא זמינות גבוהה: כתובת IP אחת
  • HA: שלוש כתובות IP

עדכון הכללים של חומת האש

אם אתם עוברים ל-Controlplane V2, עדכנו את כללי חומת האש באשכולות המשתמשים. מוודאים שכתובות ה-IP החדשות שהוקצו לצומתי מישור הבקרה באשכול המשתמש יכולות להגיע לכל ממשקי ה-API הנדרשים וליעדים אחרים, כפי שמתואר בקטע כללי חומת אש לצומתי אשכול המשתמש.

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

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

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

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

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

בודקים את תקינות האשכול ומתקנים את הבעיות שדווחו באמצעות הפקודה gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name USER_CLUSTER_NAME

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

• ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
• ‫USER_CLUSTER_NAME: שם אשכול המשתמש.

השבתת התיקון האוטומטי באשכול האדמין

אם אתם מעבירים את אשכול המשתמשים לשימוש ב-Controlplane V2 והתיקון האוטומטי מופעל באשכול האדמין, השביתו את התיקון האוטומטי. בודקים את השדה autoRepair.enabled בקובץ התצורה של אשכול האדמין. אם השדה הזה לא מוגדר או מוגדר לערך true, מבצעים את הפעולות הבאות:

1. בקובץ התצורה של אשכול האדמין, מגדירים את autoRepair.enabled לערך false . לדוגמה:

   autoRepair:
     enabled: false
   

2. מעדכנים את אשכול האדמין:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG
   

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

• ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
• ‫ADMIN_CLUSTER_CONFIG: הנתיב לקובץ התצורה של אשכול האדמין.

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

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

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

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

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

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

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

בדוגמה הבאה מוצג פלט לא ריק:

{"generatedKeyVersions":{"keyVersions":[1]}}

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

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

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

1. כדי להשבית את ההצפנה של סודות שפועלת תמיד, מוסיפים את השדה disabled: true לקטע secretsEncryption בקובץ התצורה של אשכול המשתמש:

   secretsEncryption:
       mode: GeneratedKey
       generatedKey:
           keyVersion: KEY_VERSION
           disabled: true
   

2. מעדכנים את האשכול:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

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

   • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין
   • ‫USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמש

3. מבצעים עדכון בהדרגה (rolling) ב-DaemonSet ספציפי, באופן הבא:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     rollout restart statefulsets kube-apiserver \
     -n USER_CLUSTER_NAME

4. משיגים את המניפסטים של כל הסודות באשכול המשתמש, בפורמט YAML:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     get secrets -A -o yaml > SECRETS_MANIFEST.yaml

5. כדי שכל הסודות יאוחסנו ב-etcd כטקסט פשוט, צריך להחיל מחדש את כל הסודות באשכול המשתמש:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     apply -f SECRETS_MANIFEST.yaml

   עכשיו אפשר להתחיל את המעבר ל-Controlplane V2. אחרי שההעברה מסתיימת, אפשר להפעיל מחדש את הצפנת הסודות בזמינות תמידית באשכול.

בדיקה אם יש בעיה בהגדרות של ה-webhooks של עומס העבודה

אם אתם מעבירים את אשכול המשתמשים לשימוש ב-Controlplane V2, בדקו אם יש בעיה עם תצורות שגויות של רשתות לפעולות מאפליקציות (webhooks) של עומסי עבודה.

אם יש לכם רשתות לפעילויות אינטרנט שכוללות pod של המערכת במרחב השמות kube-system, הוסיפו את namespaceSelector כדי לסנן את מרחב השמות kube-system.

לדוגמה,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

הפעלת מאגר צמתים לשימוש ב-MetalLB

אם אתם עוברים ממאזן העומסים המצורף Seesaw ל-MetalLB, בצעו את השלבים שבקטע הזה. האשכול משתמש ב-Seesaw אם loadBalancer.kind: Seesaw נמצא בקובץ התצורה של אשכול המשתמש. אם אתם מעבירים את ההגדרות המשולבות של F5 BIG-IP, דלגו לקטע הבא, מעבר ל-Dataplane V2.

בוחרים מאגר צמתים ומפעילים אותו לשימוש עם MetalLB. ההעברה פורסת את MetalLB בצמתים במאגר הצמתים הזה.

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

1. בקטע nodePools בקובץ התצורה של אשכול המשתמש, בוחרים מאגר צמתים או מוסיפים מאגר צמתים חדש ומגדירים את enableLoadBalancer ל-true. לדוגמה:

   nodePools:
     - name: pool-1
       replicas: 3
       enableLoadBalancer: true
   

2. מעדכנים את האשכול:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

מידע נוסף על MetalLB זמין במאמר איזון עומסים בחבילה עם MetalLB.

מעבר ל-Dataplane V2

לפני ההעברה, בודקים אם DataPlane V2 מופעל באשכול באמצעות הפקודה הבאה:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

אם Dataplane V2 כבר מופעל:

• אם האשכול נוצר במקור כש-Dataplane V2 מופעל, דלגו אל הכנה להעברת מאזן העומסים.
• אם האשכול הועבר בעבר מ-Calico ל-Dataplane V2 (לדוגמה, במהלך שדרוג לגרסה 1.31), דלגו לקטע הסרת DaemonSets רדומים של Calico.

כדי לעבור ל-Dataplane V2, אתם יכולים:

• משדרגים את האשכול לגרסה 1.31. לשלבים מפורטים, ראו הפעלת Dataplane V2.

• מעדכנים את האשכול בגרסה 1.30.

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

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

אם באשכול שלכם משתמשים ב-NetworkPolicy, צריך להסיר באופן זמני את המפרט שלו מהאשכול, באופן הבא:

1. בודקים אם יש NetworkPolicy שלא שייך למערכת שהוחל על האשכול:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system
   

2. אם הפלט של השלב הקודם לא היה ריק, שומרים כל מפרט של NetworkPolicy בקובץ כדי שתוכלו להחיל מחדש את המפרט אחרי עדכון האשכול.

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
   

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

   • ‫NETWORK_POLICY_NAME: השם של ה-NetworkPolicy שאתם שומרים.
   • ‫NETWORK_POLICY_NAMESPACE: מרחב השמות של NetworkPolicy.

3. מוחקים את NetworkPolicy באמצעות הפקודה הבאה:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE
   

כדי לעבור ל-Dataplane V2:

1. מגדירים את enableDataplaneV2 לערך true בקובץ התצורה של אשכול המשתמשים.

2. כדי להפעיל את DataPlane V2, מעדכנים את האשכול:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   --config USER_CLUSTER_CONFIG
   

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

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
   

הפעלתם את Dataplane V2.

הסרת DaemonSets רדומים של Calico

אחרי שמעבירים אשכול אדמין או אשכול משתמש מ-Calico ל-Dataplane V2, קבוצות ה-DaemonSet‏ calico-node ו-calico-route-daemon נשארות רדומות במרחב השמות kube-system כדי לשמר את היכולת לחזור למצב הקודם. לפני שמשנים את קנה המידה של האשכול או משדרגים אותו, צריך להסיר את ההערה features.onprem.cluster.gke.io/dpv2-migration פעם אחת לכל אשכול שהועבר, כדי שבקר האשכול ימחק באופן סופי את ה-DaemonSets הרדומים של Calico וימנע מהם לבצע אתחול בצמתים חדשים (ראו את הבעיה הידועה הפסקות קצובות לסירוגין בחיבור אחרי שדרוג או שינוי קנה המידה של אשכול שהועבר מ-Calico ל-Dataplane V2). אין צורך לבצע את השלבים האלה באשכולות שנוצרו כש-Dataplane V2 מופעל.

זהירות: הסירו את ההערה הזו רק אחרי שההעברה ל-Dataplane V2 הושלמה בכל הצמתים. אם תסירו אותו באשכול שעדיין משתמש ב-Calico או שנמצא באמצע תהליך ההעברה, Calico יוסר מהצמתים הקיימים ורשת ה-Pod תופרע.

1. מוודאים שההעברה ל-Dataplane V2 הושלמה, ושלכל הצמתים באשכול יש את התווית networking.gke.io/cni-type: cilium:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes -L networking.gke.io/cni-type
   

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

2. אחרי שמוודאים ש-Dataplane V2 פועל בכל הצמתים ואין יותר צורך לחזור ל-Calico, מסירים את ההערה features.onprem.cluster.gke.io/dpv2-migration מהמשאב בהתאמה אישית OnPremUserCluster (וגם מ-OnPremAdminCluster אם אשכול האדמין הועבר מ-Calico במהלך השדרוג מגרסה 1.29 ל-1.30):

   # For a user cluster:
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremusercluster USER_CLUSTER_NAME \
       -n USER_CLUSTER_NAME-gke-onprem-mgmt \
       features.onprem.cluster.gke.io/dpv2-migration-
   
   # For an admin cluster:
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremadmincluster ADMIN_CLUSTER_NAME \
       -n kube-system \
       features.onprem.cluster.gke.io/dpv2-migration-
   

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

   • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
   • ‫USER_CLUSTER_NAME: שם אשכול המשתמש.
   • ‫ADMIN_CLUSTER_NAME: השם של אשכול האדמין (אפשר למצוא אותו על ידי הרצת kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremadmincluster -n kube-system).
   הערה: אל תשתמשו ב-kubectl delete daemonset כדי למחוק ידנית את ה-DaemonSets, כי בקר האשכול מתאים את חבילת התוספים במהלך עדכונים ושדרוגים ויוצר אותם מחדש, אלא אם מסירים את ההערה features.onprem.cluster.gke.io/dpv2-migration.

3. מוודאים שהבקר מחק את ה-DaemonSets של calico-node ו-calico-route-daemon (שניהם מחזירים NotFound):

   kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-system get daemonset calico-node calico-route-daemon
   

בשלב הבא, מכינים את האשכול להעברה למאזן העומסים המומלץ ול-Controlplane V2.

הכנה להעברת מאזן העומסים

אם אשכולות המשתמשים שלכם משתמשים במאזן העומסים Seesaw או ב-F5 BIG-IP משולב, בצעו את השלבים בקטע הזה כדי לבצע את השינויים הנדרשים בקובץ התצורה של אשכול המשתמשים. אחרת, דלגו לקטע הבא, הכנה להעברה ל-Controlplane V2.

F5 BIG-IP

אם האשכולות שלכם משתמשים בהגדרת F5 BIG-IP המשולבת, כדי להתכונן למיגרציה ל-ManualLB, בצעו את השינויים הבאים בקובץ התצורה של אשכול המשתמש:

1. משנים את loadBalancer.kind ל-"ManualLB".
2. משאירים את אותו ערך בשדה loadBalancer.vips.ingressVIP.
3. אם אתם עוברים ל-Controlplane V2, צריך לשנות את הערך של השדה loadBalancer.vips.controlPlaneVIP לכתובת ה-IP שהקציתם. אם לא, אפשר להשאיר את אותו ערך.
4. מוחקים את כל הקטע loadBalancer.f5BigIP.

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

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

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

ציון מאגרי כתובות

בקר MetalLB מקצה כתובות IP לשירותים. כשמפתחי אפליקציות יוצרים שירות מסוג LoadBalancer באשכול משתמש, בקר MetalLB מקצה באופן אוטומטי כתובת IP לשירות. הבקר של MetalLB בוחר כתובת IP ממאגר כתובות שאתם מציינים.

כדי לוודא שיש מספיק כתובות IP באשכול המשתמש, כדאי להביא בחשבון את המספר המקסימלי של שירותי LoadBalancer שצפויים להיות פעילים. לאחר מכן, מציינים מספיק כתובות IP בקטע loadBalancer.metalLB.addressPools בקובץ התצורה של אשכול המשתמשים.

נקודה חשובה: מכיוון ששירות מסוג LoadBalancer חושף את שרת ה-proxy של Ingress, צריך לכלול את כתובת ה-VIP של Ingress של אשכול המשתמשים באחד ממאגרי הכתובות.

הכתובות במאגר צריכות להיות בפורמט CIDR או בפורמט של טווח. כדי לציין כתובת ספציפית, משתמשים ב-CIDR של /32. לדוגמה:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

החרגה של כתובות IP שמשמשות למטרות אחרות

אל תכללו את כתובות ה-IP הבאות במאגר כתובות:

• כתובות ה-VIP של מישור הבקרה:

  • אשכול אדמין
  • אשכול משתמשים

• כתובות ה-IP של צומתי מישור הבקרה:

  • אשכול אדמין
  • אשכול משתמשים

• כתובות ה-IP של השער:

  • אשכול אדמין
  • אשכול משתמשים

• כתובות IP של שירותים:

  • אשכול אדמין
  • אשכול משתמשים

• כתובות IP לפודים:

  • אשכול אדמין
  • אשכול משתמשים

• כתובות ה-IP של צומתי העובדים באשכול המשתמש

• כתובות ה-IP של שרתי vCenter, שרתי DNS, שרתי NTP ותחנת הניהול

עדכון קובץ התצורה של האשכול

מעדכנים את קובץ התצורה של האשכול כדי להסיר את הקטע של Seesaw ולהוסיף את הקטע של MetalLB, באופן הבא:

1. מגדירים את loadBalancer.kind להיות "MetalLB".
2. אפשר להשאיר את אותו ערך בשדה loadBalancer.vips.ingressVIP.
3. מוסיפים את כתובת ה-VIP של הכניסה למאגר כתובות של MetalLB.
4. אם אתם עוברים ל-Controlplane V2, צריך לשנות את הערך של השדה loadBalancer.vips.controlPlaneVIP לכתובת ה-IP שהקציתם. אם לא, אפשר להשאיר את אותו ערך.
5. מסירים את הקטע loadBalancer.seesaw.
6. מוסיפים קטע loadBalancer.metalLB.

בחלק הבא של קובץ התצורה של אשכול המשתמשים מוצגים השינויים האלה וההגדרה של MetalLB:

• מאגר כתובות שממנו בקר MetalLB יכול לבחור ולהקצות לשירותים מסוג LoadBalancer. כתובת ה-VIP של תעבורת הנתונים הנכנסת, שבדוגמה הזו היא 198.51.100.10, נמצאת במאגר הזה בפורמט של טווח, 198.51.100.10/32.
• כתובת ה-VIP שהוקצתה לשרת ה-API של Kubernetes באשכול המשתמש.
• כתובת ה-VIP של הכניסה שהגדרתם לשרת ה-proxy של הכניסה.
• מאגר צמתים שמופעל בו שימוש ב-MetalLB. ההעברה פורסת את MetalLB בצמתים במאגר הצמתים הזה.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
      - name: "address-pool-1"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

הכנה להעברה ל-Controlplane V2

אם באשכול לא מופעל Controlplane V2:

• מעדכנים את קובץ התצורה של אשכול המשתמש.
• אם באשכול מוגדר איזון עומסים ידני (loadBalancer.kind: "ManualLB"), צריך לעדכן גם את ההגדרות במאזן העומסים.

השלבים האלה מתוארים בקטעים הבאים.

אם Controlplane V2 כבר מופעל באשכול, דלגו לקטע העברת אשכול המשתמש.

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

מבצעים את השינויים הבאים בקובץ התצורה הקיים של אשכול המשתמש:

1. מגדירים את enableControlplaneV2 כ-true.
2. אם רוצים, אפשר להגדיר את מישור הבקרה של אשכול המשתמשים ב-Controlplane V2 לזמינות גבוהה (HA). כדי לשנות מאשכול שאינו HA לאשכול HA, משנים את הערך של masterNode.replicas מ-1 ל-3.
3. מוסיפים את כתובת ה-IP הסטטית (או הכתובות) של הצמתים במישור הבקרה של אשכול המשתמשים לקטע network.controlPlaneIPBlock.ips. כתובת ה-IP (או הכתובות) של צומתי מישור הבקרה צריכה להיות באותו VLAN כמו צומתי העובדים. צריך לציין את שמות המארחים.
4. ממלאים את השדות netmask ו-gateway בקטע network.controlPlaneIPBlock.
5. אם הקטע network.hostConfig ריק, ממלאים אותו.
6. מוודאים שבשדה loadBalancer.vips.controlPlaneVIP מופיעה כתובת ה-IP החדשה של ה-VIP של מישור הבקרה. כתובת ה-IP צריכה להיות באותו VLAN כמו כתובות ה-IP של הצמתים במישור הבקרה.
7. אם באשכול המשתמשים מוגדר איזון עומסים ידני, מגדירים את הערך 0 בשדות loadBalancer.manualLB.controlPlaneNodePort ו-loadBalancer.manualLB.konnectivityServerNodePort. הם לא נדרשים כש-Controlplane V2 מופעל, אבל הערך שלהם חייב להיות 0.
8. אם באשכול המשתמשים מוגדר איזון עומסים ידני, צריך להגדיר את מאזן העומסים כמו שמתואר בקטע הבא.

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

במקרה הצורך, משנים את המיפויים במאזן העומסים.

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

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

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

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

אחרי שמגדירים את המיפויים, מאזן העומסים מאזין לתנועה בכתובת ה-IP שהגדרתם ל-VIP של תעבורת הנתונים הנכנסת של אשכול המשתמשים, ביציאות HTTP ו-HTTPS רגילות. מאזן העומסים מנתב את הבקשות לכל צומת באשכול. אחרי שהבקשה מנותבת לאחד מהצמתים באשכול, הרשת הפנימית של Kubernetes מנתבת את הבקשה ל-Pod היעד.

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

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

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

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

העברה ל-Controlplane V2

במהלך ההעברה ל-Controlplane V2, העדכון מבצע את הפעולות הבאות:

1. יצירת מישור הבקרה של אשכול חדש עם ControlPlane V2 מופעל.
2. עצירת מישור הבקרה של Kubernetes באשכול kubeception.
3. מצלם תמונת מצב של etcd באשכול kubeception.
4. מכבה את הצמתים של מישור הבקרה של אשכול המשתמשים באשכול kubeception. עד שההעברה מסתיימת, הצמתים לא נמחקים כדי לאפשר התאוששות מכשל על ידי חזרה לאשכול kubeception.
5. משחזר את נתוני האשכול במישור הבקרה החדש, באמצעות קובץ ה-snapshot של etcd שנוצר בשלב קודם.
6. מחבר את הצמתים של מאגר הצמתים באשכול kubeception למישור הבקרה החדש, שאפשר לגשת אליו באמצעות ה-controlPlaneVIP החדש.
7. התאמה של אשכול המשתמש ששוחזר כדי לעמוד במצב הסופי של האשכול עם ControlPlane V2 מופעל.

שימו לב לנקודות הבאות:

• במהלך ההעברה אין זמן השבתה של עומסי העבודה באשכולות המשתמשים.
• במהלך ההעברה, מישור הבקרה של אשכול המשתמשים מושבת לזמן קצר. באופן ספציפי, מישור הבקרה לא זמין בין עצירת מישור הבקרה של Kubernetes באשכול kubeception לבין השלמת החיבור של הצמתים במאגר הצמתים של אשכול kubeception למישור הבקרה החדש. (בבדיקות, זמן ההשבתה היה פחות מ-7 דקות, אבל משך הזמן בפועל תלוי בתשתית שלכם).
• בסיום ההעברה, הצמתים של מישור הבקרה באשכולות המשתמשים של אשכולות kubeception נמחקים. אם באשכול האדמין הערך של network.ipMode.type מוגדר כ-"static", אתם יכולים למחזר חלק מכתובות ה-IP הסטטיות שלא בשימוש. אתם יכולים להציג את רשימת האובייקטים של הצמתים באשכול האדמין באמצעות kubectl get nodes -o wide כדי לראות אילו כתובות IP נמצאות בשימוש. כדי למחזר את כתובות ה-IP האלה, צריך להסיר אותן מקובץ התצורה של אשכול האדמין ולהריץ את הפקודה gkectl update admin.
• בסיום ההעברה, צומתי העובדים עוברים עדכון בהדרגה (rolling). צריך להמתין עד שכל הצמתים יהיו מוכנים לפני שממשיכים לשלבים שאחרי ההעברה בקטע הבא.
• אחרי ההעברה, כתובת ה-VIP הישנה של מישור הבקרה עדיין פועלת, אבל היא לא יציבה. אל תסתמכו עליו. כדאי לעדכן בהקדם האפשרי את כל התלויות בכתובת ה-VIP הישנה, כדי להשתמש בכתובת ה-VIP החדשה.

אחרי ההעברה

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

1. מוודאים שאשכול המשתמש פועל:

   kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG
   

   הפלט אמור להיראות כך:

   cp-vm-1       Ready    control-plane,master   18m
   cp-vm-2       Ready    control-plane,master   18m
   cp-vm-3       Ready    control-plane,master   18m
   worker-vm-1   Ready                           6m7s
   worker-vm-2   Ready                           6m6s
   worker-vm-3   Ready                           6m14s
   

2. אם עברתם ל-Controlplane V2, עדכנו את כללי חומת האש באשכול האדמין כדי להסיר את הצמתים של מישור הבקרה באשכול המשתמשים של kubeception.

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

   1. בקובץ התצורה של אשכול המשתמש, מסירים את השדה disabled: true.

   2. מעדכנים את אשכול המשתמשים:

      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config USER_CLUSTER_CONFIG
      

4. אם השבתתם את התיקון האוטומטי באשכול האדמין, הפעילו מחדש את התכונה.

   1. בקובץ התצורה של אשכול האדמין, מגדירים את autoRepair.enabled כ-true.

   2. מעדכנים את האשכול:

      gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config ADMIN_CLUSTER_CONFIG
      

העברה של מאזן עומסים

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

העברה של MetalLB

אם עברתם ל-MetalLB, ודאו שהרכיבים של MetalLB פועלים באופן תקין:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

בפלט מוצגים Pods של הבקר והרמקול של MetalLB. לדוגמה:

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

אחרי שההעברה מסתיימת, מוחקים את המכונות הווירטואליות של Seesaw באשכול המשתמשים. השמות של המכונות הווירטואליות של Seesaw מופיעים בקטע vmnames בקובץ seesaw-for-[USERCLUSTERNAME].yaml שבספריית ההגדרות האישיות.

העברת F5 BIG-IP

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

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

הפלט הצפוי אמור להיראות כך:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z