DaemonSet, which will run a Pod on each node of the Kubernetes cluster, is like a "daemon" (Daemon) in the Linux system.
Deployment doesn't care which nodes these Pods will run on in the cluster. In its view, the operating environment and functions of Pods are irrelevant. As long as the number of Pods is sufficient, the application should work normally.
However, there are some special services that are not completely independent of the system, but have a "binding" relationship with the host, and must be attached to the node to generate value, for example:
The goal of DaemonSet is to run on each node of the cluster and only run one Pod, as if a node is equipped with a "watchdog" to faithfully "guard" the node, which is the origin of the name DaemonSet.
Both DaemonSet and Deployment belong to online business, so they are also "apps" group, use the command kubectl api-resources to know that its abbreviation is ds.
DaemonSet is only different from Deployment in the Pod deployment scheduling strategy, and everything else is the same. To some extent, we can also regard DaemonSet as a special case of Deployment.
"Taint" is an attribute of a Kubernetes node, and its function is also to "label" the node, but in order not to be confused with the existing labels field, it was changed to taint. The opposite of "taint" is the "tolerance" of the Pod. As the name suggests, it is whether the Pod can "tolerate" the stain.
When Kubernetes creates a cluster, it will automatically add some "stains" to the node Node to facilitate the scheduling and deployment of Pods. You can use kubectl describe node to view the status of Master and Worker.
DaemonSet is the most common way to run node-specific Pods in Kubernetes, but it is not the only way. Kubernetes also supports another application deployment method called "static Pod".
"Static Pod" is very special. It is not controlled by the Kubernetes system and has no relationship with apiserver and scheduler, so it is "static".
But since it is a Pod, it must "run" on the container runtime, and there will be a YAML file to describe it, and the only Kubernetes component that can manage it is the kubelet running on each node.
The YAML files of "Static Pod" are stored in the /etc/kubernetes/manifests directory of the node by default, which is a dedicated directory for Kubernetes.
The four core components of Kubernetes, apiserver, etcd, scheduler, and controller-manager, originally existed in the form of static Pods, which is why they can be started before the Kubernetes cluster.
If you have some special needs that DaemonSet cannot meet, you can consider using a static Pod, write a YAML file and put it in this directory. The kubelet of the node will periodically check the files in the directory, and if any changes are found, it will call the container runtime to create or delete Static Pods.
This article is a study note for Day 16 in July. The content comes from Geek Time "Kubernetes Introductory Practical Course". This course is recommended.