本章我們將學習 Helm，Kubernetes 的包管理器。
每個成功的軟件平臺都有一個優秀的打包系統，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 則是 Kubernetes 上的包管理器。
本章我們將討論爲什麼需要 Helm，它的架構和組件，以及如何使用 Helm。
Why Helm
Helm 到底解決了什麼問題？爲什麼 Kubernetes 需要 Helm？
答案是：Kubernetes 能夠很好地組織和編排容器，但它缺少一個更高層次的應用打包工具，而 Helm 就是來幹這件事的。
先來看個例子。
比如對於一個 MySQL 服務， Kubernetes 需要部署下面這些對象：
-
Service，讓外界能夠訪問到 MySQL。
![]()
-
Secret，定義 MySQL 的密碼。
![]()
-
PersistentVolumeClaim，爲 MySQL 申請持久化存儲空間。
![]()
-
Deployment，部署 MySQL Pod，並使用上面的這些支持對象。
![]()
我們可以將上面這些配置保存到對象各自的文件中，或者集中寫進一個配置文件，然後通過 kubectl
apply -f 部署。
到目前爲止，Kubernetes 對服務的部署支持得都挺好，如果應用只由一個或幾個這樣的服務組成，上面的部署方式完全足夠了。
但是，如果我們開發的是微服務架構的應用，組成應用的服務可能多達十個甚至幾十上百個，這種組織和管理應用的方式就不好使了：
-
很難管理、編輯和維護如此多的服務。每個服務都有若干配置，缺乏一個更高層次的工具將這些配置組織起來。
-
不容易將這些服務作爲一個整體統一發布。部署人員需要首先理解應用都包含哪些服務，然後按照邏輯順序依次執行
kubectl apply。即缺少一種工具來定義應用與服務，以及服務與服務之間的依賴關係。 -
不能高效地共享和重用服務。比如兩個應用都要用到 MySQL 服務，但配置的參數不一樣，這兩個應用只能分別拷貝一套標準的 MySQL 配置文件，修改後通過
kubectl apply部署。也就是說不支持參數化配置和多環境部署。 -
不支持應用級別的版本管理。雖然可以通過
kubectl rollout undo進行回滾，但這隻能針對單個 Deployment，不支持整個應用的回滾。 -
不支持對部署的應用狀態進行驗證。比如是否能通過預定義的賬號訪問 MySQL。雖然 Kubernetes 有健康檢查，但那是針對單個容器，我們需要應用（服務）級別的健康檢查。
Helm 能夠解決上面這些問題，Helm 幫助 Kubernetes 成爲微服務架構應用理想的部署平臺。
下一節我們討論 Helm 的架構。
書籍：
1.《每天5分鐘玩轉Kubernetes》
https://item.jd.com/26225745440.html
2.《每天5分鐘玩轉Docker容器技術》
https://item.jd.com/16936307278.html
3.《每天5分鐘玩轉OpenStack》
https://item.jd.com/12086376.html
