一、背景

Kubernetes(k8s) 是一個基於容器技術的分散式架構領先方案。它在 Docker 技術的基礎上，為容器化的應用提供部署執行、資源排程、服務發現和動態伸縮等一系列完整功能，提高了大規模容器叢集管理的便捷性。

在容器雲環境及容器化服務在業界開始大規模部署應用的前提下，Kubernetes 在業界的實際應用情況又是怎樣的呢？在今年召開的JFrog SwampUp 使用者大會上，Codefresh 公司為大家展示了一些有意思的資料。如下圖：

據Codefresh 公司統計，在目前JFrog 的企業使用者當中，有80% 已經使用了Kubernetes ，這說明Kubernetes 已經得到了業界的認可並開始了廣泛的應用。然而，只有5% 的JFrog 使用者在生產環境中使用Kubernetes 。也就是說，企業更多的只是在自己的研發、測試環境中去使用 Kubernetes 。這是什麼原因呢？JFrog 透過自身在Kubernetes 應用上的大量實踐證明，“Kubernetes is hard ”，直接使用Kubernetes 去部署和管理容器化的雲服務，尤其是基於微服務的雲服務，是非常具有挑戰性的工作。

那如何才能更便捷地應用Kubernetes 呢？JFrog 選擇了Helm ，Kubernetes 的官方包管理工具。我們再來看Codefresh 提供的另一組資料，如下圖：

和上一組資料一樣，只有5% 的JFrog 企業使用者在生產環境使用了Kubernetes 。但同時，也有5% 的JFrog 使用者使用了Helm 。可見，當把Kubernetes 應用到生產環境的時候，眾多企業也和JFrog 一樣，選擇了Helm 這一“利器”。

為什麼Helm 會受到這樣的青睞？本文將透過JFrog 實施Helm 和Kubernetes 的實踐來介紹和分析Helm 的優勢所在。

 

二、 Helm 是什麼

在介紹Helm 之前，我們先來看看直接應用Kubernetes 部署雲服務會遇到哪些困難。

Kubernetes 使用yaml 檔案來描述和管理服務中各個元件的配置和部署需求，每個元件對應一個yaml 檔案。當下的雲服務通常都是由多個元件構成的，如何配置和處理好這些元件，也就是多個yaml 檔案之間的關聯關係，成為了Kubernetes 應用的額外任務。而當雲服務升級，卻僅僅涉及其中一個或某幾個模組時，升級模組的新yaml 檔案和已有yaml 檔案之間的關聯關係就會變得更加錯綜複雜，從而更增加了使用Kubernetes 來配置和管理升級的難度。

其次，Kubernetes 把元件的配置資訊也直接記錄到yaml 檔案當中。從描述元件的角度來講，這種方式確實比較清晰。但是，當雲服務的部署面對多個環境，如不同的開發、測試、產品環境（這也是當前比較常見的應用場景）時，要如何處理這些環境配置之間的差別？要為每個環境都開發和維護一套不同的yaml 檔案？這顯然大大增加了應用Kubernetes 的難度和工作量。

而且，Kubernetes 的yaml 檔案本身是沒有版本的概念的。那麼當某次部署失敗，需要回滾到上一個穩定版本時，該選擇哪一套yaml 檔案來處理？顯然，這需要很多額外的工作來處理。

那 Helm 是如何來解決這些問題的呢？

Helm （ ）是Kubernetes 的官方包管理工具。Helm 是透過被稱作Helm Chart 的包來描述和管理雲服務的。Helm Chart 對應的是一組結構化的目錄和yaml 檔案，而這些目錄和檔案大致可分為三個部分：

1 、模板

在templates 目錄下存放著一組用來描述雲服務當中各個元件的yaml 檔案，這和目前Kubernetes 的用法類似。Helm 把這些yaml 檔案組織在同一目錄，能夠很方便地瞭解當前雲服務的組成，結構清晰且便於管理。

2 、配置與依賴

templates 目錄下的yaml 檔案是不包含具體的配置資訊的，只保留了對配置項（key ）的引用。真正與目標環境對應的配置資訊（value ）是儲存在values.yaml 檔案裡的。當然，values.yaml 只是儲存了一些預設的、靜態的配置資訊，在部署的過程中也可以動態地增加或修改這些配置資訊。這種配置與應用分離的設計使得同一套templates 可以方便地部署到不同的目標環境中，只需要更新values.yaml 檔案或部署時動態修改配置資訊就可以了。

