How to view the taints applied to a Kubernetes node?

Introduction

Kubernetes, the popular container orchestration platform, provides a powerful feature called "taints" to control the scheduling of pods on nodes. In this tutorial, we will dive into the process of viewing the taints applied to Kubernetes nodes, which is an essential skill for effectively managing your Kubernetes cluster.

Skills Graph

Understanding Kubernetes Taints

Kubernetes Taints are a mechanism used to repel or "taint" a node, making it unavailable for scheduling certain Pods. Taints work in conjunction with Pod Tolerations, which allow Pods to "tolerate" a particular taint and be scheduled on the tainted node.

Taints are used to ensure that Pods are only scheduled on nodes that can handle their requirements. For example, you might have a node that is optimized for GPU-intensive workloads, and you want to ensure that only Pods that require GPUs are scheduled on that node. By applying a taint to the node, you can prevent other Pods from being scheduled there.

Taints are defined as key-value pairs, with the following formats:

• key=value:effect: The effect can be one of three values: NoSchedule, PreferNoSchedule, or NoExecute.
• key:effect: In this case, the value is an empty string, and the effect is one of the three mentioned above.

The NoSchedule effect means that no new Pods will be scheduled on the node unless they have a matching toleration. The PreferNoSchedule effect is a "soft" version of NoSchedule, where the scheduler will try to avoid placing a Pod on the node, but it won't be strictly enforced. The NoExecute effect means that new Pods won't be scheduled on the node and existing Pods on the node, if any, will be evicted if they don't have a matching toleration.

Taints can be applied to a node using the kubectl taint command. For example, to apply a taint with the key gpu and the NoSchedule effect to a node named node1, you would run:

kubectl taint nodes node1 gpu=true:NoSchedule

This taint would prevent any Pods from being scheduled on node1 unless they have a toleration that matches the taint.

Viewing Taints on Kubernetes Nodes

To view the taints applied to a Kubernetes node, you can use the kubectl get nodes command with the -o wide option. This will display the taints along with other node information.

Here's an example:

$ kubectl get nodes -o wide
NAME     STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION     CONTAINER-RUNTIME
node1    Ready    <none>          5d    v1.22.0   10.0.0.4      <none>        Ubuntu 22.04 LTS    5.15.0-46-generic containerd://1.6.6
node2    Ready    <none>          5d    v1.22.0   10.0.0.5      <none>        Ubuntu 22.04 LTS    5.15.0-46-generic containerd://1.6.6

In this example, no taints have been applied to the nodes.

To view the taints in a more readable format, you can use the kubectl describe node command:

$ kubectl describe node node1
Name:               node1
Roles:              <none>
...
Taints:             gpu=true:NoSchedule

Here, we can see that the node node1 has a taint with the key gpu, a value of true, and the NoSchedule effect.

You can also use the kubectl get nodes --show-labels command to view the taints as part of the node labels:

$ kubectl get nodes --show-labels
NAME     STATUS   ROLES           AGE   VERSION   LABELS
node1    Ready    <none>          5d    v1.22.0   kubernetes.io/arch=amd64,kubernetes.io/os=linux,node-role.kubernetes.io/worker=true,node.kubernetes.io/taint-effect=NoSchedule,node.kubernetes.io/taint-key=gpu,node.kubernetes.io/taint-value=true
node2    Ready    <none>          5d    v1.22.0   kubernetes.io/arch=amd64,kubernetes.io/os=linux,node-role.kubernetes.io/worker=true

In this output, we can see the taint applied to node1 as part of the node labels.

Applying Taints and Tolerations

Applying Taints to Nodes

As mentioned earlier, you can apply taints to a Kubernetes node using the kubectl taint command. Here's an example:

kubectl taint nodes node1 gpu=true:NoSchedule

This command will apply a taint with the key gpu, a value of true, and the NoSchedule effect to the node node1.

Applying Tolerations to Pods

To allow a Pod to be scheduled on a tainted node, you need to add a toleration to the Pod's specification. Here's an example:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
  - name: gpu-container
    image: nvidia/cuda:11.3.0-base-ubuntu20.04
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

In this example, the Pod has a toleration that matches the taint applied to node1. The key and value fields must match the taint, and the effect field must also match.

The operator field can be one of the following:

• Equal: The taint value and the toleration value must be equal.
• Exists: The taint key must exist, but the value does not matter.

Automatic Tolerations

Kubernetes automatically adds some tolerations to certain system components, such as kube-dns and kube-proxy. These tolerations help ensure that these critical components can be scheduled on any node, even if it has taints applied.

You can view the automatically added tolerations by inspecting the YAML of these system components, for example:

kubectl get deployment kube-dns -n kube-system -o yaml

This will show the tolerations added to the kube-dns deployment.

Summary

In this Kubernetes tutorial, you have learned how to view the taints applied to Kubernetes nodes, a crucial aspect of managing workload scheduling and resource allocation within your cluster. By understanding and managing Kubernetes taints, you can ensure that your applications are deployed on the right nodes, optimizing resource utilization and maintaining the overall health of your Kubernetes environment.