העברה ופריסה של אפליקציות באשכולות GKE Autopilot

כדי לפרוס את עומסי העבודה של הקונטיינרים שהועברו באשכולות GKE Autopilot, משתמשים באותו הליך להעברת עומסי העבודה שבו משתמשים לארכיטקטורה הקיימת. השינויים היחידים הם:

  • צריך להגדיר את הערך v2kServiceManager ל-true בתוכנית ההעברה לפני שיוצרים את הארטיפקטים של הקונטיינר.

  • צריך לבדוק את קובץ services-config.yaml החדש ולערוך את שירותי האתחול. מידע נוסף זמין במאמר שימוש בקובץ services-config.yaml.

כדי לבצע העברה:

  1. איך מתקינים את הגרסה 1.15.0 של Migrate to Containers

  2. מוסיפים מקור למיגרציה ויוצרים מיגרציה כמו שעושים היום עם סביבת זמן הריצה הקיימת.

  3. התאמה אישית של תוכנית ההעברה לפי הצורך.

    1. מורידים את תוכנית המיגרציה. תוכנית המיגרציה מיוצגת על ידי AppXGenerateArtifactsFlow.

      לדוגמה, למיגרציה בשם my-migration:

      migctl migration get my-migration

    2. פותחים את תוכנית ההעברה שהורדה, my-migration.yaml, בכלי לעריכת טקסט.

    3. אימות של מנהל השירותים המשופר של Linux. הדגל v2kServiceManager מוגדר כ-true כברירת מחדל. עם זאת, אם הכלי Migrate to Containers יזהה שירות מערכת שלא נתמך על ידי מנהל השירות, תוצג אזהרה והדגל v2kServiceManager יוגדר לערך false. כשהדגל הוא false ההעברה תשתמש בסביבת זמן ריצה מדור קודם שתומכת בשירות שלכם.

      ההתראה הבאה מוצגת לצד השירות שלא נתמך:

      Service is not supported by v2k service manager, therefore legacy runtime
will be used instead of v2k service manager, and migrated workload would
not fit running on Autopilot clusters of Cloudrun.

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

      כדי להפעיל את מנהל השירותים החדש, מאפסים את הדגל לערך true:

      v2kServiceManager: true

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

    5. כשמסיימים לערוך, שומרים את הקובץ הערוך.

    6. מעלים את תוכנית ההעברה הערוכה:

      migctl migration update my-migration --main-config my-migration.yaml

  4. יוצרים ובודקים את תוצרי המיגרציה כמו שעושים היום עם סביבת זמן הריצה הקיימת.

  5. עורכים את הקובץ החדש services-config.yaml כדי להגדיר את מאפייני האתחול של הקונטיינר. שומרים את הקובץ ובונים מחדש את קובץ אימג' של קונטיינר כדי להחיל את השינויים.

    מידע נוסף זמין במאמר שימוש בקובץ services-config.yaml.

  6. פורסים את הקונטיינר באשכול GKE Autopilot באמצעות kubectl:

    kubectl apply -f deployment_spec.yaml

דוגמה: פריסת קונטיינר של מדריך למתחילים באשכול Autopilot

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

  1. בשלב 3 של העברת המכונה הווירטואלית, שבו בודקים את תוכנית ההעברה, מגדירים את v2kServiceManager ל-true בתוכנית ההעברה ושומרים את התוכנית:

     
v2kServiceManager: true

  2. בקטע Deploying the migrated workload (פריסת עומס העבודה שהועבר), צריך ליצור אשכול GKE Autopilot ולהתחבר אליו לפני פריסת הקונטיינר:

    1. יוצרים אשכול GKE Autopilot:

      gcloud container clusters create-auto "CLUSTER_NAME"
--project "PROJECT_NAME"  --region "REGION" --release-channel "regular"
--subnetwork "projects/PROJECT_NAME/regions/us-central1/subnetworks/default"

    2. מתחברים לאשכול:

      gcloud container clusters get-credentials CLUSTER_NAME 
  --zone REGION --project PROJECT_NAME

    3. פורסים את הקונטיינר כמו שמתואר בקטע פריסת עומס העבודה שהועבר.

שינויים ב-CRD‏ AppXGenerateArtifactsFlow

אם אתם משתמשים בקובצי CRD כדי לשלוט בהעברה, עורכים את קובץ ה-CRD‏ AppXGenerateArtifactsFlow כדי להגדיר את v2kServiceManager ל-true. מידע נוסף על שימוש בקובצי CRD כדי לשלוט בהעברה זמין במאמר התאמה אישית של תוכנית העברה.

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