OpenShift virtualization (upstream project - Kubernetes: KubeVirt, see below) ΠΈ ), nee Container-native Virtualization, was introduced as a functionality of the OpenShift platform, which is designed to deploy and manage virtual machines (VMs) as the basic Kubernetes entities. This kind of task is technically challenging due to fundamental differences in technology. In order to achieve this goal, familiar technologies based on Red Hat Enterprise Linux and KVM were used, which have been with us for more than one year and have proven their effectiveness.
In this article, we will look at the technical aspects of OpenShift virtualization, which make it possible for VMs and containers to coexist within the same platform that manages them as a single entity.
Computational tasks
Containers use Linux kernel mechanisms such as namespaces and cgroups to isolate processes and manage resources. Usually, processes are understood as Python, Java applications or executable files, but in fact they can be any processes, the same bash, Emacs or vim.
What is a virtual machine? From the point of view of the hypervisor, this is also a process. But not the application process, but the KVM process responsible for executing a specific VM.
The container image contains all the tools, libraries and files needed for the KVM virtual machine. If we inspect the pod of a running VM, we will see qemu-kvm helpers and processes there. In addition, we have access to KVM tools for managing virtual machines such as qemu-img, qemu-nbd and virsh.
Since the virtual machine is a pod, it automatically inherits all the functionality of a pod in Kubernetes. Just like normal pods, VM pods are subject to scheduling schemes and criteria like taints, tolerations, affinity, and anti-affinity. You also benefit from high availability, etc. However, there is one important difference: normal pods do not migrate from host to host in the usual sense. If a node goes down, then the pod on it is terminated and reassigned to another node in the cluster. And in the case of a virtual machine, we expect to see a live migration.
To address this gap, a custom resource definition (CDR) was created that describes the live migration mechanism, which is responsible for initializing, monitoring and managing VM live migrations between worker nodes.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
When a node is deactivated, migration tasks are automatically created for those virtual machines that have Live Migration as their eviction strategy. Thus, you can control the behavior of virtual machines when moving between cluster nodes. You can either set up Live Migration or manage a VM just like any other Pod.
Network
Any Kubernetes system provides communication between nodes and pods using software SDN networks. OpenShift is no exception, and since version 3 it uses OpenShiftSDN by default for this. In addition, OpenShift 4 has another new feature called Multus, which allows you to make multiple networks available and connect pods to them at the same time.
Using Multus, the administrator can define additional CNI networks, which will then be deployed and configured on the cluster by a special Cluster Network Operator. The pods then connect to one or more of these networks, usually the standard OpenShiftSDN and an additional interface. SR-IOV devices, standard Linux Bridge devices, MACVLAN and IPVLAN devices can all be used if your VM needs it. The figure below shows how to set Multus CNI for the bridge network on the eth1 interface:
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
With regard to OpenShift virtualization, this means that the VM can be connected to an external network directly, bypassing SDN. This is important for virtual machines migrated to OpenShift from Red Hat Virtualization or VMware vSphere, as there will be no change in network settings if you have access to the second OSI layer. This also means that the VM may have a network address that bypasses the SDN. Thus, we can effectively use specialized network adapters, or connect directly to the storage system over the network ...
To learn more about how to create and connect OpenShift virtualization virtual machines to a network, see . In addition, , deployed as part of OpenShift virtualization, offers another familiar way to create and manage network configurations on physical hosts that run under hypervisors.
Storage
Connecting and managing virtual machine disks within OpenShift virtualization is performed using such Kubernetes concepts as StorageClasses, PersistentVolumeClaims (PVC) and PersistentVolume (PV), as well as standard storage protocols for the Kubernetes environment. Thus, Kubernetes administrators and application teams get a single and familiar management mechanism for both containers and virtual machines. And for many administrators of virtualization environments, this concept may sound familiar, since it uses the same principle of separating VM and disk configuration files that OpenStack and many other cloud platforms use.
However, we cannot simply create a new disk for the VM each time, since when migrating from the hypervisor to OpenShift, we need to save the data. Yes, even when we are deploying a new VM, it is always faster to do it from a template than to create from scratch. Thus, we need the functionality of importing existing disks.
To simplify this task, OpenShift virtualization deploys the Containerized Data Importer (CDI) project, which reduces importing disk images from multiple sources to creating a PVC entry.
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
It is this entry that activates CDI, launching the sequence of actions shown in the figure below:
After the CDI has completed, the PVC will contain the virtual machine disk ready for use and brought to the standard format for OpenShift ...
When working with OpenShift virtualization, OpenShift Container Storage (OCS), Red Hat's solution based on the Ceph file system that implements persistent storage functionality for containers, will also come in handy. In addition to the standard PVC access methods - RWO (block) and RWX (file) - OCS provides RWX for raw block devices, which is very useful when sharing block access for performance-intensive applications. In addition, OCS supports the new Object Bucket Claim standard, which allows applications to use object storage directly.
Containerized virtual machines
If you're interested in checking out how it works, then know that OpenShift virtualization is already available in the Tech Preview as part of OpenShift 3.11 and later. Owners of an active OpenShift subscription can use OpenShift virtualization completely free of charge and without any additional gestures. At the time of this post, OpenShift 4.4 and OpenShift virtualization 2.3 are up-to-date, if you are using previous versions, then you should upgrade to get the latest features. A fully supported version of OpenShift virtualization is due out in the second half of 2020.
For more information, refer to for installation instructions, including for information about setting up external networks.
Source: habr.com