3. 资源模型详解：Release 对象在 Kubernetes 中的存储机制

Release 对象在 Kubernetes 中的命名格式为：sh.helm.release.v1.<release-name>.v<revision>。每个 Release 的每个 Revision 对应一个独立的 Secret 或 ConfigMap 资源。

# 查看指定 Release 的所有 Revision 对应的 Secret
kubectl get secret -n <namespace> | grep "sh.helm.release.v1.<release-name>"

# 示例输出
sh.helm.release.v1.my-app.v1   Opaque   1   10d
sh.helm.release.v1.my-app.v2   Opaque   1   5d
sh.helm.release.v1.my-app.v3   Opaque   1   1d

3.2 Revision 版本管理原理

Helm 的 Revision 机制是版本控制和回滚的基础。每次执行 helm upgrade、helm install 或 helm rollback 操作，都会生成一个新的 Revision。

3.2.1 Revision 的生命周期

1. 创建（Install）：首次安装时生成 Revision 1。
2. 更新（Upgrade）：每次 helm upgrade 递增 Revision 号（如 v1 → v2）。
3. 回滚（Rollback）：执行 helm rollback 时，会基于目标 Revision 生成一个新的 Revision（如从 v3 回滚到 v1，实际生成 v4，其内容与 v1 相同）。
4. 删除（Uninstall）：删除 Release 时，默认保留历史 Revision 的 Secret（可通过 --keep-history 控制）。

3.2.2 Revision 存储结构

每个 Revision 的 Secret 中存储了完整的 Release 对象，包括 Chart 模板渲染后的所有 Kubernetes 资源清单（Manifest）、Values 值、Chart 元数据等。其数据结构如下：

# 查看某个 Revision 的 Secret 内容（Base64 解码后）
kubectl get secret sh.helm.release.v1.my-app.v1 -n <namespace> -o jsonpath='{.data.release}' | base64 -d | base64 -d | gunzip

# 解码后的 JSON 结构（简化）
{
  "name": "my-app",
  "info": {
    "status": "deployed",
    "first_deployed": "2024-01-01T00:00:00Z",
    "last_deployed": "2024-01-10T00:00:00Z",
    "deleted": ""
  },
  "chart": {
    "metadata": { ... },
    "templates": [ ... ],
    "values": { ... }
  },
  "config": { ... },
  "manifest": "---\napiVersion: v1\nkind: Service\n...",
  "version": 1,
  "namespace": "default"
}

3.3 Rollback 回滚的底层实现

Helm 的 Rollback 操作并非简单地“切换”到历史 Revision，而是通过创建一个新的 Revision 来“重现”历史状态。这种设计保证了 Revision 历史的完整性和可追溯性。

3.3.1 Rollback 执行流程

1. 读取目标 Revision：Helm 从 Kubernetes 中读取指定 Revision 的 Secret（如 v1）。
2. 生成新 Revision：基于目标 Revision 的 Manifest 和 Values，生成一个新的 Release 对象，Revision 号为当前最大 Revision + 1（如 v4）。
3. 应用 Manifest：将新 Revision 中的 Manifest 应用到 Kubernetes 集群（等同于执行 kubectl apply）。
4. 更新状态：将新 Revision 的 Secret 写入集群，并将旧 Revision（如 v3）的状态标记为 superseded。

3.3.2 Rollback 与 Upgrade 的本质区别

3.4 存储机制与故障排查的关联

理解 Release 对象的存储机制对于故障排查至关重要。以下是一些常见场景：

• Secret 损坏或丢失：如果某个 Revision 的 Secret 被意外删除，将无法回滚到该版本。建议启用 --history-max 限制历史 Revision 数量，避免 Secret 过多。
• 存储后端切换：从 ConfigMaps 切换到 Secrets（或反之）时，Helm 不会自动迁移已有 Release 对象。需要手动处理或使用 helm migrate 工具。
• etcd 存储压力：大量历史 Revision 会占用 etcd 存储空间。建议根据实际需求设置 --history-max（默认 10）。

# 设置最大历史 Revision 数量为 5
helm upgrade my-app ./chart --history-max 5

# 查看当前 Release 的历史 Revision 数量
helm history my-app -n <namespace>