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

סקירה כללית

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

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

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

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

    או

  • ממאזן העומסים Seesaw שכלול בחבילה אל MetalLB.

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

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

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

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

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

דרישות

במיגרציה הזו:

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

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

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

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

בטבלה הבאה מוסבר איך ההעברה משפיעה:

מאת	אל	גישה ל-Kubernetes API	עומסי עבודה של משתמשים
אשכול Kubeception באמצעות Calico, שהערך שלו הוא enableDataplaneV2 unset או 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) או לא.

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

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

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

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

הכתובות במאגר צריכות להיות בפורמט 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 במישור הבקרה:

  • admin cluster
  • user cluster

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

  • admin cluster
  • user cluster

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

  • admin cluster
  • user cluster

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

  • admin cluster
  • user cluster

• כתובות IP של Pods:

  • admin cluster
  • user cluster

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

• כתובות ה-IP של שרתי vCenter,‏ שרתי DNS,‏ שרתי NTP ותחנת העבודה של האדמין

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

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

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

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

• מאגר כתובות שהבקר של MetalLB יכול לבחור מתוכו ולהקצות ל-Services מסוג LoadBalancer. כתובת ה-IP הווירטואלית של הכניסה, שבמקרה הזה היא 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") באשכול, צריך לעדכן גם את ההגדרה במאזן העומסים.

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

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

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

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

1. מגדירים את enableControlplaneV2 לערך true.
2. אופציונלי, אפשר להגדיר זמינות גבוהה (HA) למישור הבקרה של אשכול המשתמשים Controlplane V2. כדי לשנות מאשכול ללא זמינות גבוהה לאשכול עם זמינות גבוהה, משנים את הערך של 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. אם באשכול המשתמשים נעשה שימוש באיזון עומסים ידני, צריך להגדיר את הערכים loadBalancer.manualLB.controlPlaneNodePort ו-loadBalancer.manualLB.konnectivityServerNodePort ל-0. הם לא נדרשים כש-Controlplane V2 מופעל, אבל הערך שלהם חייב להיות 0.
8. אם באשכול המשתמשים נעשה שימוש באיזון עומסים ידני, צריך להגדיר את מאזן העומסים כמו שמתואר בקטע הבא.

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

שינוי המיפויים במאזן העומסים לפי הצורך

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

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

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

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

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

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

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

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

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

העברה של מישור הבקרה גרסה 2

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

1. יוצר את מישור הבקרה של אשכול חדש עם ControlPlane V2 מופעל.
2. הפקודה מפסיקה את מישור הבקרה של Kubernetes באשכול kubeception.
3. מצלם תמונת מצב של etcd של אשכול kubeception.
4. מכבה את הצמתים של מישור הבקרה של אשכול המשתמש של kubeception. עד שההעברה תושלם, הצמתים לא יימחקו כי כך אפשר לשחזר את הכשל על ידי חזרה לאשכול kubeception הזה.
5. משחזר את נתוני האשכול במישור הבקרה החדש, באמצעות תמונת המצב של 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.
• בסוף המיגרציה, צמתי העובדים עוברים עדכון בהדרגה. מחכים שכל הצמתים יהיו מוכנים לפני שממשיכים לשלבים שאחרי ההעברה שמפורטים בקטע הבא.
• אחרי ההעברה, כתובת ה-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

אחרי מיגרציה מוצלחת, מוחקים את מכונות ה-VM של 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