Helm Chart 安裝升級與回復操作

– 8 分鐘閱讀

Helm 作為 Kubernetes 的套件管理器，簡化了應用程式的佈署和管理流程。本文以 WordPress 為例，示範如何使用 Helm 安裝 Chart、修改設定值進行升級，以及在需要時回復到先前的版本。首先，我們會設定 WordPress 的基本組態，包含使用者名稱、密碼、電子郵件等資訊，並將應用程式佈署到 Kubernetes 叢集中。接著，我們會調整副本數量和資源請求，例如記憶體和 CPU，以滿足應用程式的需求，並學習如何使用 Helm 升級命令更新這些設定。升級過程中，Helm 提供了 --reuse-values 和 --reset-values 等選項，方便開發者管理組態值。最後，我們將探討 Helm 的回復機制，演示如何利用 Helm 的版本控制功能，將應用程式還原到之前的穩定狀態，並說明如何查詢版本歷史記錄和執行回復操作。

安裝首個 Helm Chart

在上一節的命令中，第二個提供的連結是用來存取管理控制檯。將第二個 echo 命令中的連結複製到瀏覽器中，你應該會看到以下的登入畫面：

WordPress 管理控制檯登入頁面

登入管理控制檯時，請輸入你在安裝過程中提供的 wordpressUsername 和 wordpressPassword 值。這些值可以透過檢視本地的 wordpress-values.yaml 檔案來檢視。你也可以透過執行以下命令來取得，這些命令是在 WordPress Chart 的註解中指示的：

$ echo Username: helm-user
$ echo Password: $(kubectl get secret --namespace chapter3 wordpress -o jsonpath='{.data.wordpress-password}' | base64 --decode)

存取 WordPress 應用

成功驗證後，將顯示管理控制檯的儀錶板，如下圖所示：

此圖示 - WordPress 管理控制檯頁面

如果你負責管理這個 WordPress 網站，這裡是你可以組態網站、撰寫文章和管理外掛的地方。如果你點選右上角標有 Howdy, helm-user 的連結，你將被導向 helm-user 的個人資料頁面。在那裡，你可以看到你在安裝過程中提供的其他幾個值，如下圖所示：

此圖示 - WordPress 個人資料頁面

First Name、Last Name 和 Email 欄位分別對應於 wordpressFirstname、wordpressLastname 和 wordpressEmail Helm 值。

感覺自由探索你的 WordPress 例項。完成後，請繼續下一節瞭解如何對 Helm 發行版進行升級。

升級 WordPress 發行版

升級發行版是指修改發行版安裝時使用的值或升級到更新版本的 Chart。在此節中，我們將透過組態與 WordPress 副本和資源需求相關的其他值來升級 WordPress 發行版。

修改 Helm 值

通常 Helm Chart 會暴露一些值來組態應用程式的例項數量及其相關的資源集合。以下截圖說明瞭 helm show values 命令的一些部分，這些部分與用於此目地的值相關。

replicaCount 在 helm show values 命令中的使用

副本（replica）是 Kubernetes 中描述用於佈署應用程式所需的 Pod 數量的一個術語。因此，replicaCount 用來指定作為發行版的一部分佈署的應用程式例項數量：

此圖示 - replicaCount 在 helm show values 命令中

在 wordpress-values.yaml 檔案中新增以下行以將副本數從 1 增加到 2：

replicaCount: 2

資源需求組態

第二個我們需要定義的值是 resources YAML 標籤下的一組值：

此圖示 - resources 標籤下的值

可以像在 resources 標籤中一樣縮排值，以提供邏輯分組。在 resources 標籤下有一個 requests 標籤，用於組態 Kubernetes 將為 WordPress 應用程式分配的記憶體和 CPU 值。讓我們在升級過程中修改這些值，將記憶體需求減少到 256Mi（256 美比位元組），CPU 需求減少到 100m（100 毫核心）。將這些修改新增到 wordpress-values.yaml 檔案中，如下所示：

resources:
requests:
memory: 256Mi
cpu: 100m

檢視完整更新後的 wordpress-values.yaml 檔案

更新這兩個新值後，你的整個 wordpress-values.yaml 檔案應該如下所示：

wordpressUsername: helm-user
wordpressPassword: my-pass
wordpressEmail: helm-user@example.com
wordpressFirstName: Helm
wordpressLastName: User
wordpressBlogName: Learn Helm!
service:
type: NodePort
replicaCount: 2
resources:
requests:
memory: 256Mi
cpu: 100m

執行升級操作

更新完值檔後，就可以執行 helm upgrade 命令來升級發行版了。

執行升級操作命令範例

helm upgrade [RELEASE] [CHART] [flags]

helm upgrade 的基本語法與 helm install幾乎相同。然而，helm install 需要你提供新發行版的名稱，而 helm upgrade 則需要你提供現有發行版的名稱以進行升級。

