וירטואליזציה של OpenShift: קונטיינרים, KVM ומכונות וירטואליות

וירטואליזציה של OpenShift (פרויקט במעלה הזרם - Kubernetes: KubeVirt, ראה. כאן и כאן), בנוי וירטואליזציה מקורית של Container, הוצגה כפונקציונליות של פלטפורמת OpenShift, המיועדת לפריסה וניהול של מכונות וירטואליות (VMs) כישויות בסיסיות של Kubernetes. משימה מסוג זה היא מאתגרת מבחינה טכנית בשל הבדלים מהותיים בטכנולוגיה. על מנת להשיג מטרה זו, השתמשנו בטכנולוגיות מוכרות המבוססות על Red Hat Enterprise Linux ו-KVM, אשר נמצאות איתנו שנים רבות והוכיחו את יעילותן.

במאמר זה, נבחן את ההיבטים הטכניים של וירטואליזציה של OpenShift המאפשרים ל-VMs ומכולות להתקיים במקביל בתוך פלטפורמה אחת המנהלת אותם כישות אחת.

משימות חישוביות

קונטיינרים משתמשים במנגנוני ליבת לינוקס כגון מרחבי שמות וקבוצות cgroups כדי לבודד תהליכים ולנהל משאבים. בדרך כלל תהליכים מובנים כמו Python, יישומי Java או קבצי הפעלה, אבל למעשה הם יכולים להיות כל תהליכים, כגון bash, Emacs או vim.

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

תמונת המכולה מכילה את כל הכלים, הספריות והקבצים הדרושים למכונה הוירטואלית KVM. אם נבדוק את הפוד של VM פועל, נראה שם עוזרים ותהליכי qemu-kvm. בנוסף, יש לנו גישה לכלי KVM לניהול מכונות וירטואליות כגון qemu-img, qemu-nbd ו-virsh.

מכיוון שמכונה וירטואלית היא פוד, היא יורשת אוטומטית את כל הפונקציונליות של פוד ב-Kubernetes. תרמילים של VM, בדיוק כמו תרמילים רגילים, כפופים לסכימות וקריטריונים של מתזמן כגון כתמים, סובלנות, זיקה ואנטי זיקה. אתה גם מקבל את היתרונות של זמינות גבוהה וכו'. עם זאת, יש הבדל אחד חשוב: תרמילים רגילים אינם נודדים ממארח ​​למארח במובן הרגיל. אם צומת עובר למצב לא מקוון, הפוד שבו נסגר ומוקצה מחדש לצומת אחר באשכול. ובמקרה של מכונה וירטואלית, אנו מצפים לראות הגירה חיה.

כדי להתמודד עם הפער הזה, נוצרה הגדרת משאב מותאמת אישית (CDR) כדי לתאר את מנגנון ההגירה החי שאחראי על אתחול, ניטור וניהול העברות חיות של מחשבי VM בין צמתי עובדים.

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

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

רשת

כל מערכת Kubernetes מספקת תקשורת בין צמתים ותרמילים באמצעות רשתות SDN תוכנות. OpenShift אינו יוצא דופן, והחל מגרסה 3, משתמש ב-OpenShiftSDN כברירת מחדל עבור זה. בנוסף, ל-OpenShift 4 יש תכונה חדשה נוספת בשם Multus, המאפשרת להפוך מספר רשתות לזמינות ולחבר אליהן פודים בו-זמנית.

