一、背景
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（https://helm.sh）是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，可以在https://hub.kubeapps.com裏找到。我們在開發自己的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的官方文檔，https://docs.helm.sh。
4、充分利用社區的力量
目前有很多開發者都在研究和實踐Helm，我們應該充分利用他們的經驗和成果，並積極地和他們溝通交流，從而提升我們使用Helm的效率和質量。
常用的用於Helm交流的社區包括：
- GitHub issues: https://github.com/helm/charts/issues
- Slack: #helm-users room in the Kubernetes Slack (https://kubernetes.slack.com/)
- Slack: #helm-dev room in the Kubernetes Slack (https://kubernetes.slack.com/)
四、Helm倉庫
下圖是Helm的應用架構：
其中，Tiller部署在Kubernetes環境中，執行應用部署等操作。而Helm作爲客戶端，完成Helm Chart的管理和部署任務的發佈。在這個架構中，Helm倉庫（Storage）保存了Helm部署所需要的各種Chart文件、依賴包和配置信息，在Helm部署過程中起到了十分重要的作用。
JFrog的Artifactory產品，作爲全球唯一提供Helm倉庫支持的統一製品管理倉庫，可以在爲Helm Chart提供倉庫支持的同時，爲相關製品，如docker鏡像、版本化的配置信息，以及各種依賴製品等提供一站式的統一服務和管理。而JFrog的Xray產品，集成Artifactory的統一製品倉庫，能夠實現安全漏洞的自動掃描及漏洞的影響範圍分析。
有關JFrog產品的詳細介紹、能力分析及用戶案例，請參考本公衆號的系列文章和官網的相關介紹（http://jfrogchina.com）。
五、總結
通過Kubernetes部署雲服務已經在業界的到了廣泛的應用。Helm通過其統一管理、配置與應用分離、版本化等特性能夠大大降低Kubernetes部署的難度，提升部署的效率和質量，也逐漸得到了衆多的關注和應用。
JFrog的Artifactory和Xray等產品能夠提供包含Helm倉庫在內的統一製品倉庫管理和安全漏洞掃描，在實現基於Helm的CI/CD流水線和自動化部署方案起到了重要的作用。Codefresh公司就利用JFrog的產品和相關工具搭建了自己產品的流水線並廣泛使用。
