Blog

Under the Hood: An Introduction to Kubernetes Architecture

Sep 11, 2017 | by Oleg Chunikhin

A 101 on Kubernetes components and how they all work together

If you’re making the move to containers, you’ll need a container management platform. And, if you’re reading this article, chances are you’re considering the benefits of Kubernetes.

But what is Kubernetes? What’s under the hood of this incredibly popular container orchestration engine? How does it all come together to deliver the potential of a future-ready, solid and scalable solution for handling in-production, containerized applications? (Note the deliberate use of the word “potential,” we’ll come back to why we inserted that word later).

In this article, we’ll discuss how Kubernetes works and why it has the potential (there’s that word again) to support enterprise-scale software/container management.

What is Kubernetes?

Kubernetes (often abbreviated to K8S), is a container orchestration platform for applications that run on containers.

Not only does Kubernetes have everything you need to support your complex container apps, it’s also the most convenient framework on the market for both developers and operations.

Kubernetes works by grouping containers that make up an application into logical units for easy management and discovery. It’s particularly useful for microservice applications, apps made up of small and independent services that come together to create a more meaningful app.

Although Kubernetes runs on Linux, it is platform agnostic and can be run on bare metal, virtual machines, cloud instances, or OpenStack.

What’s Under the Hood?

To understand how Kubernetes works, let’s look at the anatomy of Kubernetes.

  1. The Kubernetes Master Node

First let’s talk about the master. This is the Kubernetes control panel or control plane. This is where decisions are made about the cluster, such as scheduling, and detecting/responding to cluster events. The components of the master can be run on any node in the cluster. Below is a breakdown of each of the key components of the master:

  1. Kubernetes Worker Nodes

The second important component under the hood are nodes. Whereas the master handles and manages the cluster, worker nodes run the containers and provide the Kubernetes runtime environment.

Worker nodes comprise a kubelet. This is the primary node agent. It watches the API server for pods that have been assigned to its node. Kubelet carries out tasks and maintains a reporting backchannel of pod status to the master node.

Inside each pod there are containers, kubelet runs these via Docker (pulling images, starting and stopping containers, etc.). It also periodically executes any requested container liveness probes. In addition to Docker, RKT is also supported and the community is actively working to support OCI.

Another component of worker nodes is kube-proxy. This is the network brain of the node, maintaining network rules on the host and performing connection forwarding. It’s also responsible for load balancing across all pods in the service.

  1. Kubernetes Pods

As mentioned earlier, a pod is a group of one or more containers (such as Docker containers), with shared storage/network. Each pod contains specific information on how the containers should be run. Think of pods as a ring-fenced environment to run containers.

Pods are also a unit for scaling. If you need to scale an app component up or down, this can be achieved by adding or removing pods.

It’s possible to run more than one container in a pod (where each share the same IP address and mounted volumes), if they’re tightly coupled.

Pods are deployed on a single node and have a definite lifecycle. They can be pending, running, succeeding, or failing, but once gone, they are never brought back to life. If a pod dies, a replication controller or other controller must be used to create a new one.

intro k8s blog banner

How Does It All Work Together?

Now that you have an understanding of what’s under the Kubernetes hood, let’s take a look at how it all works to automate the deployment, scaling, and operation of containerized applications.

Like all useful automation tools, Kubernetes utilizes object specifications or blueprints that take care of running your system. Simply tell Kubernetes what you want to happen, and it does the rest. A useful analogy is hiring a contractor (albeit a good one) to renovate your kitchen. You don’t need to know stage-by-stage what they’re doing. You just specify the outcome, approve the blueprint and let them handle the rest. Kubernetes works in the same way. Kubernetes operates on a declarative model, object specifications provided in so called manifest files declare how you want the cluster to look. There’s no need for a list of commands, it’s up to Kubernetes to do anything and everything it needs to get there.

Building your Blueprints

Kubernetes blueprints consist of several building or Lego® blocks. You’ll compose your blueprint out of these blocks and Kubernetes brings it to life. Blocks include things like the specifications to set-up containers, you can also modify the specifications of running apps and Kubernetes will adjust your system to comply.

This is quite a revolution. Just like the cloud revolutionized infrastructure management, Kubernetes and other systems are taking the application development space by storm. Now DevOps teams have the potential (there’s that word again) to deploy, manage, and operate applications with ease. Just send your blueprints to Kubernetes via the API interface in the master controller.

There are several available Lego blocks that can help define your blueprint. Some of the more important ones are:

How Kubernetes Bulletproofs Itself

Kubernetes simultaneously runs and controls a set of nodes on virtual or physical machines. This is achieved by running agents on each node. The agent talks to the master via the same API used to send the blueprint to Kubernetes. The agent registers itself in the master, providing Kubernetes with information about the nodes. Reading through the API, the agent determines which containers are required to run on the corresponding node and how they are to be configured.

The master node runs several Kubernetes components. Together, these make all control decisions about which container needs to be started on which node and how it should be configured.  

In addition, the master and agent may interact with a cloud provider and manage additional cloud resources such as load balancers, persistent volumes, persistent block storage, network configuration, and number of instances. The master can be a single instance running Kubernetes components or a set of instances to ensure high availability. A master can also serve (in certain configurations) as a node to run containers, although this is not recommended for production.

Realizing the True “Potential” of Kubernetes

As the market leader in container management, Kubernetes has all the components needed to deliver a solid architectural foundation and scalability for your enterprise’s in-production containerized applications. As an open source project with open standards and a huge community behind it, it also provides the flexibility needed to quickly adapt in today’s ever-changing IT environment. But recall our opening statement about the “potential” of Kubernetes. While it certainly can deliver on many of its promises, there are hurdles along the way that every enterprise should be mindful of.

As much as it is beloved, managing Kubernetes is a time-consuming process requiring highly-skilled staff and a potentially large monetary commitment. To address these challenges, Kubernetes management tools are emerging each day, but finding the right tool with the needed flexibility to adapt in an ever-changing IT landscape can be a problem. To help you navigate your options, check out our earlier article on what to look for in a Kubernetes management platform.