ניהול מכונות וירטואליות

בדף הזה מוסבר איך לנהל מכונות וירטואליות ב-Google Distributed Cloud במודל מחובר שבו פועל VM Runtime ב-Google Distributed Cloud. כדי לבצע את השלבים שבדף הזה, אתם צריכים להכיר את VM Runtime ב-GDC. רשימה של מערכות הפעלה נתמכות של אורחים זמינה במאמר מערכות הפעלה מאומתות של אורחים עבור VM Runtime ב-GDC.

כדי ללמוד איך מכונות וירטואליות משמשות כרכיב חיוני בפלטפורמה המחוברת של Distributed Cloud, אפשר לעיין במאמר הרחבת GKE Enterprise לניהול מכונות וירטואליות בפריסה מקומית.

קלאסטרים של מישור בקרה מקומי תומכים בוווב-הוקים של מכונות וירטואליות. כך אפשר לאמת בקשות משתמשים שנשלחות לשרת Kubernetes API המקומי ב-Distributed Cloud. בקשות שנדחו יוצרות מידע מפורט על סיבת הדחייה.

הפעלת VM Runtime ב-GDC במודל מחובר של Distributed Cloud

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

משאב VMRuntime שמגדיר את VM Runtime בתמיכה של GDC ב-Distributed Cloud connected גם מגדיר תמיכה ב-GPU באשכול באמצעות הפרמטר enableGPU. חשוב להגדיר את שני הפרמטרים בהתאם לצרכים של עומס העבודה. לא צריך להפעיל תמיכה ב-GPU כדי להפעיל את VM Runtime בתמיכה ב-GDC באשכול המחובר ל-Distributed Cloud.

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

ערך של enable ערך של enableGPU ההגדרה שמתקבלת
false false עומסי העבודה פועלים רק במאגרי מידע, ואי אפשר להשתמש במשאבי GPU.
false true עומסי עבודה פועלים רק בקונטיינרים ויכולים להשתמש במשאבי GPU.
true true עומסי עבודה יכולים לפעול במכונות וירטואליות ובקונטיינרים.
שני סוגי עומסי העבודה יכולים להשתמש במשאבי GPU.
true false עומסי עבודה יכולים לפעול במכונות וירטואליות ובקונטיינרים.
אי אפשר להשתמש במשאבי GPU בשני סוגי עומסי העבודה.

אם כבר הפעלתם תמיכה ב-GPU, צריך לשנות את המשאב VMRuntime כדי להוסיף את הפרמטר enable, להגדיר את הערך שלו ל-true ואז להחיל אותו על אשכול Distributed Cloud.

הפעלת VM Runtime במערכת המשנה של מכונות וירטואליות ב-GDC

בהתאם לסוג האשכול שבו רוצים להפעיל את VM Runtime במערכת המשנה של המכונה הווירטואלית ב-GDC, מבצעים אחת מהפעולות הבאות:

  • במקרה של אשכולות של מישור הבקרה ב-Cloud, צריך ליצור את המשאב VMRuntime באופן ידני.
  • במקרים של אשכולות של מישור בקרה מקומי, צריך לערוך את משאב VMRuntime הקיים.

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

  1. בהתאם לסוג אשכול היעד, יוצרים או משנים את VMRuntime המשאב המותאם אישית עם התוכן הבא ומחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  # Enable Anthos VM Runtime support
  enabled: true
  # vmImageFormat defaults to "raw" if not set
  vmImageFormat: "raw"

    אל תשנו את הערך של הפרמטר vmImageFormat. ‫Distributed Cloud connected לא תומך בפורמטים אחרים של דיסקים וירטואליים.

    בדרך כלל התהליך נמשך כמה דקות.

  2. כדי לוודא שVMRuntime המשאב המותאם אישית הוחל על האשכול, משתמשים בפקודה הבאה:

    kubectl get vmruntime -o yaml

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

     - apiVersion: vm.cluster.gke.io/v1
   kind: VMRuntime
   metadata:
     name: vmruntime
     ...
   spec:
     enabled: true
     vmImageFormat: raw
   status:
     ...
   ready: true
     ...

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

    kubectl get pods -n vm-system

    הפקודה מחזירה פלט שמציג את ה-VM Runtime ב-Pods של מערכת המשנה GDC שפועלים באשכול, בדומה לדוגמה הבאה:

    NAME                                                READY   STATUS         RESTARTS        AGE
