TAGS: |

Why Kubernetes And Containerization?

Michael Levan

There’s a general consensus in today’s tech world:  “Use Kubernetes.”

But why?

Why jump into Kubernetes if you’re already running production-level workloads on virtual machines? Why change what your engineering team has been doing for ten years that works just fine? Why have engineers learn a new technology that may take time to implement?

In this post, I discuss the “why” behind using Kubernetes and how it helps environments succeed.

A Quick Example

Recently I was working with a client that’s building out a new set of services and essentially starting fresh in the one sector of the organization. A fresh build is great because you don’t have to worry about technical debt. It’s all new and you can start with the best practices.

The client had a bunch of Terraform code that was creating many different services in the cloud, along with some Bash scripts to hold it all together. The idea was that there was one binary/app that needed to run a job once. It needed to run one job for each user using the application.

The problem was it could only handle one job at a time. Because of that, if multiple users tried to use the application simultaneously, it would fail. The solution was a bash script workaround, which didn’t feel like a long-term solution.

Instead, I recommended that they run it in a container. The workflow would look something like this:

  • A user reaches out to the application
  • A pod gets created in Kubernetes
  • The pod runs
  • The pod is destroyed
  • A new pod comes up for a new user

Remember, pods/containers are meant to be ephemeral, so there was no need for a pod to stay up after the application ran. Not only did this approach save money by using different cloud services, but there was also no duct tape required to hold it all together. Containers orchestrated by Kubernetes made this possible.

Containers

Overall, containerized applications make deployments easier. Before containerization took off, your option for deployments was essentially to create a virtual machine, add the binary to the virtual machine, and run it. The problem was this approach required a few different teams, including Infrastructure and Dev. Also, this workflow took time because the virtual machine needed to be created and configured by the Infrastructure team and then handed off to Dev.

With containerization, that’s simply not the case. An application gets containerized and then deployed by (hopefully) an automated solution, such as GitOps, and the application runs as expected in production. Containers make “moving faster” a far more efficient experience in production.

One Platform For All Workloads

Kubernetes is, at a high level, a container scheduler. Kubernetes isn’t just a product or tool. It’s a platform. It’s an entire environment inside of one cluster.

To break it down at a high level, you have:

  • Networking
  • Infrastructure
  • Storage
  • Applications

All these elements run in a single environment. You don’t have to worry about physical hardware or running multiple pieces of infrastructure. Instead, every component that you need to run an environment is in one cluster, and it’s all virtualized. The networking, storage, and other pieces of infrastructure are all software-defined and managed via an API. If you need more clusters, that’s fine. You can create more and scale out the workloads from one Kubernetes cluster to another. How? With an API.

When you manage Kubernetes, you’re working directly with multiple different APIs.

There are APIs for storage, networking, pods, and everything else inside Kubernetes. This makes managing a platform and environment much easier for engineers because engineers don’t have to worry about multiple CLIs and multiple interfaces. It’s all one declarative API methodology, which makes automation, repeatability, and overall management far more efficient.

Scaling Production

At the end of the day, Kubernetes has one primary purpose – manage and scale containerized applications. Its job is to schedule containerized applications (pods) where they will run as efficiently as possible. Because of its one job, scaling is “built-in” because without scaling, Kubernetes wouldn’t have much of a purpose.

When it comes to scaling, at a high level, you can do it two ways:

  • Scale pods
  • Scale clusters

When it comes to scaling pods, it’s all automated. There’s something called ReplicaSets which you can set in a Kubernetes Manifest. The ReplicaSet can say “I want two pods” or “I want ten pods.” Then, those pods will be scheduled. You can also set minimum and maximum amounts of pods. That way, if your application is under heavy load, the pods will scale up so the application doesn’t crash. Then, when the application load reduces, the pods scale back down to save cluster resources.

With scaling clusters, you can add more worker nodes and more control planes (if you’re running Kubernetes on-prem). If, for example, you have two worker nodes and they’re both at 80% capacity, you can easily add a third worker node so new pods can be scheduled on the new worker node. This ensures the Kubernetes cluster doesn’t crash from not having enough resources (CPU, memory, etc.). In the cloud, you can even set up auto-scaling of nodes. A new worker node will be added automatically under heavy load and then removed when not needed. Auto-scaling can help save on costs by only using resources as needed.

Kubernetes more or less has built-in scaling for any environment, whether it’s one Kubernetes cluster or one thousand Kubernetes clusters. Note that if you have one application that you need to containerize and it has one binary, creating an entire scaled out Kubernetes cluster doesn’t make much sense. You’ll probably want to look at a service like Elastic Container Service (ECS) until you have more than one binary/container to deploy.

Fewer Headaches But More Responsibility

With Kubernetes there are fewer headaches, but there’s more to manage and learn.

What does this mean? Kubernetes, once it’s configured and set up, makes deploying containerized applications far easier. When you compare it to having to run a bunch of virtual machines for each application, it’s way more efficient from an engineering and cost perspective. If time is money, engineers are saving a lot of money deploying a containerized workload in comparison to deploying a binary on a virtual machine.

However, with great technology comes great responsibility. There’s a lot that goes into managing Kubernetes. It’s not just a click of a button in the cloud. There’s RBAC, security, deployment techniques, and overall management of the cluster itself. Plus, you still have to containerize the application to actually get it deployed.

If you’ve never used Kubernetes before, expect at least one to two months of studying and testing environments, and another two or three months more of learning and preparing before you move to production. Even then, you can expect to be continuously learning about new developments in the Kubernetes ecosystem.

This is not to steer you away from Kubernetes because, at the end of the day, it’s the best platform out there right now to scale containerized workloads. But you must understand what you’re getting yourself into. The end result will be amazing, but the beginning of the journey will be a bit of a struggle—as with all new technology.

About Michael Levan: Michael Levan is a seasoned engineer and consultant in the Kubernetes space who spends his time working with startups and enterprises around the globe on Kubernetes and cloud-native projects. He also performs technical research, creates real-world, project-focused content, and coaches engineers on how to cognitively embark on their engineering journey. He is a DevOps pro, HashiCorp Ambassador, AWS Community Builder, and loves helping the tech community by public speaking internationally, blogging, and authoring tech books.