הדרכה: פריסת מכונה וירטואלית קיימת באשכול באמצעות VM Runtime ב-GDC

בעזרת VM Runtime on GDC אתם יכולים לפרוס עומסי עבודה (workloads) של מכונות וירטואליות (VM) ישירות בהתקנה של תוכנת Distributed Cloud, רק בשרת פיזי. במדריך הזה תעבירו אפליקציה לדוגמה של נקודת מכירה, שמייצגת מסוף של נקודת מכירה קמעונאית, ממכונה וירטואלית ב-Compute Engine לאשכול Bare Metal, ותיגשו לממשק הקצה (frontend) שלה באינטרנט.

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

מטרות

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

כדי להשלים את המסמך הזה, אתם צריכים את המשאבים הבאים:

  • גישה לאשכול בשרת פיזי בגרסה 1.12.0 ואילך, שנוצר לפי המדריך התקנה עם מאזן עומסים ידני. במאמר הזה מוגדרים משאבי רשת כדי שתוכלו לגשת לעומס העבודה שפועל בתוך ה-VM דרך דפדפן. אם אתם לא צריכים את ההתנהגות הזו, אתם יכולים לפעול לפי ההוראות שבמסמך הזה באמצעות כל התקנה של תוכנת Distributed Cloud לשרת פיזי בלבד.
  • תחנת עבודה שעומדת בדרישות הבאות:
    • יש לו גישה לאשכול באמצעות ה-CLI של bmctl.
    • יש לו גישה לאשכול באמצעות ה-CLI של kubectl.

הפעלת VM Runtime on GDC והתקנת הפלאגין virtctl

ההגדרה של המשאב המותאם אישית של VM Runtime on GDC היא חלק מכל אשכולות ה-bare metal החל מגרסה 1.10. מופע של המשאב המותאם אישית VMRuntime כבר נוצר במהלך ההתקנה. עם זאת, היא מושבתת כברירת מחדל.

  1. הפעלת VM Runtime on GDC:

    sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
    • ‫KUBECONFIG_PATH: הנתיב של קובץ ה-kubeconfig של אשכול המשתמש.

  2. מוודאים שה-VMRuntime מופעל:

    kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime

    יכול להיות שיעברו כמה דקות עד שה-VMRuntime יהיה מוכן. אם הוא לא מוכן, בודקים כמה פעמים עם השהיות קצרות. בפלט של הדוגמה הבאה אפשר לראות ש-VMRuntime מוכן:

    vmruntime.vm.cluster.gke.io/vmruntime condition met

  3. מתקינים את הפלאגין virtctl ל-kubectl:

    sudo -E bmctl install virtctl

    הפלט לדוגמה הבא מראה שתהליך ההתקנה של הפלאגין virtctl הושלם:

    Please check the logs at bmctl-workspace/log/install-virtctl-20220831-182135/install-virtctl.log
[2022-08-31 18:21:35+0000] Install virtctl succeeded

  4. מוודאים שהפלאגין virtctl מותקן:

    kubectl virt

    בפלט לדוגמה הבא אפשר לראות שהפלאגין virtctl זמין לשימוש עם kubectl:

    Available Commands:
  addvolume         add a volume to a running VM
  completion        generate the autocompletion script for the specified shell
  config            Config subcommands.
  console           Connect to a console of a virtual machine instance.
  create            Create subcommands.
  delete            Delete  subcommands.
...

פריסת עומס העבודה שמבוסס על מכונות וירטואליות

כשפורסים מכונה וירטואלית בהתקנה של תוכנת Distributed Cloud לשרת פיזי בלבד, סביבת זמן הריצה של המכונה הווירטואלית ב-GDC מצפה לתמונת מכונה וירטואלית. התמונה הזו משמשת כדיסק האתחול של ה-VM שנפרס.

כדי להעביר VM קיים לאשכול, קודם צריך ליצור קובץ אימג' של ה-VM הזה. אחר כך צריך לארח את קובץ האימג' במאגר שהאשכול יכול לגשת אליו. בסיום, אפשר להשתמש בכתובת ה-URL של קובץ האימג' כדי ליצור את ה-VM. ב-VM Runtime on GDC, קובצי האימג' צריכים להיות בפורמט qcow2. אם תספקו סוג תמונה אחר, היא תומר באופן אוטומטי לפורמט qcow2. כדי להימנע מהמרה חוזרת ולאפשר שימוש חוזר, אתם יכולים להמיר קובץ אימג' של דיסק וירטואלי ולארח את קובץ האימג' של qcow2.

