Kubernetes: 为守护进程集实现滚动更新

创建于 2016-03-04 · 3评论 · 资料来源: kubernetes/kubernetes

你好，

很抱歉按照此处提到的错误顺序执行此操作： https :

我做了 #22439 来解决这个问题（在 kubectl 方面）

需要能够在单个命令行中更新守护程序集。
基本上它相当于做：

kubectl delete  -f dsfile  --cascade=false
kubectl create   -f dsfile
for pod in pods
kubectl  delete pod
wait for delete

编辑： @bgrant0607建议更新 ds 而不是 delte/recreate

areapp-lifecycle areworkload-apdaemonset prioritbacklog siapps

资料来源

Seb-Solon

👍13

最有用的评论

1.6 包括 DaemonSet 的滚动升级。

kargakis 于 2017-03-20

🎉9 ❤6

所有3条评论

15310 涵盖了 DaemonSet 从 beta 升级到 GA 的要求，包括服务器端更新编排。我宁愿为此付出努力，但它很棘手，我们不打算在 1.3 中处理这个问题。

如果您想贡献客户端解决方案，尽管这不是我们考虑的长期方向 (#12143)，但不应引入新命令。相反，我们应该让kubectl rolling-update为 DaemonSet 工作（如果您愿意，也应该让 ReplicaSet 工作）。

https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/rollingupdate.go

因为rolling-update没有指定资源类型（ replicationcontroller ），我们必须默认假设rc 。除此之外，我认为语法可以自然地扩展到其他控制器类型，使用类型/名称语法。

例如：

kubectl rolling-update daemonset/mydaemon --image=image:v2

但是，除了命令本身之外，我不希望更新过程共享代码。

当前的滚动更新命令创建一个新的 ReplicationController 并逐渐扩大它，同时缩小旧的。在--image的情况下，它在最后执行“删除舞蹈”以将名称改回原始 RC -- 它删除原始 RC，创建另一个同名 RC，然后删除用于推出新映像的临时 RC。

在 DaemonSet 的情况下，kubectl 会做相反的事情：它会更新原始的 DaemonSet 并一个一个删除 pod 以导致它们被替换。如果指定了--image ，它会在最后完成。如果指定了新的 DaemonSet 名称（例如， kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml ），则将在更新过程结束时创建新的 DaemonSet，并删除原来的 DaemonSet。我们要么需要确保 DaemonSet 优雅地处理它，要么需要在创建新 DaemonSet 之前删除原始 DaemonSet（类似于我在 #7402 中的提议）。

cc @mikedanese @davidopp @madhusudancs @janetkuo @kargakis @pwittrock @gmarek

bgrant0607 于 2016-04-29

1.6 包括 DaemonSet 的滚动升级。

kargakis 于 2017-03-20

🎉9 ❤6

感谢更新！ 👍

Seb-Solon 于 2017-03-20

此页面是否有帮助？

0 / 5 - 0 等级

Kubernetes: 为守护进程集实现滚动更新

最有用的评论

所有3条评论

15310 涵盖了 DaemonSet 从 beta 升级到 GA 的要求，包括服务器端更新编排。 我宁愿为此付出努力，但它很棘手，我们不打算在 1.3 中处理这个问题。

相关问题

15310 涵盖了 DaemonSet 从 beta 升级到 GA 的要求，包括服务器端更新编排。我宁愿为此付出努力，但它很棘手，我们不打算在 1.3 中处理这个问题。