為什麼選 Helm 而不是 Kustomize

兩週前給自己一個任務：從零寫一個 Helm chart，把 Helm 真正搞懂。
練習寫完之後，也一併做了工具選型的練習，
思考 Kustomize 更單純，選擇Helm 的理由是什麼？
問自己「這個情境到底需要什麼能力」，讓需求去挑工具，而不是讓功能挑我。

我需要什麼：讓需求挑工具，而不是讓功能挑我

我把需求拆成四個問句，判斷 Kustomize 與Helm 的選擇：

• 我需不需要邏輯？
  • 只要 manifest 裡會出現條件式或迴圈，Kustomize 就沒辦法 ー 它沒有 if / range。
• 我需不需要生命週期？
  • install / upgrade / rollback、release 狀態存在 cluster 的 namespace Secret 裡，這是 Helm 的核心
  • Kustomize 沒有 release 概念，回滾只能 git revert 再重 apply。
• 我需不需要依賴？
  • 我既有的 redis、postgresql 都是 chart，把它們當子 chart 整合，Helm 直接支援。
• 我需不需要 hook？
  • pre-install 跑一個 Job 這種事 Helm 有 hook，Kustomize 沒有。

如果我的需求只是「同一份 manifest 套三個環境、改改 replica 跟 image」，我會選 Kustomize ー 那是它最簡潔的部份。

練習：我自己寫的 chart

自己練習寫成一個能跑的 chart。重點不是 helm create 那幾個指令（scaffold 誰都生得出來…）。
真正的學習在於把那個「什麼都會做」的預設 chart 改造成自己的 chart，我新增了：

• ConfigMap
• 一個 pre-install 的 hook Job
• 寫了 values.schema.json 擋掉錯誤輸入。

helm create 給你一個全能但不屬於你的骨架；把它變成自己的，整個過程其實就是在決定要丟掉與新增、保留什麼。

Repo：https://github.com/shoudevops/helm-practice

移除功能 ≠ 刪檔案：autoscaling 的觸手

最有感的練習來自「刪掉一個功能」。
我想拿掉 autoscaling，直覺是把 hpa.yaml 刪了就好。
刪完以為收工，渲染卻炸了，deployment.yaml 裡那行 {{- if not .Values.autoscaling.enabled }} 還在引用一個我以為已經不存在的值，直接 nil pointer。
原來這個功能的觸手不只在 hpa.yaml：values.yaml 有它的設定、NOTES.txt 提到它、deployment 的 replicas 判斷也勾著它。
我一根一根追，追到 deployment 那行才算真的乾淨。

從過程中學習到：刪一個功能，要追著它在 values / 其他 template / NOTES 裡的每一根引用，刪檔案只是第一步。
順帶一提，過程裡我也踩到兩個地雷：

• secret 千萬別進 git
• --reset-values 會把累積的自訂值清光。

什麼時候我會改用 Kustomize

這篇文章不是在說 Helm 有多萬能。
第三方 app 我會用 Helm 裝；
但純粹是環境之間的差異，我會用 Kustomize 的 overlay，甚至 helm template 渲染完再用 Kustomize patch 收尾。

判準還是同一條：

• 一旦我需要條件式或 rollback，Kustomize 就出局；如果只是改幾個值，就用不著 Helm。

小結

回到文章最開始的問題：為什麼不用 Kustomize？
因為選型能力從來不是背得出哪個工具有哪些功能，而是先誠實問自己「我需要什麼」，再讓需求去挑工具。
下一步我想補的是 secret 管理 ー SOPS 或 External Secrets Operator，那又是另一個「需求挑工具」的題目了。