בשלבים הבאים תשתמשו בקובץ אימג' מוכן מראש של qcow2, שבו עומס העבודה לדוגמה נוצר כקובץ אימג' של דיסק של מכונה וירטואלית ב- Google Cloud ויוצא לקטגוריה של Cloud Storage.

קוד המקור במסמך הזה זמין במאגר anthos-samples ב-GitHub. כדי להשלים את השלבים הבאים, תצטרכו להשתמש במשאבים מהמאגר הזה.

  1. פריסת StatefulSet של MySQL. האפליקציה של נקודת המכירה צריכה להתחבר למסד נתונים של MySQL כדי לאחסן את פרטי המלאי והתשלום. במאגר של נקודת המכירה יש מניפסט לדוגמה שפורס StatefulSet של MySQL, מגדיר ConfigMap משויך ו-Service של Kubernetes. הקובץ ConfigMap מגדיר את פרטי הכניסה למכונה של MySQL, שהם אותם פרטי כניסה שמועברים לאפליקציה של נקודת המכירה.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml

  2. פורסים את עומס העבודה של ה-VM באמצעות קובץ האימג' המוכן מראש של qcow2:

    kubectl virt create vm pos-vm \
    --boot-disk-size=80Gi \
    --memory=4Gi \
    --vcpu=2 \
    --image=https://storage.googleapis.com/pos-vm-images/pos-vm.qcow2

    הפקודה הזו יוצרת קובץ YAML שנקרא על שם ה-VM‏ (google-virtctl/pos-vm.yaml). אפשר לבדוק את הקובץ כדי לראות את ההגדרה של VirtualMachine ו-VirtualMachineDisk. במקום להשתמש בפלאגין virtctl, אפשר לפרוס את עומס העבודה של ה-VM באמצעות הגדרות של Kubernetes Resource Model ‏ (KRM), כמו שמופיע בקובץ ה-YAML שנוצר.

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

    Constructing manifest for vm "pos-vm":
Manifest for vm "pos-vm" is saved to /home/tfadmin/google-virtctl/pos-vm.yaml
Applying manifest for vm "pos-vm"
Created gvm "pos-vm"

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

    המשאב VirtualMachine מזוהה על ידי המשאב vm.cluster.gke.io/v1.VirtualMachine בסביבת זמן הריצה של VM ב-GDC. הקיצור שלו הוא gvm.

    כשיוצרים VM, נוצרים שני המשאבים הבאים:

    • ‫VirtualMachineDisk הוא הדיסק הקבוע שאליו מיובא התוכן של קובץ האימג' של ה-VM.
    • VirtualMachine הוא המכונה הווירטואלית עצמה. ה-DataVolume נטען ל-VirtualMachine לפני שהמכונה הווירטואלית מופעלת.

    בודקים את הסטטוס של VirtualMachineDisk. ‫VirtualMachineDisk יוצר באופן פנימי משאב DataVolume. קובץ האימג' של ה-VM מיובא ל-DataVolume שנטען ל-VM:

    kubectl get datavolume

    הפלט הבא לדוגמה מראה את תחילת הייבוא של קובץ האימג':

    NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    ImportScheduled   N/A                   8s

  4. בודקים את הסטטוס של VirtualMachine. ה-VirtualMachine נמצא במצב Provisioning עד שה-DataVolume מיובא לחלוטין:

    kubectl get gvm

    בפלט לדוגמה הבא מוצג תהליך ההקצאה של VirtualMachine:

    NAME      STATUS         AGE     IP
pos-vm    Provisioning   1m

  5. מחכים עד שהייבוא של קובץ האימג' של ה-VM אל DataVolume יסתיים. ממשיכים לעקוב אחרי ההתקדמות בזמן שהתמונה מיובאת:

    kubectl get datavolume -w

    הפלט לדוגמה הבא מראה את קובץ האימג' של הדיסק שיובא:

    NAME              PHASE              PROGRESS   RESTARTS   AGE
