Learn Cloud Native

Sign up to receive our newsletter

What is a Node in Kubernetes?

A node is a physical server or virtual machine that hosts the Kubernetes control plane software and/or Kubernetes Pods. Nodes are the fundamental infrastructure building blocks of Kubernetes. Without nodes, you can’t build a Kubernetes cluster, and without a cluster, you can’t run a Kubernetes environment.

That’s why understanding how nodes work and how to manage them is critical for getting started with Kubernetes. Keep reading for an overview of Kubernetes nodes, including the differences between master and worker nodes, how to create nodes, and how to work with features like node labels and selectors.

Kubernetes Node Types

There are two types of nodes in Kubernetes:

  • Master nodes: Which host the Kubernetes API server, the Etcd key-value store, and other control plane components.
  • Worker nodes: Which host Pods – meaning essentially the application containers that users deploy on Kubernetes.

In a single-node cluster, your node serves as both the master and worker node. In most setups, however, you’ll create a cluster that consists of multiple nodes with workloads spread between them.

Each cluster requires at least one master node. But to achieve high availability, admins may run multiple master nodes, each with its own instance of the control plane software and data. That way, if one master node fails, other masters can keep the cluster operating.

Nodes vs. Clusters

If you’re new to Kubernetes, it’s easy to confuse nodes with clusters. But there is a difference between them.

A cluster is what you get when you deploy one or more nodes and manage them all via Kubernetes.

In contrast, a node is just a machine that runs within the cluster.

The main confusion comes when working with single-node clusters, which usually are the first experience when learning Kubernetes. In that case, your node is also essentially your cluster, because the cluster has only one node in it. As noted above, however, virtually every production-grade Kubernetes environment will consist of multiple nodes. Single-node clusters are typically only used for experimentational purposes, as part of lightweight distributions like Minikube.

How Are Nodes Created in Kubernetes?

The way you create nodes in Kubernetes depends on which distribution you use and where your nodes are hosted.

In almost all situations, you can create nodes manually by doing the following:

  1. Set up a PC or server (which, again, could be either a physical or virtual machine). The machine will need to run some version of Linux if you want it to be a master node.
  2. Install Kubelet on the node. Kubelet is the Kubernetes agent that runs on all nodes and allows them to communicate with the control plane.
  3. Join the node to your cluster. Kubelet can self-register nodes to the control plane if you run it with the –register-node flag and specify the necessary information for it to find and join the control plane. Alternatively, you can use the kubeadm CLI tool to join a node to a cluster manually.

In many cases, however, your Kubernetes distribution can automatically create nodes for you and join them to a cluster. For example, if you run Kubernetes using Amazon Elastic Kubernetes Service (EKS), you can use the eksctl utility to create a set of nodes (which EKS refers to as node groups) and join them to an existing cluster with a command such as:

eksctl create nodegroup \ --cluster your-cluster-name \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed false \ --ssh-public-key your-ssh-key
Code language: PHP (php)

In this case, EKS will automatically create the nodes for you in the Amazon cloud and join them to the cluster specified via the —cluster flag.

Similarly, if you use MicroK8s, the lightweight Kubernetes distribution from Canonical, you can automatically create new nodes and join them to a running cluster with:

microk8s add-node

This command will set up an additional node on the machine that is hosting your MicroK8s cluster and join it to that cluster.

Using Nodes in Kubernetes

Kubectl is the main tool for interacting with nodes in Kubernetes. The following are some basic kubectl commands that you can use to track and manage nodes.

List All Nodes

kubectl get node
Code language: JavaScript (javascript)

Get Details About the Status of a Node

kubectl describe nodes node-name

List All Worker Nodes

kubectl get node --selector='!'
Code language: JavaScript (javascript)

List All Worker Nodes That Are Ready (Meaning They Can Host Pods)

kubectl get nodes--selector '!' --output jsonpath = "{.items[?(@.status.conditions[-1].type=='Ready')].status.conditions[-1].type}"
Code language: JavaScript (javascript)

“Drain” a Node (To Remove Running Pods from It)

kubectl drain node-name

Node Labels and Selectors

We said above that there are two types of nodes in Kubernetes: masters and workers. That’s true, but it doesn’t mean that this is the only distinction Kubernetes is capable of making between nodes.

On the contrary, you can define and manage different types of nodes by using node labels and selectors. A node label is what it sounds like: a label that you create to describe a particular node or set of nodes. A selector is a configuration value that tells Kubernetes to select nodes with specific labels.

For example, imagine that you have a cluster where some nodes are VMs and others are physical, bare-metal servers. You want to be able to control which Pods are deployed on VMs and which ones are deployed on bare metal.

You can do this by first assigning node labels using a kubectl command such as:

kubectl label nodes node1 servertype=baremetal

This tells Kubernetes that the node named node1 should have the label servertype=baremetal. You can verify that that label was applied correctly using this command, which will return the label details (among other information):

kubectl describe node node1

Now, to tell Kubernetes that a particular pod should only be deployed on a certain type of node, create a pod configuration in YAML that specifies a nodeSelector value. For example:

apiVersion: v1 kind: Pod metadata: name: baremetal-pod spec: containers: - name: your-container image: your-container-image nodeSelector: servertype: baremetal

When deployed, this pod will only run on servers that you labeled with the servertype=baremetal label.

Best Practices for Working with Kubernetes Nodes

To get the most out of your nodes – and, by extension, out of your cluster – consider the following practices for creating and managing nodes.

Use Physical vs. Virtual Nodes Strategically

The main advantage of creating a single node for each physical machine available to you is that Pods hosted on that node will have bare-metal access. You will also have fewer nodes overall, which simplifies node administration.

On the other hand, dividing physical servers into multiple nodes, with each node running as a VM, makes node provisioning easier because you can manage it through virtualization software rather than working directly with bare metal. It also allows you to share resources on a single machine with multiple services, which may be useful if you have a relatively small number of powerful servers and need to run multiple types of workloads on them. And, in the event that you are working in a development environment with just one physical machine, using virtual machines as nodes is the only way to create a multi-node cluster.

Thus, each type of node has its advantages and disadvantages. Think carefully about what works best for you when creating nodes.

Don’t Forget to Drain Nodes

As noted above, you should remove Pods from nodes before you shut nodes down. Kubernetes itself doesn’t do this for you, and you can disrupt your applications if you forget to drain nodes before turning them off.

Use Node Autoscaling (If Available)

Most cloud-based Kubernetes services have autoscaling features, which automatically create or remove nodes for you based on overall workload demand. Taking advantage of autoscaling is a useful way to ensure that you always have the right number of nodes available – and that you don’t waste money paying for nodes that you don’t need.

Unfortunately, autoscaling isn’t available out-of-the-box in Kubernetes environments that use on-prem or self-managed infrastructure, although you can create it yourself.

Provision Nodes Intelligently

In general, the less software that runs on each node, the better. Consider using a minimalist Linux distribution instead of a full-blown one when provisioning nodes in order to avoid running extraneous processes – which create a security risk and waste resources.


Effective node management lays the foundation for effective cluster management in Kubernetes. Knowing how to create nodes, which types of nodes to create, and when to add or remove nodes from a cluster are fundamental skills for managing Kubernetes.