另外，針對某些已被廣泛使用的雲服務或元件，目前已經存在比較成熟、經過驗證的Helm Chart 了。當使用到這些服務或元件時，可以直接在requirements.yaml 檔案裡描述這種依賴關係。在部署的時候，Helm 會自動獲取這些依賴的Helm Chart 使用，並儲存在charts 目錄。這種依賴性的設計，避免了很多重複性的工作，也使得Helm Chart 的並行開發和共享成為可能。

3 、版本化

每一個Helm Chart 包都可以在Chart.yaml 檔案裡定義自己的版本。另外，每一次 Helm 的部署都會自動生成一個版本（release ）。使用Helm 的命令，可以方便地實現這些已部署版本的查詢、升級、回滾和其他管理任務。

三、 Helm 的應用實踐

透過上面對 Helm 的介紹和分析可以看出， Helm 能夠很好地解決 Kubernetes 應用部署的難題。 JFrog 在自己的 Kubernetes 實踐當中也充分使用了 Helm 。

目前，在JFrog 各個產品自身的CI/CD 流水線上都使用Helm 進行Kubernetes 上的部署，已經可以實現每週100+ 不同產品線的任意版本組合部署，每次部署超過50 種微服務。JFrog 也將為客戶提供這些Helm Chart ，以幫助客戶在Kubernetes 環境快速部署JFrog 的各種產品。

在實踐Helm 的過程中，JFrog 也積累了一些經驗和最佳實踐。

1 、配置與應用分離

針對所有的環境使用同樣的Helm Chart ，但是根據不同的環境配置自己特定的values.yaml 檔案。同時，根據目標環境的變化對這些values.yaml 檔案進行版本化的管理。

2 、善用依賴

目前已經有很多產品和通用元件都實現了比較完善、經過驗證的Helm Chart ，可以在 裡找到。我們在開發自己的Helm Chart 時，可以透過定義依賴來充分地利用這些已有的成果，在減少工作量的同時，也能提高產品的質量。

3 、在實際部署前檢查Helm Chart

Helm 提供了很多實用的命令來幫助我們在實際部署之前檢查Helm Chart 裡的錯誤，降低使用的風險。比如：

·        helm lint <chart path>

helm lint 可以用來檢查下載的Helm Chart 是否存在問題

·        helm install –debug –dry-run <chart>

helm install 帶上dry-run 引數可以在不實際執行部署的情況下檢查Helm Chart 的各種配置是否正確

Helm 的各種命令及其具體用法請參考Helm 的官方文件， 。

4 、充分利用社群的力量

目前有很多開發者都在研究和實踐Helm ，我們應該充分利用他們的經驗和成果，並積極地和他們溝通交流，從而提升我們使用Helm 的效率和質量。

常用的用於 Helm 交流的社群包括：

·        GitHub issues: 

·        Slack: #helm-users room in the Kubernetes Slack ( )

·        Slack: #helm-dev room in the Kubernetes Slack ( )

四、 Helm 倉庫

下圖是 Helm 的應用架構：

其中，Tiller 部署在Kubernetes 環境中，執行應用部署等操作。而Helm 作為客戶端，完成Helm Chart 的管理和部署任務的釋出。在這個架構中，Helm 倉庫（Storage ）儲存了Helm 部署所需要的各種Chart 檔案、依賴包和配置資訊，在Helm 部署過程中起到了十分重要的作用。

JFrog 的Artifactory 產品，作為全球唯一提供Helm 倉庫支援的統一製品管理倉庫，可以在為Helm Chart 提供倉庫支援的同時，為相關製品，如docker 映象、版本化的配置資訊，以及各種依賴製品等提供一站式的統一服務和管理。而JFrog 的Xray 產品，整合Artifactory 的統一製品倉庫，能夠實現安全漏洞的自動掃描及漏洞的影響範圍分析。

有關JFrog 產品的詳細介紹、能力分析及使用者案例，請參考本公眾號的系列文章和官網的相關介紹（ ）。

五、總結

透過Kubernetes 部署雲服務已經在業界的到了廣泛的應用。Helm 透過其統一管理、配置與應用分離、版本化等特效能夠大大降低Kubernetes 部署的難度，提升部署的效率和質量，也逐漸得到了眾多的關注和應用。

JFrog 的Artifactory 和Xray 等產品能夠提供包含Helm 倉庫在內的統一製品倉庫管理和安全漏洞掃描，在實現基於Helm 的CI/CD 流水線和自動化部署方案起到了重要的作用。Codefresh 公司就利用JFrog 的產品和相關工具搭建了自己產品的流水線並廣泛使用。