部分推出 Kubernetes Pod答案

【问题标题】：Partially Rollout Kubernetes Pods部分推出 Kubernetes Pod
【发布时间】：2019-01-05 20:03:49
【问题描述】：

我有 1 个节点和 3 个 pod。我想在三个 pod 中的 1 个中推出新图像，而其他 2 个 pod 保留旧图像。有可能吗？

第二个问题。我尝试推出一个包含错误的新图像，并且我已经定义了 maxUnavailable。但是 kubernetes 仍然会推出所有的 pod。我认为一旦 kubernetes 在第一个 pod 中发现错误，kubernetes 将停止推出整个 pod。我们是否需要手动停止推出？

这是我的部署脚本。

# Service setup
apiVersion: v1
kind: Service
metadata:
  name: semantic-service
spec:
  ports:
    - port: 50049
  selector:
    app: semantic
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: semantic-service
spec:
  selector:
    matchLabels:
      app: semantic
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: semantic
    spec:
      containers:
      - name: semantic-service
        image: something/semantic-service:v2

【问题讨论】：

您正在寻找“金丝雀”或“蓝/绿”部署策略；两者都需要两个部署对象。问题的后半部分有几个案例（新的 Deployment 还是更新？Kubernetes 知道错误吗？）如果您说出如何创建或更改 Deployment 以及 Pod 的状态可能会有所帮助，甚至可能在一个单独的问题中。

标签： docker kubernetes google-cloud-platform

【解决方案1】：

正如@David Maze 在评论中所写，您可以考虑使用canary，这样可以区分不同版本的部署或具有多个标签的同一组件的配置，然后跟踪这些标签并指向不同的版本，更多信息关于Canary deployments 可以找到here。实现目标的另一种方法是Blue/Green deployment，以防您想使用两个尽可能相同的不同环境，并以一种全面的方式随时在蓝/绿环境之间切换和回滚部署。

回答第二个问题取决于给定映像包含什么样的错误以及 Kubernetes 如何在 Pod 中识别此问题，因为 maxUnavailable: 1 参数说明了更新期间可能不可用的 Pod 的最大数量。在集群部署控制器Deployment update 的过程中创建一个新的 Pod，然后假设可用 Pod 的数量与 rollingUpdate 策略参数匹配，则删除旧的 Pod。

此外，Kubernetes 使用liveness/readiness probes 在部署更新期间检查 Pod 是否准备好（活动），并让旧 Pod 继续运行，直到 probes 在新副本上成功。我建议在部署尝试跨集群 Pod 推出更新时检查 probes 以确定 Pod 的状态。

【讨论】：

啊，你是对的！我对不同版本的部署和kubernetes滚动更新概念有错误的理解。谢谢！

【解决方案2】：

关于问题 1：

我有 1 个节点和 3 个 pod。我想在 1 中推出新图像三个 pod 和其他 2 个 pod 保留旧图像。是吗可能吗？

答案：
将策略中的maxSurge 更改为0：

replicas: 3
strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 <------ From the 3 replicas - 1 can be unavailable
      maxSurge: 0       <------ You can't have more then the 3 replicas of pods at a time

关于问题 2：

我尝试推出包含错误的新图像，但我已经定义最大不可用。但是 kubernetes 仍然会推出所有的 pod。一世曾经以为 kubernetes 会停止推出整个 pod kubernetes 在第一个 pod 中发现错误。我们是否需要手动停止推出？

A) 为了让 kubernetes 停止推出整个 pod - 使用 minReadySeconds 指定应该考虑创建的 pod 的时间 ready（使用 liveness / readiness 探针就像@Nick_Kh 建议的那样）。
如果在minReadySeconds 的时间间隔结束之前其中一个探测失败了，那么所有的推出将被阻止。

因此，结合 maxSurge = 0 和 minReadySeconds 的设置以及 liveness/readiness 探针，您可以实现所需的状态：3 个 pod：2 个带有旧图像，1 个带有新图像 em>。

B ) 如果是 A - 您无需手动停止部署。

但如果你必须这样做，你可以运行：

$ kubectl rollout pause deployment <name>

调试不工作的 pod 并采取相关措施。

如果您决定恢复部署，您可以运行：

$ kubectl rollout undo deployment <name> --to-revision=1

（查看修订：$ kubectl rollout history deployment <name>）。

请注意，在您 paused 推出后，您需要使用以下代码 resume 它：

$ kubectl rollout resume deployment <name>

即使您决定undo 并返回到以前的版本。

【讨论】：