افتراضية OpenShift: الحاويات و KVM والآلات الافتراضية

المحاكاة الافتراضية لـ OpenShift (مشروع المنبع - Kubernetes: KubeVirt، انظر. هنا и هنا)، nee Container-native Virtualization، تم تقديمها كوظيفة من وظائف نظام OpenShift الأساسي، والتي تم تصميمها لنشر وإدارة الأجهزة الافتراضية (VMs) باعتبارها كيانات Kubernetes أساسية. يمثل هذا النوع من المهام تحديًا تقنيًا بسبب الاختلافات الأساسية في التكنولوجيا. ومن أجل تحقيق هذا الهدف، استخدمنا تقنيات مألوفة تعتمد على Red Hat Enterprise Linux وKVM، والتي كانت معنا لسنوات عديدة وأثبتت فعاليتها.

في هذه المقالة، سنلقي نظرة على الجوانب الفنية لمحاكاة OpenShift الافتراضية التي تتيح للأجهزة الافتراضية والحاويات التعايش ضمن منصة واحدة تديرها ككيان واحد.

المهام الحسابية

تستخدم الحاويات آليات Linux kernel مثل مساحات الأسماء ومجموعات التحكم لعزل العمليات وإدارة الموارد. تُفهم العمليات عادةً على أنها تطبيقات Python أو Java أو ملفات قابلة للتنفيذ، ولكنها في الواقع يمكن أن تكون أي عمليات، مثل bash أو Emacs أو vim.

ما هي الآلة الافتراضية؟ من وجهة نظر برنامج Hypervisor، فهذه أيضًا عملية. ولكن ليست عملية التقديم، ولكن عملية KVM المسؤولة عن تنفيذ جهاز افتراضي محدد.

تحتوي صورة الحاوية على جميع الأدوات والمكتبات والملفات اللازمة لجهاز 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 إضافية، والتي سيتم بعد ذلك نشرها وتكوينها على المجموعة بواسطة مشغل شبكة مجموعة خاص. يتم بعد ذلك توصيل القرون بواحدة أو أكثر من هذه الشبكات، عادةً ما تكون 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 الافتراضية، فهذا يعني أنه يمكن توصيل جهاز افتراضي بشبكة خارجية مباشرة، متجاوزًا SDN. يعد هذا أمرًا مهمًا بالنسبة للأجهزة الافتراضية التي تم ترحيلها إلى OpenShift من Red Hat Virtualization أو VMware vSphere، لأنه إذا كان لديك حق الوصول إلى طبقة OSI الثانية، فلن يكون هناك أي تغيير في إعدادات الشبكة. وهذا يعني أيضًا أن الجهاز الافتراضي قد يكون له عنوان شبكة يتجاوز SDN. وبالتالي، يمكننا استخدام محولات الشبكة المتخصصة بشكل فعال، أو الاتصال مباشرة بنظام التخزين عبر الشبكة...

يمكنك معرفة المزيد حول كيفية إنشاء الأجهزة الافتراضية لمحاكاة OpenShift وتوصيلها بالشبكة هنا. وبالإضافة إلى ذلك، مشغل نمتاست، الذي تم نشره كجزء من المحاكاة الافتراضية لـ OpenShift، يقدم طريقة أخرى مألوفة لإنشاء وإدارة تكوينات الشبكة على العقد الفعلية المستخدمة ضمن برامج Hypervisor.

تخزين

يتم إجراء توصيل وإدارة أقراص الآلة الافتراضية ضمن المحاكاة الافتراضية لـ OpenShift باستخدام مفاهيم Kubernetes مثل StorageClasses وPersistentVolumeClaims (PVC) وPersistentVolume (PV)، بالإضافة إلى بروتوكولات التخزين القياسية لبيئة Kubernetes. وهذا يمنح مسؤولي Kubernetes وفرق التطبيقات طريقة شائعة ومألوفة لإدارة كل من الحاويات والأجهزة الافتراضية. وبالنسبة للعديد من مسؤولي بيئات المحاكاة الافتراضية، قد يبدو هذا المفهوم مألوفًا لأنه يستخدم نفس مبدأ فصل ملفات تكوين الأجهزة الافتراضية والأقراص المستخدمة في OpenStack والعديد من الأنظمة الأساسية السحابية الأخرى.

ومع ذلك، لا يمكننا ببساطة إنشاء قرص جديد للجهاز الافتراضي في كل مرة، لأنه عند الترحيل من برنامج Hypervisor إلى OpenShift، نحتاج إلى حفظ البيانات. نعم، حتى عندما نقوم بنشر جهاز افتراضي جديد، يكون دائمًا القيام بذلك من القالب أسرع من إنشائه من البداية. وبالتالي، نحن بحاجة إلى وظيفة لاستيراد الأقراص الموجودة.

لتبسيط هذه المهمة، تقوم المحاكاة الافتراضية لـ OpenShift بنشر مشروع مستورد البيانات الحاوية (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 Virtualization 2.3 محدثين؛ إذا كنت تستخدم الإصدارات السابقة، فيجب عليك الترقية للحصول على أحدث الميزات. من المقرر إصدار نسخة مدعومة بالكامل من المحاكاة الافتراضية OpenShift في النصف الثاني من عام 2020.

للمزيد من المعلومات أرجو الأتصال وثائق أوبن شيفت للحصول على تعليمات التثبيت، بما في ذلك قسم الإعداد Multis، والذي يوفر معلومات حول إعداد الشبكات الخارجية.

المصدر: www.habr.com