如何在Kubernetes中实现自动回滚？

Question

假设我有一个部署。 由于某种原因，它在一段时间后没有响应。 是否有办法告诉Kubernetes在失败时自动回滚到先前的版本？

- Healthy Bowl

---

如果您的就绪探针设置正确，大多数旧的Pod将一直运行，直到新的Pod报告为健康状态。Kubernetes中没有自动回滚的功能，但是如果您可以告诉它如何检测“损坏”，它会知道不要升级到损坏的版本。 - David Maze

Answer 1

您提到：

我有一个部署。由于某些原因，一段时间后它不再响应。

在这种情况下，您可以使用 活性探针和就绪探针：

Kubelet 使用活性探针来确定何时重新启动容器。例如，活性探针可以捕获死锁，其中应用程序正在运行但无法取得进展。在这种状态下重新启动容器可以帮助使应用程序更加可用，尽管存在错误。

Kubelet 使用就绪探针来确定容器何时准备好开始接受流量。当 Pod 的所有容器都准备就绪时，该 Pod 被视为已准备就绪。此信号的一个用途是控制哪些 Pod 用作服务的后端。当 Pod 不准备就绪时，它会被从服务负载均衡器中移除。

上述探针可以防止您部署损坏的版本，但是活性探针和就绪探针无法将您的部署回滚到以前的版本。在 Github 上有类似的问题，但我不确定在不久的将来是否会有任何进展。

如果您真的想自动化回滚过程，下面我将描述一个您可能会发现有用的解决方案。

---

此解决方案要求从 Pod 中运行 kubectl 命令。 简而言之，您可以使用脚本不断监视您的部署，并在出现错误时运行 kubectl rollout undo deployment DEPLOYMENT_NAME。

首先，您需要决定如何找到失败的部署。以下是一个示例，我将使用以下命令检查执行更新超过 10 秒的部署：
注意：您可以根据需要使用不同的命令。

kubectl rollout status deployment ${deployment} --timeout=10s

为了持续监控默认命名空间中的所有部署，我们可以创建一个 Bash 脚本：

#!/bin/bash

while true; do
    sleep 60
    deployments=$(kubectl get deployments --no-headers -o custom-columns=":metadata.name" | grep -v "deployment-checker")
    echo "====== $(date) ======"
    for deployment in ${deployments}; do
        if ! kubectl rollout status deployment ${deployment} --timeout=10s 1>/dev/null 2>&1; then
            echo "Error: ${deployment} - rolling back!"
            kubectl rollout undo deployment ${deployment}
        else
            echo "Ok: ${deployment}"
        fi
    done
done

我们希望能够在Pod内部运行该脚本，因此我将其转换为ConfigMap，这将使我们能够将该脚本挂载到卷中（参见：在Pod中将ConfigMaps用作文件）。

$ cat check-script-configmap.yml
apiVersion: v1
kind: ConfigMap
metadata:
  name: check-script
data:
  checkScript.sh: |
    #!/bin/bash

    while true; do
        sleep 60
        deployments=$(kubectl get deployments --no-headers -o custom-columns=":metadata.name" | grep -v "deployment-checker")
        echo "====== $(date) ======"
        for deployment in ${deployments}; do
            if ! kubectl rollout status deployment ${deployment} --timeout=10s 1>/dev/null 2>&1; then
                echo "Error: ${deployment} - rolling back!"
                kubectl rollout undo deployment ${deployment}
            else
                echo "Ok: ${deployment}"
            fi
        done
    done        

$ kubectl apply -f check-script-configmap.yml
configmap/check-script created

我创建了一个单独的 deployment-checker ServiceAccount，并分配了 edit Role，我们的 Pod 将在此 ServiceAccount 下运行：
注意：我创建了一个 Deployment 而不是单个 Pod。

$ cat all-in-one.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployment-checker
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: deployment-checker-binding
subjects:
  - kind: ServiceAccount
    name: deployment-checker
    namespace: default
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: deployment-checker
  name: deployment-checker
spec:
  selector:
    matchLabels:
      app: deployment-checker
  template:
    metadata:
      labels:
        app: deployment-checker
    spec:
      serviceAccountName: deployment-checker
      volumes:
        - name: check-script
          configMap:
            name: check-script
      containers:
      - image: bitnami/kubectl
        name: test
        command: ["bash", "/mnt/checkScript.sh"]
        volumeMounts:
        - name: check-script
          mountPath: /mnt
      
      

应用上述清单后，deployment-checker 部署将被创建并开始监控 default 命名空间中的部署资源。

$ kubectl apply -f all-in-one.yaml
serviceaccount/deployment-checker created
clusterrolebinding.rbac.authorization.k8s.io/deployment-checker-binding created
deployment.apps/deployment-checker created

$ kubectl get deploy,pod | grep "deployment-checker"
deployment.apps/deployment-checker   1/1     1            
pod/deployment-checker-69c8896676-pqg9h   1/1     Running   

最后，我们可以检查它的运作方式。我创建了三个部署 (app-1, app-2, app-3)：

$ kubectl create deploy app-1 --image=nginx
deployment.apps/app-1 created

$ kubectl create deploy app-2 --image=nginx
deployment.apps/app-2 created

$ kubectl create deploy app-3 --image=nginx
deployment.apps/app-3 created

然后，我将app-1的图像更改为不正确的图像（nnnginx）：

$ kubectl set image deployment/app-1 nginx=nnnginx
deployment.apps/app-1 image updated

在deployment-checker日志中，我们可以看到app-1已经回滚到了先前的版本：

$ kubectl logs -f  deployment-checker-69c8896676-pqg9h
...
====== Thu Oct  7 09:20:15 UTC 2021 ======
Ok: app-1
Ok: app-2
Ok: app-3
====== Thu Oct  7 09:21:16 UTC 2021 ======
Error: app-1 - rolling back!
deployment.apps/app-1 rolled back
Ok: app-2
Ok: app-3

- matt_j

---

太棒了，非常感谢！ - Niels Uitterdijk

非常感谢您！我想在一些部署中使用不同的超时值。我对bash很不熟悉，你能帮忙吗？ - Noa Be

Answer 2

我偶然发现了 Argo Rollout，它解决了这个非自动回滚以及其他与部署相关的问题。

https://argoproj.github.io/argo-rollouts/

- Luc