DaemonSet

最后更新于: 2025-12-06 10:36:40

DaemonSet

通过该控制器的名称我们可以看出它的用法：**Daemon**，就是用来部署守护进程的，DaemonSet用于在每个 Kubernetes 节点中将守护进程的副本作为后台进程运行，说白了就是在每个节点部署一个 Pod副本，当节点加入到 Kubernetes 集群中，Pod 会被调度到该节点上运行，当节点从集群够被移除后，该节点上的这个 Pod 也会被移除，当然，如果我们删除 DaemonSet，所有和这个对象相关的 Pods都会被删除。那么在哪种情况下我们会需要用到这种业务场景呢？其实这种场景还是比较普通的，比如：

集群存储守护程序：如 glusterd、ceph 要部署在每个节点上以提供持久性存储；
节点监控守护进程：如 Prometheus 监控集群，可以在每个节点上运行一个 node-exporter 进程来收集监控节点的信息；
日志收集守护程序：如 fluentd 或 logstash，在每个节点上运行以收集容器的日志
节点网络插件：比如 flannel、calico，在每个节点上运行为 Pod 提供网络服务。

⚠️ 这里需要特别说明的一个就是关于 DaemonSet 运行的 Pod 的调度问题，正常情况下，Pod 运行在哪个节点上是由 Kubernetes 的调度器策略来决定的，然而，由 DaemonSet 控制器创建的 Pod 实际上提前已经确定了在哪个节点上了（Pod创建时指定了**.spec.nodeName**），所以：

**DaemonSet** 并不关心一个节点的 **unshedulable😂** 字段，这个我们会在后面的调度章节和大家讲解的。
**DaemonSet** 可以创建 Pod，即使调度器还没有启动。

注意：Daemonset的简写是ds：

1[root@nfs-server ~]#kubectl api-resources|head -1; kubectl api-resources |grep daemonsets
2NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
3daemonsets                        ds           apps/v1                                true         DaemonSet

DaemonSet是受污点的的影响的；

💘 实战：Daemonset测试-2022.12.22（成功测试）

实验环境

11、win10,vmwrokstation虚机；
22、k8s集群：3台centos7.6 1810虚机，2个master节点,1个node节点 
3   k8s version：v1.20
4   CONTAINER-RUNTIME：containerd:v1.6.10

实验软件（无）

下面我们直接使用一个示例来演示下

在每个节点上部署一个 Nginx Pod

 1# nginx-ds.yaml
 2apiVersion: apps/v1
 3kind: DaemonSet
 4metadata:
 5  name: nginx-ds
 6  namespace: default
 7spec:
 8  selector:
 9    matchLabels:
10      k8s-app: nginx
11  template:
12    metadata:
13      labels:
14        k8s-app: nginx
15    spec:
16      containers:
17      - image: nginx:1.7.9
18        name: nginx
19        ports:
20        - name: http
21          containerPort: 80

注意：我们可以看到，DaemonSet的yaml写法和Deployment非常类似，只是改变了下kind名称，注意下DaemonSet是没有副本数这一参数选项的。

部署

1[root@master1 ~]#kubectl apply -f nginx-ds.yaml
2daemonset.apps/nginx-ds created

创建完成后，我们查看 Pod 的状态

1[root@master1 ~]#kubectl get node
2NAME      STATUS   ROLES                  AGE   VERSION
3master1   Ready    control-plane,master   19d   v1.22.2
4node1     Ready    <none>                 19d   v1.22.2
5node2     Ready    <none>                 19d   v1.22.2
6[root@master1 ~]#kubectl get po -l k8s-app=nginx -owide
7NAME             READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
8nginx-ds-g5jf4   1/1     Running   0          85s   10.244.1.82    node1   <none>           <none>
9nginx-ds-hl7fx   1/1     Running   0          85s   10.244.2.106   node2   <none>           <none>

我们观察可以发现除了 master1 节点之外的2个节点上都有一个相应的 Pod 运行，因为 master1 节点上默认被打上了**污点（taints）**，所以默认情况下不能调度普通的 Pod 上去，后面讲解调度器的时候会和大家学习如何调度上去。

