如何選出適合本身的管理Helm Chart的最佳方式？

本文轉載自Rancher Labs

不管你喜歡與否，你都不得不認可Helm是管理Kubernetes應用程序獨一無二的工具，你甚至能夠經過不一樣的方式使用它。

在Helm的使用過程當中，咱們注意到有幾個問題不斷出現：

• 你將你的Helm chart放在哪裏？

你是使用app文件保存它們仍是使用chart倉庫？

• 你如何劃分Helm chart？

你是使用一個共享的chart或是爲每一個服務維護一個chart？

我正在經過我以往在各類創業公司的經驗來嘗試解決這些問題，可是我也借鑑了大型公司的作法。

如下是我要概述的幾個方法：

1. 使用一個chart倉庫來存儲一個大型共享chart
2. 使用一個chart倉庫來存儲許多特定於服務的chart
3. 使用特定於服務的chart，這些chart與服務自己存儲在同一倉庫中

而後，我將介紹在決定這些選項時應該考慮的因素，例如依賴項差別和團隊結構等。

Option1：在一個chart倉庫中維護一個大型共享chart

在咱們一個項目中，咱們從一個用於部署多個服務的大型chart開始。它存儲在ChartMuseum中，並由負責部署基礎架構的人員進行維護。

若是你的各個服務在本質上十分相似，那麼共享chart能夠爲你省去不少麻煩。這裏咱們採用Helm維護者Josh Dolitsky在KubeCon 2019上描述的狀況：

我最近在負責一個項目，這個項目包含9個微服務……我意識到它們幾乎都是相同的HTTP監聽服務。因此我決定僅僅構建一個helm chart來部署9個不一樣的服務，爲每一個服務作不一樣的配置——僅爲特定的服務設置一個新的docker標籤。

在這種狀況下，將Helm chart存儲在ChartMuseum等chart倉庫中是有意義的，由於只有值須要保存在這些特定服務的倉庫中。

Option2：在一個chart倉庫中維護幾個特定於服務的chart

特定於服務的chart優點在於，你能夠更改一項服務，而無需擔憂會破壞另外一項服務。可是它們可能會致使重複的工做——若是你要更新通用配置，則必須在每一個chart中進行相同的更改。

是否須要在一個chart倉庫中保存它們則是另外一個問題了。若是這些chart是特定於服務的，那麼將它們存儲在一塊兒尚沒有強有力的架構論證。固然，若是你有專門的人員或團隊來維護全部的chart，一塊兒存儲多個特定於服務的chart一般會比較容易。

例如，與我一塊兒工做的一位DevOps工程師，他在一箇中心chart倉庫中維護15種不一樣的微服務chart。對於他而言，在同一個位置更新全部chart比向15個不一樣的倉庫提交拉取請求要容易得多。開發人員固然清楚如何更新chart，可是處理資源相關的設置顯然更吸引他們。

Option3：在與服務自己相同的倉庫種維護特定於服務的chart

對於基於微服務的應用程序來講，特定於服務的chart是一個很好的選擇。而當你將每一個chart與服務代碼保存在同一倉庫中時，使用特定於服務的chart則會更好。

若是你在服務倉庫中存儲Helm chart，那麼能夠更輕鬆地獨立於其餘項目持續部署服務。而且你能夠將chart更新（例如添加新變量）與應用程序邏輯的更改一塊兒提交，使其更易於識別和還原重大更改。

然而，本選項的優點取決於你所維護的微服務的數量。若是你的微服務數量正邁入兩位數，那麼這一選項的優點則沒有那麼明顯，更多的是阻礙。若是你要處理很是同質的服務（如Josh Dolisky），則尤爲如此。

決定選項時須要考慮的因素

通常狀況下，有兩個方面須要考慮：