cdi-apiserver-6c76c6cf7b-n68wn                      1/1     Running        0               132m
cdi-deployment-f78fd599-vj7tv                       1/1     Running        0               132m
cdi-operator-65c4df9647-fcb9d                       1/1     Running        0               134m
cdi-uploadproxy-7765ffb694-6j7bf                    1/1     Running        0               132m
macvtap-fjfjr                                       1/1     Running        0               134m
virt-api-77dd99dbbb-bs2fb                           1/1     Running        0               132m
virt-api-77dd99dbbb-pqc27                           1/1     Running        0               132m
virt-controller-5b44dbbbd7-hc222                    1/1     Running        0               132m
virt-controller-5b44dbbbd7-p8xkk                    1/1     Running        0               132m
virt-handler-n76fs                                  1/1     Running        0               132m
virt-operator-86565697d9-fpxqh                      2/2     Running        0               134m
virt-operator-86565697d9-jnbt7                      2/2     Running        0               134m
vm-controller-controller-manager-7844d5fb7b-72d8m   2/2     Running        0               134m
vmruntime-controller-manager-845649c847-m78r9       2/2     Running        0               175m

הענקת גישה למרחב השמות של היעד למאגר המחובר של Distributed Cloud

השלבים בקטע הזה רלוונטיים רק לאשכולות של מישור הבקרה בענן. אם אתם מגדירים את VM Runtime במערכת המשנה של מכונה וירטואלית ב-GDC באשכול של מישור בקרה מקומי, דלגו על הקטע הזה.

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

כדי להעניק למרחב השמות של היעד גישה למאגר המחובר של Distributed Cloud, צריך לבצע את השלבים הבאים:

  1. מבצעים תיקון לחשבון השירות שמוגדר כברירת מחדל במרחב השמות של היעד באמצעות המפתח imagePullSecret שנקרא gcr-pull:

    kubectl patch sa default -p "{\"imagePullSecrets\": [{\"name\": \"gcr-pull\"}]}" -n NAMESPACE

    מחליפים את NAMESPACE בשם של מרחב השמות של היעד.

  2. מרעננים את הסוד המשויך במרחב השמות של היעד:

    # Delete existing secret.
kubectl delete secret gcr-pull -n NAMESPACE --ignore-not-found
# Copy the new secret to the target namespace.
kubectl get secret gcr-pull -n vm-system -o yaml | sed "s/namespace: vm-system/namespace: NAMESPACE/g" | kubectl apply -f -

    מחליפים את NAMESPACE בשם של מרחב השמות של היעד.

    תוקף הסוד יפוג אחרי שעה. צריך לרענן אותו ידנית אחרי שהוא פג.

התקנה של כלי הניהול virtctl

כדי לנהל מכונות וירטואליות באשכול מחובר של Distributed Cloud, צריך את כלי הלקוח virtctl. כדי להתקין את הכלי, מבצעים את השלבים הבאים:

  1. מתקינים את כלי הלקוח virtctl כפלאגין של kubectl:

    export VERSION=v0.49.0-anthos1.12-gke.7
gcloud storage cp gs://anthos-baremetal-release/virtctl/${VERSION}/linux-amd64/virtctl /usr/local/bin/virtctl
cd /usr/local/bin
sudo ln -s virtctl kubectl-virt
sudo chmod a+x virtctl
cd -

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

    kubectl plugin list

    אם הפלאגין הותקן בהצלחה, הפלט של הפקודה יכלול את kubectl-virt כאחד מהפלאגינים.

הקצאת מכונה וירטואלית ב-Distributed Cloud במודל מחובר עם אחסון בלוקים גולמי

בקטע הזה מופיעות דוגמאות להגדרות שממחישות איך להקצות מכונה וירטואלית של Linux ומכונה וירטואלית של Windows באשכול שמחובר ל-Distributed Cloud עם אחסון בלוקים גולמי. בדוגמאות נעשה שימוש באחסון בלוקים שמופעל כ-PersistentVolume.

מגבלות השימוש באחסון בלוקים גולמי

המגבלות הבאות חלות כשמריצים מכונות וירטואליות עם אחסון בלוקים גולמי ב-Distributed Cloud connected:

  • השדה OSType לא נתמך במפרטים של משאבי VirtualMachine באשכולות של מישור הבקרה ב-Cloud. לכן, רק method‏ console ו-method‏ vnc נתמכות לגישה למכונות וירטואליות שפועלות באשכולות של מישור הבקרה ב-Cloud.
  • אי אפשר ליצור מכונה וירטואלית באשכול שמחובר ל-Distributed Cloud ישירות באמצעות הפקודה kubectl virt, כי Distributed Cloud Connected לא מספק אחסון במערכת קבצים למכונות וירטואליות.
  • במשאבי אחסון בלוקים PersistentVolumeClaim אין תמיכה בפורמט qcow2 של תמונת דיסק.
  • התוסף Containerized Data Importer ‏ (CDI) לא תומך במשאבי DataVolumeאחסון בלוקים כי מרחב העבודה הזמני של התוסף פועל רק באחסון של מערכת קבצים. מידע נוסף זמין במאמר בנושא שטח אחסון זמני.

