העברת אשכולות המותאמים ל-VPC ל-GKE Dataplane V2

במאמר הזה מוסבר איך להעביר אשכולות קיימים של Google Kubernetes Engine‏ (GKE) מסוג אשכול המותאם ל-VPC מ-Dataplane V1 ל-GKE Dataplane V2, איך לעקוב אחרי ההעברה ואיך לבטל אותה אם צריך.

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

לפני שמתחילים, כדאי לקרוא את המאמר מידע על מעבר ל-GKE Dataplane V2 כדי להבין מה קורה בכל שלב של ההעברה ואיך לתכנן את השיבושים בעומס העבודה.

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

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

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

  • האשכול מותאם ל-VPC.
  • באשכול פועלת גרסה 1.35.3-gke.1155000 ואילך.
  • במאגרי הצמתים פועלת גרסה 1.35.1-gke.1516000 ואילך.
  • אם אתם משתמשים ב-Cloud Service Mesh או ב-Istio בקוד פתוח, גרסת ה-Istio שלכם היא 1.23 ואילך.

הכנת האשכול

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

  • הסרת NetworkPolicy: הסרת מדיניות הרשת הקיימת. אם GKE אוכף פתאום את מדיניות הרשת ב-Kubernetes כשהוא יוצר מחדש את הצמתים, יכול להיות שתחוו שיבושים לא מכוונים ברשת.
  • מדיניות רשת של Calico: אם אתם משתמשים באשכול GKE Standard עם מדיניות רשת (Calico) מופעלת, צריך להשבית את האכיפה של מדיניות הרשת. אי אפשר להעביר את האשכולות האלה ישירות.
  • המלצות של Active Assist: כדאי לבדוק את Active Assist או את דף הפרטים של האשכול כדי לראות אם יש המלצות שעלולות לסתור את ההעברה.
  • קיבולת של כתובות IP: מוודאים שלטווח כתובות ה-IP של ה-Pod באשכול יש קיבולת מספקת לשיטות השדרוג של מאגר הצמתים. מידע נוסף זמין במאמר תובנות לגבי ניצול כתובות IP ב-GKE.
    • תכונות רשת: הפעילו תכונות רשת כמו NodeLocal DNSCache או הרשאות גישה בתוך הצומת לפני שאתם מתחילים את ההעברה או אחרי שההעברה מסתיימת. אי אפשר להפעיל אותם במהלך המיגרציה.

הסבר על המגבלות

  • הגדרות רשת נעולות: אחרי שמתחילים את ההעברה, אי אפשר לשנות את הגדרות הרשת ברמת האשכול עד שההעברה מסתיימת.
  • חלונות זמן לתחזוקה: ההעברה מתבצעת בהתאם לחלונות הזמן לתחזוקה ולחריגים לתחזוקה שהגדרתם, ולכן יכול להיות שהיא תיראה תקועה. כדי לזרז את התהליך, אפשר לתקן את מאגרי הצמתים באופן ידני. השלבים מפורטים במאמר זירוז ההעברה.
  • תכונות אופציונליות של GKE Dataplane V2: אחרי ההעברה, אפשר להגדיר תכונות אופציונליות של GKE Dataplane V2, כמו יכולת הצפייה (observability) ב-GKE Dataplane V2 או תמיכה בריבוי רשתות עבור Pods.
  • ‫Terraform: אי אפשר להשתמש ב-Terraform כדי לבצע מיגרציה ל-GKE Dataplane V2.

התחלת ההעברה

כדי להתחיל את ההעברה באופן ידני ולעקוף את בדיקות האבחון האוטומטיות, אתם יכולים לתקן את האשכול באמצעות Google Cloud CLI.

מריצים את הפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-dataplane-v2

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: מיקום המחשוב של האשכול.

מעקב אחרי התקדמות ההעברה

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

  1. בודקים את סטטוס האשכול:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫LOCATION: מיקום המחשוב של האשכול.

  2. בודקים את הסטטוס של מאגר הצמתים:

    gcloud container node-pools list \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value(name, networkConfig.datapathProvider)'

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫LOCATION: מיקום המחשוב של האשכול.

  3. בודקים את anetd DaemonSet כדי לוודא שהסוכנים פועלים:

    kubectl get ds -n kube-system anetd

האצת ההעברה

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

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

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --datapath-provider=advanced-datapath

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

  • ‫NODE_POOL_NAME: שם מאגר הצמתים.
  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: מיקום המחשוב של האשכול.

סיום ההעברה

אחרי שכל מאגרי הצמתים הועברו ל-GKE Dataplane V2, המערכת של GKE מסיימת את ההעברה באופן אוטומטי. בסיום ההעברה, פלט הפקודה מציג את הסטטוס ADVANCED_DATAPATH והאשכול מריץ את GKE Dataplane V2.

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

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: מיקום המחשוב של האשכול.

כשההעברה מסתיימת, הפלט מראה ADVANCED_DATAPATH.

החזרה למצב קודם של העברה

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

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

    kubectl get ds -n kube-system anetd

  2. ביטול פעולות מתמשכות של מאגר צמתים:

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

      gcloud container operations list \
    --location=LOCATION \
    --filter="operationType=UPGRADE_NODES AND status=RUNNING AND targetLink:*/clusters/CLUSTER_NAME"

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

      • ‫LOCATION: מיקום המחשוב של האשכול.
      • ‫CLUSTER_NAME: שם האשכול.

    2. מבטלים את הפעולה באמצעות מזהה הפעולה:

      gcloud container operations cancel OPERATION_ID \
    --location=LOCATION

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

      • ‫OPERATION_ID: המזהה של הפעולה שפועלת.
      • ‫LOCATION: מיקום המחשוב של האשכול.

  3. מפעילים את החזרה לגרסה הקודמת: שולחים בקשת תיקון לאשכול כדי לחזור מההעברה ל-Dataplane V1.

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-dataplane-v2

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫LOCATION: מיקום המחשוב של האשכול.

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

    gcloud container node-pools list \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value(name, networkConfig.datapathProvider)'

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫LOCATION: מיקום המחשוב של האשכול.

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

  5. השלמת ההעברה: אחרי שכל מאגרי הצמתים מועברים ל-Dataplane V1, ‏ GKE משלים את ההעברה באופן אוטומטי. כדי לוודא שהפעולה הסתיימה, בודקים את סטטוס האשכול:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫LOCATION: מיקום המחשוב של האשכול.

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

פתרון בעיות בהעברה

בקטע הזה מוסבר איך לפתור בעיות נפוצות שעלולות לקרות כשעוברים ל-GKE Dataplane V2.

ההעברה של מאגר הצמתים נכשלה

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

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