Virtualisasi OpenShift (projek huluan - Kubernetes: KubeVirt, lihat. ΠΈ ), nee Virtualisasi asli kontena, diperkenalkan sebagai kefungsian platform OpenShift, yang direka untuk mengatur dan mengurus mesin maya (VM) sebagai entiti Kubernetes asas. Tugas semacam ini secara teknikalnya mencabar kerana perbezaan asas dalam teknologi. Untuk mencapai matlamat ini, kami menggunakan teknologi biasa berdasarkan Red Hat Enterprise Linux dan KVM, yang telah bersama kami selama bertahun-tahun dan telah membuktikan keberkesanannya.
Dalam artikel ini, kita akan melihat aspek teknikal virtualisasi OpenShift yang membolehkan VM dan bekas wujud bersama dalam satu platform yang mengurusnya sebagai satu entiti.
Tugas pengiraan
Bekas menggunakan mekanisme kernel Linux seperti ruang nama dan cgroup untuk mengasingkan proses dan mengurus sumber. Biasanya proses difahami sebagai Python, aplikasi Java atau fail boleh laku, tetapi sebenarnya ia boleh menjadi sebarang proses, seperti bash, Emacs atau vim.
Apakah mesin maya? Dari sudut pandangan hypervisor, ini juga satu proses. Tetapi bukan proses permohonan, tetapi proses KVM yang bertanggungjawab untuk melaksanakan VM tertentu.
Imej bekas mengandungi semua alatan, perpustakaan dan fail yang diperlukan untuk mesin maya KVM. Jika kita memeriksa pod VM yang sedang berjalan, kita akan melihat di sana pembantu dan proses qemu-kvm. Selain itu, kami mempunyai akses kepada alatan KVM untuk mengurus mesin maya seperti qemu-img, qemu-nbd dan virsh.
Memandangkan mesin maya ialah pod, ia secara automatik mewarisi semua fungsi pod dalam Kubernetes. Pod VM, sama seperti pod biasa, tertakluk pada skim dan kriteria penjadual seperti kotoran, toleransi, pertalian dan anti pertalian. Anda juga mendapat manfaat ketersediaan tinggi, dsb. Walau bagaimanapun, terdapat satu perbezaan penting: pod biasa tidak berhijrah dari hos ke hos dalam erti kata biasa. Jika nod di luar talian, pod padanya ditamatkan dan ditugaskan semula ke nod lain dalam kelompok. Dan dalam kes mesin maya, kami menjangkakan untuk melihat penghijrahan secara langsung.
Untuk menangani jurang ini, definisi sumber tersuai (CDR) telah dibuat untuk menerangkan mekanisme migrasi langsung yang bertanggungjawab untuk memulakan, memantau dan mengurus migrasi langsung VM antara nod pekerja.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Apabila nod dinyahaktifkan, tugas migrasi dibuat secara automatik untuk mesin maya yang telah ditetapkan Migrasi Langsung sebagai strategi pengusiran mereka. Dengan cara ini anda boleh mengawal tingkah laku mesin maya apabila bergerak antara nod kluster. Anda boleh mengkonfigurasi Migrasi Langsung dan mengurus VM, seperti semua pod lain.
Π‘Π΅ΡΡ
Mana-mana sistem Kubernetes menyediakan komunikasi antara nod dan pod menggunakan rangkaian SDN perisian. OpenShift tidak terkecuali dan, bermula dari versi 3, menggunakan OpenShiftSDN secara lalai untuk ini. Selain itu, OpenShift 4 mempunyai satu lagi ciri baharu yang dipanggil Multus, yang membolehkan anda menyediakan berbilang rangkaian dan menyambungkan pod kepada mereka secara serentak.
Menggunakan Multus, pentadbir boleh menentukan rangkaian CNI tambahan, yang kemudiannya akan digunakan dan dikonfigurasikan pada kluster oleh Operator Rangkaian Kluster khas. Pod kemudiannya disambungkan kepada satu atau lebih rangkaian ini, biasanya OpenShiftSDN standard dan antara muka tambahan. Peranti SR-IOV, peranti Linux Bridge standard, MACVLAN dan IPVLAN semuanya boleh digunakan jika VM anda memerlukannya. Rajah di bawah menunjukkan cara untuk menetapkan Multus CNI untuk rangkaian jambatan pada antara muka 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
Berhubung dengan virtualisasi OpenShift, ini bermakna VM boleh disambungkan ke rangkaian luaran secara langsung, memintas SDN. Ini penting untuk mesin maya yang dipindahkan ke OpenShift daripada Red Hat Virtualization atau VMware vSphere, kerana jika anda mempunyai akses kepada lapisan OSI kedua, tidak akan ada perubahan dalam tetapan rangkaian. Ini juga bermakna VM mungkin mempunyai alamat rangkaian yang memintas SDN. Oleh itu, kami boleh menggunakan penyesuai rangkaian khusus dengan berkesan, atau menyambung terus ke sistem storan melalui rangkaian...
Anda boleh mengetahui lebih lanjut tentang cara mencipta dan menyambungkan mesin maya virtualisasi OpenShift ke rangkaian . Di samping itu, , digunakan sebagai sebahagian daripada virtualisasi OpenShift, menawarkan satu lagi cara biasa untuk mencipta dan mengurus konfigurasi rangkaian pada nod fizikal yang digunakan di bawah hipervisor.
Penyimpanan
Menyambung dan mengurus cakera mesin maya dalam virtualisasi OpenShift dilakukan menggunakan konsep Kubernetes seperti StorageClasses, PersistentVolumeClaims (PVC) dan PersistentVolume (PV), serta piawaian protokol storan untuk persekitaran Kubernetes. Ini memberikan pentadbir Kubernetes dan pasukan aplikasi cara biasa dan biasa untuk mengurus kedua-dua bekas dan mesin maya. Dan bagi kebanyakan pentadbir persekitaran virtualisasi, konsep ini mungkin terdengar biasa kerana ia menggunakan prinsip yang sama untuk memisahkan fail konfigurasi VM dan cakera yang digunakan dalam OpenStack dan banyak platform awan lain.
Walau bagaimanapun, kita tidak boleh hanya mencipta cakera baharu untuk VM setiap kali, kerana apabila berhijrah daripada hipervisor ke OpenShift, kita perlu menyimpan data. Ya, walaupun apabila kami menggunakan VM baharu, ia sentiasa lebih pantas untuk melakukannya daripada templat daripada menciptanya dari awal. Oleh itu, kami memerlukan kefungsian untuk mengimport cakera sedia ada.
Untuk memudahkan tugas ini, virtualisasi OpenShift menggunakan projek Pengimport Data Kontainer (CDI), yang mengurangkan pengimportan imej cakera cakera daripada pelbagai sumber kepada mencipta entri 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
Entri inilah yang mengaktifkan CDI, mencetuskan urutan tindakan yang ditunjukkan dalam rajah di bawah:
Selepas CDI selesai, PVC akan mengandungi cakera mesin maya yang sedia untuk digunakan dan ditukar kepada format OpenShift standard...
Apabila bekerja dengan virtualisasi OpenShift, OpenShift Container Storage (OCS), penyelesaian Red Hat berdasarkan sistem fail Ceph yang melaksanakan fungsi storan berterusan untuk bekas, juga berguna. Sebagai tambahan kepada kaedah capaian PVC standard - RWO (blok) dan RWX (fail) - OCS menyediakan RWX untuk peranti blok mentah, yang sangat berguna untuk berkongsi akses blok untuk aplikasi dengan keperluan prestasi tinggi. Selain itu, OCS menyokong standard Tuntutan Baldi Objek baharu, yang membenarkan aplikasi menggunakan storan data objek secara langsung.
Mesin maya dalam bekas
Jika anda berminat untuk menyemak cara ia berfungsi, maka ketahui bahawa virtualisasi OpenShift sudah tersedia dalam versi Pratonton Teknologi sebagai sebahagian daripada OpenShift 3.11 dan lebih tinggi. Pemilik langganan OpenShift sedia ada boleh menggunakan virtualisasi OpenShift sepenuhnya secara percuma dan tanpa sebarang langkah tambahan. Pada masa penerbitan siaran ini, OpenShift 4.4 dan OpenShift virtualisasi 2.3 adalah terkini; jika anda menggunakan versi sebelumnya, maka anda harus meningkatkan untuk mendapatkan ciri terkini. Versi virtualisasi OpenShift yang disokong sepenuhnya harus dikeluarkan pada separuh kedua 2020.
Untuk maklumat lanjut, sila rujuk untuk arahan pemasangan, termasuk , yang menyediakan maklumat tentang menyediakan rangkaian luaran.
Sumber: www.habr.com