Kubernetes 中的 Helm 回滚行为：管道状态混乱

Question

问题描述： 使用 Helm 将更改部署到 Kubernetes 集群时，会实施安全机制。如果 pod 遇到持续 300 秒的崩溃循环，Helm 会触发自动回滚到之前的部署版本。虽然这种回滚机制旨在维护系统稳定性，但在某些情况下可能会带来混乱。

这个命令：

helm 升级 --install -f value.yaml 。 --atomic --超时 300s

当成功回滚后，后续部署尝试遇到问题并失败时，就会出现问题。在这种情况下，尽管 Helm 由于部署失败而执行了回滚，但 CI/CD 管道仍可能被标记为成功。此行为可能会导致用户和利益相关者感到困惑，因为他们可能不会立即意识到由于部署失败而发生了回滚。

本期的目标是讨论和探索 Helm 回滚报告和管道状态处理的潜在改进，以确保在传达部署结果时更加清晰和准确。这将帮助用户快速准确地识别何时触发回滚以及整体部署是否成功。

建议的解决方案：

1. 增强 Helm 的报告功能，以便在因部署失败而启动回滚时进行显式通信。
2. 实施一种机制，根据回滚和后续部署尝试的结果来更新 CI/CD 管道状态。
3. 向用户和利益相关者提供有关状态更改的信息通知，确保他们及时获悉任何回滚和部署失败。

这一改进将带来更加透明和用户友好的部署流程，减少混乱并促进更好的事件管理。

本期的目标是讨论和探索 Helm 回滚报告和管道状态处理的潜在改进，以确保在传达部署结果时更加清晰和准确。这将帮助用户快速准确地识别何时触发回滚以及整体部署是否成功。

如果我们可以处理这个用例，请提出任何方法

Answer 1

我观察到，当我们在 Kubernetes 集群中使用 Helm 部署对应用程序的更改时，存在一种安全机制。如果 Pod 连续 300 秒进入崩溃循环，则会触发自动回滚到之前的版本。

helm upgrade --install -f values.yaml <release-name> . --atomic --timeout 300s

但是，重要的是要注意，有时即使在成功回滚之后，如果后续部署尝试失败，管道仍可能被标记为成功。这可能会让用户感到困惑，因为他们可能不会立即意识到 Helm 由于部署失败而执行了回滚。

所以我使用自定义脚本来解决和处理上述问题

   helm upgrade --install -f values.yaml {{Release_name}} . --wait --timeout {{timeout}}
      #Get Status code
      helm_upgrade_exit_status=$?
      echo 'Helm release failed with EXIT_CODE: '$helm_upgrade_exit_status''
      # Check the Helm upgrade/install status
      if [ $helm_upgrade_exit_status -eq 0 ]; then
        echo "Helm upgrade/install successful...."
      else
        #If helm release failed than rollback
        echo "Helm upgrade/install failed. Rolling back pervious version..."
        
        # Perform the Helm rollback
        helm  rollback {{Release_name}}  0 --wait --timeout {{timeout}}
        if [ $? -eq 0 ]; then
          echo "Helm rollback completed..."
          echo "Action Required: Check your deployment  on k8s cluster why it Rollbacked"         
          # Exit with a non-zero status code to indicate pipeline failure
          exit 1
        else
          echo "Helm Rollback also failed ..."
          exit 1
        fi
      fi