Kubevirt is a Kubernetes add-on that enables the management of libvirt virtual machines. It is a tool that is used to schedule and manage virtual machines on a Kubernetes cluster.
With the ever growing adoption of containers in core deployment practices, the ease of porting applications becomes important. Kubernetes is becoming a front-runner in the containerised deployment framework with its feature set and awesome community support. In case the application cannot be containerised, we still should be able to use common frameworks to manage different workloads. An operator is a method of packaging, deploying and managing a Kubernetes application, which is anything that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling. You can think of an operator as the runtime that manages this type of application on Kubernetes.
The Operator Framework is an open source project that provides developer and runtime Kubernetes tools, enabling you to accelerate the development of an operator. This framework includes the following:
The Operator SDK: This is to build operators based on their expertise, without requiring any knowledge of Kubernetes API complexities. It provides the tools to build, test and package operators. Initially, the SDK facilitates the marriage of an application’s business logic, e.g., how to scale, upgrade, or back up with the Kubernetes API to execute those operations.
The Operator Lifecycle Manager: This oversees installation and updates as well as manages the life cycle of all the operators (and their associated services) running across a Kubernetes cluster. The Operator Lifecycle Manager is the backplane that facilitates the management of operators on a Kubernetes cluster. With it, administrators can control what operators are available in particular namespaces and who can interact with the running operators.
Operator metering: This enables usage reporting for operators that provide specialised services.
Introducing Kubevirt
Kubevirt has been developed as a virtual machine management add-on for Kubernetes, to address the need of development teams to adopt Kubernetes with existing virtual machine-based workloads that cannot be easily containerised. It provides a unified development platform whereby developers can build, modify and deploy applications residing in both application containers as well as virtual machines, in a common, shared environment.
Kubevirt extends Kubernetes by adding virtualisation resource types (especially of the VM type) through the Kubernetes Custom Resource Definitions API. It provides the ability to manage additional resources alongside the resources provided by Kubernetes, by default. But the resources themselves are not enough to launch virtual machines; so, instead, the functionality and business logic is added to the cluster by running additional controllers and agents on an existing cluster.
The architecture of Kubevirt
Kubevirt is built using a service-oriented architecture and a choreography pattern. It provides additional functionality to your Kubernetes cluster to perform virtual machine management. You may be aware of how pods are created in Kubernetes from specifications, and how controllers perform the necessary actions to make the pod alive to match the required state. Kubevirt uses similar mechanisms with additional types added to the Kubernetes API, additional controllers for business logic and additional daemons for node-specific logic. Figure 1 illustrates the initial architecture of Kubevirt with its additional controllers, daemons and their communication.
Kubevirt is deployed on top of a Kubernetes cluster, which allows users to run Kubernetes-native workloads next to the VMs managed through Kubevirt.
Components of Kubevirt
Kubevirt consists of a set of services as described in the architecture given below.
virt-api-server serves as the entry point for all virtualisation related flows and takes care to update the virtualisation related custom resource definition (CRD). It also acts as the main entry point to Kubevirt, and is responsible for the defaulting and validation of the provided VMs.
virt-controller provides all the cluster-wide virtualisation functionality. It is responsible for monitoring the VM (CRDs) and managing the associated pods. The virt-controller is responsible for creating and managing the life cycle of the pods associated to the VM objects.
virt-handler is a Kubernetes DaemonSet needed on every host in the cluster. It performs functions similar to those of Kubelet, where it is reactive and watching out for changes in the VM object. Once changes are detected, it will perform all the necessary operations to change a VM to meet the required state.
virt-launcher is responsible for providing the cgroups and namespaces, which will be used to host the VM process. virt-handler signals virt-launcher to start a VM by passing the VM’s CRD object to virt-launcher.
libvirtd instance is present in every VM Pod. virt-launcher uses libvirtd to manage the life cycle of the VM process.
Similar to Kubernetes, Kubevirt also has support for providing additional functionality for storage and networking, with additional controllers and/or plugins.
Kubevirt community
Kubevirt is a work in progress. The code base is hosted on GitHub and is distributed under the Apache License, version 2.0. The contributors hang out on IRC at #Kubevirt at FreeNode. You can join the Kubevirt-dev Google Group for developer discussions.
