作者 | Ray Elenteny譯者 | 鼕雨策劃 | 褚杏娟當提到 Helm 時 我們常常會做這樣的類比：Helm 之於 Kubernetes 詳解 Kubernetes 包管理工具 Helm - 趣味新聞網

作者 | Ray Elenteny

譯者 | 鼕雨

策劃 | 褚杏娟

當提到 Helm 時，我們常常會做這樣的類比：Helm 之於 Kubernetes，就像 apt 之基於 debian 的係統，yum 或 rpm 之於基於 Red Hat 的係統一樣。除瞭包管理之外，Helm 還內置瞭配置管理的許多內容。

Helm 是針對 Kubernetes 的一款包管理工具，最初是由一傢名為 Deis 的公司開發的，後來被微軟收購。微軟全力支持 Helm，加快瞭它的開發速度，現在它是雲本地計算基金會 (CNCF) 的一部分。

圖片來源:“Helm history”――2018 年 5 月，在 CNCF TOC 上 Helm 項目的演示幻燈片

作為 CNCF 的一部分，Helm 得到瞭眾多組織的積極開發和支持，並由此發展齣一個龐大而活躍的社區。以下是 Helm 截至 2021 年 10 月的項目貢獻統計數據示例：

錶資料來源：中國石油天然氣基金發展統計項目《項目總體統計錶》

1

為什麼 Kubernetes 需要一個包管理器？

大多數技術都是以“Hello World”的示例來引入關鍵概念，Kubernetes 也不例外。除最簡單的組件以外，將任何組件部署到 Kubernetes 集群都需要跨多個組件進行協調。

比如，管理 Kubernetes 集群外的應用程序部署的過程並不復雜，然而由於存在依賴關係和依賴版本、配置工件、部署前和部署後的步驟、驗證等，這就變成一項繁瑣的工作瞭。正如 apt 和 yum 是為 Linux 管理該過程一樣，Helm 為 Kubernetes 處理這個過程。

總的說來，Helm 特性具有以下特性：

Kubernetes 管理組件和應用程序的部署生命周期

基於模闆的定義，支持跨部署環境 (例如，開發、質保、生産) 的可移植性

鈎子機製可以在部署生命周期的不同階段注入特定於用例的代碼

部署測試框架

2

Helm 的結構

使用 Helm 隻需要安裝一個可執行文件。helm 命令提供瞭 20 多個參數，用於構建、部署、刪除、迴滾等，將應用程序部署到 Kubernetes 集群中。

Helm 部署構件是 Helm Chart。Helm Chart 由用於將組件或應用程序部署到 Kubernetes 集群的資源組成。Chart 中最常見的資源是 YAML 文件，它遵循標準的 Kubernetes 資源描述。如果你能夠很熟練地使用 kubectl create 或者 kubectl apply 命令部署到 Kubernetes 集群，那麼就會覺得 Helm Chart 中的 YAML 文件看起來很熟悉。Helm Chart 通常包含額外的資源，如 README 文件、默認參數文件和部署所需的額外文件 (如證書)。

開發 Helm Chart 需要使用預定義的目錄結構組織文件。可以用 Helm 命令 helm create創建一個 Helm chart，它是預定義的目錄結構，包含一些示例文件。生成的 chart 包含幾個 YAML 文件。一個 Kubernetes 部署通常需要多個要部署的 Kubernetes 資源描述，在許多情況下，這些部署必須有一個優先級順序。當手動部署時，必須知道順序。而 Helm 則不必如此，因為 Helm 知道 Kubernetes 資源描述的優先順序。

Helm 部署過程的一個關鍵特性是 Chart Hooks。在 Helm Chart 的部署生命周期中，Chart hook 是一種執行額外任務的機製。Helm 支持以下幾點來引入圖 Chart Hook:

錶格來源:“有用的鈎子――Chart Hook”，Helm Chart 可以依賴於其他 Helm Chart

例如，一個應用程序可能包含對一組微服務的依賴，其中的微服務由他自己的 Helm Chart 定義。當應用程序部署時，Helm 會管理這些依賴項。為瞭與微服務模式保持一緻，每個組件都可以獨立於其他組件進行更新，因此它仍然是內聚的應用程序的集閤的定義。

3

規劃 Helm 部署

Helm 在應用程序開發和部署的各個方麵都能夠發揮作用，這需要工程和運營團隊緊密閤作，以設計解決方案並迴答部署問題。通過團隊協調，可以迭代地做齣部署決策，以使用單個部署包來支持每個環境的目標以適應每個部署環境中的差異。

除瞭前麵描述的鈎子概念之外，Helm 還提供瞭一種健壯的模闆機製，使團隊能夠解決單一部署包的挑戰。通常，Helm Chart 中的 YAML 文件看起來不像手寫的 YAML Kubernetes 資源描述。

相反，Helm Chart 中的 YAML 文件是使用 Helm 的模闆語言開發的：

這個由 helm create 生成的被模闆化的 ingress 描述示例，提供瞭幾個變量，用來定義和配置 ingress 資源，包括是否應該創建 ingress 資源。通過模闆，Helm 提供瞭對 Kubernetes 資源如何部署的大量控製。規劃良好的模闆模式可以生成單個部署包，使 Helm Chart 能夠成功部署，範圍從開發人員工作站上的單節點 Kubernetes 集群到生産 Kubernetes 集群。

4

Helm Chart 和 CI/CD

作為組織持續集成 / 持續交付管道的一部分，Helm 扮演著促成者和組件的角色。作為一個推動者，它通過成為跨環境 (工程、質保、交付、認證、生産等) 部署應用程序或組件的機製來增強管道。在 CI/CD 管道中，自動化的 Helm Chart 部署非常簡單。

Helm Chart 作為一個應用程序組件，也像應用程序代碼一樣是迭代開發和部署的。這意味著 CI/CD 管道在驗證 Helm Chart 本身時是不可或缺的。事實上，Helm Chart 應該被視為應用程序代碼的一部分，而不是應用程序開發過程的外圍部分――甚至應該將 Helm Chart 作為應用程序源代碼的一部分納入管理。與應用程序構建生成版本化的容器映像並將其推送到鏡像注冊錶的方式類似，helm package 將 chart 綁定到版本化的歸檔文件中。生成的歸檔文件被提交到 Helm Chart 存儲庫，可以從該存儲庫訪問它以進行部署。

上圖突齣強調瞭應用程序軟件開發生命周期中的各個階段。無論使用哪種模式來管理 Helm Chart 的源代碼，它在應用程序 CI/CD 管道中與應用程序本身一樣不可或缺。

5

結束語

Helm 一直是 Kubernetes 生態係統炒作麯綫的一部分，隨著 Kubernetes 炒作麯綫開始變平，Helm 也已經成熟。Helm 的方法是革命性的嗎？不完全是。Helm 利用多年積纍瞭大量的軟件包和配置管理工具的知識，現在將這些經驗帶給 Kubernetes。同時，Helm 通過 Helm Chart 定義部署包的觀點對組織 CI/CD 管道的效率産生瞭直接影響，最顯著的是配置模式和部署靈活性。設計良好的 Helm Chart 是有效交付的重要組成部分。

https://dzone.com/articles/kubernetes-package-management-with-helm?