筆記。 翻譯。：今年 16 月 3.0 日標誌著 Kubernetes 套件管理器 Helm 開發的一個重要里程碑。 這一天，該專案未來主要版本的第一個 alpha 版本 - XNUMX - 發布了。 它的發布將為 Helm 帶來期待已久的重大變化，Kubernetes 社群的許多人對此寄予厚望。 我們自己就是其中之一，因為我們積極使用 Helm 進行應用程式部署：我們已將其整合到我們用於實施 CI/CD 的工具中 不時為上游的發展做出自己的貢獻。 此翻譯結合了來自 Helm 官方部落格的 7 個註釋，這些註釋致力於 Helm 3 的第一個 alpha 版本，並談論該專案的歷史和 Helm 3 的主要功能。它們的作者是 Microsoft 員工 Matt “bacongobbler” Fisher也是Helm 的主要維護者之一。
15 年 2015 月 2 日，現在稱為 Helm 的專案誕生了。 成立僅一年後，Helm 社群就加入了 Kubernetes，同時積極致力於 Helm 2018。XNUMX 年 XNUMX 月，Helm 作為一個正在開發（孵化）的項目。 快進到現在，新 Helm 3 的第一個 alpha 版本即將發布。 （本次發布 五月中旬 - 大約。 譯）.
在這篇文章中，我將討論這一切是從哪裡開始的，我們如何達到今天的水平，介紹 Helm 3 第一個 alpha 版本中提供的一些獨特功能，並解釋我們計劃如何向前推進。
概括：
- Helm 的創建歷史；
- 向蒂勒溫柔地告別；
- 圖表儲存庫；
- 發布管理;
- 圖表依賴性的變化；
- 圖書館圖表；
- 下一步是什麼？
頭盔的歷史
分娩
Helm 1 最初是由 Deis 創建的開源專案。 我們是一家小型新創公司 微軟，2017 年春季。 我們的另一個開源項目，也稱為 Deis，有一個工具 deisctl，它被用來（除其他外）安裝和操作 Deis 平台 。 當時，Fleet 是最早的容器編排平台之一。
2015 年年中，我們決定改變路線，將 Deis（當時更名為 Deis Workflow）從 Fleet 遷移到 Kubernetes。 第一個重新設計的是安裝工具。 deisctl。 我們用它來安裝和管理 Fleet 叢集中的 Deis Workflow。
Helm 1 是按照 Homebrew、apt 和 yum 等著名套件管理器的形象創建的。 其主要目標是簡化在 Kubernetes 上打包和安裝應用程式等任務。 Helm 於 2015 年在舊金山 KubeCon 會議上正式推出。
我們對 Helm 的第一次嘗試取得了成功，但也存在一些嚴重的限制。 他採用了一組 Kubernetes 清單，並使用生成器作為介紹性 YAML 區塊 （前題）*，並將結果載入到 Kubernetes 中。
* 筆記。 翻譯。：從 Helm 第一個版本開始，選擇 YAML 語法來描述 Kubernetes 資源，在編寫設定時支援 Jinja 範本和 Python 腳本。 我們在「Helm 簡史」一章中詳細介紹了這一點以及 Helm 第一個版本的整體結構 .
例如，要替換 YAML 檔案中的字段，您必須將以下構造新增至清單：
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml今天模板引擎的存在真是太好了，不是嗎？
由於多種原因，這個早期的 Kubernetes 安裝程式需要一個硬編碼的清單檔案列表，並且只執行一小部分固定的事件序列。 由於使用起來非常困難，Deis Workflow 研發團隊在嘗試將產品轉移到這個平台時遇到了困難——然而，這個想法的種子已經播下。 我們的第一次嘗試是一個很好的學習機會：我們意識到我們真正熱衷於創建實用的工具來解決用戶的日常問題。
基於過去錯誤的經驗，我們開始開發 Helm 2。
製作頭盔 2
2015年底，Google團隊聯繫了我們。 他們正在為 Kubernetes 開發類似的工具。 Kubernetes 的 Deployment Manager 是用於 Google Cloud Platform 的現有工具的連接埠。 “我們願意，”他們問道，“花幾天時間來討論相似點和不同點嗎？”
2016 年 2 月，Helm 和部署管理者團隊在西雅圖會面交流想法。 談判以一個雄心勃勃的計劃結束：將兩個項目結合起來創建 Helm XNUMX。與 Deis 和 Google 一起，來自 （現在是 Bitnami 的一部分 - 大約翻譯），然後我們開始開發 Helm 2。
我們希望保持 Helm 的易用性，但添加以下內容：
- 用於客製化的圖表模板；
- 團隊的集群內管理；
- 世界一流的圖表存儲庫；
- 具有簽名選項的穩定包格式；
- 對語意版本控制和維護版本之間的向後相容性的堅定承諾。
為了實現這些目標，Helm 生態系中加入了第二個元素。 這個叢集內元件稱為 Tiller，負責安裝 Helm 圖表並管理它們。
自 2 年發布 Helm 2016 以來，Kubernetes 增加了幾項重大創新。 新增了基於角色的存取控制（），最終取代了基於屬性的存取控制（ABAC）。 引入了新的資源類型（部署當時仍處於測試階段）。 自訂資源定義（最初稱為第三方資源或 TPR）被發明。 最重要的是，已經出現了一套最佳實踐。
在所有這些變化中，Helm 繼續忠實地為 Kubernetes 用戶服務。 經過三年的時間和許多新的補充，很明顯是時候對程式碼庫進行重大更改，以確保 Helm 能夠繼續滿足不斷發展的生態系統不斷增長的需求。
向蒂勒溫柔告別
在 Helm 2 的開發過程中，我們引入了 Tiller 作為與 Google 部署管理器整合的一部分。 Tiller 對於在公共叢集中工作的團隊發揮了重要作用：它允許操作基礎架構的不同專家與同一組版本互動。
由於 Kubernetes 1.6 中預設啟用基於角色的存取控制 (RBAC)，因此在生產中使用 Tiller 變得更加困難。 由於可能的安全性策略數量龐大，我們的立場是預設提供寬鬆的配置。 這使得新手可以嘗試 Helm 和 Kubernetes，而無需先深入研究安全設定。 不幸的是，這種權限配置可能會賦予使用者太多他們不需要的權限。 在多租戶叢集中安裝 Tiller 時，DevOps 和 SRE 工程師必須學習額外的操作步驟。
在了解社群在特定情況下如何使用 Helm 後，我們意識到 Tiller 的發布管理系統不需要依賴叢集內元件來維護狀態或充當發布資訊的中心樞紐。 相反，我們可以簡單地從 Kubernetes API 伺服器接收訊息，在客戶端產生圖表，並將安裝記錄儲存在 Kubernetes 中。
如果沒有 Tiller，Tiller 的主要目標也可以實現，因此我們對 Helm 3 的第一個決定就是完全放棄 Tiller。
Tiller 消失後，Helm 的安全模型得到了徹底簡化。 Helm 3 現在支援目前 Kubernetes 的所有現代安全、身分和授權方法。 Helm 權限是透過以下方式決定的 。 叢集管理員可以將使用者權限限製到任何粒度等級。 版本仍然保存在叢集中，並且 Helm 的其餘功能保持不變。
圖表儲存庫
從較高層次來看，圖表儲存庫是可以儲存和共享圖表的地方。 Helm 用戶端打包圖表並將其傳送至儲存庫。 簡而言之，圖表存儲庫是一個原始的 HTTP 伺服器，帶有一個 index.yaml 檔案和一些打包的圖表。
雖然 Charts Repository API 在滿足最基本的儲存要求方面有一些優點，但也有一些缺點：
- 圖表儲存庫與生產環境中所需的大多數安全實作不相容。 在生產場景中，擁有用於身份驗證和授權的標準 API 極為重要。
- Helm 的圖表來源工具用於簽署、驗證圖表的完整性和來源，是圖表發布過程的可選部分。
- 在多用戶場景中，同一圖表可以由另一個用戶上傳，從而使儲存相同內容所需的空間量增加一倍。 已經開發了更聰明的儲存庫來解決這個問題，但它們不是正式規範的一部分。
- 使用單一索引檔案來搜尋、儲存元資料和檢索圖表使得開發安全的多用戶實現變得困難。
項目 （也稱為 DockerRegistry v2）是 DockerRegistry 的後繼者，本質上充當一組用於打包、運輸、儲存和交付 Docker 映像的工具。 許多大型雲端服務都提供基於分發的產品。 由於越來越多的關注，發行版專案受益於多年的改進、安全最佳實踐和現場測試，使其成為開源世界最成功的無名英雄之一。
但您是否知道分發項目旨在分發任何形式的內容，而不僅僅是容器映像？
感謝大家的努力 （或 OCI），Helm 圖表可以放置在任何 Distribution 實例上。 目前，這個過程還處於實驗階段。 完整的 Helm 3 所需的登入支援和其他功能正在開發中，但我們很高興能夠從 OCI 和 Distribution 團隊多年來的發現中學習。 透過他們的指導和指導，我們了解了大規模運作高可用服務的感覺。
提供了有關 Helm 圖表存儲庫即將發生的一些更改的更詳細說明 .
發布管理
在 Helm 3 中，應用程式狀態由一對物件在叢集內追蹤：
- 釋放物件－代表一個應用程式實例；
- 發布版本秘密 - 表示應用程式在特定時間點的所需狀態（例如，發布新版本）。
通話 helm install 建立一個發布物件和發布版本秘密。 稱呼 helm upgrade 需要一個發布物件（它可以更改）並建立一個包含新值和準備好的清單的新發布版本金鑰。
Release 物件包含有關發行版的信息，其中發行版是指定圖表和值的特定安裝。 該物件描述有關發布的頂級元資料。 發布物件在應用程式的整個生命週期中持續存在，並且是所有發布版本機密以及由 Helm 圖表直接建立的所有物件的擁有者。
發布版本秘密將發布與一系列修訂（安裝、更新、回溯、刪除）相關聯。
在 Helm 2 中，修訂非常一致。 稱呼 helm install 創建了 v1，後續更新（升級）- v2，依此類推。 發布和發布版本秘密已被折疊成一個稱為修訂版的單一物件。 修訂版儲存在與 Tiller 相同的命名空間中，這表示每個版本在命名空間方面都是「全域」的； 因此，只能使用該名稱的一個實例。
在 Helm 3 中，每個版本都與一個或多個版本金鑰相關聯。 發布對象始終描述部署到 Kubernetes 的目前版本。 每個發行版秘密僅描述該發行版的一個版本。 例如，升級將建立新的發布版本金鑰，然後變更發布物件以指向該新版本。 在回滾的情況下，您可以使用先前的發行版本金鑰將版本回滾到先前的狀態。
Tiller 被廢棄後，Helm 3 將發布資料儲存在與發布相同的命名空間中。 此變更可讓您在不同的命名空間中安裝具有相同版本名稱的圖表，並且資料在叢集更新/重新啟動之間保存在 etcd 中。 例如，您可以將 WordPress 安裝在「foo」命名空間中，然後安裝在「bar」命名空間中，這兩個版本都可以命名為「wordpress」。
圖表依賴關係的更改
圖表打包（使用 helm package）與 Helm 2 一起使用的可以與 Helm 3 一起安裝，但是圖表開發工作流程已被徹底修改，因此必須進行一些更改才能繼續使用 Helm 3 進行圖表開發。特別是圖表依賴項管理系統已發生變化。
圖表的依賴管理系統已從 requirements.yaml и requirements.lock 上 Chart.yaml и Chart.lock。 這意味著使用該命令的圖表 helm dependency，需要一些設定才能在 Helm 3 中工作。
讓我們來看一個例子。 讓我們在 Helm 2 中的圖表中加入依賴項，看看遷移到 Helm 3 後會發生什麼變化。
在頭盔 2 requirements.yaml 看起來像這樣：
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
在 Helm 3 中，相同的依賴關係將反映在您的 Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
圖表仍會下載並放置在目錄中 charts/，所以子圖 （子圖），位於目錄中 charts/，將繼續工作而不做任何改變。
圖書館圖表簡介
Helm 3 支援一類稱為庫圖表的圖表 （圖書館圖表）。 此圖表由其他圖表使用，但不會自行建立任何發布工件。 庫圖表範本只能聲明元素 define。 其他內容將被忽略。 這允許使用者重複使用和共享可跨多個圖表使用的程式碼片段，從而避免重複並遵守原則 .
庫圖表在 部分聲明 dependencies 在文件中 Chart.yaml。 安裝和管理它們與其他圖表沒有什麼不同。
dependencies:
- name: mylib
version: 1.x.x
repository: quay.io我們對該組件將為圖表開發人員開放的用例以及庫圖表中出現的最佳實踐感到興奮。
接下來是什麼？
Helm 3.0.0-alpha.1 是我們開始建立新版本 Helm 的基礎。 在文章中，我描述了 Helm 3 的一些有趣的功能。其中許多功能仍處於開發的早期階段，這是正常的； alpha 版本的目的是測試這個想法，收集早期使用者的回饋，並確認我們的假設。
alpha 版本一發布 （記住這是 - 大約。 譯），我們將開始從社區接受 Helm 3 的補丁。 您需要創建一個堅實的基礎，以允許開發和採用新功能，並讓用戶透過開票和進行修復來感受到參與過程。
我試圖強調 Helm 3 的一些主要改進，但這個清單並不詳盡。 Helm 3 的完整路線圖包括改進的更新策略、與 OCI 註冊表的更深入整合以及使用 JSON 模式來驗證圖表值等功能。 我們還計劃清理程式碼庫並更新過去三年中被忽視的部分。
如果您覺得我們錯過了什麼，我們很想聽聽您的想法！
加入我們的討論 :
-
#helm-users提出問題並與社區進行簡單的溝通； -
#helm-dev討論拉取請求、程式碼和錯誤。
您也可以在每週四 19:30 MSK 舉行的每週公共開發者電話會議中聊天。 會議致力於討論主要開發人員和社區正在處理的問題以及本週的討論主題。 任何人都可以加入並參加會議。 Slack 頻道中提供鏈接 #helm-dev.
譯者PS
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com