K8S系列：DaemonSet的更新策略

最新推荐文章于 2025-03-26 01:35:10 发布
原创 最新推荐文章于 2025-03-26 01:35:10 发布 · 2.5k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes #docker #java

本文介绍了Kubernetes DaemonSet的两种更新策略：OnDelete和RollingUpdate。OnDelete是默认策略，需手动删除旧Pod以触发新Pod创建；而RollingUpdate自1.6版本起引入，会自动替换旧Pod。尽管更新过程类似Deployment，但DaemonSet不支持更新历史管理和kubectl rollback命令进行回滚。

目录

OnDelete

RollingUpdate

不同于普通Pod的滚动升级

目前DaemonSet的升级策略（updateStrategy）包括两种：OnDelete和RollingUpdate。

OnDelete

OnDelete：DaemonSet的默认升级策略，与1.5及之前版本的Kubernetes保持一致。当使用OnDelete作为升级策略时，在创建好新的DaemonSet配置之后，新的Pod并不会被自动创建，直到用户手动删除旧版本的Pod，才触发新建操作，即只有手工删除了DaemonSet创建的Pod副本，新的Pod副本才会被创建出来。如果不设置updateStrategy的值，则在Kubernetes 1.6之后的版本中会被作为updateStrategy的默认设置。

RollingUpdate

RollingUpdate：从Kubernetes 1.6版本开始引入。当使用RollingUpdate作为升级策略对DaemonSet进行更新时，旧版本的Pod将被自动“杀掉”，然后自动创建新版本的DaemonSet Pod。

