Kubernetes Cordon and Uncordon Command

Introduction

In a Kubernetes cluster, nodes can go into various states, such as "ready" or "not ready". The cordon and uncordon commands are used to control the scheduling of pods on a particular node. The cordon command marks a node as "unschedulable", preventing new pods from being scheduled on that node, while the uncordon command marks a node as "schedulable" again, allowing new pods to be scheduled on that node. In this lab, we will explore how to use these commands to control the scheduling of pods on nodes in a Kubernetes cluster.

Skills Graph

Cordoning a Node

In this step, we will use the cordon command to mark a node as "unschedulable", preventing new pods from being scheduled on that node. Here are the steps:

1. List the nodes in the cluster using the following command:

kubectl get nodes

2. Cordon the node using the following command:

kubectl cordon minikube

3. Verify that the node has been cordoned by checking the SchedulingDisabled field in the node's status using the following command:

kubectl get node | grep SchedulingDisabled

Uncordoning a Node

In this step, we will use the uncordon command to mark a node as "schedulable" again, allowing new pods to be scheduled on that node. Here are the steps:

1. Uncordon the node using the following command:

kubectl uncordon minikube

2. Verify that the node has been uncordoned by checking the SchedulingDisabled field in the node's status using the following command:

kubectl get node | grep SchedulingDisabled

Cordoning and Uncordoning Nodes with Pods

In this step, we will simulate a scenario where a node needs to be cordoned and uncordoned while it has pods running on it. Here are the steps:

1. Execute the following command to enter the directory /home/labex/project/:

cd /home/labex/project/

2. Create a deployment named "deploy.yaml" with multiple copies using the following YAML file in the directory /home/labex/project/:

## deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.16
          ports:
            - containerPort: 80

3. Cordon the node using the following command:

kubectl cordon minikube

4. Apply the YAML file using the following command::

kubectl apply -f deploy.yaml

5. List the pods running on the nodes using the following command:

kubectl get pods -o wide

Check if the Pod is scheduled and started properly.

6. Uncordon the node using the following command:

kubectl uncordon minikube

7. Check the status of the pods running on the node to ensure that they are rescheduled on the uncordoned node using the following command:

kubectl get pods -o wide

Using Labels to Cordon and Uncordon Nodes

In this step, we will use labels to cordoned and uncordoned nodes based on specific criteria. Here are the steps:

1. Label the nodes in the cluster using the following command:

kubectl label nodes minikube org=labex

2. Cordon the nodes that have the specified label using the following command:

kubectl cordon -l org=labex

3. Verify that the nodes have been cordoned by checking the SchedulingDisabled field in the nodes' status using the following command:

kubectl get node -l org=labex | grep SchedulingDisabled

4. Uncordon the nodes that have the specified label using the following command:

kubectl uncordon -l org=labex

5. Verify that the nodes have been uncordoned by checking the SchedulingDisabled field in the nodes' status using the following command:

kubectl get node -l org=labex | grep SchedulingDisabled

Summary

In this lab, we explored how to use the cordon and uncordon commands in Kubernetes to control the scheduling of pods on nodes. We learned how to cordoned and uncordoned nodes, even with running pods, and how to use labels to selectively cordoned and uncordoned nodes based on specific criteria. These commands are useful for managing the availability and resiliency of pods in a Kubernetes cluster.