مجازی سازی OpenShift: کانتینرها، KVM و ماشین های مجازی

مجازی سازی OpenShift (پروژه بالادست - Kubernetes: KubeVirt، نگاه کنید. اینجا и اینجا)، nee Container-native Virtualization، به عنوان یکی از قابلیت های پلتفرم OpenShift معرفی شد که برای استقرار و مدیریت ماشین های مجازی (VMs) به عنوان موجودیت های پایه Kubernetes طراحی شده است. این نوع کار به دلیل تفاوت های اساسی در فناوری، از نظر فنی چالش برانگیز است. برای رسیدن به این هدف از فناوری های آشنا مبتنی بر لینوکس Red Hat Enterprise و KVM استفاده کردیم که سال ها در کنار ما بوده و کارایی خود را به اثبات رسانده است.

در این مقاله، جنبه‌های فنی مجازی‌سازی OpenShift را بررسی خواهیم کرد که امکان همزیستی ماشین‌های مجازی و کانتینرها را در یک پلتفرم واحد فراهم می‌کند که آنها را به عنوان یک موجودیت واحد مدیریت می‌کند.

وظایف محاسباتی

کانتینرها از مکانیسم های هسته لینوکس مانند فضاهای نام و cgroup ها برای جداسازی فرآیندها و مدیریت منابع استفاده می کنند. معمولاً پردازش ها به صورت پایتون، برنامه های کاربردی جاوا یا فایل های اجرایی درک می شوند، اما در واقع می توانند هر فرآیندی مانند bash، Emacs یا vim باشند.

ماشین مجازی چیست؟ از دیدگاه هایپروایزر، این نیز یک فرآیند است. اما نه فرآیند برنامه، بلکه فرآیند KVM که مسئول اجرای یک VM خاص است.

تصویر ظرف حاوی تمام ابزارها، کتابخانه ها و فایل های مورد نیاز برای ماشین مجازی KVM است. اگر غلاف یک VM در حال اجرا را بررسی کنیم، کمک‌کننده‌ها و فرآیندهای qemu-kvm را می‌بینیم. علاوه بر این، ما به ابزارهای KVM برای مدیریت ماشین های مجازی مانند qemu-img، qemu-nbd و virsh دسترسی داریم.

از آنجایی که ماشین مجازی یک پاد است، به طور خودکار تمام عملکردهای یک پاد را در Kubernetes به ارث می برد. پادهای VM، درست مانند پادهای معمولی، تابع طرح‌ها و معیارهای زمان‌بندی مانند لکه‌ها، تحمل‌ها، وابستگی و ضد قرابت هستند. شما همچنین از مزایای دسترسی بالا و غیره بهره مند می شوید. با این حال، یک تفاوت مهم وجود دارد: غلاف های معمولی به معنای معمول از میزبانی به میزبان دیگر مهاجرت نمی کنند. اگر یک گره آفلاین شود، غلاف روی آن خاتمه یافته و دوباره به گره دیگری در خوشه اختصاص داده می شود. و در مورد ماشین مجازی، انتظار داریم که مهاجرت زنده را مشاهده کنیم.

برای رفع این شکاف، یک تعریف منبع سفارشی (CDR) برای توصیف مکانیسم مهاجرت زنده ایجاد شد که مسئول اولیه سازی، نظارت و مدیریت مهاجرت های زنده ماشین های مجازی بین گره های کارگر است.

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 اضافی را تعریف کند، که سپس توسط یک اپراتور شبکه Cluster خاص، روی خوشه مستقر و پیکربندی می‌شوند. سپس پادها به یک یا چند مورد از این شبکه ها، معمولاً OpenShiftSDN استاندارد و یک رابط اضافی متصل می شوند. دستگاه‌های SR-IOV، پل استاندارد لینوکس، دستگاه‌های 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 را دور بزند. این برای ماشین‌های مجازی که از Red Hat Virtualization یا VMware vSphere به OpenShift مهاجرت کرده‌اند مهم است، زیرا اگر به لایه دوم 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 (block) و RWX (پرونده) - OCS RWX را برای دستگاه‌های بلوک خام ارائه می‌کند که برای اشتراک‌گذاری دسترسی بلوک برای برنامه‌هایی با الزامات عملکرد بالا بسیار مفید است. علاوه بر این، OCS از استاندارد جدید Object Bucket Claim پشتیبانی می کند که به برنامه ها اجازه می دهد مستقیماً از ذخیره سازی داده های شی استفاده کنند.

ماشین های مجازی در کانتینرها

اگر علاقه مند به بررسی نحوه عملکرد آن هستید، بدانید که مجازی سازی OpenShift از قبل در نسخه پیش نمایش فناوری به عنوان بخشی از OpenShift 3.11 و بالاتر در دسترس است. دارندگان اشتراک OpenShift موجود می توانند از مجازی سازی OpenShift کاملاً رایگان و بدون هیچ مرحله اضافی استفاده کنند. در زمان انتشار این پست، OpenShift 4.4 و OpenShift مجازی سازی 2.3 جاری هستند؛ اگر از نسخه های قبلی استفاده می کنید، باید برای دریافت آخرین ویژگی ها، آن را ارتقا دهید. نسخه کاملاً پشتیبانی شده مجازی سازی OpenShift باید در نیمه دوم سال 2020 منتشر شود.

برای اطلاعات بیشتر لطفا به اسناد OpenShift برای دستورالعمل های نصب، از جمله بخش راه اندازی چندگانه، که اطلاعاتی در مورد راه اندازی شبکه های خارجی ارائه می دهد.

منبع: www.habr.com