OpenShift ورچوئلائيزيشن: ڪنٽينرز، KVM ۽ ورچوئل مشينون

OpenShift ورچوئلائيزيشن (اپ اسٽريم پروجيڪٽ - Kubernetes: KubeVirt، ڏسو. هتي и هتي)، nee ڪنٽينر-آبائي ورچوئلائيزيشن، متعارف ڪرايو ويو هڪ ڪارڪردگي جي طور تي OpenShift پليٽ فارم، جيڪو ڊزائين ڪرڻ ۽ انتظام ڪرڻ لاء ٺهيل آهي مجازي مشين (VMs) کي بنيادي ڪبرنيٽس ادارن جي طور تي. ٽيڪنالاجي ۾ بنيادي اختلافن جي ڪري هن قسم جو ڪم ٽيڪنيڪل طور تي مشڪل آهي. ھن مقصد کي حاصل ڪرڻ لاءِ، اسان Red Hat Enterprise Linux ۽ KVM تي ٻڌل واقف ٽيڪنالاجيون استعمال ڪيون، جيڪي اسان سان ڪيترن ئي سالن کان موجود آھن ۽ انھن جي اثرائيت کي ثابت ڪيو آھي.

هن آرٽيڪل ۾، اسان OpenShift ورچوئلائيزيشن جي ٽيڪنيڪل پهلوئن تي نظر وجهنداسين جيڪي VMs ۽ ڪنٽينرز لاءِ هڪ پليٽ فارم جي اندر گڏ رهڻ کي ممڪن بڻائين ٿا جيڪي انهن کي هڪ واحد اداري طور منظم ڪن ٿا.

ڪمپيوٽيشنل ڪم

ڪنٽينر لينڪس ڪنيل ميڪانيزم استعمال ڪن ٿا جهڙوڪ نالا اسپيس ۽ سي گروپس پروسيس کي الڳ ڪرڻ ۽ وسيلن کي منظم ڪرڻ لاءِ. عام طور تي پروسيس کي پٿون، جاوا ايپليڪيشنون يا ايگزيڪيوٽو فائلن جي طور تي سمجھندا آهن، پر حقيقت ۾ اهي ڪنهن به پروسيس ٿي سگهن ٿيون، جهڙوڪ bash، Emacs يا vim.

هڪ مجازي مشين ڇا آهي؟ هائپرائزر جي نقطي نظر کان، اهو پڻ هڪ عمل آهي. پر ايپليڪيشن جو عمل نه، پر KVM عمل هڪ مخصوص VM تي عمل ڪرڻ لاء ذميوار آهي.

ڪنٽينر جي تصوير ۾ KVM ورچوئل مشين لاءِ گهربل سڀئي اوزار، لائبريريون ۽ فائلون شامل آهن. جيڪڏهن اسان هلندڙ VM جي پوڊ جو معائنو ڪنداسين، اسان اتي ڏسنداسين مددگار ۽ qemu-kvm پروسيس. اضافي طور تي، اسان وٽ رسائي آهي KVM اوزارن کي منظم ڪرڻ لاء مجازي مشينن جهڙوڪ qemu-img، qemu-nbd ۽ virsh.

جيئن ته هڪ مجازي مشين هڪ پوڊ آهي، اهو خود بخود ڪبرنيٽس ۾ پوڊ جي سڀني ڪارڪردگي کي ورثي ۾ ڏئي ٿو. وي ايم پوڊس، صرف باقاعده پوڊ وانگر، شيڊولر اسڪيمن ۽ معيار جي تابع آهن جهڙوڪ داغ، رواداري، لاڳاپو ۽ ضد. توهان پڻ اعلي دستيابي جا فائدا حاصل ڪريو، وغيره. تنهن هوندي، اتي هڪ اهم فرق آهي: باقاعده پوڊ عام طور تي ميزبان کان ميزبان ڏانهن لڏپلاڻ نه ڪندا آهن. جيڪڏهن ڪو نوڊ آف لائن ٿي وڃي ٿو، ان تي پوڊ ختم ڪيو ويندو آهي ۽ ڪلستر ۾ ڪنهن ٻئي نوڊ کي ٻيهر لڳايو ويندو آهي. ۽ هڪ مجازي مشين جي صورت ۾، اسان کي زنده لڏپلاڻ ڏسڻ جي اميد آهي.

هن خال کي حل ڪرڻ لاءِ، لائيو لڏپلاڻ واري ميڪانيزم کي بيان ڪرڻ لاءِ هڪ ڪسٽم ريسورس ڊيفينيشن (سي ڊي آر) ٺاهي وئي جيڪا ڪم ڪندڙ نوڊس جي وچ ۾ VMs جي لائيو لڏپلاڻ جي شروعات، نگراني ۽ انتظام ڪرڻ جو ذميوار آهي.

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

جڏهن هڪ نوڊ کي غير فعال ڪيو ويندو آهي، لڏپلاڻ جا ڪم پاڻمرادو ٺاهيا ويندا آهن انهن ورچوئل مشينن لاءِ جن کي لائيو لڏپلاڻ انهن جي بي دخلي حڪمت عملي طور مقرر ڪئي وئي آهي. اهو طريقو توهان مجازي مشينن جي رويي کي ڪنٽرول ڪري سگهو ٿا جڏهن ڪلستر نوڊس جي وچ ۾ حرڪت ڪندي. توھان ٻئي ڪري سگھوٿا لائيو لڏپلاڻ کي ترتيب ڏيو ۽ وي ايم کي منظم ڪريو، ٻين سڀني پوڊ وانگر.

نيٽورڪ

