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

במאמר הזה מוסבר איך לפרוס עומס עבודה שמבוסס על מכונה וירטואלית (VM) בהתקנה של Google Distributed Cloud (תוכנה בלבד) ב-Bare Metal באמצעות VM Runtime ב-GDC. עומס העבודה שמשמש במדריך הזה הוא אפליקציית נקודת המכירה לדוגמה. האפליקציה הזו מייצגת מסוף של נקודת מכירה טיפוסי שפועל על חומרה מקומית בחנות קמעונאית.

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

במסמך הזה נעשה שימוש בתמונה שהוכנה מראש של מכונת VM ב-Compute Engine, שבה עומס העבודה פועל כשירות systemd. אפשר לפעול לפי אותם השלבים כדי לפרוס את האפליקציה שלכם.

מטרות

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

כדי למלא את המסמך הזה, תצטרכו את מקורות המידע הבאים:

  • גישה לאשכול בשרת פיזי בגרסה 1.12.0 ואילך, שנוצר לפי המדריך Install with Manual Loadbalancer. במסמך הזה מוגדרים משאבי רשת כדי שתוכלו לגשת לעומס העבודה שפועל בתוך המכונה הווירטואלית דרך דפדפן. אם אתם לא צריכים את ההתנהגות הזו, אתם יכולים לפעול לפי ההוראות במאמר הזה כדי להתקין את Google Distributed Cloud על bare metal.
  • תחנת עבודה שעומדת בדרישות הבאות:
    • יש לו גישה לאשכול באמצעות ה-CLI של bmctl.
    • יש לו גישה לאשכול באמצעות ה-CLI של kubectl.

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

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

  1. הפעלת VM Runtime ב-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.
...

פריסת עומס העבודה שמבוסס על VM

כשפורסים מכונה וירטואלית בהתקנה של Google Distributed Cloud (תוכנה בלבד) על מתכת חשופה, VM Runtime ב-GDC מצפה לקובץ אימג' של מכונה וירטואלית. קובץ האימג' הזה משמש כדיסק האתחול של המכונה הווירטואלית שנפרסה.

במדריך הזה, תעבירו עומס עבודה שמבוסס על מכונה וירטואלית ב-Compute Engine לאשכול. המכונה הווירטואלית הזו ב-Compute Engine נוצרה, ואפליקציית נקודת המכירה (PoS) לדוגמה הוגדרה לפעול כשירות systemd. נוצר דיסק עם תמונה של המכונה הווירטואלית הזו יחד עם עומס העבודה של אפליקציית נקודת המכירה ב- Google Cloud. לאחר מכן, התמונה הזו יוצאה לקטגוריה של Cloud Storage כתמונה של qcow2. בשלבים הבאים תשתמשו בתמונה של qcow2 שהוכנה מראש.

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

  1. פריסת MySQL StatefulSet. אפליקציית הקופה מצפה להתחבר למסד נתונים של MySQL כדי לאחסן מידע על מלאי ותשלומים. במאגר הקופה יש קובץ מניפסט לדוגמה שפורס MySQL StatefulSet, מגדיר ConfigMap משויך ו-Kubernetes Service. ה-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 Runtime ב-GDC. הקיצור של זה הוא gvm.

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

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

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

    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

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

התמונה שמשמשת למכונה הווירטואלית כוללת את אפליקציית הדוגמה של נקודת המכירה. האפליקציה מוגדרת להתחיל אוטומטית באתחול כשירות 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 Runtime ב-GDC VirtualMachine.

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

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

    שלושת השירותים מתחברים זה לזה דרך localhost. עם זאת, האפליקציה מתחברת למסד הנתונים של MySQL באמצעות שירות Kubernetes של mysql-db שנוצר בשלב הקודם. ההתנהגות הזו אומרת שהמכונה הווירטואלית מחוברת אוטומטית לאותה רשת כמו Pods ו-Services, מה שמאפשר תקשורת חלקה בין עומסי העבודה של המכונה הווירטואלית לבין אפליקציות אחרות שמבוססות על קונטיינרים. לא צריך לבצע פעולות נוספות כדי לאפשר גישה ל-Kubernetes‏ Services ממכונות וירטואליות שנפרסו באמצעות VM Runtime ב-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. יוצאים מהמכונה הווירטואלית. כדי לצאת מחיבור המסוף, משתמשים ברצף בריחה ^] על ידי הקשה על Ctrl + ].

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

אם הגדרתם את האשכול לפי המדריך התקנה באמצעות מאזן עומסים ידני, כבר נוצר משאב 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. יוצרים Kubernetes Service שמנתב תנועה למכונה הווירטואלית. מקור המידע 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 בדפדפן. צילומי המסך הבאים מציגים קיוסק של נקודת מכירה עם שני פריטים. אפשר ללחוץ על הפריטים, יותר מפעם אחת אם רוצים להזמין כמה פריטים, ולבצע הזמנה באמצעות הלחצן תשלום. הניסיון הזה מראה שפרסתם בהצלחה עומס עבודה מבוסס-מכונה וירטואלית באשכול באמצעות VM Runtime ב-GDC.

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

הסרת המשאבים

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

מחק את הכל

  • מוחקים את VM Runtime ב-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".

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

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

    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 הזו נגישה לציבור דרך קטגוריית Cloud Storage‏ pos-vm-images. מידע נוסף על אופן ההגדרה של המכונה הווירטואלית ועל אופן יצירת התמונה שלה זמין בהוראות במאגר של מערכת הקופה.
  • כשיוצרים מכונה וירטואלית באשכול באמצעות הפקודה kubectl virt create vm pos-vm, נוצר קובץ YAML שנקרא על שם המכונה הווירטואלית (google-virtctl/pos-vm.yaml). אפשר לבדוק את הקובץ כדי לראות את ההגדרה של VirtualMachine ושל VirtualMachineDisk. במקום להשתמש בפלאגין virtctl, אפשר לפרוס מכונה וירטואלית באמצעות הגדרות KRM, כמו שמופיע בקובץ ה-YAML שנוצר.