背景
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 檔案，而這些目錄和檔案大緻可分為三個部分：
模闆
在 templates 目錄下存放着一組用來描述雲服務當中各個元件的 yaml 檔案，這和目前 kubernetes 的用法類似。helm 把這些 yaml 檔案組織在同一目錄，能夠很友善地了解目前雲服務的組成，結構清晰且便于管理。
配置與依賴
templates 目錄下的 yaml 檔案是不包含具體的配置資訊的，隻保留了對配置項（key）的引用。真正與目标環境對應的配置資訊（value）是存儲在 values.yaml 檔案裡的。當然，values.yaml 隻是存儲了一些預設的、靜态的配置資訊，在部署的過程中也可以動态地增加或修改這些配置資訊。這種配置與應用分離的設計使得同一套 templates 可以友善地部署到不同的目标環境中，隻需要更新 values.yaml 檔案或部署時動态修改配置資訊就可以了。
另外，針對某些已被廣泛使用的雲服務或元件，目前已經存在比較成熟、經過驗證的 helm chart 了。當使用到這些服務或元件時，可以直接在 requirements.yaml 檔案裡描述這種依賴關系。在部署的時候，helm 會自動擷取這些依賴的 helm chart 使用，并存儲在 charts 目錄。這種依賴性的設計，避免了很多重複性的工作，也使得 helm chart 的并行開發和共享成為可能。
版本化
每一個 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 也積累了一些經驗和最佳實踐。
配置與應用分離
針對所有的環境使用同樣的 helm chart，但是根據不同的環境配置自己特定的 values.yaml 檔案。同時，根據目标環境的變化對這些 values.yaml 檔案進行版本化的管理。
善用依賴
目前已經有很多産品和通用元件都實作了比較完善、經過驗證的 helm chart，可以在https://hub.kubeapps.com 裡找到。我們在開發自己的 helm chart 時，可以通過定義依賴來充分地利用這些已有的成果，在減少工作量的同時，也能提高産品的品質。
在實際部署前檢查 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。
充分利用社群的力量
目前有很多開發者都在研究和實踐 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 的産品和相關工具搭建了自己産品的流水線并廣泛使用。