为什么 Openshift 在滚动部署之前扩展旧部署答案

【问题标题】：Why does Openshift scale up old deployment before rolling deployment为什么 Openshift 在滚动部署之前扩展旧部署
【发布时间】：2020-11-21 21:59:50
【问题描述】：

在我的团队中，我们有时会在 Openshift 中缩小到只有一个 pod，以简化测试。如果我们随后将所需的副本数设置为 2 进行滚动更新，Openshift 会在执行滚动部署之前扩展到两个 pod。这很麻烦，因为新的“旧” pod 可以启动我们不希望在新部署开始之前启动的东西，因此我们必须记住在新部署之前取下一个 pod。

有没有办法阻止旧部署扩大到所需的副本数，而新的部署扩大到所需的副本数？还有，为什么会这样？

OpenShift 主控： v3.11.200
Kubernetes 主机： v1.11.0+d4cacc0
OpenShift Web 控制台： 3.11.200-1-8a53b1d

来自我们的 Openshift 模板：

- apiVersion: v1
  kind: DeploymentConfig
  spec:
    replicas: 2
    strategy:
      type: Rolling

【问题讨论】：

您确定在创建新 pod 时将访问路由到它们。仅当具有新版本的 pod 启动并运行时，OCP（和 k8s）才会路由来自服务的流量。如果您想关闭旧应用并部署新的 onw，请使用“重新创建”类型的策略

标签： kubernetes deployment openshift

【解决方案1】：

这是使用RollingUpdate 策略时的预期行为。它一个一个地删除旧的 Pod，同时添加新的 Pod，使应用程序在整个过程中保持可用，并确保其处理请求的能力不下降。由于您只有一个 pod，Kubernetes 会扩展部署以保持策略和 zero-downtime 在清单中的要求。

它扩展到 2，因为如果未指定 maxSurge 默认为 25%。这意味着在更新期间，Pod 实例最多可以比所需数量多 25%。

如果您想确保它不会被扩展，您可以将策略更改为Recreate。这将导致在创建新 Pod 之前删除所有旧 Pod。当您的应用程序不支持并行运行多个版本并且需要在启动新版本之前完全停止旧版本时，请使用此策略。但请注意，此策略确实会在短时间内让您的应用完全不可用。

这是一个很好的document，描述了滚动更新策略。还值得检查官方 kubernetes documentation 关于部署。

【讨论】：

谢谢 :) 当我有 2 个旧 pod 和 1 个新 pod 开始开始部署时，这是 50% 的激增，对吧。这是否意味着 maxSurge 被“拉伸”到 50% 以接受一个新的 pod？