שדרוג אשכול

משותף רגיל

במאמר הזה מוסבר איך לשדרג את גרסת Kubernetes של אשכול Kubernetes עם פער אוויר ב-Google Distributed Cloud (GDC). כדי לוודא שהאשכולות כוללים את התכונות והתיקונים האחרונים של Kubernetes, צריך לתכנן שדרוגים שגרתיים שלהם.

המסמך הזה מיועד לקהלים כמו אדמינים ממחלקת IT, מהנדסי אבטחה ומנהלי רשתות בקבוצת האדמינים של הפלטפורמה, שאחראים על ניהול משאבים ב-Kubernetes בארגון שלהם. מידע נוסף זמין במאמר קהלי היעד של GDC עם air gap.

לפני שמתחילים

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

בקשת תפקידים ב-IAM

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

תפקידים בארגון

כדי להציג את רשימת הגרסאות הזמינות לשדרוג של אשכול Kubernetes, צריך לבקש ממנהל החשבון הארגוני ב-IAM להקצות לכם את התפקיד אדמין של אשכול משתמשים (user-cluster-admin). התפקיד הזה לא קשור למרחב שמות.

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

תפקידים בפרויקט

כדי ליצור, למחוק, לערוך או להציג שדרוגים של אשכולות, בקשו מהאדמין של הפרויקט ב-IAM להקצות לכם את התפקיד אדמין אשכולות רגיל (standard-cluster-admin). התפקיד הזה קשור למרחב השמות של הפרויקט.

הכנת הסביבה

כדי להריץ פקודות באשכול Kubernetes באמצעות ה-API, צריך לוודא שיש לכם את המשאבים הבאים:

• מורידים ומתקינים את ה-gdcloud CLI.

• מתקינים את ה-CLI של kubectl.

• מאתרים את שם האשכול של Kubernetes, או שואלים חבר בקבוצת האדמינים של הפלטפורמה מה שם האשכול.

• בהוראות הבאות, החליפו את CLUSTER_NAME בשם של אשכול Kubernetes.

• נכנסים לחשבון ויוצרים את קובץ ה-kubeconfig לשרת ה-API לניהול.

• בהוראות הבאות, מחליפים את MANAGEMENT_API_SERVER בנתיב kubeconfig של שרת ה-API לניהול.

שדרוג אשכול Kubernetes

משתמשים ב-API של UserClusterUpgradeRequest כדי לשדרג אשכול Kubernetes קיים.

כדי לשדרג אשכול Kubernetes באמצעות ה-API, מבצעים את השלבים הבאים:

1. מציגים את גרסאות השדרוג הזמינות של Kubernetes על ידי הדפסת הערך kubernetesVersion של האובייקטים UserClusterMetadata:

   kubectl --kubeconfig MANAGEMENT_API_SERVER \
       get userclustermetadata -o=custom-columns='TARGET_VERSION:.spec.kubernetesVersion'
   

   מחליפים את MANAGEMENT_API_SERVER בנתיב לקובץ kubeconfig של שרת ה-API לניהול.

   הפקודה מחזירה רשימה של גרסאות Kubernetes זמינות:

   TARGET_VERSION
   1.30.1000-gke.85
   

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

3. מבקשים את שדרוג האשכול על ידי יצירת משאב UserClusterUpgradeRequest:

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
     apiVersion: cluster.gdc.goog/v1
     kind: UserClusterUpgradeRequest
     metadata:
       name: CLUSTER_NAME
       namespace: CLUSTER_NAMESPACE
     spec:
       clusterRef:
         name: CLUSTER_NAME
       targetVersion: TARGET_VERSION
     EOF
   

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

   • ‫MANAGEMENT_API_SERVER: הנתיב לקובץ kubeconfig של שרת ה-API לניהול.
   • ‫CLUSTER_NAME: השם של אשכול Kubernetes שרוצים לשדרג, למשל user-vm-2.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של אשכול Kubernetes. באשכולות משותפים, צריך להשתמש במרחב השמות platform. באשכולות רגילים, משתמשים במרחב השמות של הפרויקט של האשכול.
   • ‫TARGET_VERSION: גרסת היעד לשדרוג שזוהתה בשלב הקודם, למשל 1.30.1000-gke.85.

   הזמן הממוצע לשדרוג של אשכול Kubernetes הוא כ-20 דקות.

4. כדי לוודא שהאשכול שודרג, עוקבים אחרי המשאב UserClusterUpgradeRequest:

   kubectl --kubeconfig MANAGEMENT_API_SERVER \
       describe userclusterupgraderequest CLUSTER_NAME \
       -n CLUSTER_NAMESPACE
   

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

   • ‫MANAGEMENT_API_SERVER: הנתיב לקובץ kubeconfig של שרת ה-API לניהול.
   • ‫CLUSTER_NAME: השם של אשכול Kubernetes שרוצים לשדרג, למשל user-vm-2.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של אשכול Kubernetes. באשכולות משותפים, צריך להשתמש במרחב השמות platform. באשכולות רגילים, משתמשים במרחב השמות של הפרויקט של האשכול.

   בודקים את הקטע Spec בפלט. הוא מכיל את Current Version ו-Target Version. אם הערכים של Current Version ו-Target Version שונים, השדרוג עדיין מתבצע.

   Spec:
     ...
     Current Version: 1.29.500-gke.60
     Target Version: 1.30.1000-gke.85
   Status:
     Conditions:
     - Message: Upgrade is in progress
       Reason: UpgradeInProgress
       Status: "False"
       Type: Succeeded
   

   השדרוג הושלם בהצלחה כשהתנאי Succeeded הוא בסטטוס True, והערך של Current Version תואם לערך של Target Version.

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

אימות סטטוס האשכול אחרי השדרוג

אחרי שמשדרגים את אשכול Kubernetes, בודקים את סטטוס המשאב Cluster כדי לוודא שהאשכול והרכיבים שלו תקינים:

1. בודקים את השדות status.conditions ו-status.componentsConditions במשאב Cluster:

   kubectl --kubeconfig MANAGEMENT_API_SERVER \
       get cluster CLUSTER_NAME \
       -n CLUSTER_NAMESPACE -o yaml
   

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

   • ‫MANAGEMENT_API_SERVER: הנתיב לקובץ kubeconfig של שרת ה-API לניהול.
   • ‫CLUSTER_NAME: השם של אשכול Kubernetes, למשל user-vm-2.
   • ‫CLUSTER_NAMESPACE: מרחב השמות של אשכול Kubernetes. באשכולות משותפים, צריך להשתמש במרחב השמות platform. באשכולות רגילים, משתמשים במרחב השמות של הפרויקט של האשכול.

2. בפלט, בודקים את הפרטים הבאים בקטע status:

   • ב-status.conditions, מוודאים שהתנאי Ready כולל status של True, ושהתנאי Reconciling כולל status של False.
   • ב-status.componentsConditions, מוודאים שלתנאי Ready יש status של True, שלתנאי Reconciling יש status של False, ושלאף תנאי אין reason של ReconciliationError או Reconciling.

   באשכולות Kubernetes עם שלושה צומתי מישור בקרה ושלושה צומתי עובד, השדרוג נמשך כ-20 דקות. אם האשכול או הרכיבים שלו נשארים במצב Reconciling אחרי 20 דקות, או אם אחד מהתנאים מציג את הערך ReconciliationError, פנו לקבוצת מפעילי התשתית שלכם לקבלת עזרה נוספת.

המאמרים הבאים

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