ڪو به ڪبرنيٽس سسٽم سافٽ ويئر SDN نيٽ ورڪ استعمال ڪندي نوڊس ۽ پوڊس جي وچ ۾ رابطي کي مهيا ڪري ٿو. OpenShift ڪو به استثنا نه آهي ۽، نسخو 3 کان شروع ٿئي ٿو، OpenShiftSDN هن لاءِ ڊفالٽ طور استعمال ڪري ٿو. ان کان علاوه، OpenShift 4 ۾ هڪ ٻيو نئون فيچر آهي جنهن کي Multus سڏيو ويندو آهي، جيڪو توهان کي اجازت ڏئي ٿو ڪيترن ئي نيٽ ورڪن کي دستياب ڪرڻ ۽ انهن سان گڏ پوڊ کي ڳنڍڻ جي.

Multus استعمال ڪندي، ايڊمنسٽريٽر اضافي CNI نيٽ ورڪ جي وضاحت ڪري سگھي ٿو، جن کي پوءِ خاص ڪلسٽر نيٽ ورڪ آپريٽر ذريعي ڪلسٽر تي ترتيب ۽ ترتيب ڏنو ويندو. پوڊز وري انهن نيٽ ورڪن مان هڪ يا وڌيڪ سان ڳنڍيل آهن، عام طور تي معياري OpenShiftSDN ۽ هڪ اضافي انٽرفيس. SR-IOV ڊوائيسز، معياري لينڪس برج، MACVLAN ۽ IPVLAN ڊوائيسز سڀ استعمال ڪري سگھجن ٿيون جيڪڏھن توھان جي VM کي ضرورت آھي. هيٺ ڏنل انگ اکر ڏيکاري ٿو ته ڪيئن eth1 انٽرفيس تي پل نيٽ ورڪ لاءِ Multus CNI سيٽ ڪجي:

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 ورچوئلائيزيشن جي اندر ورچوئل مشين ڊسڪ کي ڳنڍڻ ۽ منظم ڪرڻ ڪبرنيٽس تصورات جهڙوڪ StorageClasses، PersistentVolumeClaims (PVC) ۽ PersistentVolume (PV)، گڏوگڏ ڪبرنيٽس ماحول لاءِ اسٽوريج پروٽوڪول معياري استعمال ڪندي ڪيو ويندو آهي. هي Kubernetes منتظمين ۽ ايپليڪيشن ٽيمن کي ڏئي ٿو هڪ عام، واقف طريقو ٻنهي ڪنٽينرز ۽ ورچوئل مشينن کي منظم ڪرڻ لاءِ. ۽ ورچوئلائيزيشن ماحول جي ڪيترن ئي منتظمين لاءِ، اهو تصور شايد واقف ٿي سگهي ٿو ڇاڪاڻ ته اهو ساڳيو اصول استعمال ڪري ٿو VM ترتيب واري فائلن ۽ ڊسڪ کي الڳ ڪرڻ جو جيڪو OpenStack ۽ ٻين ڪيترن ئي ڪلائوڊ پليٽ فارمن ۾ استعمال ٿئي ٿو.

تنهن هوندي، اسان صرف هر وقت VM لاء نئين ڊسڪ ٺاهي نٿا سگهون، ڇاڪاڻ ته جڏهن هائپرائزر کان 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 ڪنٽينر اسٽوريج (OCS)، هڪ Red Hat حل جنهن جي بنياد تي Ceph فائل سسٽم جيڪو ڪنٽينرز لاء مسلسل اسٽوريج ڪارڪردگي کي لاڳو ڪري ٿو، پڻ ڪارائتو آهي. معياري PVC رسائي جي طريقن کان علاوه - RWO (بلاڪ) ۽ RWX (فائل) - OCS خام بلاڪ ڊوائيسز لاء RWX مهيا ڪري ٿو، جيڪو اعلي ڪارڪردگي جي ضرورتن سان ايپليڪيشنن لاء بلاڪ رسائي جي حصيداري لاء تمام مفيد آهي. اضافي طور تي، OCS نئين آبجیکٹ بالٽ دعوي جي معيار کي سپورٽ ڪري ٿو، جيڪا ايپليڪيشنن کي سڌو سنئون ڊيٽا اسٽوريج استعمال ڪرڻ جي اجازت ڏئي ٿي.

ڪنٽينرز ۾ مجازي مشينون

جيڪڏهن توهان چيڪ ڪرڻ ۾ دلچسپي رکو ٿا ته اهو ڪيئن ڪم ڪري ٿو، پوء ڄاڻو ته OpenShift ورچوئلائيزيشن اڳ ۾ ئي موجود آهي ٽيڪن پريويو ورزن ۾ OpenShift 3.11 ۽ اعلي جي حصي جي طور تي. موجوده OpenShift رڪنيت جا مالڪ OpenShift ورچوئلائيزيشن استعمال ڪري سگھن ٿا مڪمل طور تي مفت ۽ بغير ڪنهن اضافي قدمن جي. ھن پوسٽ جي وقت، OpenShift 4.4 ۽ OpenShift ورچوئلائيزيشن 2.3 موجوده آھن؛ جيڪڏھن توھان استعمال ڪري رھيا آھيو پوئين ورزن، توھان کي اپڊيٽ ڪرڻ گھرجي تازه ترين خاصيتون حاصل ڪرڻ لاءِ. OpenShift ورچوئلائيزيشن جو مڪمل طور تي سپورٽ ٿيل ورزن 2020 جي ٻئي اڌ ۾ جاري ڪيو وڃي.

وڌيڪ معلومات لاء مهرباني ڪري رابطو ڪريو OpenShift دستاويز تنصيب جي هدايتن لاء، بشمول ملٽس سيٽ اپ سيڪشن، جيڪو خارجي نيٽ ورڪ قائم ڪرڻ بابت معلومات مهيا ڪري ٿو.

جو ذريعو: www.habr.com