מעבר ממאזן העומסים Seesaw ל-MetalLB

במאמר הזה מוסבר איך לבצע מיגרציה ממאזן העומסים Seesaw אל מאזן העומסים MetalLB בגרסאות 1.16 עד 1.29. אם האשכולות שלכם הם בגרסה 1.30 ומעלה, מומלץ לפעול לפי ההוראות במאמר תכנון העברת אשכול לתכונות מומלצות.

יש כמה יתרונות לשימוש ב-MetalLB בהשוואה לאפשרויות אחרות לאיזון עומסים.

‫1.28 ו-1.29: GA
‫1.16: גרסת טרום-השקה (Preview)

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

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

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

הערות לגבי משך השבתה

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

  • כשמעבירים אשכול אדמין:

    • יש השבתה של מישור הבקרה באשכולות משתמשים של kubeception בזמן ההעברה של controlPlaneVIP. זמן ההשבתה צריך להיות פחות מ-10 דקות, אבל משך ההשבתה תלוי בתשתית שלכם.

    • יש זמן השבתה למישור הבקרה של אשכול האדמין, כי צריך ליצור מחדש את צומת האדמין הראשי עם controlPlaneVIP שמצורף ישירות למכונה הווירטואלית. זמן ההשבתה אמור להיות פחות מ-20 דקות, אבל משך ההשבתה תלוי בתשתית שלכם.

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

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

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

בקובץ ההגדרה של אשכול המשתמשים, בוחרים מאגר צמתים ומגדירים את enableLoadBalancer ל-true:

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

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

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

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

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

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

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

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

מוודאים שרכיבי 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 בתיקיית התצורה.

דוגמה: אשכול משתמשים, כתובות IP סטטיות

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

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

  • משאירים את הקטע network.hostConfig.
  • מגדירים את loadBalancer.kind להיות MetalLB.
  • להסיר את הקטע loadBalancer.seesaw.
  • מוסיפים קטע loadBalancer.metalLB.

דוגמה:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
    ingressVIP: "172.16.20.31"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.31/32"
      - "172.16.20.40 - 172.16.21.49"

נקודות מרכזיות מהדוגמה הקודמת:

  • למרות שהאשכול לא ישתמש יותר במאזן העומסים של Seesaw, צריך את הקטע network.hostConfig כי הצמתים של האשכול משתמשים בכתובות IP סטטיות.

  • הערך של ingressVIP מופיע במאגר הכתובות של MetalLB.

  • כתובות ה-IP החיצוניות, 172.16.21.41 ו-172.16.21.45, של השירותים הקיימים מסוג LoadBalancer כלולות במאגר הכתובות של MetalLB.

דוגמה: אשכול משתמש kubeception, ‏ DHCP

נניח שיש לכם אשכול משתמשים שמשתמש ב-DHCP לצמתים שלו. נניח גם שלקלאסטר יש שני שירותים מסוג LoadBalancer, והכתובות החיצוניות של השירותים האלה הן 172.16.21.61 ו-172.16.21.65.

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

  • להסיר את הקטע network.hostConfig.
  • מגדירים את loadBalancer.kind להיות MetalLB.
  • להסיר את הקטע loadBalancer.seesaw.
  • מוסיפים קטע loadBalancer.metalLB.

דוגמה:

enableControlplaneV2: false
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.50"
    ingressVIP: "172.16.20.51"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.51/32"
      - "172.16.20.60 - 172.16.21.69"

נקודות מרכזיות מהדוגמה הקודמת:

  • האשכול לא ישתמש יותר במאזן העומסים של Seesaw, ולא ישתמש בכתובות IP סטטיות לצמתי האשכול. לכן, אין צורך בקטע network.hostConfig.

  • הערך של ingressVIP מופיע במאגר הכתובות של MetalLB.

  • כתובות ה-IP החיצוניות, 172.16.21.61 ו-172.16.21.65, של השירותים הקיימים מסוג LoadBalancer כלולות במאגר הכתובות של MetalLB.

דוגמה: Controlplane V2 user cluster, DHCP

