前言：為什麼會有 Helm Chart？

當我們要在 Kubernetes 上部署一個完整的專案時，往往不只是單一個 Pod 就能完成任務，而是需要 Deployment、Service、ConfigMap、Ingress、RBAC、甚至 CRD 等等元件一起協作，才能讓應用「真的能運作」。

如果每次都要自己一個一個寫 YAML、再一個一個 apply，不僅速度慢，而且容易出錯，也很難管理版本差異。於是，Helm Chart 誕生了。它把這些部署所需的 YAML 模板、參數化設定、版本控制包在一起，就像 「Kubernetes 世界的套件管理工具」。

除了「加速安裝」之外，它更重要的價值在於：

• 封裝一整組元件，確保它們能正確搭配。
• 提供 Values file 來客製化，避免重複造輪子。
• 內建版本管理與 rollback，減少「apply 爛掉 → 緊急救火」的恐懼。

因此 Helm Chart 不只是「安裝快」，而是 讓複雜系統的部署可重現、可版本化 的核心工具。

Helm Chart 是什麼？

Helm 可以想成是 Kubernetes 的套件管理工具，而 Chart 就是套件的「藍圖」。

一個 Chart 包含：

• Chart：模板（template）集合，描述資源 YAML 的樣子。
• Values：參數檔，決定這份模板要套入什麼值。
• Release：安裝後的實例，代表這份 Chart 在叢集裡的一次部署。

用一個比喻：

• Chart 就像蛋糕食譜。
• Values 是不同的配方或客製需求（多點糖、少點奶油）。
• Release 則是實際烤出來的一個蛋糕。

Helm Chart 的檔案結構

以一個最小的 Chart 為例：

mychart/
  Chart.yaml          # chart 基本資訊 (name, version, description)
  values.yaml         # 預設參數
  templates/          # Kubernetes YAML 模板
    deployment.yaml
    service.yaml

在 values.yaml 裡定義：

replicaCount: 2
image:
  repository: nginx
  tag: 1.27

在 templates/deployment.yaml 裡用 Go template 語法：

...
spec:
  replicas: {{ .Values.replicaCount }}
  containers:
    - name: nginx
      image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Helm 會把 values.yaml 的參數套進模板，最後輸出合法的 Kubernetes manifest。

常見的操作：

• helm install：建立一個新的 Release。
• helm upgrade：更新既有 Release，會產生新的 revision。
• helm rollback：回到某個舊版本。這裡的版本化機制是 Helm 的關鍵優勢之一。

那麼，什麼時候該用 CRD、Helm Chart、還是 Addon？

CRD、Helm Chart、Addon 其實有不少共通點：它們都是為了 降低 Kubernetes 應用部署的複雜度，並且都建立在 Kubernetes 的宣告式模型之上，最終仍是透過 YAML 或 API 來維護狀態。更重要的是，三者常常會互相搭配使用，例如 CRD 透過 Helm Chart 發布，或 Addon 的底層實作就是 Helm 與 CRD。而什麼時機該選擇哪個工具，確實是很多人實務上會困惑的問題。

我們先來釐清一下三種元件的定義：

• CRD（CustomResourceDefinition）：讓你在 Kubernetes 裡創造「新型態的 API」。例如 ArgoCD 就用 CRD 來定義 Application。CRD 適合用在「需要一個新抽象層」的情境，而不是單純部署元件。
• Helm Chart：更像是一種「打包與安裝方式」，幫助你部署一組已存在的 Kubernetes 資源，或搭配 CRD 一起安裝。
• Addon：則是雲端廠商（像 AWS EKS）提供的「一鍵安裝服務」，本質上很多也是用 Helm 或 manifest 實作，只是交由平台托管更新與維運。

因此，假設我要部署一個 Observability 方案：

• 我可能會用 CRD 來定義新的 LogPipeline 資源，好讓使用者只要寫 YAML 就能描述「收集哪些 log，送去哪裡」。
• 這個方案裡面還需要 Prometheus 或 Grafana，但他們整包服務元件太多了，手動部署不切實際，所以我會使用社群打包好的 Helm Chart。
• 如果我在 EKS 上，AWS 已經提供了 CloudWatch Logs Addon，那我就不必自己維護 Fluent Bit，一鍵安裝即可。

差異比較表

結語

今天我們用不同角度看待 Helm Chart，不只是理解 Chart、Values、Release 的三角關係，也比較了 Helm Chart、CRD、Addon 的定位。

Helm Chart 解決的是「怎麼方便、可控地部署一整組元件」的問題，而不是重新定義 API。

明天開始，我們會把這些概念帶到 Argo CD，看看 GitOps 是如何利用 Helm 來完成「宣告式、可回溯、跨環境一致」的部署流程。