1. 告別 Tiller

Helm 3 移除了 Tiller ，是個不錯的決定。但是要理解為什麼不錯，我們還需要了解一下 Tiiller 產生的背景。Tiller 是 Helm 的服務端元件（執行在 Kubernetes 叢集上），主要目的是為了讓多個不同的操作者能夠在同一個叢集上操作。開發 Helm 2 時，由於 Kubernetes 沒有基於角色的訪問控制（RBAC），Helm 不得不自己控制誰、在哪裡能夠安裝應用。直到 Kubernetes 1.6 中開啟了 RBAC ，這件事就變得簡單了。Helm 也不必與 Kubernetes 做重複的事情，因此 Helm 3 徹底移除了 Tiller 。

Tiller 作為維護 Helm 應用資訊和狀態的核心。Helm 3 直接從 Kubernetes API Server 就可以獲取到相同的資訊，並且在客戶端呈現 Charts 。對於 Kubernetes 來說，這種方式更加簡單而原生。

移除 Tiller 之後，Helm 的安全模型也變得簡單（使用 RBAC 來控制生產環境 Tiller 的許可權非常不易於管理）。Helm 3 使用 kubeconfig 鑑權。叢集管理員針對應用，可以設定任何所需級別的許可權控制，而其他功能保持不變。

2. 好吧，除了 Tiller ，還有什麼改變？

正如前面提到的，移除 Tiller 是一件大事，但不是唯一的一件。讓我們看看其他的。

2.1 三路合併補丁策略

Helm 2 使用的是兩路合併補丁策略。也就是，當你想執行任何 helm 操作時，比較最新的 chart 包與期望的 chart 包配置。這兩個包之間的不同，決定了應該調整 Kubernetes 中的哪些資源。聽起來不錯，對嗎？但是沒有考慮手動修改應用的情況（例如，使用 kubectl edit）。這將導致應用無法回滾到之前的狀態，因為 Helm 2 將最新的 chart 包當做最新的狀態，而最新的 chart 包裡面沒有改變（我們只是更新了應用在叢集的狀態），Helm 2 忽略了這一變化的回滾。

三路策略合併補丁可以解決這個問題。Helm 3 是如何做的呢？它只是多考慮了應用的線上狀態（使用三路替代兩路，舊的配置，線上狀態，新的配置）。例如，假設你部署了一個應用：

helm install very_important_app ./very_important_app

這個應用的副本數量設定為 3 。現在，如果有人不小心執行了 kubectl edit 或：

kubectl scale -replicas=0 deployment/very_important_app

然後，團隊中的某個人發現 very_important_app 莫名其妙宕機了，嘗試執行命令：

helm rollback very_important_app

在 Helm 2 中，這個操作將比較舊的配置與新的配置，然後生成一個更新補丁。由於，誤操作的人僅修改了應用的線上狀態（舊的配置並未更新）。Helm 在回滾時，什麼事情也不會做。因為舊的配置與新的配置沒有差別（都是 3 個副本）。然後，Helm 不執行回滾，副本數繼續保持為 0 。此時，你有些慌了…

另一方面，在 Helm 3 中，將使用舊的配置，線上狀態，新的配置生成更新補丁。Helm 發現舊的配置副本數是 3 ，線上狀態是 0 ，判斷出新的配置期望改回 3 ，因此生成一個更新補丁回滾。此時，你不那麼慌了…

使用 Helm 3 進行升級時，也會發生類似的過程。例如，某個基於控制器的應用（或類似服務網格）注入任何內容到 Helm 部署的 Kubernetes 物件中。在 Helm 2 中進行升級時，注入的內容將被移除。在 Helm 3 中，由於考慮到了線上狀態，注入的內容將會被保留。假設我們想要在叢集上安裝 Istio 。Istio 將 Sidecar 注入到每個部署中。使用 Helm 進行部署：

containers:- name: server  image: my_app:2.0.0

安裝 Istio 之後，你的容器定義看起來像這樣：

containers:- name: server  image: my_app:2.0.0- name: istio-sidecar  image: istio-sidecar-proxy:1.0.0

如果使用 Helm 2 進行升級，你將得到如下結果：

containers:- name: server  image: my_app:2.1.0

Istio Sidecar 由於不在配置中，將會被移除。然而，Helm 3 將基於舊的配置、線上狀態、新的配置生成一個更新補丁。Helm 3 會將 image 更新為 2.1.0 ，另外線上狀態還包含一些額外的配置。最終，使用 Helm 3 升級將得到你想要的：

containers:- name: server  image: my_app:2.1.0- name: istio-sidecar  image: istio-sidecar-proxy:1.0.0

三路策略合併補丁更新，讓 Helm 升級更加可控和安全。

2.2 Secrets 作為預設儲存器

Helm 2 使用 ConfigMaps 儲存應用的資訊。在 Helm 3 中，改為 Secrets （secret 型別為 helm.sh/release ）作為預設儲存器。這帶來了一些優勢，並極大簡化了 Helm 的功能。Helm 2 必須要經過一系列操作才能獲取（和應用）配置。這些配置加密、打包儲存在某一個 keys 或 ConfigMap 中。Helm 3 直接將配置儲存在 Secret ，無需執行復雜操作，只需要提取、解碼、使用即可。另一個優點是，應用名稱不必叢集唯一。包含應用資訊的 Secrets 儲存在應用安裝的 Namespace 中。因此，在不同的 Namespace 中，應用可以具有相同的名字。

2.3 JSON Schema 驗證 Chart 資訊

可以使用 JSON Schema 強制對 chart 中的 values 值進行校驗。基於此功能，你能夠確保使用者提供的 values 值符合 chart 包的要求。這給 OPS 與 DEV 創造了更多合作機會（OPS 團隊能給 DEVs 更大自由度），當用戶 values 值設定錯誤時，能夠給出更好的錯誤提示。

2.4 現在需要應用名字了

如果沒有提供應用名，在 Helm 2 中，將會隨機生成一個；在 Helm 3 中，將會報錯（如果還是想使用隨機名稱，可以加上 — generate-name 標識）。

2.5 移除了 Helm serve

本來就沒有很多人使用 helm serve（用來給開發，在機器上跑一個本地的 Chart Repository）。現在 helm serve 移除了。但是你仍然可以以外掛的形式安裝。

2.6 不再自動建立名稱空間

當在不存在的 Namespace 中建立應用時，Helm 2 將會自動建立 Namespace 。Helm 3 遵循其他 Kubernetes 工具的慣例，如果 Namespaces 不存在，則返回錯誤。