הקצאת מכונה וירטואלית של Linux ב-Distributed Cloud שמחובר לאחסון בלוקים גולמי

בדוגמה הבאה מוסבר איך להקצות מכונה וירטואלית של Linux עם אחסון בלוקים גולמי שמריץ את Ubuntu Server 22.04. מקור ההתקנה הוא קובץ אימג' של דיסק ISO של Ubuntu Server 22.04.

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

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: containerized-data-importer
  name: iso-ubuntu
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-block
  volumeMode: Block
  resources:
    requests:
      storage: 5Gi

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

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ubuntuhd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi
  storageClassName: local-block
  volumeMode: Block

  3. יוצרים משאב VirtualMachineDisk עם התוכן הבא עבור תמונת הדיסק להתקנה של Ubuntu Server, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-iso-disk"
spec:
  persistentVolumeClaimName: iso-ubuntu
  diskType: cdrom

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

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-main-disk"
spec:
  persistentVolumeClaimName: ubuntuhd

  5. יוצרים משאב VirtualMachineType עם התוכן הבא שמציין את ההגדרות של המכונה הווירטואלית, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  6. יוצרים משאב VirtualMachine עם התוכן הבא, שמפעיל את המכונה הווירטואלית באשכול, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: ubu-vm
  name: ubu-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Linux
  compute:
    virtualMachineTypeName: small-2-20
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: ubuntu-main-disk
      boot: true
    - virtualMachineDiskName: ubuntu-iso-disk

    השדה osType רלוונטי רק לאשכולות של מישור בקרה מקומי. הוא נדרש באשכולות של מישור הבקרה המקומי כדי להגדיר את התכונות הבאות:

  7. מתקינים את Ubuntu Server במכונה הווירטואלית:

    1. מחכים עד ש-importer Pod יוריד את קובץ האימג' של דיסק ההתקנה של Ubuntu Server.

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

      kubectl get gvm VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    3. מתחברים למכונה הווירטואלית:

      kubectl virt vnc VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    4. משלימים את שלבי ההתקנה של Ubuntu Linux.

  8. לפנות:

    1. מפסיקים את המכונה הווירטואלית:

      kubectl virt stop VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    2. עורכים את קובץ ה-YAML של המכונה הווירטואלית כדי להסיר את ההפניה לקובץ האימג' של דיסק ההתקנה:

      kubectl edit gvm VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    3. מפעילים את המכונה הווירטואלית:

      kubectl virt start VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    4. מוחקים את המשאבים VirtualMachineDisk ו-PersistentVolumeClaim של תמונת הדיסק להתקנה:

      kubectl delete virtualmachinedisk ubuntu-iso-disk
kubectl delete pvc iso-ubuntu

הקצאת מכונה וירטואלית של Windows ב-Distributed Cloud במודל מחובר עם אחסון בלוקים גולמי

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

  1. משיגים עותק מורשה של Windows וקובץ אימג' של מדיה להתקנה.

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

  3. יוצרים משאב PersistentVolumeClaim עם התוכן הבא עבור מנהל ההתקן virtio, ואז מחילים אותו על האשכול:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: containerized-data-importer
  name: virtio-driver
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-block
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi

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

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: windowshd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi
  storageClassName: local-block
  volumeMode: Block

  5. יוצרים משאב VirtualMachineDisk עם התוכן הבא בשביל תמונת הדיסק להתקנה של Windows, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "windows-iso-disk"
spec:
  persistentVolumeClaimName: iso-windows
  diskType: cdrom

  6. יוצרים משאב VirtualMachineDisk עם התוכן הבא עבור מנהל ההתקן virtio, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "win-virtio-driver"
