Kubernetes is great. It gives you, among other things, security, high availability, and easy deployment of microservices. And above all, it is fun to work with.

But there are so many ways to deploy a Kubernetes cluster… should I use managed Kubernetes in the cloud? Or provision a custom Kubernetes cluster with Ansible and kubeadm? What about abstractions like k3s or kind?

Although Kubernetes solves a lot of problems in mid- to large-scale projects, it is sometimes hard to get around. In this article, I will discuss Kubernetes provisioning with kubeadm, when you need it, and when you want to use managed Kubernetes instead.

Using Kubeadm for Learning Kubernetes the Hard Way

Let’s look at the cloud-native way first, before we move to managed Kubernetes. Kubeadm is the “official” cloud-native way of provisioning a Kubernetes cluster. It is also the best way to understand what happens under the hood in Kubernetes.

The reason is that provisioning Kubernetes with kubeadm and more than one node is not easy, and for a good reason. You have to manage cluster networking and automation on a large scale. You also need to configure a load balancer in front of your control planes. All this is given to you for free in managed Kubernetes, but with kubeadm, you need to learn and configure all those things yourself.

Of course, you usually learn how to do basic troubleshooting first, but after that, one of the key things to understand is provisioning. The first time it clicked for me on how Kubernetes works was when I set up a Kubernetes cluster with three control planes and an HAProxy load balancer.

Why is this so important? What edge does it give you to know how to use kubeadm?

Simple. When you are provisioning Kubernetes with AWS or GCP, you need to know what happens under the hood. If you don’t, you are going to have problems when something in your cluster breaks. I will elaborate by using an analogy.

Imagine you’re a car mechanic who understands almost every part of a car—except the turbocharger. A customer brings in a car with a strange noise coming from the engine bay, somewhere near the turbo.

The turbocharger is brand new, and all the initial signs suggest that the problem is somewhere else. But because you don’t fully understand how the turbo works, you can’t confidently rule it out. You keep coming back to the same question: What if it is the turbo?

Instead of systematically narrowing down the real problem, you waste time second-guessing yourself.

Kubernetes is no different. If you’ve only ever worked with managed clusters, parts of the control plane remain a black box. When something goes wrong, you might know that AWS or GCP manages that layer—but without understanding what happens underneath, you can’t always rule it out with confidence.

Building a cluster with kubeadm removes that uncertainty. You have seen the components, configured them, broken them, and fixed them yourself. You know where the boundaries are—and that makes troubleshooting managed Kubernetes much more systematic.

Kubernetes in Production

Given all that we discussed so far, I still have a negative opinion about kubeadm in production. The main reasons are scalability and speed. Since the cloud providers manage the automated provisioning for you, there is not much that you have to do except run a command in the CLI.

Another reason is that the cloud providers are horizontally idempotent. This is especially great for the IT industry because people sometimes do go on holiday. Now the thing with provisioning a Kubernetes cluster the cloud-native way is that there are endless possibilities for how to do it. If the engineer who provisioned the on-premises cluster goes on holiday or sick leave, then the whole team has a problem.

In the cloud, however, this is no problem at all. GKE, AKS and EKS all function the same way, so even if the project is different, you still know what you have to do. This is what I mean by having horizontal idempotence. The Kubernetes environments are similar across projects, which simplifies the onboarding process for new team members.

Last but not least, Kubernetes is perfect for running in the cloud. Actually, Kubernetes is the first thing you should run in the cloud if you decide to use the cloud. Kubernetes provides an infrastructure that can scale up and down with great efficiency. The workload running in Kubernetes is elastic by design, which is the perfect use case for the cloud.