21 | 容器化守护进程的意义：DaemonSet

张磊

你好，我是张磊。今天我和你分享的主题是：容器化守护进程的意义之 DaemonSet。
在上一篇文章中，我和你详细分享了使用 StatefulSet 编排“有状态应用”的过程。从中不难看出，StatefulSet 其实就是对现有典型运维业务的容器化抽象。也就是说，你一定有方法在不使用 Kubernetes、甚至不使用容器的情况下，自己 DIY 一个类似的方案出来。但是，一旦涉及到升级、版本管理等更工程化的能力，Kubernetes 的好处，才会更加凸现。
比如，如何对 StatefulSet 进行“滚动更新”（rolling update）？
很简单。你只要修改 StatefulSet 的 Pod 模板，就会自动触发“滚动更新”:
$ kubectl patch statefulset mysql --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"mysql:5.7.23"}]'
statefulset.apps/mysql patched
在这里，我使用了 kubectl patch 命令。它的意思是，以“补丁”的方式（JSON 格式的）修改一个 API 对象的指定字段，也就是我在后面指定的“spec/template/spec/containers/0/image”。
这样，StatefulSet Controller 就会按照与 Pod 编号相反的顺序，从最后一个 Pod 开始，逐一更新这个 StatefulSet 管理的每个 Pod。而如果更新发生了错误，这次“滚动更新”就会停止。此外，StatefulSet 的“滚动更新”还允许我们进行更精细的控制，比如金丝雀发布（Canary Deploy）或者灰度发布，这意味着应用的多个实例中被指定的一部分不会被更新到最新的版本。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入剖析 Kubernetes》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(40)

最新
精选

虎虎❤️
思考题，我觉得应该是效率的问题。查了一下v1.11 的 release notes。scheduler关于affinity谓词的性能大大提高了。查阅了Ds用默认调度器代替controller的设计文档之前的做法是： controller判断调度谓词，符合的话直接在controller中直接设置spec.hostName去调度。目前的做法是： controller不再判断调度条件，给每个pode设置NodeAffinity。控制器根据NodeAffinity去检查每个node上是否启动了相应的Pod。并且可以利用调度优先级去优先调度关键的ds pods。
作者回复: 是的，关键就在于，调度优先级这个特性出现了。所以现在的设计其实没啥特别的地方。
2
68
北卡
我跟上面的朋友有同样的疑问，关于Partition更新的。我设置了Partition，用部分pod来做灰度发布，然后发现没问题，我要全部更新，就只需要去掉Partition字段吗？然后我下一次更新的时候，就要再先加上Partition，然后再更新。全部更新时再去掉。我看了老师的回复，表达的是这个意思吗？
作者回复: 是的。准确的说，是一步一步的减小partition ，一直减成0。就发布完了。

33
紫夜
张老师，DaemonSet的滚动更新，是先delete旧的pod，再启动新的pod，还是和Deployment一样，先创建新的pod，再删除旧的pod?
作者回复: 到目前为止，DS只有一种策略就是先删除再创建 OnDelete
4
29
DJH
张老师，请教几个基础问题： 1. 在上一讲中，有一点我还是没想通，为何MySQL的数据复制操作必须要用sidecar容器来处理，而不用Mysql主容器来一并解决，你当时提到说是因为容器是单进程模型。如果取消sidecar容器，把数据复制操作和启动MySQL服务这两个操作一并写到MySQL主容器的sh -c命令中，这样算不算一个进程呢？ 2. StatefulSet的容器启动有先后顺序，那么当序号较小的容器由于某种原因需要重启时，会不会先把序号较大的容器KILL掉，再按照它们本来的顺序重新启动一次？ 3. 在这一讲中，你提到了滚动升级时StatefulSet控制新旧副本数的spec.updateStrategy.rollingUpdate.Partition字段。假设我现在已经用这个功能已经完成了灰度发布，需要把所有POD都更新到最新版本，那么是不是Edit或者Patch这个StatefulSet，把spec.updateStrategy.rollingUpdate.Partition字段修改成总的POD数即可？ 4. 在这一讲中提到ControllerRevision这个API对象，K8S会对StatefulSet或DaemonSet的每一次滚动升级都会产生一个新的ControllerRevision对象，还是每个StatefulSet或DaemonSet对象只会有一个关联的ControllerRevision对象，不同的revision记录到同一个ControllerRevision对象中？ 5. Deployment里可以控制保留历史ReplicaSet的数量，那么ControllerRevision这个API对象能不能做到保留指定数量的版本记录？问题比较多，谢谢！
作者回复: 已经解释。不会，重启不会破坏拓扑规则，而且文章里说了，你要确保你的脚本不受重启影响。去掉partition。多个对象。支持，字段也一样。

23
Kanner
那为什么Deployment不用ControllerRevison管理版本呢
作者回复: 第一，它比较老。第二，它要用replicaset。

19
宋晓明
老师：有没有公司这样用k8s的：apiserver管理很多pod 每个pod的ip地址全部暴露出来 nginx的upstream配置全是pod的ip地址，访问流程也就是client—>nginx—>pod:port 还有一个程序会监控pod地址变化，一旦变化，自动更新nginx配置。这是新公司使用k8s的流程，感觉好多k8s特性都没用到，比如service，ingress等大材小用了。。。
作者回复: 小规模用用可以，上生产环境还是要用标准的功能。你会发现越用越爽。
4
10
虎虎❤️
一直不理解notation和label的区别，他们的设计思想是什么呢？加污点是前者还是后者？
作者回复: 系统用的和用户用的。taint是spec的一个字段

10
小谢同学
Stateful set 管理的replica 不是通过RS实现的么？
作者回复: 不是。直接管pod

8
donson
“需要注意的是，在 Kubernetes v1.11 之前，由于调度器尚不完善，DaemonSet 是由 DaemonSet Controller 自行调度的，即它会直接设置 Pod 的 spec.nodename 字段，这样就可以跳过调度器了。”，后来随着调度器的完善，调度器就把DaemonSet的调度逻辑收回，由调度器统一调度。划清边界，领域内聚
作者回复: 调度器只是原因之一。

7
初学者
还是没有明白damonset的实现与"污点"的关系，理论上为了实现每个node上有且只有pod, daemonset controller 和nodeaffinity就可以了，为啥需要"污点"机制？
作者回复: 所以你就得在daemonset controller里写调度了

5

收起评论