באמצעות Multus, המנהל יכול להגדיר רשתות CNI נוספות, אשר לאחר מכן ייפרסו ויוגדרו באשכול על ידי מפעיל רשת אשכול מיוחד. לאחר מכן, התרמילים מחוברים לאחת או יותר מהרשתות הללו, בדרך כלל ל-OpenShiftSDN הסטנדרטי ולממשק נוסף. ניתן להשתמש בהתקני SR-IOV, התקני Linux Bridge סטנדרטיים, MACVLAN ו-IPVLAN אם ה-VM שלך זקוק לכך. האיור שלהלן מראה כיצד להגדיר Multus CNI עבור רשת הגשר בממשק eth1:

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
   { "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
   type: Raw

ביחס לווירטואליזציה של OpenShift, המשמעות היא שניתן לחבר VM ישירות לרשת חיצונית, תוך עקיפת SDN. זה חשוב למכונות וירטואליות שהועברו ל-OpenShift מ-Red Hat Virtualization או VMware vSphere, מכיוון שאם יש לך גישה לשכבת OSI השנייה, לא יהיה שינוי בהגדרות הרשת. זה גם אומר של-VM עשויה להיות כתובת רשת שעוקפת SDN. כך, אנו יכולים להשתמש ביעילות במתאמי רשת מיוחדים, או להתחבר ישירות למערכת האחסון דרך הרשת...

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

אחסון

חיבור וניהול דיסקים של מכונות וירטואליות בתוך הוירטואליזציה של OpenShift מבוצעים באמצעות מושגי Kubernetes כגון StorageClasses, PersistentVolumeClaims (PVC) ו-PersistentVolume (PV), כמו גם פרוטוקולי אחסון סטנדרטיים עבור סביבת Kubernetes. זה נותן למנהלי וצוותי יישומים של Kubernetes דרך נפוצה ומוכרת לנהל הן קונטיינרים והן מכונות וירטואליות. ועבור מנהלי מערכת רבים של סביבות וירטואליזציה, הרעיון הזה עשוי להישמע מוכר מכיוון שהוא משתמש באותו עיקרון של הפרדת קבצי תצורה ודיסקים של VM, המשמש ב-OpenStack ובפלטפורמות ענן רבות אחרות.

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

כדי לפשט משימה זו, וירטואליזציה של OpenShift פורסת את פרויקט Containerized Data Importer (CDI), אשר מצמצם ייבוא ​​של תמונות דיסקים של דיסקים ממקורות מרובים ליצירת ערך PVC.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "fedora-disk0"
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
  storageClassName: ocs-gold
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

ערך זה הוא שמפעיל את CDI, ומפעיל את רצף הפעולות המוצג באיור למטה:

לאחר השלמת ה-CDI, ה-PVC יכיל את הדיסק של המכונה הווירטואלית מוכן לשימוש והומר לפורמט OpenShift הסטנדרטי...
בעבודה עם וירטואליזציה של OpenShift, שימושי גם OpenShift Container Storage (OCS), פתרון Red Hat המבוסס על מערכת הקבצים Ceph המיישמת פונקציונליות אחסון מתמשכת עבור קונטיינרים. בנוסף לשיטות הגישה הסטנדרטיות ל-PVC - RWO (בלוק) ו-RWX (קובץ) - OCS מספקת RWX עבור התקני בלוק גולמי, דבר שימושי מאוד לשיתוף גישה לחסימה עבור יישומים עם דרישות ביצועים גבוהות. בנוסף, OCS תומך בתקן החדש Object Bucket Claim, המאפשר לאפליקציות להשתמש ישירות באחסון נתוני אובייקט.

מכונות וירטואליות בקונטיינרים

אם אתם מעוניינים לבדוק איך זה עובד, אז דעו שהוירטואליזציה של OpenShift כבר זמינה בגרסת Tech Preview כחלק מ-OpenShift 3.11 ומעלה. בעלים של מנוי קיים של OpenShift יכולים להשתמש בווירטואליזציה של OpenShift ללא עלות לחלוטין וללא שלבים נוספים. בזמן פוסט זה, OpenShift 4.4 ו-OpenShift וירטואליזציה 2.3 עדכניות; אם אתה משתמש בגרסאות קודמות, עליך לשדרג כדי לקבל את התכונות העדכניות ביותר. גרסה נתמכת במלואה של וירטואליזציה של OpenShift אמורה להשתחרר במחצית השנייה של 2020.

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

מקור: www.habr.com