Kubernetes (shortened to k8s) is currently the hottest thing in the DevOps, yet there is a lot of confusion and misunderstanding of the value that it provides.

To someone new to k8s, especially if you are a developer, not a DevOps or infrastructure type, you will probably find that it seems to be needlessly complicated. Rather than just saying “here is my container, deploy it”, you have to actually create a Deployment or a StatefulSet. Then in order to access it, you will need to create a Service which will allow for other pods to talk to it. But then if you want it to be accessible outside of the k8s cluster, you will need to either expose a NodePort or setup an Ingress.

If you want to use persistent storage, you’ll need to either manually setup Persistent Volumes or setup a Storage Class to provision them dynamically. Your pod will need a Persistent Volume Claim to connect it to persistent storage.

If you want environment variables you can either set those in the Deployment/StatefulSet configuration or in a ConfigMap.

That’s quite a lot to have to remember for a developer who just wants to deploy their application.

Why this is actually great

Kubernetes is absolutely complicated, but it acts as a common platform which can run anywhere. And those resource definition files you create to deploy your application can then be run on any Kubernetes cluster anywhere and it should function the same. Due to the architecture of k8s, it is essentially a really good configuration management tool. Everything you do in k8s can be done as code, and in fact, any manual steps you do get translated into resources which can then be exported as code.

Having a common platform where you can run your applications is amazing for portability. Rather than worrying if I am running on GCP, AWS, Azure, Digital Ocean, or wherever, as long as you can run Kubernetes, you can easily deploy your entire application stack. Just run a simple kubectl apply -f resource_definition.yml on your yaml files and everything begins to spin up.

Kubernetes should be the underlying layer of your operation

If your team has enough expertise to deploy applications directly to Kubernetes, that is awesome. But lots of teams don’t have that level of confidence, but this isn’t a problem. There are all sorts of applications and services being built using Kubernetes as the underlying layer of their deployment strategy. But they give you much easier ways to interface with k8s without having to use kubectl.

Tools like Jenkins-XEclipse CheKNativeDraft, and countless others help you work on Kubernetes without having to understand it all.

There is much more to cover about why Kubernetes is so great in comparison to traditional infrastructure practices, but I will save that for another day.

Write A Comment