deployment 下多个副本在启动时是并发启动还是顺序启动？

[dong706]

目前已知的是 StatefulSet 是按序号索引顺序创建各个 Pod ，并且会等待前一个 Pod 变为 Running 和 Ready 才会启动下一个 Pod 。

那 Deployment 也是按顺序启动么？或者是并发启动？

没有找到相关的官方说明，求大佬解惑~~~

[seers]

init 会先起，其他的并发

[wunonglin]

Deployment 是不保证顺序。StatefulSet 可以按顺序。没有并发的说法吧

[cesign]

并发，不用等 ready

[dong706]

@seers 我是指 pod 这个维度，不是 pod 内部的启动顺序

[coderxy]

Deployment 不保证顺序， 它本身就是无状态的，哪儿来的顺序概念

[shiyuu]

帮你问了一下 ChatGPT ，他的回答：

在 Kubernetes 中，Deployment 控制器管理 Pod 的创建和更新。当 Deployment 启动时，它会同时启动多个副本的 Pod 。默认情况下，所有 Pod 都是并发启动的，这意味着它们可以同时启动和运行。

但是，您也可以配置 Deployment 控制器来控制 Pod 的启动顺序。您可以通过设置 spec.strategy.rollingUpdate.maxUnavailable 参数来控制启动时最多可以有多少副本不可用，从而控制 Pod 的启动顺序。

例如，如果您设置 maxUnavailable 为 0 ，则 Deployment 将等待现有副本退役后才能启动新副本，从而实现顺序启动。如果您设置 maxUnavailable 为 1 ，则 Deployment 可以在现有副本中的一个退役后同时启动新副本，从而实现并发启动。

最后要注意的是，Deployment 中的 Pod 启动顺序取决于您设置的 maxUnavailable 参数，但不保证它们的启动时间或启动速度相同。每个 Pod 的启动时间和速度受多种因素的影响，包括容器镜像大小、容器启动命令和参数等。

[dong706]

@shiyuu 感谢感谢，我忘记问 chatGPT 了

[julyclyde]

我觉得这是个并不需要考虑的问题啊
多个实例之间相互没有关系的，自然也就没有顺序要求

[dong706]

@julyclyde 有些业务会考虑到这一点

[dong706]

@julyclyde 比如第一个启动的 pod ，会自动创建根密钥，后续启动的 pod 不需要也不能去重新创建根密钥。

[julyclyde]

@dong706 那是你的设计有问题

[dong706]

@julyclyde 我也感觉是有问题，求指教，就我上面说的这个问题，该咋解决？ pod 里的应用需要一个根密钥（不能预置，必须随机生成），deployment 下的多个 pod 共享这个根密钥文件。

[julyclyde]

@dong706 为什么不能预置呢？
随机生成之后，怎么告知通信对手？

[Marinaaaa]

@dong706 写到 Volumes 里呢？

[dong706]

@Marinaaaa Volumes 是通过 nfs+存储类动态生成的，无法提前预先知道存储位置。

[dong706]

@julyclyde 业务原因不能预置。不是用于通信，用于数据安全存储。

[twinsdestiny]

用个分布式锁，谁抢到谁生成根密钥，其他直接跳过
不然就 statefullset ，一个一个启动

[dong706]

@twinsdestiny 这个思路我实践过，但是要引入 redis....最终还是放弃了。

不过现在已经知道怎么保证 deployement 按顺序启动了，这个问题就不存在了。

就算实在没办法，我最终会采用 statefulset 来解决。

[idontnowhat2say]

@dong706 只用 deployment 就在 spec 里加个 init 容器，里面判断下密钥是否存在，不存在就生成，存在就跳过。就一个 if else 的事

[julyclyde]

@dong706 既然是存储，按说 key 在各实例之间应该是相同的啊

[julyclyde]

@idontnowhat2say initContainer 是 pod 的而不是 deployment 的。你在这里边实现，和直接在 app 里实现也没什么区别啊，都是会遇到 race condition 的