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

סקירה כללית

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

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

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

    או

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

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

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

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

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

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

דרישות

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

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

במהלך ההעברה, צפוי זמן השבתה מוגבל של מישור הבקרה. הגישה ל-Kubernetes API לא זמינה למשך כ-20 דקות באשכולות ניהול שאינם HA, אבל מישור הבקרה של Kubernetes נשאר זמין באשכולות ניהול HA עם F5. במהלך ההעברות, מישור הנתונים של Kubernetes ממשיך לפעול במצב יציב.

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

מאת	אל	גישה ל-Kubernetes API	עומסי עבודה של משתמשים
קלאסטרים של אדמינים עם זמינות גבוהה (HA) באמצעות F5 BIG-IP	קלאסטרים של אדמינים עם זמינות גבוהה (HA) עם ManualLB	אין השפעה	אין השפעה
קלאסטרים של אדמינים ללא זמינות גבוהה עם MetalLB או ManualLB	קלאסטרים של אדמינים עם זמינות גבוהה (HA) עם אותו סוג של מאזן עומסים	השפעה	אין השפעה
אשכולות אדמין ללא זמינות גבוהה עם F5 BIG-IP	קלאסטרים של אדמינים עם זמינות גבוהה (HA) עם ManualLB	השפעה	אין השפעה
אשכולות אדמין ללא זמינות גבוהה עם Seesaw	אשכולות אדמין של HA עם MetalLB	השפעה	אין השפעה

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

הכנות להעברה

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

הקצאת כתובות IP נוספות

כשמעבירים את אשכול האדמין מ-non-HA ל-HA, צריך להקצות ארבע כתובות IP נוספות. מוודאים שכתובות ה-IP האלה נמצאות באותו VLAN כמו הצמתים הקיימים של אשכול האדמין, ושלא נעשה בהן שימוש כבר בצמתים קיימים:

• מקצים כתובת IP אחת ל-VIP החדש של מישור הבקרה, לשדה loadBalancer.vips.controlPlaneVIP בקובץ התצורה של אשכול הניהול.
• מקצים כתובות IP חדשות לכל אחד משלושת הצמתים של מישור הבקרה, בקטע network.controlPlaneIPBlock בקובץ התצורה של אשכול האדמין.

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

כשמעבירים את אשכול האדמין מ-non-HA ל-HA, צריך לעדכן את הכללים לחומת האש באשכול האדמין. כך תוכלו לוודא שכתובות ה-IP החדשות שהוקצו לצמתי מישור הבקרה יכולות להגיע לכל ממשקי ה-API הנדרשים ולכל היעדים האחרים, כפי שמתואר במאמר בנושא כללי חומת האש לאשכולות אדמין.

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

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

F5 BIG-IP

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

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

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

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"
  

Seesaw

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

1. מגדירים את השדה loadBalancer.kind לערך MetalLB.
2. משאירים את הקטע network.hostConfig.
3. מגדירים או שומרים את הערך של השדה loadBalancer.vips.controlPlaneVIP]5. אם אשכול האדמין כבר זמין, אפשר להשאיר את אותו הערך. אם עוברים מאשכול אדמין ללא זמינות גבוהה לאשכול אדמין עם זמינות גבוהה, צריך לשנות את הערך של השדה loadBalancer.vips.controlPlaneVIP לכתובת ה-IP שהקציתם.
4. מסירים את הקטע loadBalancer.seesaw.

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

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

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

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

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

אם גרסת אשכול האדמין היא 1.29.0-1.29.600 או 1.30.0-1.30.100, והצפנת סודות בזמינות תמידית הופעלה באשכול האדמין בגרסה 1.14 או בגרסה קודמת, צריך להחליף את מפתח ההצפנה לפני שמתחילים בהעברה. אחרת, לא תהיה אפשרות לפענח סודות באשכול האדמין החדש של HA.

כדי לבדוק אם יכול להיות שהאשכול משתמש במפתח הצפנה ישן:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

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

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

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

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

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

1. ממלאים את network.controlPlaneIPBlock בשלוש כתובות ה-IP שהקציתם לצמתי מישור הבקרה.
2. חשוב לוודא שמילאתם את הקטע network.hostConfig. בקטע הזה יש מידע על שרתי NTP, שרתי DNS ודומיינים לחיפוש DNS שבהם נעשה שימוש במכונות הווירטואליות שהן הצמתים של האשכול.
3. חשוב לוודא שהחלפתם את הערך של loadBalancer.vips.controlPlaneVIP בכתובת ה-IP שהקציתם.
4. מגדירים את adminMaster.replicas ל-3.
5. מסירים את השדה vCenter.dataDisk. במערכת HA admin cluster, הנתיבים של שלושת דיסקי הנתונים שמשמשים את הצמתים של מישור הבקרה נוצרים באופן אוטומטי בספריית הבסיס anthos במאגר הנתונים.
6. אם הערך של loadBalancer.kind הוא "ManualLB", מגדירים את loadBalancer.manualLB.controlPlaneNodePort ל-0.

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

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    - 203.0.113.1
    - 203.0.113.2
    ntpServers:
    - 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    - ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    - ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    - ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

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

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

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

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

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

כך מוודאים שכתובת ה-VIP הישנה של מישור הבקרה ממשיכה לפעול במהלך ההעברה.

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

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

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

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

Replace the following:

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

הפקודה מציגה את התקדמות ההעברה.

כשמוצגת בקשה, מזינים Y כדי להמשיך.

במהלך ההעברה מ-non-HA ל-HA, כתובת ה-VIP הישנה של מישור הבקרה ממשיכה לפעול ואפשר להשתמש בה כדי לגשת לאשכול הניהול החדש של HA. כשההעברה מסתיימת, קובץ ה-kubeconfig של אשכול האדמין מתעדכן אוטומטית כדי להשתמש ב-VIP החדש של מישור הבקרה.

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

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

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

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

MetalLB

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

kubectl --kubeconfig ADMIN_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-gke-admin.yaml שבספריית התצורה.

ManualLB

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

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

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