Understanding the Relationships Between Kubernetes Clusters, Nodes, and Pods

Since its introduction in 2014, Kubernetes has revolutionized the ways in which development and operations teams deploy, test, and scale container-based applications.

If you’re new to Kubernetes, it’s important to understand how the various components of a Kubernetes cluster relate so you can get a sense of its full potential. 

But first, some refreshers: what are containers? And by extension, why is Kubernetes on the rise? 

What are containers?

Containers enable developers to package up an application with all of its required parts and ship it out as one standard, lightweight, secure package. This gives DevOps teams peace of mind knowing that the application they’re building and supporting will run properly in any environment—whether a virtual machine, bare metal, or the cloud.  Containers essentially eradicate the “works on my machine” problem inherent with monolithic applications.

What is Kubernetes?

For all their benefits, containers also introduce unprecedented complexity. Containers are ephemeral and blur the once-solid lines between application and infrastructure. For this reason, a new approach to container management and orchestration is required. Enter Kubernetes (sometimes short-handed as “K8s”—there are eight letters between the “K” and the “s” of “Kubernetes”).

Originally developed by Google as the Borg project, Kubernetes is an open-source container orchestration platform that automates the deployment, management, and scaling of containerized applications. Backed by major players such as Google, AWS, Microsoft, IBM, Cisco, and Intel, Kubernetes is the flagship project of the Cloud Native Computing Foundation and is now the de facto standard for container orchestration.

Kubernetes simplifies the deployment and operation of containerized applications by introducing an abstraction layer on a group of hosts. DevOps teams can focus on building container-delivered applications while Kubernetes manages a whole range of other tasks.

How Kubernetes clusters, nodes, and pods work together

As with many new technologies, Kubernetes comes with its own vocabulary. In this article, we’ll focus on the highest-level constructs of Kubernetes: clusters, nodes, and pods. Understanding their relationship in supporting container-delivered applications will help clarify the value of Kubernetes to enterprises.

Clusters and Nodes

When you deploy Kubernetes, you are managing a cluster. A cluster is made up of nodes that run containerized applications. Each cluster also has a master (control plane) that manages the nodes and pods (more on pods below) of the cluster. A node represents a single machine in a cluster, typically either a physical machine or virtual machine that’s located either on-premises or hosted by a cloud service provider. 

By conceptualizing a machine as a “node,” we introduce a layer of abstraction. We no longer need to worry about the specific characteristics or location of an individual machine. Instead, we can think about each machine as CPU and RAM resources waiting to be utilized. This allows any machine to substitute any other machine in a cluster.  

Each node hosts groups of one or more containers (which run your applications), and the master communicates with nodes about when to create or destroy containers and how to re-route traffic based on new container alignments.

The Kubernetes master is the access point (or the control plane) from which administrators and other users interact with the cluster to manage the scheduling and deployment of containers. 

A cluster will always have at least one master but may have more depending on the cluster’s replication pattern.

So, here’s how the relationship works: 

• Nodes pool their individual resources together to form a powerful machine or cluster. 
• When an application is deployed onto a cluster, Kubernetes automatically distributes workloads across individual nodes. 
• If nodes are added or removed, the cluster will then redistribute work.

It’s worth noting, too, that whichever individual nodes are running the code shouldn’t impact the program’s performance.

Pods

A pod is the basic unit of scheduling for applications running on your cluster. As discussed above, these applications are running in containers, and each pod comprises one or more container(s). 

While pods are able to house multiple containers, one-container-per-pod is the most common model. In some situations, containers that are tightly coupled and need to share resources could sit in the same pod. Pods can quickly and easily communicate with one another as if they were running on the same machine. They do still, however, maintain a degree of isolation. Each pod is assigned a unique IP address within the cluster, allowing the application to use ports without conflict.

Pods are designed as relatively ephemeral, disposable entities. When a pod gets created, it is scheduled to run on a node. The pod remains on that node until the process is terminated, the pod object is deleted, the pod is evicted for lack of resources, or the node fails.

In Kubernetes, pods are the unit of replication. If an application becomes overly popular and a pod can no longer facilitate the load, Kubernetes can deploy replicas of the pod to the cluster. Even if the app isn’t under heavy load, it’s standard practice to create several copies of a pod in a production system to enable load balancing and mitigate the risk of failure.

Putting it all together

To summarize, nodes represent physical or virtual machines that provide CPU and RAM resources for container-based applications. Nodes are grouped together into clusters. And finally, instead of managing containers individually, Kubernetes containers are housed into pods for scheduling and execution. Pods are the unit of replication.

Ready to get started?

As mentioned above, this is a simplified overview of the core components of Kubernetes—a sophisticated, powerful, potentially game-changing platform that could turn how you develop, operate, and manage your applications on its head.

Adopting containers and Kubernetes for container orchestration requires DevOps teams to rethink and adapt their monitoring strategies to account for new layers of infrastructure and application abstraction that are introduced in a distributed microservices environment. 

Learn some best practices for doing that in our guide, “A Complete Introduction to Monitoring Kubernetes with New Relic.”