加快 Kubernetes 部署的推出答案

【问题标题】：Speed up rollout of Kubernetes deployment加快 Kubernetes 部署的推出
【发布时间】：2021-06-15 17:55:32
【问题描述】：

如何加快在 Kubernetes 中推出新映像的速度？

目前，我们有一个自动构建作业，它会修改 yaml 文件以指向新修订版，然后在其上运行 kubectl apply。

它可以工作，但在将所有具有先前版本的 pod 替换为最新版本之前，需要很长时间（每个 POD 最多 20 分钟）。

此外，部署配置为 3 个副本。我们看到一次一个 pod 是从新版本开始的。（这是 Kubernetes 的“激增”吗？）但这太慢了，我宁愿杀死所有 3 个 pod，并用新映像创建 3 个新的。

【问题讨论】：

【解决方案1】：

我宁愿杀死所有 3 个 pod，并用新图像创建 3 个新的。

你可以这样做。将strategy.type: 设置为Recreate，而不是Deployment 中的默认RollingUpdate。见strategy。

但您可能会在部署期间遇到一些停机时间。

【讨论】：

【解决方案2】：

Jonas 和 SYN 是对的，但我想通过一些额外的信息和示例来扩展这个主题。

在指定更新部署的方式时，您有两种策略可供选择：

默认且更推荐的一种是.spec.strategy.type==RollingUpdate。请参阅以下示例：

spec:
  replicas: 3
  strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 1
     maxUnavailable: 0

在此示例中，将在所需数量 3 之上增加一个 Pod (maxSurge: 1)，并且可用 Pod 的数量不能低于该数量 (maxUnavailable: 0)。

选择这个配置，Kubernetes 将启动一个额外的 Pod，然后停止一个“旧的”。如果有另一个节点可用于部署此 Pod，系统将能够在部署期间处理相同的工作负载。如果没有，该 Pod 将部署在已使用的 Node 上，代价是来自同一 Node 上托管的其他 Pod 的资源。

你也可以试试这样的：

spec:
  replicas: 3
  strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 0
     maxUnavailable: 1

在上面的示例中，将没有额外的 Pod (maxSurge: 0)，并且一次只有一个 Pod 不可用 (maxUnavailable: 1)。

在这种情况下，Kubernetes 会先停止一个 Pod，然后再启动一个新 Pod。这样做的好处是基础架构不需要扩展，但最大工作量会更少。

如果您选择使用maxSurge 和maxUnavailable 的百分比值，您需要记住：

正确定义 RollingUpdate 后，您还必须确保您的应用程序提供端点以供 Kubernetes 查询并返回应用程序的状态。下面是一个 /greeting 端点，当它准备好处理请求时返回 HTTP 200 状态，当它没有准备好时返回 HTTP 500：

readinessProbe:
  httpGet:
    path: /greeting
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 1

有关活性/就绪性探测的更多信息，请访问here。

【讨论】：

【解决方案3】：

尝试设置spec.strategy.rollingUpdate.maxUnavailable（将spec.strategy.type 保持为RollingUpdate）。

将其设置为2，前两个容器应该一起重新部署，保持服务在第三个容器上运行。或者，如果您不在乎，请使用 3。

【讨论】：