在昨天的瀏覽 Bitnami Library中 我們提到了helm install my-release oci://registry-1.docker.io/bitnamicharts/kafka
這是Helm的部署指令，他形象化的使用了install來表現出部屬內容的整體性。

而對於一個封裝的服務，在管理上勢必要區分版本，此時Helm Chart的版本管理優勢就可以體現，接下來帶領讀者一起認識常見的版本管理指令。

1. 安裝指定版本

在安裝時可以指定 Chart 的版本：

helm install my-release oci://registry-1.docker.io/bitnamicharts/kafka --version 26.5.0

👉 --version 決定使用哪一版的 Chart（而不是應用程式版本）。
例如：Bitnami Kafka Chart 26.5.0 可能對應 Kafka appVersion 3.6.0。

這邊要注意在chart.yaml中兩者的區別：

apiVersion: v2
name: kafka
description: A Helm chart for Apache Kafka
type: application

# Helm Chart 本身的版本（跟應用程式分開管理）
version: 26.5.0

# 應用程式的版本（通常是 Kafka 的版本）
appVersion: 3.6.0

maintainers:
  - name: Bitnami
    email: containers@bitnami.com

• version → Helm Chart 的版本（Chart 本身的封裝版本號，用來描述 chart 結構或 values 的演進）
• appVersion → 實際應用程式的版本（通常對應到 image tag，例如 Kafka 3.6.0）

2. 查詢 Release 歷史

Helm 會為每次部署與升級留下紀錄：

helm history my-release

輸出範例：

REVISION  UPDATED                   STATUS     CHART           APP VERSION DESCRIPTION
1         Mon Sep 23 20:00:00 2025  deployed   kafka-26.5.0    3.6.0       Install complete
2         Mon Sep 23 21:30:00 2025  superseded kafka-26.6.1    3.7.0       Upgrade complete
3         Mon Sep 23 22:15:00 2025  deployed   kafka-26.6.1    3.7.0       Upgrade complete

👉 這裡可以看到 Chart 版本 與 應用程式版本 的對應。

3. 升級到新版本

升級指令範例：

helm upgrade my-release oci://registry-1.docker.io/bitnamicharts/kafka --version 26.6.1

👉 upgrade 會保留現有設定，但會嘗試套用新 Chart。
在動手之前，建議先用 helm diff 檢查升級後的差異，避免因為 values.yaml 改動造成意料之外的重建：

helm diff upgrade my-release oci://registry-1.docker.io/bitnamicharts/kafka --version 26.6.1

升級過程與影響
Helm 升級的底層，其實是透過 Kubernetes 的 Deployment / StatefulSet 滾動更新機制 來進行：

• Kubernetes 會依照 maxUnavailable、maxSurge 的設定，逐步終止舊 Pod、啟動新 Pod。
• 在 Kafka 這類 StatefulSet 服務中，則是一個一個 Broker 依序更新，確保集群 quorum 始終存在。
• 同時，新 Pod 必須通過 readiness probe 才會加入服務流量，避免未準備好的實例影響請求。

因此，在一般情況下，helm upgrade 能以平滑的方式完成更新，不會直接造成服務中斷。

需要留意的例外情況：

• 大幅度 values.yaml 變更（例如 PVC、Service type、或刪除參數 key），可能導致 Pod 重建而短暫影響服務。
• 單副本服務（或需要 cluster rebalance 的應用），即使是滾動更新，也難以完全避免停機。
• 健康檢查設定不當，可能讓未準備好的 Pod 及早接流量，導致請求失敗。

👉 總結來說，Helm 升級在設計上是 漸進式、不中斷 的，但是否能真正做到零停機，取決於應用程式本身與正確的 values.yaml 設計。

4. 回滾到舊版本

如果新版本有問題，可以回滾：

helm rollback my-release 1

👉 這會回到 release history 的第 1 個版本。

5. 檢查目前版本

helm list -n default

輸出範例：

NAME         NAMESPACE  REVISION  UPDATED                  STATUS    CHART           APP VERSION
my-release   default    3         Mon Sep 23 22:15:00 2025 deployed  kafka-26.6.1    3.7.0

👉 這裡可以快速確認目前部署的是哪一版。