注意：我们这里先来提前看看master节点是如何打上污点的。

 11、首先来看看这3个节点上是否打了污点呢？
 2[root@master1 ~]#kubectl describe node master1 |grep Taints
 3Taints:             node-role.kubernetes.io/master:NoSchedule
 4[root@master1 ~]#kubectl describe node node1 |grep Taints
 5Taints:             <none>
 6[root@master1 ~]#kubectl describe node node2 |grep Taints
 7Taints:             <none>
 8[root@master1 ~]#
 9我们可以看到只有master节点被打上了污点：`NoSchedule`；
10某个节点上如果被打上了污点的话，那么普通pod是不会被调度到其上面的，除非添加了`容忍`才可以；
11
122、这个master1节点的`污点`是当时我们再搭建集群的时候就已经打上了的。我们可以看看当时搭建k8s集群的kubeadm.yaml文件内容。
13  vim kubeadm.yaml
14  1 apiVersion: kubeadm.k8s.io/v1beta3
15  2 bootstrapTokens:
16  3 - groups:
17  4   - system:bootstrappers:kubeadm:default-node-token
18  5   token: abcdef.0123456789abcdef
19  6   ttl: 24h0m0s
20  7   usages:
21  8   - signing
22  9   - authentication
23 10 kind: InitConfiguration
24 11 localAPIEndpoint:
25 12   advertiseAddress: 172.29.9.51
26 13   bindPort: 6443
27 14 nodeRegistration:
28 15   criSocket: /run/containerd/containerd.sock
29 16   imagePullPolicy: IfNotPresent
30 17   name: master1
31 18   taints:
32 19   - effect: "NoSchedule" #这里打了污点
33 20     key: "node-role.kubernetes.io/master"
34
353、那么有的同学就会问：那么为什么你的`flannel和kubeproxy`pod都会在每个节点上创建1个pod呢？(包括master节点)

1这是因为flannel和kube-proxy配置清单里，daemonset那里有配置了容忍，所以才会在打了污点的master节点也调度一个pod。
2vim kube-flannel.yml

注意：DaemonSet和replicaset是非常相似的，直接控制pod：

1[root@master1 ~]#kubectl get po
2NAME             READY   STATUS    RESTARTS   AGE
3nginx-ds-g5jf4   1/1     Running   0          34m
4nginx-ds-hl7fx   1/1     Running   0          34m
5[root@master1 ~]#kubectl describe pod nginx-ds-g5jf4
6……
7Controlled By:  DaemonSet/nginx-ds
8……

我们再来把其中一个pod删除下，观察下这个pod是否会被立马重建？

 1[root@master1 ~]#kubectl get po -owide
 2NAME             READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
 3nginx-ds-g5jf4   1/1     Running   0          9h    10.244.1.82    node1   <none>           <none>
 4nginx-ds-hl7fx   1/1     Running   0          9h    10.244.2.106   node2   <none>           <none>
 5[root@master1 ~]#kubectl delete po nginx-ds-g5jf4
 6pod "nginx-ds-g5jf4" deleted
 7[root@master1 ~]#kubectl get po -owide
 8NAME             READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
 9nginx-ds-cg86w   1/1     Running   0          1s    10.244.1.83    node1   <none>           <none>
10nginx-ds-hl7fx   1/1     Running   0          9h    10.244.2.106   node2   <none>           <none>
11[root@master1 ~]#

我们可以发现，一旦某个节点的pod被删除，会被立马创建的。

实验结束。😘

基本上我们可以用下图来描述 DaemonSet 的拓扑图：

集群中的 Pod 和 Node 是一一对应的，而 DaemonSet 会管理全部机器上的 Pod 副本，负责对它们进行更新和删除。

那么，DaemonSet 控制器是如何保证每个 Node 上有且只有一个被管理的 Pod 呢？

首先控制器从 Etcd 获取到所有的 Node 列表，然后遍历所有的 Node。
根据资源对象定义是否有调度相关的配置，然后分别检查 Node 是否符合要求。
在可运行 Pod 的节点上检查是否已有对应的 Pod，如果没有，则在这个 Node 上创建该 Pod；如果有，并且数量大于 1，那就把多余的 Pod 从这个节点上删除；如果有且只有一个 Pod，那就说明是正常情况。

实际上当我们学习了资源调度后，我们也可以自己用 Deployment 来实现 DaemonSet 的效果，这里我们明白 DaemonSet 如何使用的即可。当然该资源对象也有对应的更新策略，有 OnDelete 和 RollingUpdate 两种方式，默认是滚动更新。