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
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
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.
- 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:
- API Server – This is the only component of the Kubernetes control panel with a
user-accessible API and the sole master component that you’ll interact with. The API server exposes a
restful Kubernetes API and consumes JSON manifest files.
- Cluster Data Store – Kubernetes uses “etcd.” This is a strong, consistent, and
highly-available key value store that Kubernetes uses for persistent storage of all API objects. Think of it
as the “source of truth” for the cluster.
- Controller Manager – Known as the “kube-controller manager,” this runs all the controllers
that handle routine tasks in the cluster. These include the Node Controller, Replication Controller,
Endpoints Controller, and Service Account and Token Controllers. Each of these controllers works separately
to maintain the desired state.
- Scheduler – The scheduler watches for newly-created pods (groups of one or more containers)
and assigns them to nodes.
- Dashboard (optional) – Kubernetes’ web UI that simplifies the Kubernetes cluster user’s interactions with
the API server.
- 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
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
- 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.
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
- Pods – A description of a set of containers that need to run together.
- Services – An object that describes a set of pods that provide a useful service. Services
are typically used to define clusters of uniform pods.
- Persistent Volumes – A Kubernetes abstraction for persistent storage. Kubernetes supports
many types of volumes, such as NFS, Ceph, GlusterFS, local directory, etc.
- Namespaces – This is a tool used to group, separate, and isolate groups of objects.
Namespaces are used for access control, network access control, resource management, and quoting.
- Ingress rules – These specify how incoming network traffic should be routed to services and
- Network policies – This defines the network access rules between pods inside the cluster.
- ConfigMaps and Secrets – Used to separate configuration information from
- Controllers – These implement different policies for automatic pod management. There are
three main types:
- Deployment – Responsible for maintaining a set of running pods of the same type.
- DaemonSet – Runs a specific type of pod on each node based on a condition.
- StatefulSet – Used when several pods of the same type are needed to run in
parallel, but each of the pods is required to have a specific identity.
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.