Kubernetes has become the new standard for deploying and managing software in the Cloud because of the wide number of features that Kubernetes provides. Some handy features that make Kubernetes the preferred deployment option include automated rolling and rollback of deployments, storage orchestration, automated bin packing, self-healing, management of secrets and configuration files, and many more.
One of the essential components that are a part of the Kubernetes Architecture are the Nodes. Within this blog, we will take a deep dive at the Kubernetes Nodes, and learn about their functionality, how they work, and more. If you wish to get a good understanding of the entire Kubernetes Architecture, please check out this blog.
What are Kubernetes Nodes?
A Kubernetes Node is an individual machine where the workloads can run. It is essentially a unique computer or virtual machine itself. Multiple such nodes are connected together to form a Kubernetes cluster. A node can be either a physical machine or a virtual machine hosted on a cloud provider such as AWS, GCP, or Azure. As per Kubernetes v1.31, a total of 5,000 nodes are supported per cluster.
There are two main types of Nodes in a Kubernetes Cluster.
- Control Plane Node: The Kubernetes Control Plane Node (also known as the Master Node) houses all the core components of Kubernetes. The Control Plane controls the entire cluster and there must be at least one Control Plane node running in the cluster. For enabling a High Availability cluster, there can be multiple control plane nodes as well. The control plane houses core components such as the API server, etcd, controller manager, etc.
- Worker Node: The worker node is where all the application pods are scheduled to. Each node in Kubernetes has the kubelet - a component responsible for building and managing the pods on the node.
Kubernetes Node Components
There are a few different components present in every single Node within Kubernetes, whether it is the control plane or a worker node. Let us look at these components and understand they function within the Cluster.
Kubelet
The kubelet is an agent that communicates with the Control Plane node and executes certain commands on the worker nodes. It gets the Pod specification i.e instructions on how to create the pod, through the API server and executes the containers associated with the Pod and ensures that the containers running within the pods are running and in a healthy state.
Kubelet also periodically monitors the state of the pods and in case of any problem, works on healing the pod. Kubelet also has an internal HTTP server exposing a read-only view at port 10255. For example, a few of the endpoints provided by the kubelet
/healthz: Endpoint for running health checks/pods: Endpoint to get a list of running pods,/spec: Endpoint to get specifications of the machine on which kubelet is running
Kube Proxy
Kube-proxy runs on each node to enable networking within the node between the different pods, and allow the pods to communicate outside the cluster. It deals with individual host sub-netting and ensures that the services are available to external parties. For each Service endpoint, Kube-proxy sets up the routes so that it can reach it. It serves as a network proxy and a load balancer for the pods running on that particular node.
The kube-proxy has 3 modes of operation namely iptables, ipvs, and userspace. Userspace is a deprecated method that is not recommended for usage. By default, the kube-proxy runs with iptables and is suitable for moderately sized clusters. The drawback with iptables is that it uses sequential network rules which can impact network performance. Ipvs on the other hand support parallel processing for network rules and can support a large number of services. This is ideal for running in clusters that have a lot of nodes and pods.
Container Runtime
A container runtime in Kubernetes is responsible for creating and running containers in the node. There are a number of different container runtimes that can be used with Kubernetes such as containerD, docker, or CRIO. The container runtime is responsible for pulling the appropriate container images from the registry and running the containers in the pods.
Kubernetes does not handle the containers in any way i.e. it does not pull images, create containers, or handle the container lifecycle. A separate container runtime needs to be installed on the node for this. The kubelet interacts with a container runtime that follows the Container Runtime Interface (CRI) specification and provides it with the correct instructions for building the containers.
Understanding Node Properties
Every Kubernetes Node has several different properties, which are useful to know when trying to troubleshoot a Node, or if you’re trying to schedule a pod to Kubernetes. Let us look at some of these important properties of a Node.
Before looking at any of the Node properties, you will have to visualize the nodes that are a part of the Kubernetes cluster. To do this, you can use the kubectl get nodes command which will list out all the nodes present in the cluster.
Once you know the name of the node you wish to inspect, you can use either kubectl describe node or kubectl get node -oyaml to see the different information about the Node.
Node Labels
Every Kubernetes resource has certain labels. These labels are useful for identifying the purpose of the resource. For example, a node can have labels to identify the node’s architecture, the OS running on the node, the hostname, etc.
Imagine that we had three nodes in the cluster, one is the control plane, one node is dedicated for running production workloads, and the third is for testing the application. We can use specific labels to identify which node is for which purpose.
If you want to add a label to a Node, use the kubectl label node key=value command. Let’s say we want to add a label called env=test to a node called node01. We can add the label using the following command
kubectl label node node01 env=testIf you want to see all the labels that are assigned to a particular node, you can use the kubectl get nodes commands along with a --show-labels flag to see all the labels on a node. For example, the following command will show you call the labels that belong to the node named as node01
kubectl get nodes --show-labels
The different Node labels also help with scheduling pods onto the nodes. To learn more about scheduling pods and how labels help in it, please check out this blog.
Node Annotations
Along with the labels of a node, you can also see the different annotations that are assigned to the node. Annotations help attach arbitrary non-identifying metadata to the different Kubernetes resources.
To see the different annotations assigned on the node, you can describe the Node using kubectl describe node to see the different annotations.
To see a list of the commonly used annotations for different Kubernetes objects, you can refer to this page.
Node Allocation & Capacity
A node is simply a physical or a virtual machine. It has a certain amount of memory and CPU capacity. You can see this information in the node’s manifest file as well.
It can show you information about the total capacity and the number of allocable resources in the Node for resources such as CPU, storage, memory, and the number of pods that can run in the Node.
Node Conditions
If you look through the Node Manifest, you will see that it has a field called as Node Conditions. The Node conditions show the status of the different components of the Node. You can see information about statuses such as the Network, Disk Pressure, Memory Pressure, PID Pressure, and its Ready status.
If one of these statuses is in an error state, it can become easier to debug what is wrong with the Node. For example, if the Memory Pressure goes in an error state, you can determine that the Node is running low on memory and you can either reduce the number of pods or increase the memory capacity by vertically scaling the node.
Node Info
You can also see the node’s information. This includes information about the node’s hardware and software such as:
- Hardware Architecture
- Container Runtime Version
- Operating System Image
- Kubelet & KubeProxy versions
Node Status
The Node status in the Node’s manifest shows information about the network of the node. You can see the different IP addresses and their types that are assigned to the node.
Useful commands for Node Operations
When working with Nodes, there are certain commands that you will want to run frequently. Below, we have listed some of the most used commands when working with Nodes. You can use them as a quick reference guide for performing certain actions within the node.
kubectl get nodes- Get a list of all the nodes in the clusterkubectl get nodes --show-labels- See nodes along with all the labels assigned to the Nodekubectl get nodes -o wide- Get detailed information about node including its version, image and morekubectl get node -o yaml- View the node’s YAML manifestkubectl describe node- Get information about the node in a well-formatted manner.kubectl get pods -owide- View which node is the pod scheduled onkubectl get nodes -l key=value- Get nodes which have a particular label. Replace key=value with the label.kubectl taint node- Taint a node for scheduling pods
Node Management with Devtron
Devtron is a Kubernetes dashboard that simplifies the management of the Kubernetes cluster. It has several features for visualizing and managing the nodes of the Kubernetes cluster. You can get a detailed overview of the details of the nodes including information about the Node’s version, roles, and IP addresses. It also shows you the different resource requests, limits, and utilization of the cluster as well as the different labels, annotations, and taints, all within a single dashboard view.
It reduces the amount of context switching you need to do, and you don’t need to dig around the YAML file to find the different information you need. There is also a dedicated dashboard for seeing all the different node conditions.
You can also provision a terminal from Devtron’s dashboard to access the node and run the various commands. For example, if you wanted to check the kubelet on the node, you go provision a terminal and check it directly for Devtron’s dashboard instead of having to first SSH into the VM.
To learn more about Devtron’s dashboard and all its awesome features, please check out this blog.
Conclusion
Kubernetes Nodes are an essential part of the Cluster. They can either be physical machines or Virtual Machines that are connected to the Kubernetes cluster. Pods are always placed on certain nodes within the cluster. The two main types of nodes are the Control Plane node, which houses the critical Kubernetes components, and the worker node which houses the various application pods. The Kubelet, Kube Proxy, and container runtime are some of the critical components that are present on every node within the cluster.
