前言

在前一篇文章 Day 20：StorageClass 與動態供應 中，我們探討了如何透過自動化的方式來管理 Kubernetes 儲存資源。當應用越來越多、組件越來越複雜時，光靠手寫與維護大量 YAML 檔案會變得低效且容易出錯。
這時候，我們需要一個「套件管理工具」來幫助我們更方便地部署與維護應用 —— Helm。

Helm 讓 Kubernetes 的應用管理變得像安裝套件一樣簡單，並且支援版本控制、回滾與參數化設定，是 DevOps 工程師必備的工具之一。

為什麼需要 Helm

1. 集中管理
   將 Deployment、Service、ConfigMap 等多個 YAML 打包成一個 Chart，方便維護。
2. 版本控制
   Helm 可以追蹤每一次部署，並支援升級與回滾。
3. 可重複性
   相同的 Chart 可套用到不同環境（dev/staging/prod），大幅提升一致性。
4. 社群生態
   許多熱門服務（如 MySQL、Prometheus、Grafana）都有現成的 Chart 可直接使用。

Helm 的核心概念

• Chart：Helm 的封裝單位，包含 Kubernetes 所需的 YAML 模板與預設參數。
• Release：Chart 在叢集內的實例，可以有多個 Release 版本。
• Values：透過 values.yaml 或 --set 傳入，讓部署具備彈性。
• Repository：存放 Chart 的地方，例如官方的 Artifact Hub。

安裝與基本操作

1. 安裝 Helm

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

2. 新增 repository

helm repo add bitnami https://charts.bitnami.com/bitnami

helm repo update

3. 安裝應用（以 Nginx 為例）

helm install my-nginx bitnami/nginx

4. 檢查 Release

helm list

5. 升級與回滾

helm upgrade my-nginx bitnami/nginx --set service.type=NodePort
helm rollback my-nginx 1

實作範例：部署一個自訂的 Node.js API

1. 建立 Chart

helm create my-api

目錄結構：

my-api/
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl
├── values.yaml
└── Chart.yaml

2. 修改 values.yaml

replicaCount: 2
image:
  repository: my-dockerhub-user/my-api
  tag: "1.0.0"
service:
  type: ClusterIP
  port: 3000

3. 部署應用

helm install my-api ./my-api

4. 驗證服務

kubectl get pods
kubectl get svc

5. 升級版本

修改 values.yaml 的 tag: "1.0.1" 後執行：

helm upgrade my-api ./my-api

結語

Helm 讓 Kubernetes 的應用管理不再只是「拼裝 YAML 零件」，而是像「安裝套件」一樣高效有序。
實務上，團隊常會針對不同環境（dev/staging/prod）建立不同的 values.yaml，再搭配 CI/CD 流程自動化部署。這樣不僅提升了生產力，也讓部署更具一致性與可控性。

下一篇我們將延伸至 資源限制與 QoS，探討如何確保應用在 Helm 部署後能合理運行，避免「搶資源」的情況發生。