4. Helm 安装策略：关键参数详解

在生产环境中使用 helm install 部署应用时，默认的“静默安装”模式往往隐藏着巨大的风险——Pod 启动失败、依赖服务未就绪、超时无响应，最终导致集群资源浪费甚至服务中断。Helm 提供了一组关键安装参数，用于构建可观测、可回滚、可超时控制的部署策略。本章将深入剖析 --atomic、--timeout、--wait、--create-namespace 等参数的行为机制与最佳实践。

4.1 参数全景图

下表列出了 Helm install 中最常用的策略参数及其核心作用：

4.2 --wait：从“提交即完成”到“就绪才算完成”

默认情况下，helm install 在将资源清单提交给 Kubernetes API Server 后立即返回成功，不关心 Pod 是否真正启动。这会导致流水线误判部署状态。

--wait 参数改变了这一行为：Helm 会持续轮询资源状态，直到满足以下条件才返回成功：

• Deployment / StatefulSet： 所有 Pod 的 Ready 副本数达到期望值。
• Service： 关联的 Endpoint 至少有一个可用。
• Ingress： 关联的 Service 已就绪。
• Job： 成功完成。
• PVC： 绑定到 PV。

4.3 --timeout：防止无限等待的“安全阀”

当启用 --wait 后，如果 Pod 因镜像拉取失败、资源不足、配置错误等原因无法就绪，Helm 会一直阻塞。默认超时时间为 5 分钟，对于大型应用或冷启动场景可能不够。

--timeout 参数允许你设置一个合理的等待上限：

# 设置超时时间为 10 分钟
helm install my-app ./my-chart --wait --timeout 10m

# 超时后，Helm 会返回错误并退出
# 如果同时使用了 --atomic，则会触发自动回滚

超时值格式： 支持 30s、5m、1h 等人类可读格式。建议根据应用启动时间设置：

• 轻量应用： 2-3 分钟
• 中等应用： 5-8 分钟
• 大型应用（含数据库迁移）： 10-15 分钟

4.4 --atomic：失败自动回滚的“保险丝”

--atomic 是生产部署的核心参数。它结合了 --wait 的行为，并增加了失败自动回滚机制：

1. Helm 执行安装并等待资源就绪（等同于 --wait）。
2. 如果等待超时或资源创建失败，Helm 自动执行 helm rollback 到上一个版本。
3. 回滚完成后，删除本次安装创建的新 Release 记录。

# 生产部署推荐命令
helm install production-app ./app-chart \
  --atomic \
  --wait \
  --timeout 10m \
  --namespace production \
  --create-namespace

4.5 --create-namespace：Namespace 的自动管理

在 Kubernetes 中，如果目标 Namespace 不存在，helm install 会直接报错。传统做法是手动 kubectl create namespace 或使用 Helm 的 --namespace 配合预创建脚本。

--create-namespace 参数让 Helm 在安装前自动创建 Namespace（如果不存在）：

• 自动创建 Namespace，无需额外命令。
• 如果 Namespace 已存在，则直接使用，不会报错。
• 配合 --atomic 使用时，如果部署失败并回滚，不会删除 Namespace（避免影响其他资源）。

4.6 参数组合策略与 SVG 流程图

下图展示了不同参数组合下的部署决策流程：

4.7 实战：生产级部署命令模板

以下是一个面向生产环境的 Helm 安装命令模板，整合了所有关键参数：

helm install ${RELEASE_NAME} ${CHART_PATH} \
  --namespace ${NAMESPACE} \
  --create-namespace \
  --atomic \
  --wait \
  --timeout 10m \
  --cleanup-on-fail \
  --values prod-values.yaml \
  --set image.tag=${IMAGE_TAG}

4.8 常见陷阱与避坑指南