OpenShift भर्चुअलाइजेशन: कन्टेनर, KVM र भर्चुअल मेसिनहरू

OpenShift भर्चुअलाइजेशन (अपस्ट्रीम परियोजना - Kubernetes: KubeVirt, हेर्नुहोस्। यहाँ и यहाँ), nee कन्टेनर-नेटिभ भर्चुअलाइजेसन, OpenShift प्लेटफर्मको कार्यक्षमताको रूपमा प्रस्तुत गरिएको थियो, जुन आधारभूत Kubernetes संस्थाहरूको रूपमा भर्चुअल मेशिनहरू (VMs) को तैनाती र व्यवस्थापनको लागि डिजाइन गरिएको हो। प्रविधिमा आधारभूत भिन्नताका कारण यस प्रकारको कार्य प्राविधिक रूपमा चुनौतीपूर्ण छ। यो लक्ष्य हासिल गर्नको लागि, हामीले Red Hat Enterprise Linux र KVM मा आधारित परिचित प्रविधिहरू प्रयोग गर्‍यौं, जुन धेरै वर्षदेखि हामीसँग छ र तिनीहरूको प्रभावकारिता प्रमाणित भएको छ।

यस लेखमा, हामी OpenShift भर्चुअलाइजेसनको प्राविधिक पक्षहरू हेर्नेछौं जसले VM र कन्टेनरहरूलाई एकल इकाईको रूपमा व्यवस्थापन गर्ने एउटै प्लेटफर्म भित्र एकसाथ रहन सम्भव बनाउँछ।

कम्प्यूटेशनल कार्यहरू

कन्टेनरहरूले लिनक्स कर्नेल मेकानिजमहरू प्रयोग गर्छन् जस्तै नामस्थान र cgroups प्रक्रियाहरू अलग गर्न र स्रोतहरू व्यवस्थापन गर्न। सामान्यतया प्रक्रियाहरूलाई पाइथन, जाभा अनुप्रयोगहरू वा कार्यान्वयनयोग्य फाइलहरू भनेर बुझिन्छ, तर वास्तवमा तिनीहरू कुनै पनि प्रक्रियाहरू हुन सक्छन्, जस्तै bash, Emacs वा vim।

भर्चुअल मेसिन भनेको के हो? हाइपरभाइजरको दृष्टिकोणबाट, यो पनि एक प्रक्रिया हो। तर आवेदन प्रक्रिया होइन, तर KVM प्रक्रिया एक विशिष्ट VM कार्यान्वयन गर्न जिम्मेवार छ।

कन्टेनर छविले KVM भर्चुअल मेसिनको लागि आवश्यक सबै उपकरणहरू, पुस्तकालयहरू र फाइलहरू समावेश गर्दछ। यदि हामीले चलिरहेको VM को पोड निरीक्षण गर्छौं भने, हामी त्यहाँ सहयोगीहरू र qemu-kvm प्रक्रियाहरू देख्नेछौं। थप रूपमा, हामीसँग qemu-img, qemu-nbd र virsh जस्ता भर्चुअल मेसिनहरू प्रबन्ध गर्न KVM उपकरणहरूमा पहुँच छ।

भर्चुअल मेसिन पोड भएको हुनाले, यसले कुबेरनेटमा पोडको सबै प्रकार्यता स्वतः प्राप्त गर्छ। VM पोडहरू, नियमित पोडहरू जस्तै, शेड्यूलर योजनाहरू र मापदण्डहरू जस्तै दाग, सहिष्णुता, आत्मीयता र विरोधी-सम्बन्धको अधीनमा छन्। तपाईले उच्च उपलब्धता, इत्यादिको फाइदाहरू पनि पाउनु हुन्छ। यद्यपि, त्यहाँ एउटा महत्त्वपूर्ण भिन्नता छ: नियमित पोडहरू सामान्य अर्थमा होस्टबाट होस्टमा माइग्रेट गर्दैनन्। यदि नोड अफलाइन हुन्छ भने, यसमा रहेको पोड समाप्त हुन्छ र क्लस्टरको अर्को नोडमा पुन: नियुक्त गरिन्छ। र भर्चुअल मेसिनको अवस्थामा, हामी प्रत्यक्ष माइग्रेसन हेर्ने आशा गर्छौं।