נניח שיש לכם אשכול משתמשים שמופעל בו Controlplane V2, והוא משתמש ב-DHCP עבור צמתי העובדים שלו. נניח גם שלקלאסטר יש שני שירותים מסוג LoadBalancer, והכתובות החיצוניות של השירותים האלה הן 172.16.21.81 ו-172.16.21.85.

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

  • משאירים את הקטע network.hostconfig.
  • מגדירים את loadBalancer.kind להיות MetalLB.
  • להסיר את הקטע loadBalancer.seesaw.
  • מוסיפים קטע loadBalancer.metalLB.

דוגמה:

enableControlplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.70"
    ingressVIP: "172.16.20.71"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.71/32"
      - "172.16.20.80 - 172.16.21.89"

נקודות מרכזיות מהדוגמה הקודמת:

  • האשכול לא ישתמש יותר בכתובות IP סטטיות לצמתי העובדים, אבל הוא ישתמש בכתובות IP סטטיות לצמתי מישור הבקרה. לכן צריך להוסיף את הקטע network.hostConfig.

  • הערך של ingressVIP מופיע במאגר הכתובות של MetalLB.

  • כתובות ה-IP החיצוניות, 172.16.21.81 ו-172.16.21.85, של השירותים הקיימים מסוג LoadBalancer כלולות במאגר הכתובות של MetalLB.

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

בקובץ התצורה של אשכול האדמין, מגדירים את loadBalancer.kind ל-MetalLB ומסירים את הקטע loadBalancer.seesaw.

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

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

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

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

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

מוודאים שרכיבי 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 בתיקיית התצורה.

דוגמה: אשכול אדמין, כתובות IP סטטיות

נניח שיש לכם אשכול אדמין שמשתמש בכתובות IP סטטיות לצמתי האשכול.

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

  • משאירים את הקטע network.hostConfig.
  • מגדירים את loadBalancer.kind להיות MetalLB.
  • להסיר את הקטע loadBalancer.seesaw.

דוגמה:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

נקודה חשובה מהדוגמה הקודמת:

  • למרות שהאשכול לא ישתמש יותר במאזן העומסים של Seesaw, צריך את הקטע network.hostConfig כי הצמתים של האשכול משתמשים בכתובות IP סטטיות.

דוגמה: אשכול אדמין, DHCP

נניח שיש לכם אשכול אדמין שמשתמש ב-DHCP לצמתים של האשכול.

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

  • להסיר את הקטע network.hostConfig.
  • מגדירים את loadBalancer.kind להיות MetalLB.
  • להסיר את הקטע loadBalancer.seesaw.

דוגמה:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

נקודה חשובה מהדוגמה הקודמת:

  • האשכול לא ישתמש יותר במאזן העומסים של Seesaw, ולא ישתמש בכתובות IP סטטיות לצמתי האשכול. לכן, אין צורך בקטע network.hostConfig.

פתרון בעיות

אם gkectl update נכשל במהלך העברת אשכול המשתמשים, ורכיבי ה-Pod של MetalLB לא פועלים באשכול המשתמשים, צריך להפעיל ידנית את מכונות ה-VM של Seesaw באשכול המשתמשים. הפעולה הזו תגרום להקמה מחדש של תנועה לכתובות ה-VIP שמשמשות כרגע. אבל יכול להיות שהמכונות הווירטואליות של Seesaw לא ישרתו כתובות VIP שנוצרו לאחרונה אם load-balancer-seesaw Pod לא פועל. במקרה כזה, צריך ליצור כרטיס תמיכה.

אם gkectl update נכשל במהלך העברת אשכול האדמין, והפודים של MetalLB לא פועלים באשכול האדמין, צריך להפעיל ידנית את מכונות ה-VM של Seesaw באשכול האדמין. יכול להיות שהפעולה הזו תאפשר לתנועה להגיע לכתובות ה-VIP של מישור הבקרה שמשמשות כרגע את אשכולות המשתמשים, כדי שהם יפעלו שוב. אבל יכול להיות שכתובת ה-VIP של מישור הבקרה של אשכול האדמין עצמו לא תפעל. במקרה כזה, צריך לערוך את קובץ ה-kubeconfig של אשכול האדמין כדי להשתמש ישירות בכתובת ה-IP של צומת מישור הבקרה של אשכול האדמין.

בנוסף, במרחב השמות kube-system, משנים את kube-apiserver סוג השירות מ-ClusterIP ל-LoadBalancer. אם צריך, יוצרים כרטיס תמיכה.