1. Helm 架构总览:Tiller 移除、SDK 与通信模型
Helm v3 是云原生生态中事实上的包管理标准,其架构相比 v2 做了根本性简化。本章从组件构成、SDK 分层以及客户端与 Kubernetes API Server 的通信路径三个维度,建立 Helm 控制平面的整体认知。
1.1 Helm v3 核心组件
Helm v3 移除了服务端组件 Tiller,所有操作由客户端直接与 Kubernetes API Server 交互完成。这一变化消除了 v2 中 Tiller 的 RBAC 权限扩散、多租户隔离困难以及升级回滚状态不一致等痛点。
| 组件 | 角色 | 说明 |
|---|---|---|
| Helm CLI | 用户交互入口 | 解析命令、加载 Chart、调用 SDK 执行安装/升级/回滚/删除 |
| Helm SDK | 核心逻辑层 | Chart 解析、模板渲染、Release 状态机、存储后端抽象 |
| Kubernetes API Server | 集群控制面入口 | 接收 Helm 提交的 manifest,完成资源创建/更新/删除 |
| Secrets/ConfigMaps | Release 存储后端 | Helm v3 默认将 Release 记录以 Secret 形式保存在目标命名空间 |
关键变化:Helm v3 不再需要
helm init 安装服务端组件,CLI 直接使用 kubeconfig 中的凭据与 API Server 通信,权限模型完全继承 Kubernetes RBAC。
1.2 Helm SDK 分层架构
Helm SDK 是 CLI 背后的引擎,分为三个逻辑层:
- Chart 层:负责 Chart 包的加载、依赖解析、Schema 校验。核心接口为
chart.Chart和chart.Requirements。 - 模板引擎层:基于 Go
text/template扩展,提供include、required、lookup等函数,将 values.yaml 与模板合并生成最终 manifest。 - Release 管理层:维护 Release 状态机(PendingInstall → Deployed → Failed → Uninstalled),通过
storage接口读写 Release 记录。
// Helm SDK 核心调用链(伪代码)
chart, _ := loader.Load("mychart-0.1.0.tgz")
values, _ := chartutil.CoalesceValues(chart.Values, userValues)
manifest, _ := engine.Render(chart, values)
release, _ := installer.Run(chart, manifest)
storage.Create(release) // 写入 Secret
1.3 Helm 客户端与 API Server 通信模型
Helm 不维护独立的长连接或 gRPC 通道,所有通信基于 Kubernetes 客户端库 client-go 的 RESTful 调用。通信路径如下:
- 认证与授权:读取 kubeconfig 中的集群 CA、客户端证书/,通过 API Server 的 TLS 握手和 RBAC 鉴权。
- 资源操作:使用
client-go的DynamicClient或TypedClient对 Deployment、Service、ConfigMap 等资源执行 Create/Update/Delete/Get。 - Release 持久化:通过
client-go的 Secrets API 将 Release 对象序列化为 JSON 存入 Secret 的data字段。 - Watch 与状态反馈:安装/升级后,Helm 通过
watch机制等待资源达到 Ready 状态,超时则标记为 Failed。
通信模型要点:Helm 不直接操作 etcd,所有读写都经过 API Server 的 admission webhook、RBAC 和资源配额校验。这意味着 Helm 的操作完全受集群现有安全策略约束。
1.4 Release 存储后端设计
Helm v3 默认使用 Secret 作为 Release 存储后端,每个 Release 对应一个 Secret 对象,命名格式为 sh.helm.release.v1.<release-name>.v<version>。存储结构如下:
| 字段 | 类型 | 内容 |
|---|---|---|
data.release |
Base64 编码 | Protobuf 序列化的 Release 对象(含 Chart、Values、Manifest、状态) |
metadata.labels |
map[string]string | 包含 name、owner、status、version 等索引标签 |
metadata.annotations |
map[string]string | 可选的用户自定义注解 |
注意:Secret 默认不开启 etcd 加密,Release 中的敏感 values(如数据库密码)会以明文存储在 etcd 中。生产环境应启用 etcd 加密或使用
helm-secrets 插件对 values 加密。
1.5 通信安全与权限模型
Helm 客户端与 API Server 的通信安全完全依赖 Kubernetes 自身的认证与授权机制:
- TLS 双向认证:kubeconfig 中的
client-certificate和client-key用于客户端身份验证。 - RBAC 授权:Helm 操作需要对应命名空间的资源操作权限,例如安装 Chart 需要
createDeployment、Service 等资源的权限。 - ServiceAccount 映射:在 CI/CD 场景中,Helm 通常使用 ServiceAccount 的 进行认证,权限通过 RoleBinding 或 ClusterRoleBinding 授予。
# 最小 RBAC 权限示例:允许 Helm 在 default 命名空间安装/升级
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: helm-installer
rules:
- apiGroups: ["apps", ""]
resources: ["deployments", "services", "configmaps", "secrets"]
verbs: ["get", "list", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: default
name: helm-installer-binding
subjects:
- kind: ServiceAccount
name: helm-sa
namespace: default
roleRef:
kind: Role
name: helm-installer
apiGroup: rbac.authorization.k8s.io
架构总结:Helm v3 通过移除 Tiller 将安全边界收敛到 Kubernetes RBAC 体系内,SDK 层负责 Chart 处理和 Release 状态管理,client-go 层完成与 API Server 的 RESTful 通信。整个架构轻量、安全、可审计,是云原生应用交付的基础设施。