OpenShift ვირტუალიზაცია: კონტეინერები, KVM და ვირტუალური მანქანები

OpenShift ვირტუალიზაცია (upstream პროექტი - Kubernetes: KubeVirt, იხ. აქ и აქ), nee Container-native Virtualization, დაინერგა, როგორც OpenShift პლატფორმის ფუნქციონალობა, რომელიც შექმნილია ვირტუალური მანქანების (VMs) განლაგებისა და მართვისთვის, როგორც ძირითადი Kubernetes ერთეულები. ამ ტიპის ამოცანა ტექნიკურად რთულია ტექნოლოგიების ფუნდამენტური განსხვავებების გამო. ამ მიზნის მისაღწევად გამოვიყენეთ Red Hat Enterprise Linux-სა და KVM-ზე დაფუძნებული ნაცნობი ტექნოლოგიები, რომლებიც უკვე მრავალი წელია ჩვენთანაა და დადასტურებულია მათი ეფექტურობა.

ამ სტატიაში ჩვენ განვიხილავთ OpenShift ვირტუალიზაციის ტექნიკურ ასპექტებს, რომლებიც შესაძლებელს ხდის ვირტუალური კომპიუტერული ტექნიკის და კონტეინერების თანაარსებობას ერთ პლატფორმაში, რომელიც მართავს მათ, როგორც ერთიან ერთეულს.

გამოთვლითი ამოცანები

კონტეინერები იყენებენ Linux-ის ბირთვის მექანიზმებს, როგორიცაა სახელთა სივრცეები და cgroups პროცესების იზოლირებისთვის და რესურსების სამართავად. ჩვეულებრივ პროცესებს ესმით როგორც Python, Java აპლიკაციები ან შესრულებადი ფაილები, მაგრამ სინამდვილეში ისინი შეიძლება იყოს ნებისმიერი პროცესი, როგორიცაა bash, Emacs ან vim.

რა არის ვირტუალური მანქანა? ჰიპერვიზორის თვალსაზრისით, ეს ასევე პროცესია. მაგრამ არა განაცხადის პროცესი, არამედ KVM პროცესი, რომელიც პასუხისმგებელია კონკრეტული VM-ის შესრულებაზე.

კონტეინერის სურათი შეიცავს ყველა ინსტრუმენტს, ბიბლიოთეკას და ფაილს, რომელიც საჭიროა KVM ვირტუალური მანქანისთვის. თუ ჩვენ ვამოწმებთ გაშვებული VM-ის პოდს, იქ დავინახავთ დამხმარეებს და qemu-kvm პროცესებს. გარდა ამისა, ჩვენ გვაქვს წვდომა KVM ინსტრუმენტებზე ვირტუალური მანქანების მართვისთვის, როგორიცაა qemu-img, qemu-nbd და virsh.

ვინაიდან ვირტუალური მანქანა არის pod, ის ავტომატურად მემკვიდრეობით იღებს პოდის მთელ ფუნქციონირებას Kubernetes-ში. VM pods, ისევე როგორც ჩვეულებრივი pods, ექვემდებარება გრაფიკის სქემებს და კრიტერიუმებს, როგორიცაა დაბინძურება, ტოლერანტობა, აფინურობა და ანტი-აფინურობა. თქვენ ასევე იღებთ მაღალი ხელმისაწვდომობის სარგებელს და ა.შ. თუმცა, არის ერთი მნიშვნელოვანი განსხვავება: ჩვეულებრივი ღეროები არ გადადიან მასპინძიდან მასპინძელზე ჩვეულებრივი გაგებით. თუ კვანძი გადის ხაზგარეშე რეჟიმში, მასზე არსებული ბლოკი წყდება და ხელახლა მიეკუთვნება კლასტერის სხვა კვანძს. და ვირტუალური მანქანის შემთხვევაში, ჩვენ ველოდებით ცოცხალ მიგრაციას.

ამ ხარვეზის აღმოსაფხვრელად, შეიქმნა საბაჟო რესურსის განმარტება (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-ის გვერდის ავლით. ეს მნიშვნელოვანია 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 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