使用 --values 標誌可以提供 values 檔案中的值定義，與 helm install 命令相同。請執行以下命令以使用新的一組值來升級 WordPress 發行版：

$ helm upgrade wordpress bitnami/wordpress --values wordpress-values.yaml -n chapter3 --version 8.1.0

執行命令後，你應該會看到類別似於之前安裝部分展示的 helm install 的輸出。

此圖示 - helm upgrade 的輸出結果

檢視 Pod 的重啟狀態

$ kubectl get pods -n chapter3

在 Kubernetes 中，當佈署被修改時會建立新的 Pod。Helm 中也可以觀察到相同的行為。升級過程中新增的一些值引入了對 WordPress 佈署的一個組態更改，因此建立了新的帶有更新組態的 WordPress Pod。

未來趨勢預測與技術選型考量

未來隨著 Kubernetes 與 Helm 的普及化及技術進步，「Helm」可能會成為更多開發者及企業級應用佈署之工具標準之一。 然而在選型上須注意不同企業間應用差異性、不同團隊成熟度及流程等多重因素影響使用「Helm」帶來之方便性及效率提升。

「內容解密：」

1. 輸入密碼取得方法

$ echo Password: $(kubectl get secret --namespace chapter3 wordpress -o jsonpath='{.data.wordpress-password}' | base64 --decode)

該命令透過 Kubectl 指令從 Kubernetes 的 secret 資源中取得已編碼資料並解碼轉為可讀文字。 Kubectl 是 Kubernetes Command-Line Tool, 能夠透過簡單指令完成基本操作流程。

2. Helm Chart 安裝與存取 Helm 是一種 Kubernetes Packages Manager, 提供便捷安裝及更新適用於 Kubernetes 上之應用。 官方命名已經安裝或升級之應用為 “Release”, 每次執行 Helm 命令皆需指定 Release 名稱。 WordPress 是一種開源 CMS (Content Management System), 提供豐富功能供開發者發展專屬網站或線上商店。 3. Upgrade Helm Chart Helm 提供 Upgrade 功能讓開發者能夠快速簡單地更新已經安裝之 Release。 Upgrade 功能可分為更新 chart 與更新 value, chart 本身含有主題應用所有功能, value 則是調整這些功能之引數. 在上述範例中, 副本(Replica) 與資源需求(Resource)皆為 value 一環, 提供給開發者快速調整 Deployment 模式.

4. Reuse & Reset Values –reuse-values 與 –reset-values 是 Helm 提供給開發者快速回覆到原始設定或更新前設定之方便方式. –reuse-values：使用上一次 Release 的 value 資訊. –reset-values：迴歸 Chart 預設設定.

5. 不同 Value 問題 每次執行 Upgrade Command 輸入之 Values 有可能會與已經存在之 Values 有所衝突, 例如 Resource Requests Memory 被降低而超出已經存在容器所需之 Memory 則會造成出錯.

6. 高用性以及資源分配 Replicas(副本) 與 Resource Requests(資源需求) 是關於高用性以及資源分配問題, 啟動多副本讓不同時間點之訪客能夠取得穩定服務, 資源需求則是避免因超過限制造成服務故障. 在 Docker 上常見每次 Deploy 新 Image 若發生錯誤只會停止最新一次之 Container, 若該 Container 被設定為唯一則訪客無法連線網站(故障狀態), 若設定多副本則其他 Container 能夠正常運作避免故障. 而在 Resource Requests 上若設定不正確容易造成服務故障, 不僅停止服務還會造成無法啟動(無法預估容量), 故使用前必須做好詳細規劃. 7. Docker 與 Kubernetes 差異

Docker 是常見於 Open Source Server Virtualization Software, 能夠快速簡單地建立虛擬機器並進行多重任務管理. Kubernetes 則是專門針對 Container (Docker Container) 框架所設計出之自動化管理系統. 兩者皆能進行虛擬機器操作但 Kubernetes 能夠自動化佈署 Container 做到更精細化管理, 延伸運算更高效率且更穩定.

根據上述兩者差異, Docker 主要針對虛擬機器使用情境, Kubernetes 則主要針對 Container 自動化情境.

8. Docker Compose 與 Kubernetes 差異

Docker Compose 是 Docker 提供給開發者簡單架構設定之工具, 能夠透過 yaml 檔案建立起多重 Service 框架. 然而 Docker Compose 無法像 Kubernetes 一樣自動化 Deploy 與 Scale Up/Down 功能, 在不同環境亦無法保持一致性. Kubernetes 主要針對 Production Environment 自動化軟體執行問題設計出之工具, 提供 Multi-Node Support 功能並且保持架構一致性.

9. Helm 與 Kubectl 差異

Helm 與 Kubectl 本質上皆屬於 CLI (Command Line Interface), 前者主要針對 K8S (Kubernetes) Deployment 自動化設計出之工具。 而後者則屬於 K8S Core CLI Tool 能夠進行基本 K8S 操作例如 Pod、Container、Node、Namespace…

