Last week, I delved into cgroups and namespaces, the foundational pillars of containers. But before we dive deeper into containers, let’s take a step back and define what an application is. Applications are so ubiquitous today that it’s almost impossible to go a day without using one (unless you’re like my uncle, a carpenter by trade, and a bit of a luddite). We use them on our smartphones, work computers, and pretty much any digital device.
In simple terms, an application allows a user to perform a specific task repeatedly without having to code or program it each time1. Most applications we use today are what we might call monolithic applications, especially those developed in-house by organizations. These applications typically run on a specific operating system and can be cumbersome to upgrade or update.
This brings us to the concept of application refactoring. You can find more information about refactoring2 here as part of the 12 Factor App, a methodology for creating robust applications. In a nutshell, refactoring means breaking down a large application into microservices. Instead of a single large application, you end up with multiple smaller applications, or microservices. One of the benefits of this approach is that it allows updating the microservices independently. Some applications may already be refactored or set up in a microservice state, making them prime candidates for “containerization.”
So, what exactly is a container? Think of it as an image containing all the dependencies, binaries, and libraries needed to run an application without relying on a traditional OS. Containers use cgroups and namespaces to run applications in an isolated resource and namespace environment. Essentially, there’s still an application running underneath, but it’s much more isolated than traditional applications. The closest analogy I could come up with is a ThinApp package—think of it as a distant cousin. The principle is similar, but with one glaring difference: I can spread those microservices across many containers rather than cramming them into a single, completely isolated package.
When we deploy containers, we typically use a cluster that has two main parts: a control plane and worker nodes. The control plane manages the worker nodes, which are where the containers exist in the cluster. Each cluster will usually have one control plane and one or more worker nodes. These worker nodes run one or more Pods, and within each Pod, you find the container that holds the application.
On the Control Plane, you’ll find several key components:
- API Server: This is where RESTful calls interact with the cluster. These calls may come from users, admins, or other sources. The API server handles authentication, authorization, and admission control for the Pods.
- Scheduler: Finds the best Pod to handle the workload. It queues requests, determines which nodes have the best resources, and assigns the Pod to the optimal node.
- Controllers: Monitor the cluster’s state and ensure it matches the desired state. The current state is stored in the etcd KV store.
For the worker nodes, we find the following:
- Container Runtime (sometimes abbreviated as CRX): This is the component that allows the container to run. It handles fetching images from a registry and managing the container’s lifecycle.
- kube-proxy: A network proxy on each node that maintains connectivity between the various services and pods. It can handle basic TCP/UDP streams or round-robin forwarding within the cluster.
- kubelet: Acts as an agent, responding to how the Pod is described, usually via a YAML file.
Whew! That’s a lot to take in. When you put all these pieces together and run the clusters on an OS kernel without needing direct hooks into the OS, you end up with a system that requires fewer resources for the application. There are certainly more parts to this, but this overview should give you a solid starting point.
And with that, it’s time to wrap up. Until next time!
- Wikipedia entry on Application software: https://en.wikipedia.org/wiki/Application_software ↩︎
- What is Application Refactoring?: https://www.vmware.com/topics/glossary/content/application-refactoring.html ↩︎
Leave a Reply