Virtualisasi OpenShift (proyek hulu - Kubernetes: KubeVirt, lihat. и ), nee Virtualisasi Asli Kontainer, diperkenalkan sebagai fungsionalitas platform OpenShift, yang dirancang untuk menerapkan dan mengelola mesin virtual (VM) sebagai entitas dasar Kubernetes. Tugas semacam ini secara teknis menantang karena perbedaan mendasar dalam teknologi. Untuk mencapai tujuan ini, kami menggunakan teknologi familiar berbasis Red Hat Enterprise Linux dan KVM, yang telah bersama kami selama bertahun-tahun dan telah terbukti keefektifannya.
Pada artikel ini, kita akan melihat aspek teknis virtualisasi OpenShift yang memungkinkan VM dan container hidup berdampingan dalam satu platform yang mengelolanya sebagai satu kesatuan.
Tugas komputasi
Kontainer menggunakan mekanisme kernel Linux seperti namespace dan cgroup untuk mengisolasi proses dan mengelola sumber daya. Biasanya proses dipahami sebagai Python, aplikasi Java, atau file yang dapat dieksekusi, tetapi sebenarnya proses tersebut dapat berupa proses apa saja, seperti bash, Emacs, atau vim.
Apa itu mesin virtual? Dari sudut pandang hypervisor, ini juga merupakan sebuah proses. Namun bukan proses aplikasinya, melainkan proses KVM yang bertanggung jawab untuk mengeksekusi VM tertentu.
Gambar kontainer berisi semua alat, perpustakaan, dan file yang diperlukan untuk mesin virtual KVM. Jika kita memeriksa pod dari VM yang sedang berjalan, kita akan melihat helper dan proses qemu-kvm di sana. Selain itu, kami memiliki akses ke alat KVM untuk mengelola mesin virtual seperti qemu-img, qemu-nbd, dan virsh.
Karena mesin virtual adalah sebuah pod, maka secara otomatis mewarisi semua fungsi dari sebuah pod di Kubernetes. Pod VM, sama seperti pod biasa, tunduk pada skema dan kriteria penjadwal seperti taint, toleransi, afinitas, dan anti-afinitas. Anda juga mendapatkan manfaat dari ketersediaan tinggi, dll. Namun, ada satu perbedaan penting: pod biasa tidak bermigrasi dari host ke host seperti biasanya. Jika sebuah node menjadi offline, pod di dalamnya akan dihentikan dan ditugaskan kembali ke node lain di cluster. Dan dalam kasus mesin virtual, kami berharap dapat melihat migrasi langsung.
Untuk mengatasi kesenjangan ini, definisi sumber daya khusus (CDR) dibuat untuk menjelaskan mekanisme migrasi langsung yang bertanggung jawab untuk menginisialisasi, memantau, dan mengelola migrasi langsung VM antar node pekerja.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Ketika sebuah node dinonaktifkan, tugas migrasi secara otomatis dibuat untuk mesin virtual yang telah menetapkan Migrasi Langsung sebagai strategi penggusurannya. Dengan cara ini Anda dapat mengontrol perilaku mesin virtual saat berpindah antar node cluster. Anda dapat mengonfigurasi Migrasi Langsung dan mengelola VM, seperti semua pod lainnya.
Сеть
Setiap sistem Kubernetes menyediakan komunikasi antara node dan pod menggunakan jaringan SDN perangkat lunak. OpenShift tidak terkecuali dan, mulai dari versi 3, menggunakan OpenShiftSDN secara default untuk ini. Selain itu, OpenShift 4 memiliki fitur baru lainnya yang disebut Multus, yang memungkinkan Anda menyediakan beberapa jaringan dan menghubungkan pod ke jaringan tersebut secara bersamaan.
Dengan menggunakan Multus, administrator dapat menentukan jaringan CNI tambahan, yang kemudian akan disebarkan dan dikonfigurasi pada cluster oleh Operator Jaringan Cluster khusus. Pod tersebut kemudian dihubungkan ke satu atau lebih jaringan ini, biasanya OpenShiftSDN standar dan antarmuka tambahan. Perangkat SR-IOV, Linux Bridge standar, perangkat MACVLAN, dan IPVLAN semuanya dapat digunakan jika VM Anda memerlukannya. Gambar di bawah menunjukkan cara mengatur Multus CNI untuk jaringan jembatan pada antarmuka 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
Sehubungan dengan virtualisasi OpenShift, ini berarti bahwa VM dapat dihubungkan ke jaringan eksternal secara langsung, melewati SDN. Hal ini penting untuk mesin virtual yang bermigrasi ke OpenShift dari Red Hat Virtualization atau VMware vSphere, karena jika Anda memiliki akses ke lapisan OSI kedua, tidak akan ada perubahan dalam pengaturan jaringan. Ini juga berarti bahwa VM mungkin memiliki alamat jaringan yang melewati SDN. Dengan demikian, kita dapat secara efektif menggunakan adaptor jaringan khusus, atau terhubung langsung ke sistem penyimpanan melalui jaringan...
Anda dapat mempelajari lebih lanjut tentang cara membuat dan menghubungkan mesin virtual virtualisasi OpenShift ke jaringan ... Selain, , yang diterapkan sebagai bagian dari virtualisasi OpenShift, menawarkan cara lain yang sudah dikenal untuk membuat dan mengelola konfigurasi jaringan pada node fisik yang digunakan di bawah hypervisor.
Penyimpanan
Menghubungkan dan mengelola disk mesin virtual dalam virtualisasi OpenShift dilakukan menggunakan konsep Kubernetes seperti StorageClasses, PersistentVolumeClaims (PVC) dan PersistentVolume (PV), serta standar protokol penyimpanan untuk lingkungan Kubernetes. Hal ini memberikan administrator Kubernetes dan tim aplikasi cara yang umum dan familier untuk mengelola container dan mesin virtual. Dan bagi banyak administrator lingkungan virtualisasi, konsep ini mungkin terdengar familiar karena menggunakan prinsip yang sama dalam memisahkan file konfigurasi VM dan disk yang digunakan di OpenStack dan banyak platform cloud lainnya.
Namun, kita tidak bisa begitu saja membuat disk baru untuk VM setiap saat, karena saat bermigrasi dari hypervisor ke OpenShift, kita perlu menyimpan data. Ya, meskipun kami menerapkan VM baru, melakukannya dari template selalu lebih cepat daripada membuatnya dari awal. Oleh karena itu, kita memerlukan fungsionalitas untuk mengimpor disk yang ada.
Untuk menyederhanakan tugas ini, virtualisasi OpenShift menerapkan proyek Pengimpor Data Terkontainer (CDI), yang mengurangi impor gambar disk dari berbagai sumber menjadi pembuatan 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, memicu rangkaian tindakan yang ditunjukkan pada gambar di bawah:
Setelah CDI selesai, PVC akan berisi disk mesin virtual yang siap digunakan dan dikonversi ke format OpenShift standar...
Saat bekerja dengan virtualisasi OpenShift, OpenShift Container Storage (OCS), solusi Red Hat berdasarkan sistem file Ceph yang mengimplementasikan fungsionalitas penyimpanan persisten untuk container, juga berguna. Selain metode akses PVC standar - RWO (blok) dan RWX (file) - OCS menyediakan RWX untuk perangkat blok mentah, yang sangat berguna untuk berbagi akses blok untuk aplikasi dengan persyaratan kinerja tinggi. Selain itu, OCS mendukung standar Object Bucket Claim yang baru, yang memungkinkan aplikasi untuk langsung menggunakan penyimpanan data objek.
Mesin virtual dalam kontainer
Jika Anda tertarik untuk memeriksa cara kerjanya, ketahuilah bahwa virtualisasi OpenShift sudah tersedia dalam versi Pratinjau Teknologi sebagai bagian dari OpenShift 3.11 dan lebih tinggi. Pemilik langganan OpenShift yang sudah ada dapat menggunakan virtualisasi OpenShift secara gratis dan tanpa langkah tambahan apa pun. Pada saat posting ini, virtualisasi OpenShift 4.4 dan OpenShift 2.3 masih berlaku; jika Anda menggunakan versi sebelumnya, Anda harus memutakhirkan untuk mendapatkan fitur terbaru. Versi virtualisasi OpenShift yang didukung penuh akan dirilis pada paruh kedua tahun 2020.
Untuk informasi lebih lanjut, silakan merujuk ke untuk petunjuk pemasangan, termasuk , yang memberikan informasi tentang pengaturan jaringan eksternal.
Sumber: www.habr.com