2. Helm 安装与配置:客户端、Tiller 架构对比与仓库管理

本章聚焦 Helm 的安装与核心配置,涵盖 Helm 客户端安装、Helm v2 与 v3 的架构差异(特别是 Tiller 组件的去留),以及 Chart 仓库的配置与管理。掌握这些基础操作是后续进行 Chart 参数化与多环境部署的前提。

2.1 Helm 客户端安装

Helm 客户端是一个命令行工具,负责在本地管理 Chart、与 Kubernetes API 交互。支持主流操作系统,安装方式灵活。

安装方式对比

操作系统 推荐方式 命令/步骤
macOS Homebrew brew install helm
Linux (Debian/Ubuntu) APT + 官方 GPG 密钥
curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
sudo apt-get install apt-transport-https --yes
echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm
Linux (CentOS/RHEL) YUM + 官方仓库
sudo yum install -y https://mirror.go-repo.io/centos/go-repo-release-1.el7.noarch.rpm
sudo yum install helm
Windows Chocolatey choco install kubernetes-helm
通用(二进制) 下载 Release 包
wget https://get.helm.sh/helm-v3.14.0-linux-amd64.tar.gz
tar -zxvf helm-v3.14.0-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm
验证安装: 执行 helm version 确认客户端版本。Helm v3 输出示例:version.BuildInfo{Version:"v3.14.0", …}。

2.2 Helm v2 与 v3 架构对比:Tiller 的去留

Helm v2 与 v3 最核心的差异在于 Tiller 组件的存在与否。Tiller 是 Helm v2 的服务端组件,运行在集群内部,负责接收客户端请求并执行 Chart 安装、升级等操作。Helm v3 彻底移除了 Tiller,采用无服务器端架构,直接通过 Kubernetes 的 ConfigMap 或 Secret 存储 Release 信息。

架构演进核心: v2 的 Tiller 带来了 RBAC 权限管理复杂、多租户隔离困难、安全风险(Tiller 拥有集群级权限)等问题。v3 移除 Tiller 后,客户端直接使用当前 kubeconfig 的权限与 API Server 交互,权限模型更清晰、更安全。
Helm v2 与 v3 架构对比 Helm v2 架构(含 Tiller) Helm 客户端 (CLI) Tiller (服务端) Kubernetes API ⚠️ Tiller 拥有集群级权限 RBAC 配置复杂,安全风险高 Release 信息存储在 ConfigMap 中 Helm v3 架构(无 Tiller) Helm 客户端 (CLI) Kubernetes API ✅ 无 Tiller,客户端直接调用 API 权限继承自 kubeconfig Release 信息存储在 Secret 中(默认)

关键差异对比表

对比维度 Helm v2 Helm v3
服务端组件 Tiller(需安装在集群内) 无(客户端直连 API Server)
权限模型 Tiller 使用 ServiceAccount,权限管理复杂 继承 kubeconfig 中的用户/角色权限
Release 存储 ConfigMap(默认命名空间) Secret(默认命名空间,可配置)
安全风险 Tiller 常被赋予 cluster-admin,风险较高 无集群级特权组件,风险降低
多租户支持 困难,Tiller 实例难以隔离 原生支持,每个用户/命名空间独立操作
升级策略 需升级 Tiller 和客户端 仅升级客户端,更简单
生产环境建议: 新项目直接使用 Helm v3。若需从 v2 迁移,可使用 helm 2to3 插件进行转换,但务必先在测试环境验证。

2.3 Helm 仓库配置与管理

Helm 仓库(Repository)是存储和共享 Chart 包的 HTTP 服务器。通过配置仓库,可以方便地搜索、安装和更新第三方 Chart。

2.3.1 添加与查看仓库

使用 helm repo add 命令添加仓库,helm repo list 查看已配置的仓库列表。

# 添加官方稳定仓库(Bitnami 是常用社区仓库)
helm repo add bitnami https://charts.bitnami.com/bitnami

# 添加官方 Helm 稳定仓库(已归档,但仍有参考价值)
helm repo add stable https://charts.helm.sh/stable

# 查看所有已添加的仓库
helm repo list

2.3.2 搜索 Chart

添加仓库后,使用 helm search repo 搜索仓库中的 Chart。

# 搜索所有仓库中包含 "nginx" 的 Chart
helm search repo nginx

# 搜索特定仓库中的 Chart
helm search repo bitnami/nginx

2.3.3 更新与删除仓库

定期更新仓库索引以获取最新 Chart 版本。删除不再使用的仓库。

# 更新所有已添加仓库的本地索引
helm repo update

# 删除指定仓库
helm repo remove stable

2.3.4 搭建私有 Chart 仓库

企业环境中常需搭建私有仓库存储内部 Chart。常见方案包括:

  • ChartMuseum: 开源、轻量级,支持 REST API 和本地文件存储。
  • Harbor: 企业级镜像仓库,内置 Chart 仓库功能,支持 RBAC 和漏洞扫描。
  • MinIO + S3 协议: 使用对象存储作为后端,配合 helm s3 插件。
私有 Chart 仓库架构 开发者 ChartMuseum Kubernetes 集群 存储后端 (本地/S3/MinIO)

仓库管理常用命令速查

命令 说明 示例
helm repo add 添加 Chart 仓库 helm repo add myrepo http://myrepo.example.com
helm repo list 列出所有已配置仓库 helm repo list
helm repo update 更新仓库本地索引 helm repo update
helm repo remove 删除指定仓库 helm repo remove myrepo
helm search repo 在仓库中搜索 Chart helm search repo myrepo/wordpress
最佳实践: 为每个环境(dev/staging/prod)配置独立的仓库或仓库路径,避免 Chart 版本混乱。使用 helm repo index 命令可为本地目录生成索引文件,便于搭建简易仓库。