为什么 kubernetes 滚动更新的更新周期值应该很长（默认值：1m0s）？

Question

我想知道如果我将 --update-period（默认值为 1m0s）减少到大约 5s（甚至 1s），潜在的问题是什么？看了几个视频，主持人似乎暗示过短时间是个坏主意，但没有解释原因。

我之所以要缩短它的原因是我们有时更喜欢快速和有点冒险的过渡，而不是安全和稳定的过渡。据我所知，滚动更新的作用是：

while the goal has not been achieved {
  scale-up the new version
  sleep as specified by --update-period
  scale-down the old one
  check deadline
}

从上面的流程来看，我没有看出长时间不睡觉的问题。截止日期检查基于超时配置，因此，更改 --update-period 的唯一结果似乎是更频繁地迭代循环。

我还没有完全理解的一件事是如何执行缩减，但我假设它仍然会正常终止，例如发送 SIGTERM 并等待 30 秒，直到最后将 SIGKILL 发送到 pod 中的进程。

仅供参考，我正在使用 Google 容器引擎。

Answer 1

它应该不会太长，这只是一个预防措施，以防 pod 转换到运行状态但几秒钟后崩溃。如果您的更新周期很短，您将继续部署最终不稳定的 pods，并且不会给整个过程足够的时间来通知。

如果您愿意承担风险，那么更新周期较短是完全可以的。

此外，如果您想要真正快速可靠的部署，您应该检查部署 API。滚动更新逻辑发生在服务器端，提高了可靠性和速度。

why a update-period value for kubernetes rolling-update should be long (default: 1m0s)?