Learning Kubernetes - Episode 4 - Introduction and Explanation of Node Object

#Introduction

Previously, we learned about different tools for installing Kubernetes Clusters locally, from Minikube, Kind, K3s, to K8s, as well as the installation steps for each tool. In episode 4, we'll discuss one of the objects in Kubernetes more deeply: Node.

Note: Here I'll be using a Kubernetes Cluster installed through K3s.

#Node

Note: There are several terms related to the Node object in Kubernetes over time:

Old Term New / Current Term
Master Node Control Plane
Minion / Worker Node Node (Data Plane)

So if you encounter various terms like these in documentation, blogs, and so on, they might be using the old terminology.

Old Term	New / Current Term
Master Node	Control Plane
Minion / Worker Node	Node (Data Plane)

A Node is a worker machine in Kubernetes. Simply put, a Node is what does the work, runs applications, and essentially, where our applications run is all within the Node (Data Plane). So the Master (Control Plane) only manages (orchestrates) the Nodes in Kubernetes.

You might wonder what a Node actually looks like. Well, a Node is essentially a VM (Virtual Machine) in the end. So if we're using cloud computing services, we'll run a VM in the cloud, then register or add that VM to the Kubernetes Cluster as a Node (Data Plane) role. Or if we have our own servers in a data center, whether on-premise or colocation, it might not be a VM but a physical machine directly (commonly called Bare Metal) on a server rack, without an additional hypervisor layer for Kubernetes.

Architecture & Deployment Models

#3 Applications That Must Exist in a Node Object

Within a Node, there are definitely three applications that will exist on every Node: kubelet, kubeproxy, and the container runtime.

Kubernetes Object Node

Note: For those who want to know more about the functions of these 3 main applications that must exist in the Node object, such as kubelet, kubeproxy, and container runtime, you can read episode 2 here: Learning Kubernetes - Episode 2 - Understanding Kubernetes Concepts and Architecture #data-plane-worker-node

kubelet, kubeproxy, and container runtime are the 3 main applications that will definitely exist in a Node. So even if we add hundreds of Nodes or even thousands of Nodes, each of these Nodes will always have these three applications.

Later, when we want to deploy applications in a Kubernetes Cluster, we don't need to specify which Node the application will run on. No matter how many Nodes exist, Kubernetes will automatically manage application placement. Once a Node joins (registers) the Cluster, we can consider all those Nodes as one unified resource, making the deployment process easier and more flexible without having to think about specific Node locations.

If we want to run multiple identical applications simultaneously on those machines, we can easily scale the application. So we no longer need to worry about how many Nodes are in the Kubernetes cluster.

As time goes on, server resources will inevitably become limited, such as insufficient RAM, storage, CPU, and so on. All of this will be handled by the infrastructure or DevOps team.

#Viewing the List of Nodes

After understanding what a Node is and the 3 main applications that must exist in every Node, let's try to see how to view the list of Nodes in the Kubernetes Cluster. To view it, you can use the following kubectl command:

Note: You can also run the following command in shorter versions or several variations like:
bash
sudo kubectl get no
sudo kubectl get no -o wide
sudo kubectl get node
sudo kubectl get nodes
All the above commands are valid and will run successfully.

The result will look like this:

From the Node check in my Kubernetes Cluster above, there are 2 Nodes registered in the cluster, where 1 acts as master (Control Plane), and the other as Node (Data Plane).

#Viewing Node Details

If you want to see more detailed information about one of the registered Nodes above, you can check it using the following command:

Note: Replace <node_name> with the name registered in the Kubernetes Cluster. In this example, I want to check the Node named k3s-4, so the command is:
bash
sudo kubectl describe node k3s-4

If the above command runs successfully, you'll see output like this:

Note: There will be a lot of information displayed. You can read through it in detail. For example, there's information like:

Node name

Its role

Labels

Annotations

Memory

Disk

IP Address

Hostname

CPU

Operating System

And so on

Information about Labels and Annotations will be discussed in more detail in future episodes about those objects.

#Conclusion

In episode 4, we've discussed the Node object in Kubernetes specifically, from its definition, role, to the main applications that always exist on every Node like kubelet, kubeproxy, and container runtime. We've also seen how to check the list of Nodes and the detailed information within them.

By understanding the Node concept, we now know how Kubernetes manages resources and runs applications automatically without having to think about placement details manually. This knowledge is very important as a foundation before learning other more complex Kubernetes objects.

I hope the explanation in this episode helps you understand the role of Nodes in Kubernetes architecture. Don't hesitate to experiment directly on your own cluster to understand better.

Are you getting a better understanding of Nodes in Kubernetes? In the next episode, we'll discuss another equally important Kubernetes object: Pod. So keep your learning spirit alive.