用 Helm 和 Kustomize 把同一个应用打包两次

目标

用两种交付工具对同一个 Deployment 进行打包。用 Helm 创建 Chart，修改 values 后依次进行模板渲染、安装和升级； 用 Kustomize 搭好 base，再用 prod overlay 叠加 replicas 和标签。 分别从 Helm release 和 Kustomize 产物两侧确认“究竟是哪份清单真正应用到了集群”。

为什么重要

Kubernetes 清单不会只靠一份手写的 YAML 就结束。不同环境的 replicas、镜像、标签各不相同， 管理这些差异的方法，正是“应用交付（delivery）”的核心。Helm 用填入值（values）的模板来解决， Kustomize 则用在 base 之上叠加 overlay 的方式来解决同一个问题。 两者的思路不同，但产物同样是送往 API 服务器的清单。

亲手体验 helm install 和 helm upgrade 以 release 为单位留下变更历史， 以及 Kustomize 不动原始文件、只通过 overlay 表达差异， 你就会培养出在部署流水线中通过 release 修订版本和组装结果回溯“现在应用的到底是什么”的感觉。

步骤

1. 创建命名空间 kcna-pkg。
2. 用 helm create 生成 webapp Chart 的骨架。
3. 把 replicaCount 改为 3，将 helm template 的结果保存为文件。
4. 以 release web 安装该 Chart。
5. 用 --set replicaCount=5 升级，提升修订版本和 replicas。
6. 手写 Kustomize base（store Deployment），并用 kubectl kustomize 确认组装结果。
7. 用 prod overlay 叠加 replicas 4 和 env=prod 标签并应用。
8. 把 Helm 和 Kustomize 的结果以账簿形式记录到 /root/kcna-pkg/report.txt。

参考

• 用 helm list -n kcna-pkg -o json 和 helm history web -n kcna-pkg 查看 release 状态和修订版本。
• kubectl kustomize <디렉터리>（占位符为目录）只显示组装结果，不会动集群，适合在应用之前确认。
• 官方文档：Helm Charts · Kustomize 参考。

打开打包工作区命名空间

创建命名空间 kcna-pkg。此后 Helm release 和 Kustomize 产物都会部署到这个命名空间。

命名空间可以用 kubectl create namespace 创建。要让重复运行也安全，请使用 --dry-run=client -o yaml | kubectl apply -f - 这一模式。

用 Helm 生成 Chart 骨架

在 /root/kcna-pkg/webapp 位置新建 Helm 默认 Chart（Chart 名称为 webapp）。必须生成 Chart.yaml 和 templates/deployment.yaml。

helm create <경로>（占位符为路径）会生成包含 values.yaml、Chart.yaml、templates/ 的标准 Chart 骨架。路径的最后一段就是 Chart 名称。

修改 values，渲染出 3 个副本的模板

把 /root/kcna-pkg/webapp/values.yaml 中的 replicaCount 改为 3，然后将 helm template web /root/kcna-pkg/webapp 的结果保存为 /root/kcna-pkg/rendered.yaml。渲染出的 Deployment 中必须出现 replicas: 3。

helm template 不动集群，只把 values 填入后输出最终清单的文本。默认 Chart 会把 replicaCount 的值传给 Deployment 的 replicas。这个值可以用 sed 或 yq 修改。

把 Chart 安装到集群

以 release 名称 web 把 Chart 安装到命名空间 kcna-pkg（helm install web /root/kcna-pkg/webapp -n kcna-pkg）。Helm release 列表中 web 必须显示为 deployed 状态，并且该 release 创建的 Deployment 必须真的存在。

helm install <릴리스> <차트> -n <네임스페이스>（占位符依次为 release 名称、Chart 与命名空间）会把渲染后的清单应用到集群，并记录 release。可以用 helm list -n <ns> -o json 查看状态。Helm 创建的对象会带有 meta.helm.sh/release-name 注解。

通过升级扩到 5 个副本

用 --set replicaCount=5 升级 release web（helm upgrade web /root/kcna-pkg/webapp -n kcna-pkg --set replicaCount=5）。升级后 release 的修订版本必须大于等于 2，对应 Deployment 的 spec.replicas 必须为 5。

helm upgrade 会为同一个 release 生成新的修订版本。--set 不修改 values 文件，只覆盖指定的值。可以用 helm history <릴리스> -n <ns>（占位符为 release 名称）查看修订版本是否增加。

手写 Kustomize base

在 /root/kcna-pkg/kustomize/base 中创建 kustomization.yaml 和 deployment.yaml。Deployment 名称为 store，镜像 nginx:1.27-alpine，replicas 为 1，选择器和标签统一为 app: store。kustomization 的 resources 为 [deployment.yaml]。kubectl kustomize /root/kcna-pkg/kustomize/base 必须成功，且结果中出现 Deployment store。

Kustomize base 由原始清单和指向它的 kustomization.yaml 组成。在 resources: 中列出文件名。可以用 kubectl kustomize <디렉터리>（占位符为目录）预览组装结果。Deployment 的 selector.matchLabels 与 template 标签必须一致。

用 prod overlay 叠加 4 个副本和 env=prod

在 /root/kcna-pkg/kustomize/overlays/prod 中创建 overlay。把 ../../base 作为 resources 引用，添加将 replicas 提升为 4 的补丁和公共标签 env=prod。然后用 kubectl apply -k /root/kcna-pkg/kustomize/overlays/prod -n kcna-pkg 应用。最终，命名空间 kcna-pkg 中的 Deployment store 必须具有 spec.replicas 为 4 和标签 env=prod。

overlay 通过 resources: [../../base] 引入 base，并在其上叠加变更。replicas 用包含同名 Deployment 的补丁来修改（patches:），公共标签用 commonLabels: 一次性加上。kubectl apply -k 会先组装 overlay 再直接应用。

把打包了什么、怎么打包的记成账簿

在 /root/kcna-pkg/report.txt 中恰好写四行——helm-release=web、helm-replicas=5、kustomize-replicas=4、kustomize-label=env=prod。值必须与集群的实际状态一致。

评分器会把这四行与实际状态逐一比对。请确认 Helm release 创建的 Deployment 当前的 replicas，以及通过 Kustomize 部署的 store 的 replicas 和 env 标签，再抄写过来。不要猜测，请写用 kubectl get deploy -n kcna-pkg 读到的值。