WHY VIRTUAL KUBELET?
Kubernetes, otherwise referred to as K8s, is a container orchestrator and also first-graduated project under CNCF. The most alluring fact about the K8s is the community support and the fact that it is open source. Due to this fact, people could use it wherever they wanted (either on Cloud or On-Premise).
But the hosted Kubernetes – i.e., Kubernetes on Cloud – is gaining a lot of momentum. This is because it offers a lot of integrations and features. The most important feature that gets people into Kubernetes on Cloud is its ability to scale.
Although it is a fact that Kubernetes is an open-source project and it can be used either on Cloud or On-Prem, there’s always the fear of running out of resources in an On-Prem environment. Although On-Prem gives greater control, many people consider moving to or starting with Kubernetes on Cloud ( GKE, EKS, AKS, etc.,). But, there are a few containers that you just want to run and you don’t want to bother with a new interface, or don’t care where it runs.
To understand how Virtual Kubelet does this, we’ll look at Kubernetes Architecture a bit to see where Virtual Kubelet fits in.
Kubernetes is a distributed system and like most distributed systems has a Master and Worker nodes. Kubernetes uses Kubelet, located on each worker node, to talk to other worker nodes.
Kubelet is an agent that runs on each node in the cluster. It makes sure that containers are running in a pod.
The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy.
Virtual Kubelet is an implementation of the Kubernetes kubelet that masquerades as a kubelet for the purpose of connecting a Kubernetes cluster to other APIs. This allows Kubernetes Nodes to be backed by serverless container platforms (AWS Fargate, Alibaba Cloud Elastic Container Instances, Azure Container Instances etc.).
Currently, Virtual Kubelet supports a variety of providers: Alibaba’s ECI, AWS Fargate, Azure Batch, Azure’s ACI, Kubernetes CRI, Huawei’s CCI, HashiCorp’s Nomad and OpenStack Zun. There’s a proposal for a GCP Cloud Run provider, as well.
Besides these existing providers, you can also write and add your own provider.
ARCHITECTURE WITH VIRTUAL KUBELET:
As you see, Virtual Kubelet registers itself as a kubelet with the Kubernetes APi server. But it actually talks to APIs from a serverless container provider, and runs the containers there and not in the cluster (but the containers show up as if they’re in the cluster).
You could deploy Virtual Kubelet in 3 different ways.
- Outside a K8s Cluster (i.e., no cluster needed)
- Inside a K8s Cluster (with skaffold)
- With a Helm Chart (Inside a K8s Cluster)
It’s possible to use Virtual Kubelet with Minikube or Docker for Desktop Kubernetes Cluster.
A few of the instances where Virtual Kubelet could be useful.
- Container Runtime: When you want to use a different container runtime that is readily available with a Virtual Kubelet Provider in a Cloud Provider.
- Performance issues: for faster performance or GPU
- Closer to your Client: When you need your container closer to your customer in a different geographical region.
- Scalability issues: In case of containers when where you run them doesn’t matter, and your Kubernetes Cluster is reaching its limits.
There are a lot of demos written by various people from various companies, available in the README files of the providers of Virtual Kubelet.