यस खाडललाई सम्बोधन गर्न, प्रत्यक्ष माइग्रेसन मेकानिजमको वर्णन गर्न कस्टम रिसोर्स डेफिनिशन (CDR) सिर्जना गरिएको थियो जुन कार्यकर्ता नोडहरू बीचको VMs को प्रत्यक्ष माइग्रेसन प्रारम्भ, निगरानी र व्यवस्थापन गर्न जिम्मेवार छ।

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

जब एक नोड निष्क्रिय हुन्छ, माइग्रेसन कार्यहरू स्वचालित रूपमा ती भर्चुअल मेसिनहरूका लागि सिर्जना हुन्छन् जसमा लाइभ माइग्रेसन तिनीहरूको निष्कासन रणनीतिको रूपमा सेट गरिएको हुन्छ। यस तरिकाले क्लस्टर नोडहरू बीचमा सर्दा भर्चुअल मेसिनहरूको व्यवहार नियन्त्रण गर्न सक्नुहुन्छ। तपाईं लाइभ माइग्रेसन कन्फिगर गर्न र VM व्यवस्थापन गर्न सक्नुहुन्छ, अन्य सबै पोडहरू जस्तै।

सञ्जाल

कुनै पनि Kubernetes प्रणालीले सफ्टवेयर 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 भर्चुअलाइजेशनको सम्बन्धमा, यसको मतलब यो हो कि SDN लाई बाइपास गरेर VM लाई सीधै बाह्य नेटवर्कमा जडान गर्न सकिन्छ। Red Hat Virtualization वा VMware vSphere बाट OpenShift मा माइग्रेट गरिएका भर्चुअल मेसिनहरूको लागि यो महत्त्वपूर्ण छ, किनकि यदि तपाईंसँग दोस्रो OSI तहमा पहुँच छ भने, त्यहाँ नेटवर्क सेटिङहरूमा कुनै परिवर्तन हुनेछैन। यसको मतलब यो पनि हो कि VM सँग SDN लाई बाइपास गर्ने नेटवर्क ठेगाना हुन सक्छ। यसरी, हामी प्रभावकारी रूपमा विशेष नेटवर्क एडेप्टरहरू प्रयोग गर्न सक्छौं, वा नेटवर्कमा भण्डारण प्रणालीमा सिधै जडान गर्न सक्छौं ...

तपाइँ कसरी OpenShift भर्चुअलाइजेशन भर्चुअल मेसिनहरू नेटवर्कमा सिर्जना गर्ने र जडान गर्ने बारे थप जान्न सक्नुहुन्छ यहाँ... साथै, nmstate अपरेटर, OpenShift भर्चुअलाइजेसनको भागको रूपमा तैनात गरिएको, हाइपरभाइजरहरू अन्तर्गत प्रयोग गरिने भौतिक नोडहरूमा नेटवर्क कन्फिगरेसनहरू सिर्जना र व्यवस्थापन गर्न अर्को परिचित तरिका प्रदान गर्दछ।

भण्डारण