spec:
  persistentVolumeClaimName: virtio-driver
  diskType: cdrom

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

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "windows-main-disk"
spec:
  persistentVolumeClaimName: windowshd

  8. יוצרים משאב VirtualMachineType עם התוכן הבא שמציין את ההגדרות של המכונה הווירטואלית, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  9. יוצרים משאב VirtualMachine עם התוכן הבא, שמפעיל את המכונה הווירטואלית באשכול, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: win-vm
  name: win-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Windows
  compute:
    virtualMachineTypeName: my-vmt
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: windows-main-disk
      boot: true
    - virtualMachineDiskName: windows-iso-disk
    - virtualMachineDiskName: win-virtio-driver

    השדה osType רלוונטי רק לאשכולות של מישור בקרה מקומי. הוא נדרש באשכולות של מישור הבקרה המקומי כדי להגדיר את התכונות הבאות:

  10. מתקינים את Windows במכונה הווירטואלית:

    1. ממתינים להורדה של קובץ האימג' של דיסק ההתקנה של Windows ב-importer Pod.

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

      kubectl get gvm VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – win-vm בדוגמה הזו.

    3. משלימים את ההתקנה של Windows לפי השלבים במאמר התחברות ל-VM של Windows והשלמת ההתקנה של מערכת ההפעלה.

  11. לפנות:

    1. מפסיקים את המכונה הווירטואלית:

      kubectl virt stop VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – win-vm בדוגמה הזו.

    2. פועלים לפי ההוראות שבמאמר ניתוק קובץ ה-ISO ודיסק מנהלי ההתקנים.

הקצאת מכונה וירטואלית ב-Distributed Cloud שמחובר ל-Symcloud Storage

בקטע הזה מופיעות דוגמאות להגדרות שממחישות איך להקצות מכונה וירטואלית של Linux ומכונה וירטואלית של Windows באשכול שמחובר ל-Distributed Cloud עם שכבת ההפשטה של Symcloud Storage.

לפני שמבצעים את השלבים שבקטע הזה, צריך קודם לבצע את השלבים שבקטע הגדרת Distributed Cloud connected ל-Symcloud Storage. אם תשביתו בהמשך את Symcloud Storage באשכול, המכונות הווירטואליות שהוגדרו לשימוש ב-Symcloud Storage ייכשלו.

הקצאת מכונה וירטואלית של Linux ב-Distributed Cloud שמחובר ל-Symcloud Storage

בדוגמה הבאה מוסבר איך להקצות מכונה וירטואלית של Linux עם Symcloud Storage שמופעלת בה Ubuntu Server 22.04. מקור ההתקנה הוא קובץ אימג' של דיסק ISO של Ubuntu Server 22.04.

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

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: ubuntu-iso-disk
spec:
  size: 20Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso

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

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-main-disk"
spec:
  size: 200Gi
  storageClassName: robin

  3. יוצרים משאב VirtualMachineType עם התוכן הבא שמציין את ההגדרות של המכונה הווירטואלית, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  4. יוצרים משאב VirtualMachine עם התוכן הבא, שמפעיל את המכונה הווירטואלית באשכול, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: ubu-vm
  name: ubu-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Linux
  compute:
    virtualMachineTypeName: small-2-20
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: ubuntu-main-disk
      boot: true
    - virtualMachineDiskName: ubuntu-iso-disk

    השדה osType רלוונטי רק לאשכולות של מישור בקרה מקומי. הוא נדרש באשכולות של מישור הבקרה המקומי כדי להגדיר את התכונות הבאות:

  5. מתקינים את Ubuntu Server במכונה הווירטואלית:

    1. מחכים עד ש-importer Pod יוריד את קובץ האימג' של דיסק ההתקנה של Ubuntu Server.

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

      kubectl get gvm VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    3. מתחברים למכונה הווירטואלית:

      kubectl virt vnc VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    4. משלימים את שלבי ההתקנה של Ubuntu Linux.

  6. לפנות:

    1. מפסיקים את המכונה הווירטואלית:

      kubectl virt stop VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    2. עורכים את קובץ ה-YAML של המכונה הווירטואלית כדי להסיר את ההפניה לקובץ האימג' של דיסק ההתקנה:

      kubectl edit gvm VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    3. מפעילים את המכונה הווירטואלית:

      kubectl virt start VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – ubu-vm בדוגמה הזו.

    4. מוחקים את משאב VirtualMachineDisk של קובץ האימג' של דיסק ההתקנה:

      kubectl delete virtualmachinedisk ubuntu-iso-disk

הקצאת מכונה וירטואלית של Windows ב-Distributed Cloud שמחובר ל-Symcloud Storage

בדוגמה הבאה מוצג תהליך הקצאת מכונה וירטואלית של Windows עם Symcloud Storage. השלבים דומים לאלה של הקצאת מכונה וירטואלית של Linux, עם תוספת של תמונת הדיסק של מנהל ההתקן virtio, שנדרשת להתקנת Windows.

  1. משיגים עותק מורשה של Windows וקובץ אימג' של מדיה להתקנה.

  2. יוצרים משאב VirtualMachineDisk עם התוכן הבא בשביל תמונת הדיסק להתקנה של Windows, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-iso-disk
  namespace: default
