安装 Helm 与仓库
这一课你将能做到
- 在本机装好 Helm 3 CLI，用
helm version 确认客户端版本（确认无 Tiller 这一 Helm 2 遗留概念）
- 执行
helm repo add / update / search / show / pull，从公共仓库拉出一份默认 values 草稿
- 在学习集群（minikube/kind）试装再卸载一个 demo Chart，并说明为什么生产应用 values 文件进 Git 而不是长串
--set
为什么要学
有了「Chart/Release」的概念图像还不够：你得会 发现 别人写好的 Chart（ingress-nginx、Bitnami 的 Redis/MySQL），也会把自己写的 Chart 装进集群。Helm 3 没有 Tiller——CLI 直连 Kubernetes API，权限边界就是你的 kubectl 身份，这意味着「连错集群」的后果和 kubectl 一样真实。装错仓库、乱用 --set、分不清 Chart version 与 appVersion，会在后面的 upgrade 和 GitOps 课里连环踩坑。本课把 CLI、仓库、试装三条腿钉牢，全程命令真实可运行。
先建立图像
你的笔记本
helm CLI ──kubeconfig──► API Server（与 kubectl 共用同一套身份）
│
├─ helm repo add/update/list ← 管理 Chart 源
├─ helm search repo/hub ← 在源里发现 Chart
├─ helm show chart/values ← 读元数据与默认配置
├─ helm pull ← 下载 Chart 包
└─ helm install/uninstall ← 创建/删除 Release
| 命令族 | 人话 | 典型用途 |
|---|
repo | 管 Chart 源（增删、刷新索引） | 接入 Bitnami、自建源 |
search | 在已添加源/Artifact Hub 里找包 | search repo redis |
show | 看包说明书 | 元数据、默认 values |
pull | 把 Chart 下载到本地 | 离线审阅、归档 |
install/uninstall | 装/卸 Release | 学习集群试装 |
list | 看当前命名空间的 Release | 清理 demo |
Chart.yaml 里两个版本号：
version: 1.2.3 ← Chart 包自身版本（SemVer，发版必须递增）
appVersion: "8.0" ← 所装应用软件的版本提示（不必严格 SemVer）
跟着做
步骤 1：安装 CLI 并确认版本
按你的操作系统任选其一（以官方安装页为准）：
# Windows：winget install Helm.Helm 或 choco install kubernetes-helm
# macOS：brew install helm
# Linux：官方脚本一行安装
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# 全平台通用：直接下载二进制
# https://helm.sh/docs/intro/install/
应看到 version.BuildInfo{Version:"v3.x.x", ...}，只有 Client 字段、没有 Server/Tiller——Tiller 是 Helm 2 的旧模型，见到「先装 Tiller」的教程请直接丢弃。
步骤 2：确认 kubectl 指向学习集群
kubectl config current-context
kubectl get nodes
应能列出节点。Helm 与 kubectl 共用 kubeconfig，current-context 指哪它连哪。养成肌肉记忆：任何 helm install 之前先看一眼 context。学习请用 minikube/kind/专用沙箱，严禁对生产执行本课示范操作。
步骤 3：添加仓库并搜索
# 添加 Bitnami（最常见的公共 Chart 源之一）
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
# 在本地索引中搜索
helm search repo nginx
helm search repo redis
输出会列出 NAME、CHART VERSION、APP VERSION。注意两点：search repo 搜的是 你已 add 的源的本地索引，不是全网；发现新包可以用 helm search hub <关键词> 查 Artifact Hub，再决定是否 add。索引会过期，装之前习惯性 repo update。
步骤 4：导出默认 values 并审阅
helm show chart bitnami/redis # 看元数据与说明
helm show values bitnami/redis > redis-values-default.yaml
打开导出的文件，找 architecture、replica.replicaCount、auth.enabled 这类键。你会直观感受到：默认 values 几百行，生产不可能靠手敲二十个 --set，正确姿势是 复制一份、只改差异、放进 Git 评审。
步骤 5：学习集群试装再卸载
# 仅学习环境！
helm install my-redis bitnami/redis \
--set auth.enabled=false \
--set replica.replicaCount=0
helm list
helm list -A # 看所有命名空间
kubectl get pods -l app.kubernetes.io/instance=my-redis
# 观察 NOTES 输出：Helm 会打印连接提示
# 用完即删，保持环境干净
helm uninstall my-redis
应看到 install 后 Release 出现在 helm list，Pod 标签带 app.kubernetes.io/instance=my-redis；uninstall 后列表清空。体验一下 NOTES.txt——它是 Chart 作者留给用户的「装完之后怎么办」说明书。
步骤 6：分清两个版本号
helm show chart bitnami/redis | grep -iE "version|appVersion"
# Windows PowerShell: helm show chart bitnami/redis | Select-String -Pattern "version"
笔记写死：「升级 Chart 包装看 version；关心应用软件代际看 appVersion。二者经常不同步，以 Chart 的变更说明为准。」这个区分在后面读 Argo CD 界面、读镜像更新公告时都会用到。
讲清楚要点
- 因为 Helm 3 无 Tiller，所以装 Chart 的权限 = 你的 kubeconfig 能改哪些资源——RBAC 拒绝时，
helm install 与 kubectl apply 的报错一模一样，排障思路也一致。
- 因为公共 Chart 来自 repo 索引，所以先
repo add 再 search，并定期 repo update——过期索引会找到已被撤下或带漏洞的旧版本。
- 因为默认 values 很长，所以用
helm show values 导出再改，而不是背参数——差异文件可以进 Git、可以评审、可以复现，这正是后面 GitOps 的原料。
- 因为
--set 适合临时试验，不适合作为生产真相源，所以正式环境用 -f values.yaml——--set 会散落在 shell 历史和 CI 日志里，且复杂类型（列表、嵌套）表达力差。
- 因为 Chart
version 与 appVersion 职责不同，所以排障先问「包版本还是应用版本」——「升了 Chart 但应用没变」或「应用变了但 Chart 没重新打包」都是这里混淆出来的。
- 因为试装会在集群留下资源，所以学完必须
helm uninstall 或清理专用命名空间——残留的 Release 会让后面的课出现「幽灵资源」干扰判断。
你可能会懵的地方
-
helm search hub 和 search repo 有什么区别？
search repo 查本地已添加仓库的索引（离线可用）；search hub 查 Artifact Hub 在线索引（需网络）。日常团队内源用 repo；发现新包先 hub 再决定 add。
-
为什么官方强调不要把生产密钥塞进 --set？
--set 会进 shell 历史与 CI 日志，泄漏面大；values 文件若进 Git 也不能明文密钥。正确路径：K8s Secret / Sealed Secrets / External Secrets，values 里只写 Secret 的 名字。
-
装 Helm 需要装「服务端」吗？
不需要。Helm 3 的「服务端」就是 Kubernetes API 本身；GitOps 场景下是 Argo/Flux 在集群内调用 Helm 渲染逻辑，同样不是 Tiller。见到「helm init」的资料一律视为 Helm 2 过时内容。
-
Bitnami 仓库是官方唯一的源吗？
否。还有 ingress-nginx、prometheus-community、grafana、各云厂商以及自建 HTTP/OCI 仓库（helm push 到 Harbor/ACR 已是主流）。选型看维护活跃度、values 文档质量、安全公告响应速度。
-
helm pull 和 helm install <repo>/<chart> 有何不同？
pull 只下载（可 --untar 解包），用于审阅与归档；install 是渲染并创建 Release。审第三方 Chart 的模板代码是良好习惯——你要知道它装了什么资源。
错法对照
| 错法 | 问题 | 正解 |
|---|
未 repo update 就安装旧 Chart | 踩已知漏洞或弃用 API | 安装前 update，values 里钉住版本 |
生产用一长串 --set a=1,b=2,... | 不可评审、难复现 | -f values-prod.yaml 进 Git |
| kubeconfig 指向生产却跑 demo install | 污染生产环境 | 先 current-context，用学习集群 |
| 分不清 Chart version / appVersion | 升错包或误以为应用已升级 | helm show chart 对照变更说明 |
| 试装后不 uninstall | 残留 Service/PVC 占资源 | 学完卸载或删专用命名空间 |
网上抄的 helm init / Tiller 教程 | Helm 2 过时命令直接报错 | 认准 Helm 3 文档 |
卡点急救
- 现象：
helm: command not found——安装后 PATH 未刷新：重开终端；Windows 检查环境变量 Path 是否包含 Helm 安装目录（ winget 默认在 ...\\Helm ）；用 helm version 验证。
- 现象：
helm search repo 找不到刚 add 的包——忘了 helm repo update，或仓库 URL 写错；执行 helm repo list 核对 URL，再 helm repo update 刷新索引后重试。
- 现象：install 卡在
ImagePullBackOff——镜像拉不下来（网络/私有仓库凭证/tag 拼错）；kubectl describe pod <pod> 看 Events 里的具体原因；学习环境可先换公共镜像验证 Chart 结构。
面试常问
-
Helm 3 相比 Helm 2 最大的变化是什么？
移除了集群内的服务端组件 Tiller。Helm 2 里 Tiller 需要集群级高权限，成为安全隐患与多租户瓶颈；Helm 3 改为 CLI 直接以当前 kubeconfig 身份调用 Kubernetes API，权限最小化、与 kubectl RBAC 一致。另外 Release 存储从 ConfigMap/Tiller 内部改到 Secret（sh.helm.release.v1.<name>.v<N>），支持 helm test、helm rollback 到任意 revision 等增强。
-
--set 和 -f 的优先级与取舍？
优先级：--set 最高，其次按 -f 传入顺序后者覆盖前者，最低是 Chart 默认 values.yaml。但生产不靠 --set：它不可评审、会进日志、复杂结构表达力差。工程实践是把差异固化为 values 文件进 Git，--set 仅限本地试验。
-
如何安全地使用第三方 Chart？
四步：认准维护活跃的源（Bitnami/官方社区）；helm show values 与 helm pull 审阅默认配置与模板；用 SemVer 约束或 Chart.lock 锁定版本；密钥类配置一律外部注入，不写进 values。升级前看 CHANGELOG 与 helm diff 插件输出的渲染差异。
自测三问
- Helm 3 为什么没有 Tiller？权限边界落在哪里？
- 写出从「添加仓库」到「导出默认 values」的最少命令序列。
- 为什么生产倾向 values 文件而不是
--set？这和后面的 GitOps 有什么关系？
小结一句话
装好 Helm 3 CLI、管好 repo、用 search/show/pull 发现与审阅 Chart，用 values 文件表达配置；学习集群可试装，生产配置进 Git 可评审——CLI 环境至此就绪。
延伸