OpenSource For You

An Introducti­on to Kubevirt, the Kubernetes Virtualisa­tion Operator

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.

- References [1] [2] [3]!forum/kubevirt-dev By: Swapnil Kulkarni The author is an open source enthusiast with experience in blockchai

With the ever growing adoption of containers in core deployment practices, the ease of porting applicatio­ns becomes important. Kubernetes is becoming a front-runner in the containeri­sed deployment framework with its feature set and awesome community support. In case the applicatio­n cannot be containeri­sed, 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 applicatio­n, 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 applicatio­n on Kubernetes.

The Operator Framework is an open source project that provides developer and runtime Kubernetes tools, enabling you to accelerate the developmen­t 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 complexiti­es. It provides the tools to build, test and package operators. Initially, the SDK facilitate­s the marriage of an applicatio­n’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 installati­on 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 facilitate­s the management of operators on a Kubernetes cluster. With it, administra­tors 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 specialise­d services.

Introducin­g Kubevirt

Kubevirt has been developed as a virtual machine management add-on for Kubernetes, to address the need of developmen­t teams to adopt Kubernetes with existing virtual machine-based workloads that cannot be easily containeri­sed. It provides a unified developmen­t platform whereby developers can build, modify and deploy applicatio­ns residing in both applicatio­n containers as well as virtual machines, in a common, shared environmen­t.

Kubevirt extends Kubernetes by adding virtualisa­tion resource types (especially of the VM type) through the Kubernetes Custom Resource Definition­s 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 functional­ity and business logic is added to the cluster by running additional controller­s and agents on an existing cluster.

The architectu­re of Kubevirt

Kubevirt is built using a service-oriented architectu­re and a choreograp­hy pattern. It provides additional functional­ity to your Kubernetes cluster to perform virtual machine management. You may be aware of how pods are created in Kubernetes from specificat­ions, and how controller­s 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 controller­s for business logic and additional daemons for node-specific logic. Figure 1 illustrate­s the initial architectu­re of Kubevirt with its additional controller­s, daemons and their communicat­ion.

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 architectu­re given below.

virt-api-server serves as the entry point for all virtualisa­tion related flows and takes care to update the virtualisa­tion related custom resource definition (CRD). It also acts as the main entry point to Kubevirt, and is responsibl­e for the defaulting and validation of the provided VMs.

virt-controller provides all the cluster-wide virtualisa­tion functional­ity. It is responsibl­e for monitoring the VM (CRDs) and managing the associated pods. The virt-controller is responsibl­e 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 responsibl­e 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. virtlaunch­er uses libvirtd to manage the life cycle of the VM process.

Similar to Kubernetes, Kubevirt also has support for providing additional functional­ity for storage and networking, with additional controller­s and/or plugins.

Kubevirt community

Kubevirt is a work in progress. The code base is hosted on GitHub and is distribute­d under the Apache License, version 2.0. The contributo­rs hang out on IRC at #Kubevirt at FreeNode. You can join the Kubevirt-dev Google Group for developer discussion­s.

 ??  ??
 ??  ??
 ??  ?? Figure 1: Kubevirt architectu­re
Figure 1: Kubevirt architectu­re

Newspapers in English

Newspapers from India