因此，helm3終於被釋放了。每個人都向蒂勒說再見，但這並不是helm3的唯一變化。讓我們討論其他變化。
是的，tiller已被刪除，這是一件好事，但要了解為什麼我們需要獲得一些背景知識。 tiller是helm的伺服器端（在kubernetes集群上執行）元件，其主要目的是使多個不同的運營商可以使用同一組發行版。
在開發helm 2時，kubernetes還沒有基於角色的訪問控制（rbac），因此要實現上述目標，helm必須自己照顧自己。 它必須跟蹤允許誰在**安裝什麼。
不再需要這種複雜性，因為預設情況下從kubernetes 1.6啟用了rbac，因此helm不需要執行kubernetes可以完成的相同工作，這就是為什麼在helm 3分er中將其完全刪除了的原因。
提勒還被用作helm發布資訊和維護helm狀態的**樞紐。 在helm 3中，直接從kubernetes api server中獲取了相同的資訊，並且在客戶端呈現了charts，這使得helm 3對於kubernetes而言更「原生」且更簡單。
隨著tiller的消失，helm的安全模型也得到了簡化（通過啟用rbac來鎖定tiller以用於生產場景中，這很難管理）。 現在可以使用kubeconfig檔案簡單地評估頭盔許可權。
因此，當版本仍記錄在群集中時，群集管理員可以將使用者許可權限制在所需的任何級別，而helm的其餘功能保持不變。
正如我在開始時提到的-移除tiller是一件大事，但不是唯一的重大改變。
讓我們來看看其他：
三路戰略合併補丁
頭盔2使用了雙向戰略合併補丁。 這意味著，當您要執行任何舵操作時，會將最新清單清單與建議的圖表清單進行比較。 它檢查了這兩個圖表之間的差異，以確定需要對kubernetes中的資源應用哪些更改。
聽起來很聰明，對不對？ 問題在於，如果更改是「手動」應用於集群的（例如通過kubectl edit ），則不會考慮更改 。 這導致資源無法回滾到其先前狀態，因為helm2僅將最後應用的圖表清單作為其當前狀態進行檢查，並且由於圖表狀態沒有變化（我們僅更改了集群上的活動狀態），helm只是做了沒有看到執行回滾的需要。
以上就是三路戰略合併補丁的發布。 helm3如何做到這一點？ 它也簡單地考慮了活動狀態（因此從現在起我們有了舊清單，它的活動狀態和新清單，因此是3路而不是2路）。
例如，假設您部署了具有以下功能的應用程式：
在helm 2中，它將生成乙個補丁，將舊清單與新清單進行比較。 因為這是回滾，並且某人僅更改了活動狀態（因此清單未更改），helm會確定沒有要回滾的內容，因為舊清單和新清單之間沒有區別（兩者都希望有3個副本）。
然後不執行回滾，副本數繼續保持為零。
您現在開始驚慌失措...
另一方面，在helm 3中，將使用舊清單，活動狀態和新清單生成補丁。 helm認識到舊狀態為3，活動狀態為0，因此它確定新清單希望將其更改回3，因此它生成補丁來解決該問題。
你現在別驚慌了...
執行公升級時，helm 3也會發生類似的過程。 由於現在考慮了活動狀態，因此，例如，如果某個基於控制器的應用程式（或類似服務網格）將任何東西注入到通過helm部署的kubernetes物件中，則將在使用helm2進行helm公升級過程中將其刪除。
helm 3並沒有這樣做-再次考慮了實時狀態。 假設我們要在群集上安裝例如istio。 istio將開始將sidecar容器注入任何部署中，因此，假設您使用helm進行部署，並且部署包括：
containers:
- name: server
image:
然後，您安裝了istio，因此您的容器定義現在看起來像這樣：
containers:
- name: server
image:
- name: istio-sidecar
image:
istio-sidecar-proxy:1.0.0
而且，如果您現在使用helm2執行公升級過程，您將得到以下結果：
containers:
- name: server
image:
istio邊車被刪除，因為它不在圖表中。 但是，helm 3會在舊清單，活動狀態和新清單之間生成容器物件的補丁。 它注意到新清單將image標記更改為2.1.0，但是活動狀態包含一些額外內容。
因此，使用helm 3進行公升級將如您所願：
containers:
- name: server
image:
- name: istio-sidecar
image:
istio-sidecar-proxy:1.0.0
三向戰略合併補丁使helming方式更可**且更安全。 如果有香蕉，您不必擔心。
秘密作為預設儲存驅動程式
helm 2使用configmaps儲存發行資訊。 在helm 3中，將使用secrets（秘密型別為helm.sh/release ）作為預設儲存驅動程式。 這帶來了一些優勢，並大大簡化了helm的功能。 為了獲得（並應用）配置，helm2必須執行一些操作，因為config本身已加密儲存並儲存在金鑰或configmap之一中。
helm3將配置直接儲存在secret中，因此它無需執行多個操作即可獲取它，而只需提取金鑰，解密並應用即可。 另乙個優點是，發布名稱在整個集群中不再必須唯一。 包含發行版的機密儲存在安裝發行版的命名空間中。 因此，一旦它們位於不同的命名空間中，便可以擁有多個具有相同名稱的發行版。
json架構圖驗證
現在可以對圖表值強制進行json模式驗證。 使用該功能，您可以確保使用者提供的值遵循圖表維護者建立的架構。
這為ops與dev的合作創造了更多可能性（ops團隊可以為dev提供更大的自由度），並且當使用者嘗試為圖表使用一組錯誤的值時，可以提供更好的錯誤報告。
現在需要發布名稱
在頭盔2中，如果未提供名稱，則會生成乙個隨機名稱。 如果在頭盔安裝中未提供任何名稱，頭盔3將丟擲錯誤（最終，如果您仍想使用隨機名稱，則可以使用– generate-name標誌）
舵服務已刪除
很少有人使用舵機服務（
為開發目的而在您的計算機上執行本地chart repository ），但對於那些這樣做的人-現在已將其刪除。 儘管您仍然可以將其用作外掛程式。
命名空間不再自動建立
在不存在的命名空間中建立發行版時，helm 2會自動建立它。 helm 3遵循其他kubernetes工具的行為，如果命名空間不存在，則返回錯誤。
那是helm最重要的變化，還有更多變化。 如果您有興趣，請檢視helm官方文件 。 在第2部分中，我將向您展示如何從helm2遷移到helm3。
from:
iwh頭盔 頭盔2與頭盔3 第1部分
iwh頭盔 因此，helm3終於被釋放了。每個人都向蒂勒說再見，但這並不是helm3的唯一變化。讓我們討論其他變化。是的，tiller已被刪除，這是一件好事，但要了解為什麼我們需要獲得一些背景知識。tiller是helm的伺服器端 在kubernetes集群上執行 元件，其主要目的是使多個不同的運營...
Microformats教程 第3部分
本文首發於 http www.lunaticsun.com article microformats three 目前，這個系列已經有兩篇文章了，它們是 什麼是microformats microformats教程 第1部分 microformats教程 第2部分 在這一部分中，我們將討論一種全新的...
Hibernate硬事實第1部分
hibernate是乙個廣泛使用的orm框架。許多組織在其專案中使用它來管理其資料訪問層。但是，許多使用hibernate的開發人員並不完全了解其功能的全部內容。這是第1 週後在hibernate中鐵的事實集中series.other職位包括 hibernate硬事實第1部分 本文 hibernat...