‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

‫1.29: תצוגה מקדימה
‫1.28: לא זמין

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

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

היתרונות של Controlplane V2 כוללים:

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

דרישות

כדי להעביר אשכול משתמשים ל-Controlplane V2, אשכול המשתמשים צריך לעמוד בדרישות הבאות:

גרסת אשכול המשתמשים צריכה להיות 1.29 ומעלה. הגרסה של מאגרי הצמתים ושל אשכול האדמין יכולה להיות נמוכה בגרסה משנית אחת או שתיים מהגרסה של אשכול המשתמש. אם צריך, משדרגים את האשכול.
ב-user cluster צריך להפעיל את Dataplane V2. השדה הזה הוא קבוע, ולכן אם Dataplane V2 לא מופעל באשכול, אי אפשר להעביר אותו ל-Controlplane V2.
צריך להגדיר את אשכול המשתמשים כך שישתמש ב-MetalLB או במאזן עומסים ידני. אם באשכול המשתמשים נעשה שימוש במאזן העומסים SeeSaw, אפשר להעביר אותו ל-MetalLB.
בודקים את מסמך התכנון של כתובות ה-IP ומוודאים שיש מספיק כתובות IP זמינות לצמתי מישור הבקרה של אשכול המשתמשים. לצמתים של מישור הבקרה נדרשות כתובות IP סטטיות, ותצטרכו כתובת IP נוספת בשביל כתובת IP וירטואלית (VIP) חדשה של מישור הבקרה.

הכנות להעברה

אם הפעלתם בעבר הצפנת סודות שפועלת תמיד באשכול המשתמשים, אתם צריכים לבצע את השלבים במאמר השבתת הצפנת סודות שפועלת תמיד ופענוח סודות לפני שתתחילו בהעברה. אחרת, לא ניתן לפענח סודות באשכול החדש של 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]}}

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

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

כדי להשבית את ההצפנה של סודות שמופעלת תמיד, מוסיפים שדה disabled: true לקטע secretsEncryption בקובץ ההגדרות של אשכול המשתמשים:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
מעדכנים את האשכול:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין
- ‫USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמשים

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

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

כדי לקבל את המניפסטים של כל הסודות באשכול המשתמשים בפורמט YAML:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml
```
כדי שכל הסודות יאוחסנו ב-etcd כטקסט פשוט, צריך להחיל מחדש את כל הסודות באשכול המשתמש:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
עכשיו אפשר להתחיל את המיגרציה ל-Controlplane V2. אחרי שההעברה מסתיימת, אפשר להפעיל מחדש את ההצפנה של סודות במצב פעיל באשכול.

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

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

לדוגמה,

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

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

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

מגדירים את enableControlplaneV2 לערך true.
אופציונלי, אפשר להגדיר זמינות גבוהה (HA) למישור הבקרה של אשכול המשתמשים Controlplane V2. כדי לשנות מאשכול ללא זמינות גבוהה לאשכול עם זמינות גבוהה, משנים את הערך של masterNode.replicas מ-1 ל-3.
מוסיפים את כתובת ה-IP הסטטית (או הכתובות) של הצמתים במישור הבקרה של אשכול המשתמשים לקטע network.controlPlaneIPBlock.ips. כתובת ה-IP (או הכתובות) של הצמתים במישור הבקרה צריכה להיות באותו VLAN כמו הצמתים של העובדים. חובה לציין את שמות המארחים.
ממלאים את מסכת הרשת ואת שער ברירת המחדל בקטע network.controlPlaneIPBlock.
אם הקטע network.hostConfig ריק, ממלאים אותו.
אם באשכול המשתמשים נעשה שימוש באיזון עומסים ידני, צריך להגדיר את מאזן העומסים כמו שמתואר בקטע הבא.
אם באשכול המשתמשים נעשה שימוש באיזון עומסים ידני, צריך להגדיר את loadBalancer.manualLB.controlPlaneNodePort ואת loadBalancer.manualLB.konnectivityServerNodePort ל-0, כי הם לא נדרשים כש-Controlplane V2 מופעל.
מעדכנים את השדה loadBalancer.vips.controlPlaneVIP עם כתובת ה-IP החדשה של ה-VIP של מישור הבקרה. שימו לב שהיא צריכה להיות באותו VLAN כמו כתובות ה-IP של צומת מישור הבקרה.
כל השדות הקודמים הם קבועים, אלא אם מעדכנים את האשכול לצורך ההעברה. חשוב לבדוק שוב את כל ההגדרות.
מריצים את הפקודה gkectl diagnose cluster ופותרים את הבעיות שהפקודה מוצאת.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
- ‫USER_CLUSTER_NAME: השם של אשכול המשתמשים.

שינוי ההגדרה של מאזן עומסים ידני

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

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

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

עדכון האשכול

מריצים את הפקודה הבאה כדי להעביר את האשכול ל-Controlplane V2:

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

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

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

הפקודה מבצעת את הפעולות הבאות:

יוצרים את מישור הבקרה של אשכול חדש עם ControlPlane V2 מופעל.
מפסיקים את מישור הבקרה של Kubernetes באשכול kubeception.
מצלמים תמונת מצב של etcd של אשכול kubeception.
מכבים את הצמתים של מישור הבקרה של אשכול המשתמשים באשכול kubeception. הערה: כדי לאפשר שחזור במקרה של כשל, כלומר חזרה לאשכול kubeception, הצמתים לא נמחקים עד להשלמת ההעברה.
משחזרים את נתוני האשכול במישור הבקרה החדש באמצעות תמונת ה-etcd שצוינה למעלה.
מחברים את הצמתים של מאגר הצמתים של אשכול kubeception למישור הבקרה החדש, שאפשר לגשת אליו באמצעות controlPlaneVIP החדש.
מבצעים התאמה בין אשכול המשתמשים ששוחזר לבין מצב הסיום של האשכול עם הפעלת ControlPlane V2.

הערות

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

אחרי המיגרציה

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

בקובץ ההגדרות של אשכול המשתמשים, מגדירים את secretsEncryption.generatedKey.disabled לערך false. לדוגמה:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false
```

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

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