Kubectl cordon contains the node as “unplannable”. This affects the facility controller eliminating the node from all previously appropriate LoadBalancer node lists and efficiently eliminating inward load balancer traffic from the blocked ones. The relevant knots will be removed.
Kubernetes runs the workload by assigning the container in the pod for running on the node. Nodes can be virtual machines or physical machines, dependent on the cluster. Each node is achieved by the control plane and consists of the services needed to run the pod.
For running the commands in Kubernetes, we have to install Ubuntu 20.04. Here we use the Linux operating system to execute the kubectl commands. Now we install the Minikube cluster to run Kubernetes in Linux. Minikube offers an extremely smooth understanding as it provides an efficient mode to test the commands and applications.
Let’s see how to use kubectl cordon:
Start Minikube
After installing the minikube cluster, we have to open a terminal for running the commands. For this purpose, we press ‘Ctrl+Alt+T’ altogether from the keyboard.
In the terminal, we write the command ‘start minikube’, and after this, we wait a while till it becomes effectively started. The output of this command is given underneath.
Check Kubectl version
We have to check the version, so we run the command ‘kubectl version’. By running this command, we get the information of client version and server version also in output. When we enter the ‘kubectl version’ command, it will display the succeeding results.
Create a pod in Kubernetes
If we have a collection of several nodes and pods that serve the application. And if any single node goes down. You cannot access the pods above it. If the pods were a chunk of a Replica Set, they would be restructured on other nodes. The amount of time we wait for a pod to become online is called the pod clean timeout and is set to the default of 5 minutes in Controller Manager. Therefore, when a node goes offline, the master node waits up to 5 minutes earlier, assuming that the node is down.
We get the following output after executing the command ‘kubectl get nodes’. The output returns the name of the node, status, roles, age, and Kubernetes version.
Draining a Node
Kubernetes offers a method to drain a node and use the kubectl node drain command to stop all pods arranged on the node and reschedule on other nodes. If we want to patch or upgrade a node with Kubernetes, we have to stop planning for that node and drain the pods running on this node. We can drain the nodes so that workloads are enthused to other nodes.
When you empty the nodes, the pods will properly exit from the node where they are and will be rebuilt on another node. Nodes are also marked as unplannable. This means that you will not be able to schedule pods on the node until you eliminate the limits.
Kubernetes can identify node errors and rearrange pods to new nodes. When the node is cordoned. This means that we cannot place a new pod on this node.
Node draining is a Kubernetes process that securely removes pods from a node. We use the ‘kubectl drain minikube’ command to remove all pods from the node securely. When we run the command, two things occur. The node is cordoned and marked as unplanned for the original pod. Then the deletion method starts, but we get a message like in the terminal after a while. After a while, depending on the situation how it takes a lot of time to deploy and exchange the old pod with the new pod) the kubectl drain minikube command is ended, and we can check if the node is empty.
The drain command separates the node and states Kubernetes to end arranging original pods on the node. Pods successively on the objective node will be removed from the empty node. That is, the pod stops. We can evacuate either a set of nodes or a single worker node.
The ‘kubectl drain minikube’ command empties the node with the specified label and cannot reschedule it on another node, so it ignores all daemon sets arranged on the node. The drain command performs two operations.
Cordon the node; this means marking the node itself as unplannable so that new pods are not arranged on the node. Kubectl contains a command named cordon that permits us to create a node unschedulable
Removes all the pods arranged on the node so that the scheduler can list them on new nodes. The delete action cannot be recovered.
- Ignore-daemonsets: we cannot delete pods running under the daemon set. This flag overlooks these pods.
- delete-emptydir-data: Verify that the data is deleted from the temporary storage EmptyDir as soon as the pod is deleted
Uncordoning a Node
We cannot schedule a new pod once the node is cordoned. If we list a new pod on the node, we have to unlock it manually.
We can schedule a new pod once the node is uncordoned. By this, we can reschedule the pod again.
When we run the script to create a node, we can uncordon the node by adding an uncordon command to the script. Here the ‘kubectl uncordon minikube’ command shows that the ‘minikube’ node will be uncordoned.
Conclusion
A pod is a basic Kubernetes object that is a vital unit to understand the Kubernetes object model. In this article, we have discussed the mode of how to use kubectl cordon. For this purpose, we first create a pod, then drain a node, and at the end, uncordon the node.