• 依賴項和可重現：每一個服務的依賴項有多少區別？對一個服務的更改有多大風險會中斷另外一個服務？你如何再現特定的開發條件？
• 團隊結構：你負責每一個服務的小型自治團隊嗎？你有了解DevOps的開發人員嗎？你的團隊中DevOps文化流行程度如何？

依賴項和可重現

若是你將你的chart和應用程序分開維護，它們的版本將彼此不一樣。若是你在部署時遇到問題，而且須要重現致使該問題的條件，則須要肯定：a）服務版本；b）用於部署它的chart版本。你可能想要走捷徑，使用「latest」 chart來測試服務x.x.x，但這並非一個好想法，由於這樣你將永遠沒法重現形成問題的確切條件。

那麼，若是你常常須要更改的chart版本怎麼辦？是否是應該一塊兒測試這些改動呢？

考慮到許多開發人員須要建立同一共享chart中的分支版本這一場景：

開發人員（圖中的Edeltraud和Eberhardt）分別在不一樣的分支中工做，而且想要在開發環境中測試他們的更改以及圖表更改——因此他們還須要分支chart。同時，DevOps工程師在他的共享chart的分支中更新一些經常使用組件。

若是沒有人將他們的chart更改更新到各個分支，那麼就有可能破壞另外一個服務部署。

不久前，咱們正好遇到了這個問題。Chart維護者用一個新的條件塊更新了共享chart。該語句檢查了一個新的變量「foo」是否被設置爲「啓用」。然而，變量「foo」尚未在全部服務的值文件中定義。對於缺乏該變量的服務，部署中斷了。不幸的是，當時chart中沒有定義默認的回滾行爲。

若是chart和代碼位於同一個倉庫中，而且能夠在同一個分支中進行測試，則針對這些問題的測試將更加容易。

即便一開始彷佛是矯枉過正，咱們也會這樣作。咱們的工做對象是不多有依賴項的服務。對於每一個服務，Helm chart只部署一個帶有特定Docker標籤的主容器。chart的名稱和docker標籤是經過變量傳遞進來的。儘管如此，咱們仍然避免了使用共享chart，而是選擇在每一個服務倉庫中放置單獨的chart。

這主要是由於咱們只處理了四個服務。但咱們的開發人員也更喜歡掌控全部可以影響CI/CD的配置。然而狀況並不是老是如此，因此如今是研究另外一個維度的好時機。

團隊結構

Chart維護的問題同時也取決於誰管理部署流程。

這裏推薦另外一篇文章，由Helm維護者Matt Farina撰寫的，在文章中他闡述了關於Helm正在嘗試解決複雜性的話題。文章連接：

https://codeengineered.com/bl...

他闡明瞭必須處理Kubernetes複雜性的三個主要角色。爲了清楚起見，我將對其內容進行一些解釋，並將角色描述以下：

1. App開發人員——這個角色主要構建服務、添加特性以及修復bug
2. Deployer——這個角色負責將應用程序推向世界。理想狀況下，有一個不錯的自動化程序能夠爲他們部署應用程序，可是他們知道它的工做方式，能夠根據須要進行修改。
3. 系統工程師——這一角色負責維護deployer部署的Kubernetes環境。他們是管理計算機資源的專家，而且能夠儘可能減小任何服務的停機時間。

第一個和第三個角色你都能在公司裏找到與其負責內容相符的職位，而Deployer這個角色則有些模糊，這個角色所負責的內容經常會被其餘兩個角色的人接管——這會影響你如何管理你的Helm chart。

尚在早期階段的初創公司的DevOps

如前所述，咱們的業務是爲初創企業提供運維支持，這些企業每每須要快速擴大規模。咱們見過不少「很是規」的設置和分工。在早期階段，App開發者可能會負責各類事情，有些人甚至會幫忙完成系統管理員的任務，好比設置打印機或配置辦公室網絡等。他們會盡力去了解其餘兩個角色所須要負責的內容，由於沒有人能夠幫助他們（直到咱們參與進來）。