pos-vm-boot-dv   ImportInProgress   0.00%                 14s
...
...
pos-vm-boot-dv   ImportInProgress   0.00%                 31s
pos-vm-boot-dv   ImportInProgress   1.02%                 33s
pos-vm-boot-dv   ImportInProgress   1.02%                 35s
...

    כשהייבוא מסתיים ונוצר DataVolume, הפלט של הדוגמה הבאה מציג את PHASE של Succeeded :

    kubectl get datavolume

    NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    Succeeded         100.0%                14m18s

  6. מוודאים שנוצר VirtualMachine:

    kubectl get gvm

    אם היצירה הצליחה, הערך של STATUS יהיה RUNNING, כמו בדוגמה הבאה, יחד עם כתובת ה-IP של ה-VM:

    NAME      STATUS    AGE     IP
pos-vm    Running   40m     192.168.3.250

התחברות למכונה הווירטואלית ובדיקת סטטוס האפליקציה

התמונה שמשמשת את ה-VM כוללת את האפליקציה לדוגמה של נקודת המכירה. האפליקציה מוגדרת להפעלה אוטומטית בזמן האתחול כשירות systemd. אפשר לראות את קובצי התצורה של שירותי systemd בספרייה pos-systemd-services.

  1. מתחברים למסוף של ה-VM. מריצים את הפקודה הבאה ולוחצים על Enter⏎ אחרי שמופיעה ההודעה Successfully connected to pos-vm…:

    kubectl virt console pos-vm

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

    Successfully connected to pos-vm console. The escape sequence is ^]

pos-from-public-image login:

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

    • שם המשתמש להתחברות: abmuser
    • סיסמה: abmworks

  2. בודקים את הסטטוס של שירותי האפליקציה של נקודת המכירה. אפליקציית נקודת המכירה כוללת שלושה שירותים: API,‏ Inventory ו-Payments. כל השירותים האלה פועלים כשירותי מערכת.

    שלושת השירותים מתחברים זה לזה דרך localhost. עם זאת, האפליקציה מתחברת למסד הנתונים של MySQL באמצעות mysql-db Kubernetes Service שנוצר בשלב הקודם. המשמעות היא שהמכונה הווירטואלית מחוברת אוטומטית לאותה רשת כמו Pods ו-Services, מה שמאפשר תקשורת חלקה בין עומסי העבודה של המכונה הווירטואלית לבין אפליקציות אחרות בקונטיינרים. לא צריך לעשות שום דבר נוסף כדי להגיע ל-Services של Kubernetes מהמכונות הווירטואליות שנפרסו באמצעות VM Runtime on GDC.

    sudo systemctl status pos*

    הפלט לדוגמה הבא מציג את הסטטוס של שלושת השירותים ושירות המערכת הבסיסי, pos.service:

    ● pos_payments.service - Payments service of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_payments.service; enabled; vendor >
    Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 750 (payments.sh)
      Tasks: 27 (limit: 4664)
    Memory: 295.1M
    CGroup: /system.slice/pos_payments.service
            ├─750 /bin/sh /pos/scripts/payments.sh
            └─760 java -jar /pos/jars/payments.jar --server.port=8083

● pos_inventory.service - Inventory service of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_inventory.service; enabled; vendor>
    Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 749 (inventory.sh)
      Tasks: 27 (limit: 4664)
    Memory: 272.6M
    CGroup: /system.slice/pos_inventory.service
            ├─749 /bin/sh /pos/scripts/inventory.sh
            └─759 java -jar /pos/jars/inventory.jar --server.port=8082

● pos.service - Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos.service; enabled; vendor preset: e>
    Active: active (exited) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
  Main PID: 743 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 4664)
    Memory: 0B
    CGroup: /system.slice/pos.service

Jun 21 18:55:30 pos-vm systemd[1]: Starting Point of Sale Application...
Jun 21 18:55:30 pos-vm systemd[1]: Finished Point of Sale Application.

● pos_apiserver.service - API Server of the Point of Sale Application
    Loaded: loaded (/etc/systemd/system/pos_apiserver.service; enabled; vendor>
    Active: active (running) since Tue 2022-06-21 18:55:31 UTC; 1h 10min ago
  Main PID: 751 (api-server.sh)
      Tasks: 26 (limit: 4664)
    Memory: 203.1M
    CGroup: /system.slice/pos_apiserver.service
            ├─751 /bin/sh /pos/scripts/api-server.sh
            └─755 java -jar /pos/jars/api-server.jar --server.port=8081

  3. יוצאים מה-VM. כדי לצאת מהחיבור למסוף, משתמשים ברצף המקשים ^] על ידי לחיצה על Ctrl + ].

