Helm 企业发布与恢复

场景：平台团队将第三方组件交付到预生产/生产，业务团队复用同一 Chart，环境差异仅在 values。前置：企业演练基线。本文命令以 Helm 3 为基准；Helm 4 的失败恢复参数应查对应 CLI，不直接混用。

关键点#

• Chart version、appVersion、镜像 digest 是三件事；依赖用 Chart.lock 固定，CI 用 dependency build，不在生产随意 update。
• release 的 namespace 与应用资源 namespace 必须明确；拥有 Secret 读取权限可能读取 release 中的敏感 values。
• --atomic 能恢复部分 Kubernetes 发布状态，不能撤销数据库迁移、外部 API 副作用或 CRD schema 改动。
• crds/ 的生命周期与普通模板不同；建立平台 CRD 升级步骤，不靠应用 rollback 猜测恢复。

依据：发布与恢复、CRD 管理。

Hands-on：交付现有业务 Chart#

仓库约定：charts/orders/ 是团队已经开发、包含 Deployment/Service/PDB/probes/resources 的业务 Chart；values schema 拒绝空镜像、错误资源单位。API/worker 的数据库变更必须 expand→migrate→contract，旧版本仍能运行。

charts/orders/{Chart.yaml,Chart.lock,values.yaml,values.schema.json,templates/}
environments/staging/orders.yaml
environments/production/orders.yaml
evidence/<change-id>/

CI 执行（以下不包含数据库迁移）：

helm version
helm dependency build charts/orders
helm lint charts/orders --strict -f environments/staging/orders.yaml
umask 077
helm template orders charts/orders --namespace orders -f environments/staging/orders.yaml > rendered.yaml
# 先安装平台提供的 CRD，再做服务器校验。避免将渲染的 Secret 写入公开日志。
kubectl apply --dry-run=server -f rendered.yaml
helm package charts/orders --destination dist

检查渲染结果：RBAC 不越权、镜像固定 digest、没有公开管理端口、PDB 与 topologySpread 合理；使用组织的准入/签名策略检查制品。推送至已有私有 OCI registry：

export CHART_PACKAGE='dist/orders-REPLACE_VERSION.tgz'
export CHART_REGISTRY='registry.example.com/platform/charts'
# 使用 CI 短期登录凭据；先按仓库方式完成 helm registry login。
helm push "$CHART_PACKAGE" "oci://$CHART_REGISTRY"

由发布身份执行；初始发布不允许应用 chart 自行创建集群管理员角色：

export CHART_VERSION='REPLACE_VERSION'
helm upgrade --install orders "oci://$CHART_REGISTRY/orders" --version "$CHART_VERSION" --namespace orders -f environments/staging/orders.yaml --atomic --wait --wait-for-jobs --timeout 15m --history-max 10
helm status orders -n orders
helm history orders -n orders
kubectl -n orders rollout status deployment/orders-api --timeout=10m

安装成功后执行基线的完整订单链路与负载；避免带业务写入副作用的 Helm test Hook 自动重跑。Hook 需幂等、限时且有清理策略，不能把数据库 destructive migration 藏在 pre-upgrade 中。

故障、恢复与生产推广#

1. 在 staging 发布一个明确不接流的 readiness 错误配置，验证发布超时后旧副本继续服务；检查 Helm 状态和资源是否真的恢复。
2. 修正配置重新发布，再验证升级期间成功率；单独演练一次手动恢复到实际存在的历史 revision：

export GOOD_REVISION='REPLACE_HISTORY_REVISION'
helm rollback orders "$GOOD_REVISION" -n orders --wait --timeout 15m
kubectl -n orders rollout status deployment/orders-api --timeout=10m

3. 业务数据已迁移或产生新写入时，先确认旧应用兼容；不能因为 Helm rollback 成功就宣称数据库恢复。
4. 生产用相同 Chart 制品和审阅过的 production values，先试点后扩大。启用 Argo CD/Flux 后，从 Git 恢复版本，停止手工改 release。

交付物：Chart/锁文件/schema、完整 values、兼容矩阵、渲染审计、升级和恢复证据。卸载前盘点 PVC、CRD、Hook、云 LB；不要用 helm uninstall 代替数据下线流程。

可直接运行的配套工程#

没有 charts/orders 时，直接使用 订单参考工程 附带的完整 Chart、schema 与可构建业务；本文发布流程可复用。