一旦他們想了解Helm，大多數應用開發者會把他們的chart放在最容易處理的地方——也就是他們維護的同一個repo。

在大型企業中的DevOps

你可能在一個更大的、架構更分明的團隊中工做，

在這種狀況下，你可能有本身的DevOps工程師甚至是整個DevOps部門。而這我的或團隊常常會以爲本身也要負責 「Deployer」的角色。頗有可能，他們會傾向於採用更集中的方法，好比將全部的chart存儲在ChartMuseum這樣的chart倉庫中。更不肯意讓應用開發者過多地參與到Helm chart中來（每每是有合理原因的）。

例如，我最近看了一個經典的技術講座，叫《從頭開始構建Helm chart》，由VMWare系統工程師Amy Chen主講。在她的開場白中，她說：

在基礎設施方面，你的主要目標是時刻準備着應對故障，沒有信任——在這個意義上說，就像我不太願意信任個人APP開發者，而且我也不太須要信任個人APP開發者。

這是能夠理解的。你不想讓應用開發者去搞亂設置，好比CPU和內存限制，或者是pod中斷預算。但整個 「DevOps文化」的概念是專門爲了改善基礎設施維護者和開發者之間有時會出現的疏離關係而演化出來的。

實踐DveOps文化

Atlassian（JIRA和Trello的全部者）出版了一本「團隊手冊」，其中定義了DevOps文化：

DevOps文化是關於開發者和運維之間的共同理解，併爲他們所構建的軟件分擔責任。這意味着增長透明度、溝通和協做，並在開發、IT/運維和 「業務」之間進行合做。

若是將其實際應用到Helm chart維護和通常的基礎架構配置中，就會把大部分的責任放在應用開發者的手中。他們也會承擔起「Deployer」的角色，並改變他們擁有的倉庫中的配置。

系統工程師仍然能夠把他們專門維護的設置集中起來。例如，一些團隊也會維護一箇中央基礎架構repo，該repo中保存着Terraform配置或Helm文件等經常使用資源，這些資源是啓動新項目所須要的（例如，用於設置ingress controller和cert manager）。Helm 3還支持所謂的 「library chart」，它只能做爲另外一個chart的一部分進行部署。這讓咱們更容易區分常見的和服務特定的變動責任。

即便當chart存儲在服務倉庫中，系統工程師仍然能夠做爲重要更改的把關人。例如，你可使用GitHub CODEOWNERS文件來確保系統工程師在你的repo中的chart目錄中的任何更改都會被添加爲審覈者。

若是系統工程師須要主動作一些與應用開發無關的改動，能夠指導開發人員爲他們作更改，並解釋爲何這些改動是必須的。如下圖片也許能反映這種狀況：

開發者能夠了解更多關於基礎設施的內容以及這些更改如何影響他們的服務。

經驗法則

若是有簡單的經驗法則，那就是：先了解選項3。嘗試爲服務倉庫中的每一個服務維護一個Helm chart。或者至少考慮一下我以前描述的混合方法。

若是你有幾十個服務都很是類似，那麼共享chart是更好的選擇。只是要記住，你必須把它維護在一箇中心repo中。可是這增長了意外耦合的風險，可能會破壞一個服務部署。風險增長意味着你在部署的時候須要更加謹慎，這反過來又意味着你會減小部署的頻率。

即便你有特定服務的chart，你可能也須要集中存儲，由於你沒有足夠的人員或專業知識以分佈式的方式來管理這些chart。或者，也許你的團隊須要在「Deployer」和「應用開發者」之間明確劃分責任。

不管你決定作什麼，我但願我已經說明清楚了你在作最後決定時須要考慮的問題。作一個「Deployer」並不容易，尤爲是當它不是你的平常工做時。

做者：Merlin Carter，專一於早期創業公司的風險投資家，擅長撰寫開發人員創新和新技術的文章

原文連接：
https://insights.project-a.co...