As Kubernetes continues to gain popularity, engineers have to know how Kubernetes works, and why it might make sense in their environment. What benefits does Kubernetes have in your environment and ultimately, what do technologies like containerization do for organizations.
In this blog post, I’ll provide some basic background on containers and Kubernetes, and some suggestions for how to think about Kubernetes for infrastructure pros. The the goal is to make your life easier when implementing it.
Containerized Apps
First, let’s start with the premise of containerization. Containerization, like virtualization and virtual machines, is a way to abstract a physical server’s resources such as memory and CPU. It’s a waste to run a single application on a powerful and expensive server when that application may only use a fraction of the server’s total capacity. An abstraction layer such as a virtual machine or container lets you run multiple applications on one machine via a resource-sharing mechanism.
In the virtualization world, that mechanism is the hypervisor. Generally speaking, a hypervisor typically sits between the server’s hardware and all of the operating systems and applications on that server. The hypervisor divides up and manages the hardware resources such that each OS and app on that machine operates like an independent entity and gets the resources it needs.
Containers use a similar principle, but instead of running multiple operating systems on top of a hypervisor, containerization lets you use a single operating system to serve multiple applications (or discrete functions of applications). Container upsides include fewer OSs to license and/or manage, and a reduced footprint for deploying applications.
At the time of writing this, containers are the smallest unit available to deploy applications to. You can take the same application that you ran on a server that had 16GB of RAM and an entire operating system and run it on a container that’s literally megabytes in size. Because it’s so small, it makes running containers not only easier to actually run and test apps, but easier to scale. Engineers don’t have to worry about creating a new virtual machine. Instead, they can just add another container, which takes a few seconds compared to an hour or so on VMs.
The problem is that at scale, you need a way to coordinate all those containers, and stitch together all those application functions into what acts like a single application. That’s where an orchestrator such as Kubernetes comes into play. Kubernetes isn’t the only container orchestrator available (Docker Swarm, Mesos, and others are still out there), but Kubernetes seems to be attracting the most attention from developers, contributors, and infrastructure professionals.
Orchestrating Workloads
Once an application is containerized and ready to be deployed, infrastructure engineers and developers have to think about how the containerized app will be scaled, managed, and maintained over however long the container is going to stay up.
At a high level, Kubernetes lets you scale containers in the form of a pod (containers live inside pods). Kubernetes components schedule pods to specific worker nodes (physical hardware or a VM), ensure that they have proper network communication, and provide some basic self-healing capabilities. If a pod goes down at 2:00 AM, chances are you don’t have to worry about it.
Moving A Data Center Into One Cluster
Where Kubernetes really begins to shine for infrastructure engineers is around cluster management. At a high level, let’s think about what engineers need to manage.
- Servers
- Networking
- Storage
- Apps
- Ingress/egress
- Policies
- Security
and probably several other things that are missing from the list.
With Kubernetes, everything at the top of the list is inside the cluster. Sure, you have specific tools like security scanners, Ingress Controllers, network frameworks called CNI’s, but everything is managed inside of the cluster itself. It’s not a separate server or a separate appliance. In fact, most of the time it’s Pods/Kubernetes resources that are running these tools. For example, with a CNI, which is the entire network (routing, switching, etc.) for Kubernetes is deployed inside of Kubernetes as Pods. When you deploy a new node/server for Kubernetes, you can do it by utilizing the Kubernetes API.
It feels like a bit of inception in a way, but the point is that you literally manage Kubernetes with Kubernetes.
Where this shines for infrastructure engineers and sysadmins is the fact that you can manage every piece of your system, other than the virtual machines that are actually running it, in a much more straightforward and declarative way.
It’s All An API
In the previous section, the last sentence wrapped up with “in a much more straightforward and declarative way”. The reason why that’s 100% factual is that Kubernetes, by definition, is an API. When you work with Kubernetes, 100% of the time you’re working with APIs. If you’re retrieving Kubernetes Pods using something like kubectl get pods , you’re making an HTTP GET request. If you create Pods using
something like kubectl create -f , you’re making an HTTP POST request.
Every action that you take inside Kubernetes, even creating new nodes after the initial cluster is up and running, is done by making an API call.
On the surface, this may sound like this is more of a plus for developers, but this is a humungous plus in the increased velocity for infrastructure engineers. In today’s world, sysadmins are used to having to learn and utilize multiple CLIs and multiple methods of interacting with platforms, which from an automation perspective, is utilizing multiple APIs.
With Kubernetes, sysadmins only have to worry about one place where all of the APIs end up existing. Although Kubernetes has multiple APIs, they’re kept under two primary groups – the core group and the named group, and because it’s all in Kubernetes, the naming conventions and how you utilize the APIs are practically identical.
Virtual Machines Still Matter
There are three primary locations where organizations run Kubernetes today:
- Public cloud
- On-prem
- Hybrid cloud
Kubernetes in the cloud essentially means a service like Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), or another Managed Kubernetes Service. On-prem could be anything from running Kubernetes in the cloud on virtual machines with a boostrapper like Kubeadm or running Kubernetes on OpenStack. Hybrid cloud is usually a combination of running Kubernetes both on-prem and in the cloud utilizing platforms like Google Anthos or Azure Stack HCI.
Regardless of which way you’re running Kubernetes, there are always still virtual machines. As mentioned, you can run containers inside a virtual machine. Perhaps fewer virtual machines if you’re running in the cloud vs on-prem, but nonetheless, there are still virtual machines, which means engineers must still have a great deal of infrastructure experience, including networking, operating systems, and system administration.
Wrapping Up
If you’re thinking about learning Kubernetes and aren’t sure if you should jump in from an infrastructure perspective, you absolutely should. Kubernetes isn’t going away. Whether you’re planning on running Kubernetes on-prem or in the cloud, having an infrastructure background is a huge help in getting Kubernetes up and running.