OpenShift भर्चुअलाइजेशन भित्र भर्चुअल मेसिन डिस्कहरू जडान र व्यवस्थापन गर्ने कार्य Kubernetes अवधारणाहरू जस्तै StorageClasses, PersistentVolumeClaims (PVC) र PersistentVolume (PV), साथै Kubernetes वातावरणको लागि भण्डारण प्रोटोकलहरू प्रयोग गरी गरिन्छ। यसले Kubernetes प्रशासकहरू र अनुप्रयोग टोलीहरूलाई कन्टेनर र भर्चुअल मेसिनहरू व्यवस्थापन गर्न साझा, परिचित तरिका दिन्छ। र भर्चुअलाइजेशन वातावरणका धेरै प्रशासकहरूका लागि, यो अवधारणा परिचित लाग्न सक्छ किनभने यसले VM कन्फिगरेसन फाइलहरू र डिस्कहरू अलग गर्ने समान सिद्धान्त प्रयोग गर्दछ जुन OpenStack र अन्य धेरै क्लाउड प्लेटफर्महरूमा प्रयोग गरिन्छ।

यद्यपि, हामीले VM को लागि हरेक पटक नयाँ डिस्क सिर्जना गर्न सक्दैनौं, किनकि हाइपरभाइजरबाट OpenShift मा स्थानान्तरण गर्दा, हामीले डाटा बचत गर्न आवश्यक छ। हो, हामीले नयाँ VM प्रयोग गर्दा पनि, यसलाई स्क्र्याचबाट सिर्जना गर्नु भन्दा टेम्प्लेटबाट गर्न जहिले पनि छिटो हुन्छ। यसैले, हामीलाई अवस्थित डिस्कहरू आयात गर्न कार्यक्षमता चाहिन्छ।

यो कार्यलाई सरल बनाउनको लागि, 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 कन्टेनर भण्डारण (OCS), Ceph फाइल प्रणालीमा आधारित रेड ह्याट समाधान जसले कन्टेनरहरूको लागि निरन्तर भण्डारण कार्यक्षमता लागू गर्दछ, पनि उपयोगी छ। मानक PVC पहुँच विधिहरूको अतिरिक्त - RWO (ब्लक) र RWX (फाइल) - OCS ले कच्चा ब्लक उपकरणहरूको लागि RWX प्रदान गर्दछ, जुन उच्च प्रदर्शन आवश्यकताहरू भएका अनुप्रयोगहरूको लागि ब्लक पहुँच साझेदारी गर्न धेरै उपयोगी छ। थप रूपमा, OCS ले नयाँ वस्तु बकेट दावी मानकलाई समर्थन गर्दछ, जसले अनुप्रयोगहरूलाई वस्तु डेटा भण्डारण सीधा प्रयोग गर्न अनुमति दिन्छ।

कन्टेनरहरूमा भर्चुअल मेसिनहरू

यदि तपाइँ यो कसरी काम गर्दछ भनेर जाँच गर्न इच्छुक हुनुहुन्छ भने, तब जान्नुहोस् कि OpenShift भर्चुअलाइजेसन टेक पूर्वावलोकन संस्करणमा OpenShift 3.11 र उच्चको भागको रूपमा उपलब्ध छ। अवस्थित OpenShift सदस्यताका मालिकहरूले OpenShift भर्चुअलाइजेसन पूर्ण रूपमा निःशुल्क र कुनै अतिरिक्त चरणहरू बिना प्रयोग गर्न सक्छन्। यो पोष्टको समयमा, OpenShift 4.4 र OpenShift भर्चुअलाइजेशन 2.3 हाल छन्; यदि तपाइँ अघिल्लो संस्करणहरू प्रयोग गर्दै हुनुहुन्छ भने, तपाइँ नवीनतम सुविधाहरू प्राप्त गर्न अपग्रेड गर्नुपर्छ। OpenShift भर्चुअलाइजेशनको पूर्ण समर्थित संस्करण २०२० को दोस्रो आधामा जारी गरिनुपर्छ।

थप जानकारीको लागि कृपया सम्पर्क गर्नुहोस् OpenShift कागजात स्थापना निर्देशनहरूको लागि, सहित Multus सेटअप खण्ड, जसले बाह्य नेटवर्कहरू सेटअप गर्ने बारे जानकारी प्रदान गर्दछ।

स्रोत: www.habr.com