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.
- 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 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.
- 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 are:
- 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 pods.
- Network policies – This defines the network access rules between pods inside the cluster.
- ConfigMaps and Secrets – Used to separate configuration information from application definition.
- 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.