在 Kubernetes 環境中，Helm Charts 有助於簡化應用程式佈署和管理，但隨著專案規模擴大，維護和測試 Helm Charts 的複雜度也隨之提升。Chart Testing (CT) 工具的出現有效解決了這些問題，它能自動偵測 Git Monorepo 中修改的 Helm Charts，並執行一系列檢查、驗證和測試，確保 Charts 的品質與可靠性。過往測試 Helm Charts 時，測試不同值組合相當繁瑣，需要重複安裝、測試、刪除的步驟。CT 工具支援多個值檔案，允許在 ci/ 目錄下存放多個測試值檔案，大幅簡化測試流程。此外，CT 工具的 --upgrade 標誌支援升級測試，確保升級過程不會出現迴歸問題，對於維護多個 Helm Charts 的 Monorepo 專案尤其重要。CT 工具提供 lint、install、lint-and-install 和 list-changed 四個主要命令，涵蓋了 Charts 的檢查、驗證、安裝和測試等環節，有效提升開發效率。使用 CT 工具需要 Helm、Git、yamllint、yamale 和 kubectl 等工具，並從 Helm 的 GitHub releases 頁面下載和組態 CT 工具。
提升 Helm Charts 測試的效能與可靠性
在 Kubernetes 環境中，Helm Charts 扮演著至關重要的角色，用於簡化應用程式的佈署和管理。然而，隨著專案規模的擴大，維護和測試 Helm Charts 的複雜度也隨之增加。Chart Testing (CT) 工具的出現，為解決這些問題提供了有效的方案。CT 工具能夠自動偵測 Git Monorepo 中修改的 Helm Charts，並執行一系列檢查、驗證和測試，確保 Charts 的品質與可靠性。
測試不同值組合的挑戰
測試 Helm Charts 時，一個重要的挑戰是如何測試不同的值組合。由於 helm test 命令無法在測試時修改釋出的值，因此必須遵循特定的工作流程來測試不同的值設定：
- 使用初始值設定安裝圖表。
- 對釋出執行
helm test。 - 刪除釋出。
- 使用不同的值設定安裝圖表。
- 重複步驟2到4，直到測試到足夠多的值可能性。
這種方法不僅繁瑣，而且容易出錯。為瞭解決這個問題，CT 工具提供了支援多個值檔案的功能，可以在 ci/ 目錄下存放多個測試值檔案，從而簡化測試流程。
防止迴歸並測試更新版本
除了測試不同的值組合外，防止迴歸並測試新版本的圖表也是至關重要的。CT 工具透過 --upgrade 標誌提供了升級測試的功能，可以確保在升級過程中不會出現迴歸問題。
多圖表維護與 Git Monorepo
在維護多個 Helm Charts 時，開發者通常會選擇使用 Git Monorepo 設計。CT 工具支援 Monorepo 結構，能夠自動偵測修改的 Charts 並執行測試。
Chart Testing Project 的介紹
Chart Testing Project 提供了一個名為 ct 的 CLI 工具，包含四個主要命令：
lint：檢查和驗證已修改的圖表。install：安裝和測試已修改的圖表。lint-and-install：結合lint和install的功能。list-changed：列出已修改的圖表。
其中，lint-and-install 命令能夠檢查和驗證已修改圖表中的版本號是否正確增加，並支援多個值檔案的測試。
測試 Helm Charts 的基本步驟
使用 ct lint-and-install 命令可以自動執行以下步驟：
- 檢測修改過的 Charts。
- 更新本地 Helm 快取。
- 下載修改過的 Charts 的依賴。
- 檢查版本號是否更新。
- 對每個版本號增加的 Chart 進行 lint 檢查和測試。
這些步驟確保了每個修改過的 Chart 在單獨的名稱空間中被安裝和測試，並且對 ci/ 目錄下定義的每個值檔案進行重複測試。
安裝必要工具
要使用 CT 工具，需要在本機上安裝以下工具：
- Helm
- Git (版本2.17.0 或更高)
- yamllint
- yamale
- kubectl
其中，Helm 和 kubectl 是 Kubernetes 環境中必備的工具，Git 用於版本控制，yamllint 和 yamale 用於 YAML 檔案的語法檢查和驗證。
下載並組態 chart testing 工具
從 Helm 的 GitHub releases 頁面下載 chart testing 工具，並進行組態：
- 下載最新發行版。
- 解壓縮下載好的 release 檔案。
- 將相關檔案移動到適當位置。
測試例項
假設我們對 Packt 儲存函式庫做了一些本地修改，並使用 chart testing 工具來 lint 和安裝修改過的 Charts。首先克隆儲存函式庫：
克隆後，在儲存函式庫根目錄下有一個名為 ct.yaml 的檔案，用於組態 chart testing 工具。
常見程式碼清單與解密說明
以下是一些常見的程式碼片段及其說明：
- 啟動 Helm Repository Update：
helm repo update
內容解密：
- 上述命令用於更新本地 Helm Repository 資訊，確保擁有最新的資料來源，以便正確下載所需的 Charts。
- 每次執行 CI/CD 流程前或在開發環境中準備佈署時，都應該執行此指令，以確保資料源正確。
- 執行 ct lint-and-install：
ct lint-and-install
內容解密：
- 該命令結合了 lint 和 install 的功能，能夠檢查和驗證已修改圖表中的版本號是否正確增加，並支援多個值檔案的測試。
- 執行過程中，會對每個修改過的 Chart 進行 lint 檢查和安裝測試，確保 Charts 的品質與可靠性。
Plantuml CT 工具工作流程
圖表翻譯：
此圖示展示了 CT 工具的工作流程。首先，檢測修改過的 Charts，接著更新本地 Helm 快取，然後下載修改過的 Charts 的依賴。之後，檢查版本號是否更新，最後對每個 Chart 進行 lint 檢查和測試。整個流程確保了 Charts 的品質與可靠性。
圖表翻譯：
此圖示展示了開發者提交變更後，CT 工具如何自動檢測修改過的 Charts 並執行測試。如果測試透過，則佈署到生產環境；如果測試未透過，則修復問題並重新提交。這個流程確保了只有經過嚴格測試的變更才會被佈署到生產環境，從而提高了佈署的可靠性和穩定性。
Helm 與 Kubernetes 整合佈署實務
在現代化的軟體開發流程中，持續整合（CI）與持續佈署（CD）是確保軟體品質與快速交付的關鍵環節。Helm 作為 Kubernetes 的套件管理工具，簡化了應用程式在 Kubernetes 叢集上的佈署與管理流程。本文將深入探討如何結合 Helm 與 Kubernetes，實作穩定高效的 CI/CD 流程。
Helm 基本操作與 CI/CD 整合
Helm 提供了一系列強大的命令來管理 Kubernetes 應用程式。以下是一些常見的操作及其在 CI/CD 中的應用：
建立 Chart 套件
$ helm create mychart內容解密：
- 此指令用於建立一個新的 Helm Chart 套件，預設包含基本的範本和設定檔。建立 Chart 是佈署應用程式的第一步。
- 在 CI/CD 流程中，我們可以根據需求自訂 Chart 內容，以適應不同的佈署環境。
建立依賴圖表
$ helm dependency build ./mychart/內容解密：
- 上述指令用於建立當前目錄內所有定義之 charts 的依賴圖表資料夾與檔案結構。這樣便於進行整合與佈署時自動下載及管理相關依賴套件。
- 在 CI/CD Pipeline 中特別重要，以確保所有相關依賴套件都能正確地被提取及安裝。
佈署與清除名稱空間
圖表翻譯：
此圖示展示了一個基本的佈署流程。首先建立名稱空間，接著佈署 Helm Chart，然後執行測試，最後清除名稱空間。這樣的流程確保了佈署環境的乾淨與隔離。
$ kubectl create namespace my-namespace && \ helm install my-release ./mychart --namespace my-namespace && \ helm test my-release --namespace my-namespace && \ kubectl delete namespace my-namespace內容解密：
- 前三句分別是建立名稱空間、佈署 Chart、執行測試流程；最後一句則用於清除所建立之名稱空間以避免環境汙染。
- 雖然佈署及清除部分可在 Pipeline 中實作自動化處理，但手動操作也能幫助開發者快速理解整合與佈署流程及其可能產生之錯誤訊息。
升級與迴歸測試
圖表翻譯：
此圖示展示了 Helm 升級與回復操作的流程。首先，Helm Client 向 Kubernetes Cluster 發出升級指令，接著 Cluster 回報升級狀態。然後進行測試並回報測試結果。如果需要回復，則執行回復操作並再次測試，最後回報最終的測試結果。
$ helm upgrade my-release ./mychart --namespace my-namespace && \ helm test my-release --namespace my-namespace && \ helm rollback my-release 1 --namespace my-namespace && \ helm test my-release --namespace my-namespace && \ kubectl delete namespace my-namespace內容解密：
- 前四句分別是升級、執行測試、回復至舊版、再次執行測試；最後一句則清除名稱空間以避免環境汙染。
- 這些操作確保了應用程式的穩定性，並能在出現問題時快速回復到之前的版本。
Yamale 安裝與 YAML 驗證
在進行 Helm Chart 的開發與佈署時，YAML 檔案的正確性至關重要。Yamale 是一個用於驗證 YAML 檔案的工具，可以幫助我們確保組態檔案的正確性。
- Yamale 安裝指令
$ pip install yamale內容解密：
- 上述指令使用 pip 安裝 Yamale。安裝 Yamale 後，可以用來驗證 YAML 檔案是否符合預期的 schema。
- Yamale 的安裝和使用相對簡單，是確保 YAML 檔案正確性的有效工具。
隨著雲原生技術的持續發展，Helm 與 Kubernetes 的整合將會更加緊密。未來，我們可以期待更多的自動化工具與最佳實踐的出現，進一步簡化 CI/CD 流程，提升開發效率與系統可靠性。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title Helm Charts 測試效能與可靠性提升
package "Kubernetes Cluster" {
package "Control Plane" {
component [API Server] as api
component [Controller Manager] as cm
component [Scheduler] as sched
database [etcd] as etcd
}
package "Worker Nodes" {
component [Kubelet] as kubelet
component [Kube-proxy] as proxy
package "Pods" {
component [Container 1] as c1
component [Container 2] as c2
}
}
}
api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2
note right of api
核心 API 入口
所有操作經由此處
end note
@enduml圖表翻譯：
此圖示展示了 CI/CD 流程。從當前狀態出發，透過持續整合、持續佈署、自動化測試、監控與回饋，最終實作持續改進，形成一個完整的 DevOps 迴圈。
透過本文的介紹與實務操作，希望能夠幫助讀者更好地理解與應用 Helm 與 Kubernetes，實作高效穩定的 CI/CD 流程。未來，我們將繼續探索更多的技術與實踐，以滿足不斷變化的業務需求。
