העברת אדמין קלאסטר ל-HA

בדף הזה מוסבר איך לבצע מיגרציה לאשכול אדמין עם זמינות גבוהה (HA) מאשכול אדמין ללא HA בגרסה 1.29.

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

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

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

הכנות להעברה

אם גרסת אשכול האדמין היא 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":""}]

סיבוב של מפתח הצפנה

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

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

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

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

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

סקירה כללית של התהליך

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

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

  2. מריצים את gkectl update admin. הפקודה הזו מבצעת את הפעולות הבאות:

    • מציג אשכול חיצוני (Kind) ומוודא שאשכול האדמין הנוכחי שאינו HA נמצא במצב תקין.

    • יוצר מישור בקרה חדש של אשכול אדמין באמצעות מפרט HA ו-VIP חדש של מישור בקרה.

    • הפקודה משביתה את מישור הבקרה של אשכול האדמין הקיים.

    • מצלמים תמונת מצב של etcd של אשכול האדמין הקיים.

    • שחזור נתוני אשכול האדמין הישן במישור הבקרה החדש של HA.

    • מבצע התאמה בין אשכול הניהול המשוחזר לבין מצב הסיום של אשכול הניהול של HA.

הערות

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

  • במהלך ההעברה, מישור הבקרה של אשכול האדמין מושבת למשך זמן מסוים. (זמן ההשבתה קצר מ-18 דקות, על סמך הבדיקות שלנו, אבל האורך בפועל תלוי בסביבות התשתית האישיות).

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

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

לפני ואחרי ההעברה

בטבלה הבאה מפורטים ההבדלים העיקריים באשכול לפני ואחרי ההעברה:

לפני ההעברהאחרי המיגרציה
רפליקות של צומת מישור הבקרה13
צמתים של תוספים20
רפליקות של Pod במישור הבקרה
(kube-apiserver,‏ kube-etcd וכו')
13
גודל דיסק הנתונים‫100GB * 1‫25GB * 3
נתיב דיסקים של נתונים מוגדר על ידי vCenter.dataDisk בקובץ התצורה של אשכול הניהול נוצר באופן אוטומטי בספרייה: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
מאזן עומסים ל-VIP של מישור הבקרה מוגדר על ידי loadBalancer.kind בקובץ התצורה של אשכול האדמין keepalived + haproxy
הקצאה של כתובות IP לצמתים של מישור הבקרה באשכול אדמין ‫DHCP או סטטי, בהתאם ל-network.ipMode.type 3 כתובות IP סטטיות
הקצאה של כתובות IP לצמתי מישור הבקרה של אשכול משתמשים של kubeception ‫DHCP או סטטי, בהתאם ל-network.ipMode.type ‫DHCP או סטטי, בהתאם ל-network.ipMode.type
קובץ נקודת ביקורתמופעל כברירת מחדלצולם בלי מבזק

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

צריך לציין ארבע כתובות IP נוספות:

  • שלוש כתובות IP לצמתים של מישור הבקרה של אשכול הניהול
  • כתובת VIP חדשה במישור הבקרה למאזן העומסים של אשכול האדמין

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

ציון כתובות IP

  1. בקובץ התצורה של אשכול הניהול, ממלאים את הקטע network.controlPlaneIPBlock. שמות מארחים נדרשים עבור אשכולות אדמין של HA. לדוגמה:

    controlPlaneIPBlock:
      netmask: "255.255.255.0"
      gateway: "172.16.20.1"
      ips:
      - ip: "172.16.20.50"
        hostname: "admin-cp-node-1"
      - ip: "172.16.20.51"
        hostname: "admin-cp-node-2"
      - ip: "172.16.20.52"
        hostname: "admin-cp-node-3"
    
  2. ממלאים את הקטע hostconfig. אם באשכול האדמין שלכם נעשה שימוש בכתובות IP סטטיות, הקטע הזה כבר מלא. לדוגמה:

    hostConfig:
      dnsServers:
      - 203.0.113.1
      - 198.51.100.1
      ntpServers:
      - 216.239.35.12
    
  3. מחליפים את הערך של loadBalancer.vips.controlPlaneVIP בכתובת VIP חדשה. לדוגמה:

    loadBalancer:
     vips:
       controlPlaneVIP: "172.16.20.59"
    

עדכון שדות הגדרה נוספים

  1. מגדירים את adminMaster.replicas לערך 3:

    adminMaster:
     replicas: 3
     cpus: 4
     memoryMB: 8192
    
  2. מסירים את השדה vCenter.dataDisk. במקרה של אשכול אדמין עם זמינות גבוהה, הנתיבים של שלושת דיסקי הנתונים שמשמשים את הצמתים של מישור הבקרה נוצרים באופן אוטומטי בספריית הבסיס anthos במאגר הנתונים.

  3. אם הערך של loadBalancer.manualLB.controlPlaneNodePort הוא לא אפס, צריך להגדיר אותו ל-0.

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

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

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

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

המיפוי הזה מבטיח שכתובת ה-VIP של מישור הבקרה הישן תפעל במהלך ההעברה.

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

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

  1. מתחילים את ההעברה:

    gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
    

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

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

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

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

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

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