Introduction
For the past several years now, the IT industry has undergone a major shift towards cloud native applications. The Cloud Native movement has revolutionized IT infrastructure as we see it, with complete isolation of the different bricks that make up an App to improve software development methodologies, resiliency in a way that is tailored to run as cloud services. Kubernetes was one of the important vehicles of this transition with many companies adopting it to offer opinionated implementation of it. VMware is one of them with the Tanzu portfolio and Tanzu Community Edition, a completely free and open-source option to run Kubernetes workloads on VMware resources.
We already talked a little bit about Tanzu Community Edition in the blog with Unmanaged clusters. In this article, we are going to have a look at how exactly Tanzu Community Edition is able to create workload clusters on various infrastructure providers.
Deploying clusters with Tanzu Community Edition
VMware Tanzu Community Edition offers a comprehensive suite with a package manager, observability, authentication and much more. However, a chunk of the value-add from VMware TCE lies in how easy it is to deploy Kubernetes clusters to multiple infrastructure providers. I say infrastructure provider and not cloud provider because you can even deploy clusters to your local Docker environment which is great for testing.
As you can see, using the Tanzu command line utility, you can deploy Kubernetes clusters to Docker, VMware vSphere, Amazon Web Services (AWS) and Microsoft Azure.
Now you might be intrigued at what happens in the background to make all this possible, this is where the amazing cluster API open-source project comes into play.
What is Cluster API
The Cluster API project provides the necessary tools to provision, upgrade and operate multiple Kubernetes clusters with ease.Instead of manually provisioning VMs, load balancers and such, bootstrapping kubernetes etc, you will simply create the objects in a Kubernetes cluster running cluster API with the right provider and the controllers will take care of the rest for you. This offers easy, repeatable and fast cluster deployments capabilities across a wide variety of infrastructure providers.
Custom Resources and Custom Resources Definitions
If you know the basics of Kubernetes, you will know that a number of resources exist in the API – out of the box, think pods, deployments, services, ingress, daemonsets, clusterroles, you name it, essentially anything that is displayed by the “kubectl api-resources” command. On top of these, it is possible to “extend” the API in a way, by defining “Custom Resources” (CR) with “Custom Resource Definitions” (CRD).
A good example of a CRD is the structure or schema of a pizza, it must have a base which can be either tomato or cream, then it can have toppings like cheese, ham, mushrooms… The CR will be the actual pizza where you create the object with the specific properties of your pizza.
Controllers
When resources are created in Kubernetes, there needs to be something that makes sure what is really configured in the infrastructure matches the kubernetes resources. This duty is handled by controllers. Controllers know how to communicate with an infrastructure endpoint via its API and make sure, what’s out there matches your kubernetes resources.
To get back to the Pizza example, somebody actually wrote an operator called “cruster-API” (love it) to order pizzas by creating Kubernetes resources. The controller watches your kubernetes pizza custom resources and will interact with the public API of Domino’s pizza to place an order when a new pizza CR is detected. While this example is funny, it is actually a great way to get to grasp the concepts of Cluster-API.
In Cluster API, there will be a controller for your cloud provider, meaning the particular logic in it will know how to interact with the API of vCenter Server for instance so it can order the creation of VMs.
Cluster API providers
The cluster API project offers a platform onto which you can plug providers to interact with the various cloud providers. For instance, in the case of Tanzu Community Edition, the following providers are used:
- CAPD: Cluster API Provider Docker
- CAPV: Cluster API Provider vSphere
- CAPA: Cluster API Provider AWS
- CAPZ: Cluster API Provider Azure
A lot more cluster API providers are out there but it takes a lot of work to add support for a provider and the TCE team isn’t that big in the end. You can find the complete list of all the providers in the cluster API website
Management and Workload clusters
You may have come across those terms when reading about VMware Tanzu already. The definition is simpler than it appears.
Management cluster
The cluster that runs the cluster API resources and interacts with the infrastructure. It is usually managed and used only by the admin teams. However, developer teams can also get limited access to it to deploy new kubernetes clusters in their own namespace for instance.
Workload clusters
The workload clusters are the clusters that are created from the management cluster. This is typically where you will run your applications or, yes you guessed it, workloads.
Bootstrap cluster
Let’s also throw bootstrap clusters while we’re here. The bootstrap cluster is a temporary cluster you usually create locally on your machine for instance. You then install CAPI in this cluster, deploy a workload cluster in your vSphere infrastructure, turn it into a management cluster by moving the resources to it and then you can delete the bootstrap cluster.
Cluster API in action
Once a TCE or vanilla Kubernetes cluster with CAPV initialized is running, let’s have a look at the resources in it. Note that I use a Vanilla Kind cluster that I initialized with CAPV here, but the same concepts apply to TCE managed clusters.
vSphere custom resource definitions (CRDs)
Those custom resources describe the objects to create in the infrastructure. Not that the Cluster API CRDs are not shown below, only the CAPV ones.
CAPI and CAPV controllers
These are the controllers that will be looking at the Custom Resources you create to make them happen on the infrastructure.
Creating a Kubernetes cluster in vSphere
You can see all the objects that are created to create a cluster.
vSphere virtual machines resources
As you can see, the machine objects created in the management cluster generate the creation of virtual machines to build the nodes that will make up the cluster.
Conclusion
Tanzu Community Edition is a powerful and relevant project as it significantly simplifies the experience of provisioning clusters. However, it is always interesting to look at what happens behind the scenes to get a better idea of how it works and why it might sometimes fail.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