了解本专栏 订阅专栏 解锁全文 超级会员免费看
K8S系列：StatefulSet的更新策略
NIO4444
05-16 2634
目录 RollingUpdate OnDelete Partitioned RollingUpdate 当updateStrategy的值被设置为RollingUpdate时，StatefulSet Controller会删除并创建StatefulSet相关的每个Pod对象，其处理顺序与StatefulSet终止Pod的顺序一致，即从序号最大的Pod开始重建，每次更新一个Pod。注意，如果StatefulSet的Pod Management Policy被设置为OrderedReady，则可
【云原生技术】K8S更新策略有哪些方式，每种方式的可选必填字段有哪些，详细举例说明
weixin_46453070的博客
01-23 1061
更新策略类型必填字段可选字段maxSurgeRecreate无无OnDelete无无Recreate策略本身并不需要，但你可以在 Deployment 中使用它来定义 Pods 启动后所需的最小就绪时间。这在使用 Rollout 或其他策略时更常见，但在 Recreate 策略中也是有效的。
k8s || 滚动升级
qq_60271706的博客
03-29 638
1.修改nginx-deployment.yaml。获取 Deployment 描述信息。检查 Deployment 修订历史。扩缩：扩张或者缩小副本数量。创建 Deployment。升级：从低版本到高版本。回滚：从高版本到低版本。查看修订历史的详细信息。回滚到之前的修订版本。
k8s控制器之StatefulSet--第四弹StatefulSet 的更新策略
linus.lin的博客
06-21 2514
此时，如果您仅仅将 Pod template 回退到一个正确的配置仍然是不够的。由于一个已知的问题，StatefulSet 将继续等待出错的 Pod 进入就绪状态（该状态将永远无法出现），才尝试将该 Pod 回退到正确的配置。如果您更新 Pod template 后，该 Pod 始终不能进入 Running 和 Ready 的状态（例如，镜像错误或应用程序配置错误），StatefulSet 将停止滚动更新并一直等待。从序号最大的 Pod 开始，逐个删除和更新每一个 Pod，直到序号最小的 Pod 被更新。
Deployment 、DaemonSet、StatefulSet更新策略
weixin_55990817的博客
08-17 3226
Deployment 如果Pod是使用Deployment创建的，那么用户可以实时的修改Deployment 内容并应用，K8S 会自动完成Deployment的更新，如果更新过过程中发生了错误，还可以用Rollback 操作恢复Pod的版本 在Deployment的定义中，可以通过spec.strategy 制定Pod 更新策略。目前支持以下两种更新策略： Recreate : 重建，spec.strategy.type=Recreate 表示Deployment会在更新Pod时先杀掉所有正在运行的P
K8S基础知识：DaemonSet、Deployment、StatefulSet、ReplicaSet的用法区别
yanghaitao5000的博客
03-26 1544
DaemonSet 的主要目的是确保在集群中的每个节点（或满足特定条件的节点）上都运行一个且仅运行一个 Pod 副本。当节点从集群中移除时，对应的 Pod 也会被自动删除。StatefulSet 用于管理有状态应用的 Pod，它为每个 Pod 提供了稳定的网络标识和持久存储。StatefulSet 中的 Pod 有固定的名称和顺序，并且在删除和重新创建时会保留其状态。的多个 Pod 副本，它提供了声明式的方式来创建、更新和删除 Pod。即在不中断服务的情况下逐步替换旧版本的 Pod 为新版本。
k8s:DaemonSet 与 StatefulSet 的 使用
m0_50434960的博客
03-12 686
DaemonSet 与 StatefulSet 的使用 DaemonSet 的使用 通过该控制器的名称我们可以看出它的用法：Daemon，就是用来部署守护进程的，DaemonSet 用于在每个Kubernetes 节点中将守护进程的副本作为后台进程运行，说白了就是在每个节点部署一个Pod 副本，当节点加入到Kubernetes 集群中，Pod 会被调度到该节点上运行，当节点从集群只能够被移除后，该节点上的这个Pod 也会被移除，当然，如果我们删除DaemonSet ，所有和这个对象相关的Pods都会被删除。
【云原生| K8S系列】Kubernetes Daemonset，全面指南
didiplus
06-12 2819
如果有500个工作节点，并且您部署了一个daemonset，则默认情况下daemonset控制器将为每个工作节点运行一个pod。另一个例子是，您有特定数量的工作节点专用于平台工具(入口、监控、日志等)，并且希望仅在标记为平台工具的节点上运行与平台工具相关的Daemonset。在这种情况下，您可以使用nodeSelector仅在平台工具专用的工作节点上运行daemonset pods。例如，在有100个工作节点的集群中，一个可能有20个标记为GPU的工作节点来运行批处理工作负载。我们将在本指南的后面讨论它。
云原生之K8S系列：Kubernetes Daemonset 全面指南
wjianwei666的专栏
06-13 410
如果有500个工作节点，并且您部署了一个daemonset，则默认情况下daemonset控制器将为每个工作节点运行一个pod。另一个例子是，您有特定数量的工作节点专用于平台工具(入口、监控、日志等)，并且希望仅在标记为平台工具的节点上运行与平台工具相关的Daemonset。在这种情况下，您可以使用nodeSelector仅在平台工具专用的工作节点上运行daemonset pods。例如，在有100个工作节点的集群中，一个可能有20个标记为GPU的工作节点来运行批处理工作负载。我们将在本指南的后面讨论它。
k8s控制器之DaemonSet--第五弹更新 DaemonSet
linus.lin的博客
06-22 1711
如果最近的 DaemonSet 模板更新被破坏了，比如，容器处于崩溃循环状态或者容器镜像不存在 （通常由于拼写错误），就会发生 DaemonSet 滚动更新中断。一旦找到这些节点，从节点上删除一些非 DaemonSet Pod，为新的 DaemonSet Pod 腾出空间。新的滚动更新不会被以前的不健康的滚动更新阻止。，主控节点和工作节点之间的时钟偏差会使 DaemonSet 无法检测到正确的滚动更新进度。首先，检查 DaemonSet 的更新策略，确保已经将其设置为。的任何更新都将触发滚动更新。
Kubernetes DaemonSet的滚动升级
weixin_34321977的博客
05-08 1061
2019独角兽企业重金招聘Python工程师标准>>> ...
Daemonset 有哪几种更新方式？
mischen520的博客
08-13 530
‌当使用OnDelete作为升级策略时，‌在创建好新的DaemonSet配置之后，‌新的Pod并不会被自动创建，‌直到用户手动删除旧版本的Pod，‌才触发新建操作。‌使用RollingUpdate更新策略时，‌在更新DaemonSet模板后，‌老的DaemonSet Pod将被终止，‌并且将以受控方式自动创建新的DaemonSet Pod。这两种更新方式的不同在于，‌OnDelete需要手动删除旧的Pod以触发新的Pod的创建，‌而RollingUpdate则会自动进行Pod的滚动更新，‌无需手动干预。
k8s教程（pod篇）-升级与回滚
justlpf的专栏
06-18 1579
当使用OnDelete作为升级策略时，在创建好新的DaemonSeti配置之后，新的Pod并不会被自动创建，直到用户手动删除旧版本的Pod，才触发新建操作，即只有手工删除了DaemonSet创建的Pod副本，新的Pod 副本才会被创建出来。升级过程中出现意外，比如写错新镜像的名称、新镜像还没被放入镜像仓库里、新镜像的配置文件发生不兼容性改变、新镜像的启动参数不对，以及因可能更复杂的依赖关系而导致升级失败等，就需要回退到之前的旧版本，这时就可以用到Deploymentl的回滚功能了。
Deployment、StatefulSet和DaemonSet的更新策略
喝醉酒的小白
08-29 1081
此策略会将所有旧的Pods一次性删除，然后创建新的Pods。：这是默认值，StatefulSet在手动触发更新时遵循此策略。新的Pods会被创建并且在它们就绪后，旧的Pods会被逐个删除。当您手动删除DaemonSet时，Kubernetes将按顺序删除每个Pod，并创建新的Pod以替换它们。Partition指定在升级期间要同时删除的Pods数量，而maxUnavailable则定义了允许的不可用Pods的最大数量。在这种策略下，新的Pods会被创建并且在就绪后旧的Pods会被逐个删除。
K8s 应用管理之道 - 升级篇（一）
琦彦
08-17 3536
背景 随着小步快跑、快速迭代的开发模式被越来越多的互联网企业认同和采用，应用的变更、升级频率变得越来越频繁。为了应对不同的升级需求，保证升级过程平稳顺利地进行，诞生了一系列的部署发布模式。 停机发布 - 把老版的应用实例完全停止，再发布新的版本。 这种发布模式主要为了解决新老版本互不兼容、无法共存的问题， 缺点：是一段时间内服务完全不可用。 优点：资源消耗小，升级速度快 滚...
DaemonSet介绍+更新回滚
小五
03-29 945
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
使用RollingUpdate策略更新DaemonSet中的Pod
白生的博客
12-08 739
在这个例子中，我们设置了maxUnavailable为1，这意味着在更新过程中，最多只能有一个Pod处于不可用状态。这将触发Kubernetes控制平面自动执行滚动更新过程。Kubernetes控制平面将逐步更新DaemonSet中的Pod。它将首先创建新的Pod，然后逐渐删除旧的Pod，以确保在更新过程中始终有足够的可用Pod。请注意，更新过程中的不可用性取决于maxUnavailable的值。如果将其设置为1，则每次更新只会影响一个Pod，而其他Pod将保持可用。
设置k8s 指定节点daemonset不调度
最新发布
07-16
### 3.1 使用节点选择器（Node Selector）限制 DaemonSet 调度范围 Kubernetes 提供了 **节点选择器**（Node Selector）机制，允许通过标签选择器将 Pod 调度到具有特定标签的节点上。DaemonSet 控制器支持在 Pod 模板中定义 `nodeSelector` 字段，以控制 Pod 的调度目标节点。 例如，若希望 DaemonSet 仅在带有 `role=monitoring` 标签的节点上运行，可以在 Pod 模板中添加如下字段： ```yaml spec: template: spec: nodeSelector: role: monitoring ``` 这种方式适用于简单的标签匹配场景，但其灵活性有限，无法表达多个条件组合或优先级策略。 --- ### 3.2 利用节点亲和性（Node Affinity）实现更精细的调度控制 为了实现更复杂的调度逻辑，可以使用 **节点亲和性**（Node Affinity）。它允许定义硬性要求（`requiredDuringSchedulingIgnoredDuringExecution`）和软性偏好（`preferredDuringSchedulingIgnoredDuringExecution`），从而控制 DaemonSet Pod 的调度位置。 以下是一个示例配置，表示 DaemonSet Pod 必须调度到标签为 `kubernetes.io/e2e-az-name=e2e-az1` 或 `e2e-az2` 的节点，并优先选择带有 `another-node-label-key=another-node-label-value` 的节点： ```yaml spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: another-node-label-key operator: In values: - another-node-label-value ``` 此方式提供了比 `nodeSelector` 更强的表达能力，适用于需要多条件筛选的场景[^4]。 --- ### 3.3 处理节点污点（Taint）与容忍度（Toleration） 某些节点可能设置了污点（Taint），以防止不符合条件的 Pod 被调度到该节点。例如，默认情况下，Kubernetes 的 master 节点通常包含 `node-role.kubernetes.io/master:NoSchedule` 污点，阻止普通 Pod 被调度[^3]。 如果希望 DaemonSet Pod 能够调度到这些节点，必须在 DaemonSet 的 Pod 模板中添加相应的容忍度（Toleration）。例如，要允许调度到 master 节点，可添加如下字段： ```yaml spec: tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule operator: Exists ``` 这样配置后，即使节点设置了相关污点，DaemonSet 控制器也能成功将 Pod 调度到目标节点上。 --- ### 3.4 综合配置示例 结合上述机制，一个完整的 DaemonSet 配置示例如下，表示仅调度到具备特定标签且可容忍 master 污点的节点上： ```yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: example-daemonset spec: selector: matchLabels: name: example template: metadata: labels: name: example spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule operator: Exists containers: - name: example-container image: nginx ``` 该配置确保 DaemonSet 只会在满足指定亲和性规则并能容忍相应污点的节点上运行。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

NIO4444

如果对您有帮助，欢迎打赏支持！

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值