I am trying to deploy my microservices into Kubernetes cluster. My cluster having one master and one worker node. I created this cluster for my R&D of Kubernetes deployment. When I am trying to deploy I am getting the even error message like the following,
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling <unknown> default-scheduler 0/2 nodes are available: 2 node(s) had taints that the pod didn't tolerate
My attempt
When I am exploring about the error, I found some comments in forums for restarting the docker in the node etc. So after that I restarted Docker. But still the error is the same.
When I tried the command kubectl get nodes
it showing like that both nodes are master and both are ready
state.
NAME STATUS ROLES AGE VERSION mildevkub020 Ready master 6d19h v1.17.0 mildevkub040 Ready master 6d19h v1.17.0
I did not found worker node here. I created one master (mildevkub020) and one worker node (mildev040) with one load balancer. And I followed the official documentation of Kubernetes from the following link,
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
My question
Is this error is because of the cluster problem? Because I am not finding the cluster worker node. Only master node.
You can use kubectl taint to remove taints. You can remove taints by key, key-value, or key-effect.
Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement). Taints are the opposite -- they allow a node to repel a set of pods. Tolerations are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints.
We can do this by using the kubectl taint command. The above taint has a key name app , with a value frontend , and has the effect of NoSchedule , which means that no pod will be placed on this node until the pod has defined a toleration for the taint. We will see what the toleration looks like in later steps.
Taints are a Kubernetes node property that enable nodes to repel certain pods. Tolerations are a Kubernetes pod property that allow a pod to be scheduled on a node with a matching taint. Let's use an example to demonstrate the benefits of taints and tolerations.
In this case, due to a typo, the pod’s toleration ( node-type=high-memory) did not match the node’s taint ( node-typee: high-memory ), so it could not be scheduled on that node. If you fix the typo in the taint so that it matches the toleration, Kubernetes should be able to schedule the Pending pod on the expected node.
Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this marks that the node should not accept any pods that do not tolerate the taints. You add a taint to a node using kubectl taint . For example, places a taint on node node1.
You add a taint to a node using kubectl taint . For example, places a taint on node node1. The taint has key key1, value value1, and taint effect NoSchedule . This means that no pod will be able to schedule onto node1 unless it has a matching toleration.
The error typically comes if there is a taint on nodes for which you don't have corresponding toleration in pod spec. Below is an example pod with toleration.
You can run below command to remove the taint from master node and then you should be able to deploy your pod on that node
kubectl taint nodes mildevkub020 node-role.kubernetes.io/master- kubectl taint nodes mildevkub040 node-role.kubernetes.io/master-
Now regarding why its showing as master node check the command you ran to join the node with kubeadm. There are separate commands for master and worker node joining.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With