Before digging deeper into Virtual Kubelet, it will be better to start by explaining the role played by the Kubelet in Kubernetes. From a theoretical point of view, Kubernetes serves as a loop of constant reconciliation. The desired state gets submitted to the API server, and from there, Kubelet and controllers plus other components inside the system progressively work towards achieving the proposed desired state. Kubernetes contains various parts inside its control plane, and each of these components serves particular purposes. Kubelet is like an agent that runs on every node in managing a pod lifecycle. After the Kubelet starts, it adds itself – through the Kubernetes API Server – as a node. A node name property is assigned to the node; the Kubelet keeps track of the Kubernetes API server for any change that could occur to pods with a similar node name. It continues to reconcile the differences through the creation of new pods as scheduled and deleting the no longer existing pods, and also updating the associated resources. The Kubelet also updates API Server with the most recent pod statuses and configures the networking of pod.
On the other hand, Virtual Kubelet that appears to be a Kubelet from the perspective of its interaction with the Kubernetes API. It is an app that operates inside a container in your latest cluster and appears as a node. It can masquerade itself as a node as it uses the Kubernetes API to create a node. Virtual Kubelet then monitors schedules pods just as the actual Kubelet does. At this point, things start to be different. Instead of interacting with a host and its runtime container, Virtual Kubelet has providers; these are modular, embedded backend. Anytime there appears a pod lifecycle; the core Virtual Kubelet logic calls a provider. It notifies the provider its need to handle an update, creation, or deletion of a pod. Virtual Kubelet injects Secrets and Configmaps and implements a reconciliation loop in case something needs to be updated, created, or deleted in the most seamless possible way.
Virtual Kubelet can be used for different purposes, but the following are the main ones. It can be used in batch jobs instead of having enough VMs running in your cluster. It can also replace VMs or additional hardware that sit idle when your CI/CD pipeline has no tasks. It can also be used in serverless, allowing you to leverage the technologies you are already using. It can also be applied in bursting so that when you run out of capacity in your cluster, the scheduler starts placing additional pods in the provider.
The Virtual Kubelet team reckons that the technology is ready for workloads production. The team is confident of making vast improvements to Virtual Kubelet’s performance, revamping the mechanisms of reconciliation of nodes and pods. These improvements mean that Virtual Kubelet can burst faster to providers and provide instantaneous results. It has freed its users from the tedium of operating systems management.