兩者皆屬於 K8S 自動化工具但因設計原因使用場景不盡相同.

未來趨勢預測與技術選型考量

未來隨著 Kubernetes 與 Helm 的普及化及技術進步，「Helm」可能會成為更多開發者及企業級應用佈署之工具標準之一。 然而在選型上須注意不同企業間應用差異性、不同團隊成熟度及流程等多重因素影響使用「Helm」帶來之方便性及效率提升。

安裝您的第一個 Helm Chart

在執行升級時，如果沒有使用 --set 或 --values 旗標提供值，Helm 會預設新增 --reuse-values 旗標。這意味著如果沒有提供新值，升級過程中將重用之前版本所使用的值：

  1. 執行另一個升級命令，不指定任何值： 
    $ helm upgrade wordpress bitnami/wordpress -n chapter3 --version 8.1.0
  2. 執行 helm get values 命令來檢查升級時所使用的值： 
    $ helm get values wordpress -n chapter3
    您會發現顯示的值與之前的升級完全相同。

提供命令列值時的行為

當在升級過程中從命令列提供值時，行為會有所不同。如果透過 --set 或 --values 旗標傳遞值，所有未提供的 Chart 值將會重置為預設值。

  1. 使用 --set 提供一個值來執行另一個升級： 
    $ helm upgrade wordpress bitnami/wordpress --set replicaCount=1 -n chapter3 --version 8.1.0
  2. 升級後，執行 helm get values 命令： 
    $ helm get values wordpress -n chapter3
    輸出將顯示唯一使用者提供的值是 replicaCount。

內容解密：

上述程式碼段落展示了 Helm 的升級過程，當沒有提供新的組態值時，Helm 會重用之前版本的組態。這些操作展示瞭如何檢查和理解 Helm Chart 在不同升級情境下的行為。

回復 WordPress 釋出

雖然前進是更常見的選擇，但有些情況下回復到應用程式的之前版本可能更為合理。Helm 提供了 helm rollback 命令來滿足這一需求。讓我們來回復 WordPress 釋出到之前的狀態。

檢查 WordPress 歷史

每個 Helm 需求都有釋出歷史記錄。釋出歷史記錄是用來追蹤在特定釋出版本中所使用的值、Kubernetes 資源和 Chart 版本。每當安裝、升級或回復 Chart 時，都會建立一個新的釋出歷史記錄。預設情況下，釋出歷史記錄資料儲存在 Kubernetes Secrets 中（其他選項包括 ConfigMap 或本地記憶體，由 HELM_DRIVER 環境變數決定）。

您可以使用以下命令來觀察這些釋出歷史記錄：

$ kubectl get secrets -n chapter3

這將傳回所有 Secret，您應該會看到以下四個輸出：

sh.helm.release.v1.wordpress.v1
sh.helm.release.v1.wordpress.v2
sh.helm.release.v1.wordpress.v3
sh.helm.release.v1.wordpress.v4

每個 Secret 對應於釋出歷史記錄的一個條目，可以透過執行 helm history 命令來檢視：

$ helm history wordpress -n chapter3

這個命令將顯示每個釋出歷史記錄的表格，類別似於以下內容（部分欄位已省略以便閱讀）：

REVISION ... STATUS ... DESCRIPTION
1 superseded Install complete
2 superseded Upgrade complete
3 superseded Upgrade complete
4 deployed Upgrade complete

在這些輸出中，每個釋出歷史記錄都有一個編號、更新時間、狀態、Chart、應用程式版本和升級描述。狀態為 superseded 的釋出歷史記錄已被升級。狀態為 deployed 的釋出歷史記錄是當前已佈署的版本。其他狀態包括 pending 和 pending_upgrade ，表示安裝或升級目前正在進行中。而 failed 則表示特定釋出歷史記錄安裝或升級失敗，而 unknown 則對應於一個未知狀態的釋出歷史記錄。

您可以使用之前描述的 helm get 命令指定 --revision 旗標來檢查具體的釋出歷史記錄號碼。例如，要確定包含完整所需值集合的釋出歷史記錄號碼，您可能需要檢查第三次釋出歷史記錄：

$ helm get values wordpress --revision 3 -n chapter3

執行回復

Helm 的回復命令語法如下：

helm rollback <RELEASE> [REVISION] [flags]

使用者需要提供要回復到之前時間點的釋出名稱和所需版本號碼。執行以下命令以執行將 WordPress 回復到第三次釋出版本：

$ helm rollback wordpress 3 -n chapter3

此回復子命令提供簡單輸出，列印以下訊息：

Rollback was a success! Happy Helming!

這次回復可以透過執行以下命令來觀察：

$ helm history wordpress -n chapter3

內容解密：

上述操作展示瞭如何利用 Helm 檢查和管理 Kubernetes 上的應用程式釋出版本。Helm 的回復功能允許使用者在需要時回到之前穩定且正確組態的釋出版本，確保系統能夠快速還原到可靠狀態。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。