簡化Kubernetes應用部署工具
【編者的話】微服務和容器化給複雜應用部署與管理帶來了極大的挑戰。Helm是目前Kubernetes服務編排領域的唯一開源子專案，做為Kubernetes應用的一個包管理工具，可理解為Kubernetes的apt-get / yum，由Deis 公司發起，該公司已經被微軟收購。Helm通過軟體打包的形式，支援釋出的版本管理和控制，很大程度上簡化了Kubernetes應用部署和管理的複雜性。
隨著業務容器化與向微服務架構轉變，通過分解巨大的單體應用為多個服務的方式，分解了單體應用的複雜性，使每個微服務都可以獨立部署和擴充套件，實現了敏捷開發和快速迭代和部署。但任何事情都有兩面性，雖然微服務給我們帶來了很多便利，但由於應用被拆分成多個元件，導致服務數量大幅增加，對於Kubernetest編排來說，每個元件有自己的資原始檔，並且可以獨立的部署與伸縮，這給採用Kubernetes做應用編排帶來了諸多挑戰：
- 管理、編輯與更新大量的K8s配置檔案
- 部署一個含有大量配置檔案的複雜K8s應用
- 分享和複用K8s配置和應用
- 引數化配置模板支援多個環境
- 管理應用的釋出：回滾、diff和檢視釋出歷史
- 控制一個部署週期中的某一些環節
- 釋出後的驗證
Helm把Kubernetes資源(比如deployments、services或 ingress等) 打包到一個chart中，而chart被儲存到chart倉庫。通過chart倉庫可用來儲存和分享chart。Helm使釋出可配置，支援釋出應用配置的版本管理，簡化了Kubernetes部署應用的版本控制、打包、釋出、刪除、更新等操作。
本文簡單介紹了Helm的用途、架構與實現。
Helm產生原因
利用Kubernetes部署一個應用，需要Kubernetes原生資原始檔如deployment、replicationcontroller、service或pod 等。而對於一個複雜的應用，會有很多類似上面的資源描述檔案，如果有更新或回滾應用的需求，可能要修改和維護所涉及的大量資原始檔，且由於缺少對釋出過的應用版本管理和控制，使Kubernetes上的應用維護和更新等面臨諸多的挑戰，而Helm可以幫我們解決這些問題。
Helm架構
Helm基本架構如下：
Helm用途：
做為Kubernetes的一個包管理工具，Helm具有如下功能：
- 建立新的chart
- chart打包成tgz格式
- 上傳chart到chart倉庫或從倉庫中下載chart
- 在Kubernetes叢集中安裝或解除安裝chart
- 管理用Helm安裝的chart的釋出週期
Helm有三個重要概念：
- chart：包含了建立Kubernetes的一個應用例項的必要資訊
- config：包含了應用釋出配置資訊
- release：是一個chart及其配置的一個執行例項
Helm元件
Helm有以下兩個組成部分：
Helm Client是使用者命令列工具，其主要負責如下：
- 本地chart開發
- 倉庫管理
- 與Tiller sever互動
- 傳送預安裝的chart
- 查詢release資訊
- 要求升級或解除安裝已存在的release
Tiller Server是一個部署在Kubernetes叢集內部的server，其與Helm client、Kubernetes API server進行互動。Tiller server主要負責如下：
- 監聽來自Helm client的請求
- 通過chart及其配置構建一次釋出
- 安裝chart到Kubernetes叢集，並跟蹤隨後的釋出
- 通過與Kubernetes互動升級或解除安裝chart
簡單的說，client管理charts，而server管理髮布release。
Helm實現
Helm client
- Helm client採用go語言編寫，採用gRPC協議與Tiller server互動。
Helm server
- Tiller server也同樣採用go語言編寫，提供了gRPC server與client進行互動，利用Kubernetes client 庫與Kubernetes進行通訊，當前庫使用了REST+JSON格式。
- Tiller server 沒有自己的資料庫，目前使用Kubernetes的ConfigMaps儲存相關資訊
說明：配置檔案儘可能使用YAM格式
歡迎轉載，請註明作者出處：張夏，FreeWheel Lead Engineer，Kubernetes中文社群