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 调用。通信路径如下:

  1. 认证与授权:读取 kubeconfig 中的集群 CA、客户端证书/,通过 API Server 的 TLS 握手和 RBAC 鉴权。
  2. 资源操作:使用 client-go 的 DynamicClient 或 TypedClient 对 Deployment、Service、ConfigMap 等资源执行 Create/Update/Delete/Get。
  3. Release 持久化:通过 client-go 的 Secrets API 将 Release 对象序列化为 JSON 存入 Secret 的 data 字段。
  4. Watch 与状态反馈:安装/升级后,Helm 通过 watch 机制等待资源达到 Ready 状态,超时则标记为 Failed。
通信模型要点:Helm 不直接操作 etcd,所有读写都经过 API Server 的 admission webhook、RBAC 和资源配额校验。这意味着 Helm 的操作完全受集群现有安全策略约束。
Helm v3 架构与通信模型 Helm CLI helm install / upgrade Helm SDK Chart 解析 模板渲染 Release 状态机 client-go REST / Watch K8s API Server TLS / RBAC / Admission etcd 集群状态 Secret (Release) Release 持久化 说明: Helm v3 移除 Tiller,CLI 直接通过 client-go 调用 API Server Release 记录以 Secret 形式存储在目标命名空间

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 需要 create Deployment、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 通信。整个架构轻量、安全、可审计,是云原生应用交付的基础设施。