2.10 DaemonSet #
DaemonSet 会在 Kubernetes 集群的每个节点上都运行一个 Pod,就好像是 Linux 系统里的 “守护进程”(Daemon)一样。
DaemonSet 和 Deployment 有很大区别,Deployment 能够创建任意多个的 Pod 实例,并且维护这些 Pod 的正常运行,保证应用始终处于可用状态。但是,Deployment 并不关心这些 Pod 会在集群的哪些节点上运行,在它看来,Pod 的运行环境与功能是无关的,只要 Pod 的数量足够,应用程序应该会正常工作。但是对一些业务比较特殊服务,它们不是完全独立于系统运行的,而是与主机存在 “绑定” 关系,必须要依附于节点才能产生价值,比如:
-
网络应用(如 kube-proxy),必须每个节点都运行一个 Pod,否则节点就无法加入 Kubernetes 网络。
-
监控应用(如 Prometheus),必须每个节点都有一个 Pod 用来监控节点的状态,实时上报信息。
-
日志应用(如 Fluentd),必须在每个节点上运行一个 Pod,才能够搜集容器运行时产生的日志数据。
-
安全应用,每个节点都要有一个 Pod 来执行安全审计、入侵检查、漏洞扫描等工作。
以上这些业务如果用 Deployment 来部署就不太合适了,因为 Deployment 所管理的 Pod 数量是固定的,而且可能会在集群里 “漂移”,但,实际的需求却是要在集群里的每个节点上都运行 Pod,也就是说 Pod 的数量与节点数量保持同步。
DaemonSet,它在形式上和 Deployment 类似,都是管理控制 Pod,但管理调度策略却不同。DaemonSet 的目标是在集群的每个节点上运行且仅运行一个 Pod。
2.10.1 描述 DaemonSet #
kubectl 不提供自动创建 DaemonSet YAML 样板的功能,不过可以在 Kubernetes 的官网 https://kubernetes.io/zh/docs/concepts/workloads/controllers/daemonset/上找到 DaemonSet 的 YAML 示例,以下是一个 DaemonSet 的 YAML 描述:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: redis-ds
labels:
app: redis-ds
spec:
selector:
matchLabels:
name: redis-ds
template:
metadata:
labels:
name: redis-ds
spec:
containers:
- image: redis:5-alpine
name: redis
ports:
- containerPort: 6379
DaemonSet 仅仅是在 Pod 的部署调度策略上和 Deployment 不同,其他的都是相同的,某种程度上可以把 DaemonSet 看做是 Deployment 的一个特例。
![](https://cdn.xiaobinqt.cn/xiaobinqt.io/20230603/1669e1a193a941ae9af7a3c85ac00f3f.png)
2.10.2 使用 DaemonSet #
![](https://cdn.xiaobinqt.cn/xiaobinqt.io/20230603/85f672873e504b3a9d3b6225aed5a16a.png)
Master 默认是不跑应用的,所以 DaemonSet 就只生成了一个 Pod,运行在了 worker 节点上,但是按照 DaemonSet 的本意,应该在每个节点上都运行一个 Pod 实例才对,但 Master 节点却被排除在外了,这是由 Kubernetes 节点的两个属性:污点(taint)和容忍度(toleration)导致的。
污点和容忍度 #
“污点” 是 Kubernetes 节点的一个属性,它的作用也是给节点 “贴标签”,但为了不和已有的 labels 字段混淆,就改成了 taint。和 “污点” 相对的,就是 Pod 的“ 容忍度”,也就是 Pod 能否 “容忍” 污点。
集群里的节点各式各样,有的节点 “纯洁无瑕”,没有 “污点”;而有的节点因为某种原因粘上了 “泥巴”,也就有了 “污点”。Pod 也脾气各异,有的 “洁癖” 很严重,不能容忍 “污点”,只能挑选 “干净” 的节点;而有的 Pod 则要求不那么高,可以适当地容忍一些小 “污点”。
Kubernetes 在创建集群的时候会自动给节点 Node 加上一些 “污点”,方便 Pod 的调度和部署。可以用 kubectl describe node 来查看 Master 和 Worker 的状态:
![](https://cdn.xiaobinqt.cn/xiaobinqt.io/20230603/3cce65414d314ccbaab24d2c72e72804.png)
![](https://cdn.xiaobinqt.cn/xiaobinqt.io/20230603/02659614868c46d8866ed61d2009c185.png)
在 Kubernetes v1.24 中,master 节点将不再使用污点 node-role.kubernetes.io/master,而是改成 node-role.kubernetes.io/control–plane。
Master 节点默认有一个 taint,名字是 node-role.kubernetes.io/master,它的效果是 NoSchedule,也就是说这个污点会拒绝 Pod 调度到本节点上运行,而 Worker 节点的 taint 字段则是空的。通常来说 Pod 都不能容忍任何 “污点”,所以加上了 taint 属性的 Master 节点也就会无缘 Pod 了。
有 2 种方法可以让让 DaemonSet 在 Master 节点(或者任意其他节点)上运行了。
第一种方法是去掉 Master 节点上的 taint,让 Master 变得和 Worker 一样 “纯洁无瑕”,DaemonSet 自然就不需要再区分 Master/Worker。
操作 Node 上的 “污点” 属性需要使用命令 kubectl taint,然后指定节点名、污点名和污点的效果,去掉污点要额外加上一个 -
。比如要去掉 Master 节点的 “NoSchedule” 效果,可以使用这条命令:
kubectl taint node master node-role.kubernetes.io/master:NoSchedule-
这种方法修改的是 Node 的状态,影响面比较大,可能会导致很多 Pod 都跑到这个节点上运行,可以选择保留 Node 的 “污点”,为需要的 Pod 添加 “容忍度”,实现精细化调度。
第二种方法是为 Pod 添加字段 tolerations,让它能够 “容忍” 某些 “污点”,就可以在任意的节点上运行。
tolerations 是一个数组,里面可以列出多个被 “容忍” 的 “污点”,需要写清楚 “污点” 的名字、效果。比较特别是要用 operator 字段指定如何匹配 “污点”,一般使用 Exists,也就是说存在这个名字和效果的 “污点”。
如果想让 DaemonSet 里的 Pod 能够在 Master 节点上运行,就要写出这样的一个 tolerations,容忍节点的 node-role.kubernetes.io/master:NoSchedule 这个污点:
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
operator: Exists
所以现在的 DaemonSet YAML 描述文件就变成了这样:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: redis-ds
labels:
app: redis-ds
spec:
selector:
matchLabels:
name: redis-ds
template:
metadata:
labels:
name: redis-ds
spec:
containers:
- image: redis:5-alpine
name: redis
ports:
- containerPort: 6379
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
operator: Exists
重新 apply 部署后可以看到有两个 Pod,分别运行在 Master 和 Worker 节点上。
![](https://cdn.xiaobinqt.cn/xiaobinqt.io/20230603/e43735f6c25548fe88c0064fc46618ae.png)
2.10.3 静态 Pod #
DaemonSet 是在 Kubernetes 里运行节点专属 Pod 最常用的方式,但不是唯一的方式,Kubernetes 还支持另外一种叫 “静态 Pod” 的应用部署手段。
“静态 Pod” 非常特殊,不受 Kubernetes 系统的管控,不与 apiserver、scheduler 发生关系。但既然是 Pod,也必然会 “跑” 在容器运行时上,也会有 YAML 文件来描述它,而唯一能够管理它的 Kubernetes 组件也就只有在每个节点上运行的 kubelet 。
“静态 Pod” 的 YAML 文件默认都存放在节点的 /etc/kubernetes/manifests 目录下,它是 Kubernetes 的专用目录。
![](https://cdn.xiaobinqt.cn/xiaobinqt.io/20230603/c2962486f8b945b9a3ac46e4d0c92528.png)
如果有一些 DaemonSet 无法满足的特殊的需求,可以考虑使用静态 Pod,编写一个 YAML 文件放到这个目录里,节点的 kubelet 会定期检查目录里的文件,发现变化就会调用容器运行时创建或者删除静态 Pod。