k8s的包管理

一、Helm的概念和架構

每一個成功的軟件平臺都有一個優秀的打包系統，好比 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 則是 Kubernetes 上的包管理器。

 

思考？？Helm 到底解決了什麼問題？爲何 Kubernetes 須要 Helm？

 

Kubernetes 可以很好地組織和編排容器，但它缺乏一個更高層次的應用打包工具，而 Helm 就是來幹這件事的。

 

舉個例子，咱們須要部署一個MySQL服務，Kubernetes則須要部署如下對象：

 

① 爲了可以讓外界訪問到MySQL，須要部署一個mysql的service；

 

②須要進行定義MySQL的密碼，則須要部署一個Secret；

 

③Mysql的運行須要持久化的數據存儲，此時還須要部署PVC；

 

④保證後端mysql的運行，還須要部署一個Deployment，以支持以上的對象。

 

針對以上對象，咱們可使用YAML文件進行定義並部署，可是僅僅對於單個的服務支持，若是應用須要由一個甚至幾十個這樣的服務組成，而且還須要考慮各類服務的依賴問題，可想而知，這樣的組織管理應用的方式就顯得繁瑣。爲此就誕生了一個工具Helm，就是爲了解決Kubernetes這種應用部署繁重的現象。

 

Helm的核心術語：

 

Chart：一個helm程序包，是建立一個應用的信息集合，包含各類Kubernetes對象的配置模板、參數定義、依賴關係、文檔說明等。能夠將Chart比喻爲yum中的軟件安裝包；

Repository：Charts倉庫，用於集中存儲和分發Charts；

Config：應用程序實例化安裝運行時所須要的配置信息；

Release：特定的Chart部署於目標集羣上的一個實例，表明這一個正在運行的應用。當chart被安裝到Kubernetes集羣，就會生成一個release，chart能夠屢次安裝到同一個集羣，每次安裝都是一個release。

Helm的程序架構：

 

Helm主要由Helm客戶端、Tiller服務器和Charts倉庫組成，以下圖：

 

helm：客戶端，GO語言編寫，實現管理本地的Chart倉庫，可管理Chart，與Tiller服務進行交互，用於發送Chart，實例安裝、查詢、卸載等操做。

Tiller：服務端，一般運行在K8S集羣之上。用於接收helm發來的Charts和Conifg，合併生成release，完成部署。

簡單的說：Helm 客戶端負責管理 chart；Tiller 服務器負責管理 release。