גישה לעומס העבודה שמבוסס על VM

אם הגדרתם את האשכול לפי המדריך Install with Manual Loadbalancer, כבר נוצר בו משאב Ingress שנקרא pos-ingress. המשאב הזה מנתב את התנועה מכתובת ה-IP החיצונית של מאזן העומסים של Ingress לשירות שרת ה-API של האפליקציה לדוגמה של נקודת המכירה.

  1. אם באשכול אין את המשאב Ingress, יוצרים אותו באמצעות המניפסט הבא:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pos-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-server-svc
            port:
              number: 8080

  2. יוצרים Service של Kubernetes שמנתב את התנועה למכונה הווירטואלית. המשאב Ingress מנתב את התנועה אל Service:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml

    הפלט לדוגמה הבא מאשר את יצירת השירות:

    service/api-server-svc created

    apiVersion: v1
kind: Service
metadata:
  name: api-server-svc
spec:
  selector:
    kubevirt/vm: pos-vm
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8081

  3. משיגים את כתובת ה-IP החיצונית של מאזן העומסים של Ingress. מאזן העומסים של Ingress מנתב את התנועה על סמך הכללים של משאב Ingress. כבר יש לכם כלל pos-ingress להעברת בקשות לשרת ה-API Service. ה-Service הזה מעביר את הבקשות למכונה הווירטואלית:

    INGRESS_IP=$(kubectl get ingress/pos-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $INGRESS_IP

    בדוגמה הבאה מוצגת כתובת ה-IP של מאזן העומסים Ingress:

    172.29.249.159 # you might have a different IP address

  4. כדי לגשת לאפליקציה, משתמשים בכתובת ה-IP של Ingress Loadbalancer בדפדפן. בצילום המסך הבא מוצגת דוגמה לעמדת מכירה עם שני פריטים. אתם יכולים ללחוץ על הפריטים, יותר מפעם אחת אם אתם רוצים להזמין כמה פריטים, ולבצע הזמנה באמצעות הכפתור תשלום. הניסיון הזה מראה שהצלחתם לפרוס עומס עבודה שמבוסס על מכונה וירטואלית באשכול באמצעות VM Runtime on GDC.

ממשק המשתמש של אפליקציית נקודת המכירה
ממשק המשתמש של אפליקציית נקודת המכירה (לחצו על התמונה כדי להגדיל)

הסרת המשאבים

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

מחק את הכל

  • מוחקים את VM Runtime on GDC VirtualMachine יחד עם כל המשאבים:

    kubectl virt delete vm pos-vm --all

    פלט הדוגמה הבא מאשר את המחיקה:

    vm "pos-vm" used the following resources:
    gvm: pos-vm
    VirtualMachineDisk: pos-vm-boot-dv
Start deleting the resources:
    Deleted gvm "pos-vm".
    Deleted VirtualMachineDisk "pos-vm-boot-dv".

מחיקת המכונה הווירטואלית בלבד

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

    kubectl virt delete vm pos-vm

    פלט הדוגמה הבא מאשר את המחיקה:

    vm "pos-vm" used the following resources:
    gvm: pos-vm
    VirtualMachineDisk: pos-vm-boot-dv
Start deleting the resources:
    Deleted gvm "pos-vm".

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

  • המכונה הווירטואלית המקורית שמשמשת במדריך הזה היא מכונה של Compute Engine שפועלת עם Ubuntu 20.04 LTS. התמונה של ה-VM הזה נגישה לכולם דרך הקטגוריה pos-vm-images ב-Cloud Storage. למידע נוסף על אופן ההגדרה של המכונה הווירטואלית ויצירת קובץ האימג' שלה, קראו את ההוראות במאגר של נקודת המכירה.
  • כשיוצרים מכונה וירטואלית באשכול באמצעות הפקודה kubectl virt create vm pos-vm, נוצר קובץ YAML שנקרא על שם המכונה הווירטואלית (google-virtctl/pos-vm.yaml). אפשר לבדוק את הקובץ כדי לראות את ההגדרה של VirtualMachine ושל VirtualMachineDisk. במקום להשתמש בפלאגין virtctl, אתם יכולים לפרוס מכונה וירטואלית באמצעות הגדרות KRM, כמו שמופיע בקובץ ה-YAML שנוצר.