透過 Helm 的版本管理，我們可以在 不中斷服務的情況下進行熱更新。例如，升級 Chart 或更新應用程式 image 時，Kubernetes 會依循滾動更新策略逐步替換 Pod，而服務仍能持續運行。

但需要注意幾點：

1. 滾動更新的觸發條件

   • 如果 values.yaml 沒有任何改動，Helm 會判定沒有變更，滾動更新將不會執行。
   • 這意味著即使升級 Chart 版本，如果設定值不變，Pod 可能不會重建。

2. 軟體更新（image 更新）

   • 我們可以在不更動 values.yaml 的情況下，僅更新 container image，完成應用程式的軟體更新。
   • 這是日常運營中常見的情境，例如安全修補或小版本升級。

3. 開發與部署的驗證流程

   • helm template 或 --dry-run：可在部署前渲染出最終 Kubernetes manifest，檢查設定是否符合預期。

     helm upgrade my-release oci://registry-1.docker.io/bitnamicharts/kafka --version 26.6.1 --dry-run
     

   • helm get manifest：部署後可查看實際應用到 Kubernetes 的 manifest，確認所有設定已正確傳遞。

     helm get manifest my-release
     

在實務操作中，對於需要零停機部署的服務，善用 Helm Chart 的版本管理、滾動更新機制以及 container image 更新策略，可以有效降低升級風險。
同時，在開發與部署週期中，提前透過 helm template 或 --dry-run 進行驗證，能協助開發的進行，以及確保設定正確無誤。綜合而言，Helm 的功能不僅是部署，更是一套能夠管理版本、控制更新節奏並驗證配置完整的工具。

在實務中，除了單一服務的版本管理與升級，當團隊使用 CI/CD 平台（例如 GitLab CI）進行多服務部署時，Helm 的版本與參數管理優勢同樣適用。特別是當多個 Helm Chart 共用部分設定值時，可以透過 pipeline 集中管理這些參數，避免在每個 Chart 中重複設定，提升維護效率，也降低因手動修改造成的錯誤風險。

例如，假設在 GitLab CI 中有一個 deploy stage，用於部署多個服務的 Helm Chart，可以透過 .gitlab-ci.yml 中的變數與模板實現共用參數：

variables:
  KAFKA: kafka-boostrap.svc
  NAMESPACE: "production"

stages:
  - deploy

deploy_service_a:
  stage: deploy
  script:
    - helm upgrade service-a ./charts/service-a --install --namespace $NAMESPACE --set kafkabootstrap=$KAFKA

deploy_service_b:
  stage: deploy
  script:
    - helm upgrade service-b ./charts/service-b --install --namespace $NAMESPACE --set kafkabootstrap=$KAFKA

在這個範例中，KAFKA 和 NAMESPACE 變數同時被多個 Helm Chart 共用，當需要更新 Kafka 連接位址或切換命名空間時，只需修改 CI/CD 變數即可，無需逐一修改各個 Chart 的設定。這種做法在多服務、多環境的部署場景中非常實用，不僅能確保版本一致性，也能大幅簡化運維流程。更多關於 CI/CD 管理與架構的實務技巧，將在後續的 GitLab CI/CD 範例（Day10–13）中進一步介紹。

小結

今天是 Helm 實戰（Day5–9）的最後一天。在這四天中，我們從 Helm 作為宣告式配置的運作原理 開始，一步步探索：

1. 設計 values.yaml：理解為何減少階層能讓配置更優雅與易於維護。
2. Helm template 與常用函數：掌握模板語法與實務最佳做法。
3. 瀏覽 Bitnami Library：學習如何建構結構清晰、可重用的 Helm Chart。
4. Helm Chart 部署與版本管理：掌握升級、回滾、滾動更新及版本控制策略。

隨著對 Helm 技術的逐步理解，我們最終的服務抽象成了一個簡單的 helm install。
我們管理的不是底層硬體，而是一個服務入口或平台，這讓系統更加可控，並提供了更高的擴展彈性。

這也是我在 DevOps 實戰中慢慢體會到的：
DevOps 不只是把維運化作一份份設定檔，而是將所有服務抽象並整合成一個可運營的平台。
這也是我選擇從 Helm 開始，再由 GitLab CI 接手自動化流程的原因。

希望今天的分享，能給各位帶來實務操作的啟發與思考方式。

感謝各位閱讀，我們明天見！