Kubernetes Basics: Clusters, Pods, and Nodes

Containerization and Kubernetes have taken the DevOps world by storm in the past decade. More and more companies have turned to this technology to enhance their deployment workflows and cut costs. Examples like Pokemon Go and OpenAI would not have been feasible without Kubernetes.

While Kubernetes is a growing technology in the current times, it comes with a relatively steep learning curve. Understanding the fundamentals of containerization and container orchestration is key to optimizing your app’s resource consumption and performance.

So, what is Kubernetes made of? How does its architecture enable swift DevOps practices and cost/performance optimization? And most important of it all, how can you benefit from this technology? Let’s find out!

Feel free to use these links to navigate the guide:

What are Containers?

Containers are a form of application deployment virtualization. They help developers to wrap an app release with its environment information and other data that will help in smooth deployment on production servers. Containerization solves the age-old problem of “it works on my laptop, though.”

Containers are flexible;  you can run anything from a small script to a full-fledged enterprise application using these. Containers can be easily replicated, scaled, and shut down as needed using special software known as container orchestration tools. Kubernetes is one of the top container orchestration tools in the current market. More on K8s later in this article.

Containers and containerization are helpful to modern DevOps practices in several ways:

What is Kubernetes?

Kubernetes is an open-source solution to managing containers at scale. Kubernetes is a “portable, extensible, open-source platform for managing containerized workloads and services.” In short, you use Kubernetes to interact with containers in a real-life scenario. Individual container deployments are very rare, and frankly speaking, they would add unnecessary load to your deployment routines.

There is so much that you can do with Kubernetes. Here’s a glimpse of its usefulness:

The list is not exhaustive. However, it does reflect the capabilities of the container orchestration tool. Kubernetes has a great community around it, and there are always ongoing attempts of innovation to devise new ways of utilizing this technology. 

An Overview of Kubernetes Components

To make the best use of Kubernetes for yourself, you need to understand how it is structured and how these components come together to bring life to such a useful tool. The following diagram describes the various components of Kubernetes. These components are in three major categories—control plane components, node components, and addons. We will take a look at each of these in detail.

The Kubernetes Architecture. Source: Kubernetes.io

Control Plane Components

The control plane acts as the master of the Kubernetes engine. It houses a range of useful tools and components that help in the normal functioning of the Kubernetes infrastructure.

API Server

The API server exposes the Kubernetes API, which acts as a frontend to the Kubernetes cluster’s state. All external components of the Kubernetes engine use the API server to interact with the engine and make changes to the running clusters as needed. The popular command-line interface library kubectl connects with Kubernetes via the API server.

Controller Manager

The controller manager runs controller services in a Kubernetes cluster. The controller services are responsible for controlling the state of the cluster and updating it to the new specifications as soon as any changes are requested. There are a few types of controllers:

Cloud Controller Manager (Optional)

The cloud controller manager takes care of cloud-specific control logic. It enables you to connect your cluster to your cloud provider’s API and isolates cluster-specific components from cloud-specific components. If you set up your Kubernetes cluster in on-premise infrastructure, you do not need a cloud controller manager.

Out of the all controllers in a Kubernetes control plane, the following can have cloud-specific dependencies:

Persistence Store (etcd)

etcd is a persistent key-value store used to store Kubernetes cluster data. It is highly consistent and available. It also enables service discovery and scheduler coordination between Kubernetes systems or clusters.

Scheduler

Scheduler watches the control plane for newly created pods and selects a node for them if they don’t have one. It runs a series of functions to assign scores to available feasible nodes and assigns the new pod to the node with the highest score.

Node Components

The following components run on each node, and they are mainly helpful for maintaining the health and performance of individual pods.

Container Runtime

The Container Runtime is the software that is responsible for running the containers inside pods. Docker was the default container runtime for Kubernetes for a long time. However, the specification was updated to use any implementation of the Kubernetes CRI (Container Runtime Interface) such as containerd, CRI-O, etc.

kubelet

Kubelet is an agent that runs on every node in the cluster. It acts as an interface between the cluster and the node and ensures that everything is up to speed inside the node.

Kubelet takes in the specifications in the form of PodSpecs and ensures that the running containers match the requirements mentioned in PodSpecs. It also interacts with the etcd store to read and store configuration values.

kube-proxy

Kube-proxy is a network proxy service located in each node that helps maintain network rules on the nodes. These rules help maintain communication to the pods, forward requests to the correct recipients and help in basic load-balancing.

Addons

Addons are components that use Kubernetes resources to implement additional features on the Kubernetes cluster. These provide an array of useful abilities such as service discovery, visualization, infrastructure management, and more. You can find a detailed list of these add-ons here.

How Nodes Work in Kubernetes

A node is the smallest computing unit in a Kubernetes setup. Normally, it represents a single machine in your infrastructure and consists of computing power and memory. Nodes are generally managed in groups called clusters—which we will discuss next. Unless extremely necessary, nodes are not managed independently.

Nodes can be virtual or physical machines. Their prime goal is to act as an abstraction between computing resources and Kubernetes. Instead of controlling the exact computing resources used in a deployment, the Kubernetes engine modifies the number of nodes to match the requirements. Nodes house pods that further house individual containers within them. More on pods later.

What are Kubernetes Clusters?

Multiple Kubernetes nodes pool their resources together to form clusters. Instead of deploying workloads directly to the nodes, you deploy them to the cluster that manages the appropriate distribution of the workload internally. 

Clusters have an entity called Master, which manages the underlying nodes. It assesses the available physical resources and changes allocations based on users’ requirements. A cluster can have one or more masters depending on its allocation requirements.

A Closer Look at Kubernetes Pods

Kubernetes pods are a logical collection of related containers that share storage and network resources. Containers inside a pod are relatively tightly coupled.

The primary purpose of using pods is to share common resources between containers. Each pod is assigned a unique IP address, but containers in a pod can easily and seamlessly connect with each other. With that said, it is also advised to keep the number of containers in a pod to a minimum for better performance. Keeping one container per pod is considered ideal. 

Pods are the smallest deployable units in Kubernetes. They are also highly dispensable—clusters scale an application up and down by deploying new pods and destroying existing ones. This eliminates the need to handle containers directly. This is also one of the reasons why a pod should ideally have only one container. If you put two unrelated, independent containers in a pod, you will not be able to scale both of them independently with full efficiency.

Pods also hold configuration information for the group of containers that they host. To communicate with other pods, each of them has its own identity in the network. As needed, pods can be associated with persistent volumes of their own.

All in all, pods offer containers a shared space while maintaining abstraction from other pods. Pods also make scalability simple by being the smallest deployable unit.

Recap + Key Takeaways

Kubernetes is an excellent solution for container orchestration. It can help you make the best use of Docker and containerization. There are numerous case studies on how the technology has improved the business workflows of real-life organizations. Therefore it is evident that switching to a Kubernetes-based workflow will turn out beneficial for your business in one way or another.

However, Kubernetes has its fair share of steepness in the learning curve. You need to invest time and resources into training your workforce for this technology. There are many incidents that arose out of improper Kubernetes management. Therefore it is vital that you take extra care when relying on such a powerful and large-scale technology.

In this guide, we talked about the basics of the popular container orchestration technology, starting from its roots—containers. Then we discussed each component that goes into bringing this technology to life. Finally, we discussed how the three fundamental components of K8s bring it to life—Nodes, Clusters, and Pods. We hope that this guide helps you understand the basics of K8s easily! 

For more in-depth content around web development and a reliable tool for optimizing your application’s performance, navigate our blog and feel free to explore Scout APM with a free 14-day trial!