spec:
  size: 5Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: WINDOWS_ISO_URL

    מחליפים את NAT_GATEWAY בכתובת ה-URL המלאה של קובץ ה-ISO של התקנת Windows.

  3. יוצרים משאב VirtualMachineDisk עם התוכן הבא עבור מנהל ההתקן virtio, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-virtio-driver
  namespace: default
spec:
  size: 1Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

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

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-main-disk
  namespace: default
spec:
  size: 15Gi
  storageClassName: robin

  5. יוצרים משאב VirtualMachineType עם התוכן הבא שמציין את ההגדרות של המכונה הווירטואלית, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  6. יוצרים משאב VirtualMachine עם התוכן הבא, שמפעיל את המכונה הווירטואלית באשכול, ואז מחילים אותו על האשכול:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: win-vm
  name: win-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Windows
  compute:
    virtualMachineTypeName: my-vmt
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: windows-main-disk
      boot: true
    - virtualMachineDiskName: windows-iso-disk
    - virtualMachineDiskName: win-virtio-driver

    השדה osType רלוונטי רק לאשכולות של מישור בקרה מקומי. הוא נדרש באשכולות של מישור הבקרה המקומי כדי להגדיר את התכונות הבאות:

  7. מתקינים את Windows במכונה הווירטואלית:

    1. ממתינים להורדה של קובץ האימג' של דיסק ההתקנה של Windows ב-importer Pod.

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

      kubectl get gvm VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – win-vm בדוגמה הזו.

    3. משלימים את ההתקנה של Windows לפי השלבים במאמר התחברות ל-VM של Windows והשלמת ההתקנה של מערכת ההפעלה.

  8. לפנות:

    1. מפסיקים את המכונה הווירטואלית:

      kubectl virt stop VM_NAME

      מחליפים את VM_NAME בשם של המכונה הווירטואלית – win-vm בדוגמה הזו.

    2. פועלים לפי ההוראות שבמאמר ניתוק קובץ ה-ISO ודיסק מנהלי ההתקנים.

הקצאת מכונה וירטואלית ב-Distributed Cloud במודל מחובר באמצעות virtctl

אם אתם לא צריכים את ההתאמה האישית שמתקבלת מכתיבת מפרטים משלכם למכונות וירטואליות, אתם יכולים להקצות מכונה וירטואלית ב-Distributed Cloud באמצעות virtctlכלי שורת הפקודה, כמו שמתואר במאמר יצירת מכונה וירטואלית.

ניהול מכונות וירטואליות שפועלות ב-Distributed Cloud במודל מחובר

הוראות לניהול מכונות וירטואליות שפועלות ב-Distributed Cloud Connected זמינות במסמכי התיעוד הבאים בנושא VM Runtime on GDC:

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

הגדרת מכשיר ttyS0 לגישה למסוף הטורי למכונות וירטואליות של Linux

אם אתם מתכננים לגשת למכונות וירטואליות של Linux באמצעות המסוף הטורי (kubectl virt console), אתם צריכים לוודא שהמסוף הטורי של ttyS0 הוגדר במערכת ההפעלה של האורח. כדי להגדיר את המכשיר הזה, צריך לבצע את השלבים הבאים:

  1. יוצרים מופע של המכשיר עם יציאה טורית ttyS0 במערכת:

    setserial -g /dev/ttyS0

  2. מגדירים את תוכנת האתחול grub כך שתשתמש במכשיר עם יציאה טורית ttyS0 על ידי הוספת השורות הבאות לקובץ התצורה /etc/default/grub. השורה הראשונה מחליפה את המשתנה GRUB_CMDLINE_LINUX הקיים.

    GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,19200n8'
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"

  3. מחילים את ההגדרה החדשה של grub על מגזר האתחול:

    update-grub

  4. מפעילים מחדש את המכונה הווירטואלית.

השבתה של VM Runtime ב-GDC במודל מחובר של Distributed Cloud

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

כדי להשבית את VM Runtime ב-GDC on Distributed Cloud connected, צריך לשנות את VMRuntime המשאב בהתאמה אישית על ידי הגדרת הפרמטר enabled spec לערך false באופן הבא, ואז להחיל אותו על האשכול:

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  # Disable Anthos VM Runtime
  enabled: false
  # vmImageFormat defaults to "raw" if not set
  vmImageFormat: "raw"

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