DaemonSets
A DaemonSet ensures that all (or some) nodes in a cluster run a copy of a pod. DaemonSets are highly recommended for certain system-level applications, such as log collection and resource monitoring, because these applications run a pod on each node and do not require many pods. A good example of DaemonSet is the kube-proxy of Kubernetes.
DaemonSets are closely related to nodes. If a node crashes, the DaemonSet will not create another pod in other nodes.
The following is an example of a DaemonSet:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonset
labels:
app: nginx-daemonset
spec:
selector:
matchLabels:
app: nginx-daemonset
template:
metadata:
labels:
app: nginx-daemonset
spec:
nodeSelector: #Node selection. A pod is created on a node only when the node meets daemon=need.
daemon: need
containers:
- name: nginx-daemonset
image: nginx:alpine
resources:
limits:
cpu: 250m
memory: 512Mi
requests:
cpu: 250m
memory: 512Mi
imagePullSecrets:
- name: default-secret
The replicas parameter used in defining a Deployment or StatefulSet does not exist in the above configuration for a DaemonSet, because each node has only one replica. It is fixed.
The nodeSelector in the preceding pod template specifies that a pod is created only on the nodes that meet daemon=need, as shown in the following figure. If you want to create a pod on each node, delete the label.
Create a DaemonSet.
$ kubectl create -f daemonset.yaml daemonset.apps/nginx-daemonset created
Run the following command. The output shows that nginx-daemonset creates no pods on nodes.
$ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE nginx-daemonset 0 0 0 0 0 daemon=need 16s $ kubectl get pods No resources found in default namespace.
This is because no nodes have the daemon=need label. Run the following command to query the labels of nodes:
$ kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS 192.168.0.212 Ready <none> 83m v1.15.6-r1-20.3.0.2.B001-15.30.2 beta.kubernetes.io/arch=amd64 ... 192.168.0.94 Ready <none> 83m v1.15.6-r1-20.3.0.2.B001-15.30.2 beta.kubernetes.io/arch=amd64 ... 192.168.0.97 Ready <none> 83m v1.15.6-r1-20.3.0.2.B001-15.30.2 beta.kubernetes.io/arch=amd64 ...
Add the daemon=need label to node 192.168.0.212, and then query the pods of nginx-daemonset again. It is found that a pod has been created on node 192.168.0.212.
$ kubectl label node 192.168.0.212 daemon=need node/192.168.0.212 labeled $ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE nginx-daemonset 1 1 0 1 0 daemon=need 116s $ kubectl get pod -owide NAME READY STATUS RESTARTS AGE IP NODE nginx-daemonset-g9b7j 1/1 Running 0 18s 172.16.3.0 192.168.0.212
Add the daemon=need label to node 192.168.0.94. You can find that a pod is created on this node, as well.
$ kubectl label node 192.168.0.94 daemon=need node/192.168.0.94 labeled $ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE nginx-daemonset 2 2 1 2 1 daemon=need 2m29s $ kubectl get pod -owide NAME READY STATUS RESTARTS AGE IP NODE nginx-daemonset-6jjxz 0/1 ContainerCreating 0 8s <none> 192.168.0.94 nginx-daemonset-g9b7j 1/1 Running 0 42s 172.16.3.0 192.168.0.212
Modify the daemon=need label of node 192.168.0.94. You can find the DaemonSet deletes its pod from the node.
$ kubectl label node 192.168.0.94 daemon=no --overwrite node/192.168.0.94 labeled $ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE nginx-daemonset 1 1 1 1 1 daemon=need 4m5s $ kubectl get pod -owide NAME READY STATUS RESTARTS AGE IP NODE nginx-daemonset-g9b7j 1/1 Running 0 2m23s 172.16.3.0 192.168.0.212
Last Article: Jobs and Cron Jobs
Next Article: Affinity and Anti-Affinity Scheduling
Did this article solve your problem?
Thank you for your score!Your feedback would help us improve the website.