共計(jì) 4594 個(gè)字符，預(yù)計(jì)需要花費(fèi) 12 分鐘才能閱讀完成。

這篇文章給大家介紹怎樣選出適合自己的管理 Helm Chart 的最佳方式，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

無論你喜歡與否，你都不得不承認(rèn) Helm 是管理 Kubernetes 應(yīng)用程序獨(dú)一無二的工具，你甚至可以通過不同的方式使用它。

在 Helm 的使用過程中，我們注意到有幾個(gè)問題不斷出現(xiàn)：

你將你的 Helm chart 放在哪里？

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

你如何劃分 Helm chart？

你是使用一個(gè)共享的 chart 或是為每個(gè)服務(wù)維護(hù)一個(gè) chart？

我正在通過我以往在各種創(chuàng)業(yè)公司的經(jīng)驗(yàn)來嘗試解決這些問題，但是我也借鑒了大型公司的做法。

以下是我要概述的幾個(gè)方法：

使用一個(gè) chart 倉庫來存儲(chǔ)一個(gè)大型共享 chart

使用一個(gè) chart 倉庫來存儲(chǔ)許多特定于服務(wù)的 chart

使用特定于服務(wù)的 chart，這些 chart 與服務(wù)本身存儲(chǔ)在同一倉庫中

然后，我將介紹在決定這些選項(xiàng)時(shí)應(yīng)該考慮的因素，例如依賴項(xiàng)差異和團(tuán)隊(duì)結(jié)構(gòu)等。

Option1：在一個(gè) chart 倉庫中維護(hù)一個(gè)大型共享 chart

在我們一個(gè)項(xiàng)目中，我們從一個(gè)用于部署多個(gè)服務(wù)的大型 chart 開始。它存儲(chǔ)在 ChartMuseum 中，并由負(fù)責(zé)部署基礎(chǔ)架構(gòu)的人員進(jìn)行維護(hù)。

如果你的各個(gè)服務(wù)在本質(zhì)上十分類似，那么共享 chart 可以為你省去很多麻煩。這里我們采用 Helm 維護(hù)者 Josh Dolitsky 在 KubeCon 2019 上描述的情況：

我最近在負(fù)責(zé)一個(gè)項(xiàng)目，這個(gè)項(xiàng)目包含 9 個(gè)微服務(wù)……我意識(shí)到它們幾乎都是相同的 HTTP 監(jiān)聽服務(wù)。所以我決定僅僅構(gòu)建一個(gè) helm chart 來部署 9 個(gè)不同的服務(wù)，為每個(gè)服務(wù)做不同的配置——僅為特定的服務(wù)設(shè)置一個(gè)新的 docker 標(biāo)簽。

在這種情況下，將 Helm chart 存儲(chǔ)在 ChartMuseum 等 chart 倉庫中是有意義的，因?yàn)橹挥兄敌枰４嬖谶@些特定服務(wù)的倉庫中。

Option2：在一個(gè) chart 倉庫中維護(hù)幾個(gè)特定于服務(wù)的 chart

特定于服務(wù)的 chart 優(yōu)勢(shì)在于，你可以更改一項(xiàng)服務(wù)，而無需擔(dān)心會(huì)破壞另一項(xiàng)服務(wù)。但是它們可能會(huì)導(dǎo)致重復(fù)的工作——如果你要更新通用配置，則必須在每個(gè) chart 中進(jìn)行相同的更改。

是否需要在一個(gè) chart 倉庫中保存它們則是另一個(gè)問題了。如果這些 chart 是特定于服務(wù)的，那么將它們存儲(chǔ)在一起尚沒有強(qiáng)有力的架構(gòu)論證。當(dāng)然，如果你有專門的人員或團(tuán)隊(duì)來維護(hù)所有的 chart，一起存儲(chǔ)多個(gè)特定于服務(wù)的 chart 通常會(huì)比較容易。

例如，與我一起工作的一位 DevOps 工程師，他在一個(gè)中心 chart 倉庫中維護(hù) 15 種不同的微服務(wù) chart。對(duì)于他而言，在同一個(gè)位置更新所有 chart 比向 15 個(gè)不同的倉庫提交拉取請(qǐng)求要容易得多。開發(fā)人員當(dāng)然清楚如何更新 chart，但是處理資源相關(guān)的設(shè)置顯然更吸引他們。

Option3：在與服務(wù)本身相同的倉庫種維護(hù)特定于服務(wù)的 chart

對(duì)于基于微服務(wù)的應(yīng)用程序來說，特定于服務(wù)的 chart 是一個(gè)很好的選擇。而當(dāng)你將每個(gè) chart 與服務(wù)代碼保存在同一倉庫中時(shí)，使用特定于服務(wù)的 chart 則會(huì)更好。

如果你在服務(wù)倉庫中存儲(chǔ) Helm chart，那么可以更輕松地獨(dú)立于其他項(xiàng)目持續(xù)部署服務(wù)。并且你可以將 chart 更新（例如添加新變量）與應(yīng)用程序邏輯的更改一起提交，使其更易于識(shí)別和還原重大更改。

然而，本選項(xiàng)的優(yōu)勢(shì)取決于你所維護(hù)的微服務(wù)的數(shù)量。如果你的微服務(wù)數(shù)量正邁入兩位數(shù)，那么這一選項(xiàng)的優(yōu)勢(shì)則沒有那么明顯，更多的是阻礙。如果你要處理非常同質(zhì)的服務(wù)（如 Josh Dolisky），則尤其如此。

決定選項(xiàng)時(shí)需要考慮的因素

一般情況下，有兩個(gè)方面需要考慮：

依賴項(xiàng)和可重現(xiàn)：每個(gè)服務(wù)的依賴項(xiàng)有多少區(qū)別？對(duì)一個(gè)服務(wù)的更改有多大風(fēng)險(xiǎn)會(huì)中斷另一個(gè)服務(wù)？你如何再現(xiàn)特定的開發(fā)條件？

團(tuán)隊(duì)結(jié)構(gòu)：你負(fù)責(zé)每個(gè)服務(wù)的小型自治團(tuán)隊(duì)嗎？你有了解 DevOps 的開發(fā)人員嗎？你的團(tuán)隊(duì)中 DevOps 文化流行程度如何？

依賴項(xiàng)和可重現(xiàn)

如果你將你的 chart 和應(yīng)用程序分開維護(hù)，它們的版本將彼此不同。如果你在部署時(shí)遇到問題，并且需要重現(xiàn)導(dǎo)致該問題的條件，則需要確定：a）服務(wù)版本；b）用于部署它的 chart 版本。你可能想要走捷徑，使用“l(fā)atest”chart 來測(cè)試服務(wù) x.x.x，但這并不是一個(gè)好想法，因?yàn)檫@樣你將永遠(yuǎn)無法重現(xiàn)造成問題的確切條件。

那么，如果你經(jīng)常需要更改的 chart 版本怎么辦？是不是應(yīng)該一起測(cè)試這些改動(dòng)呢？

考慮到許多開發(fā)人員需要?jiǎng)?chuàng)建同一共享 chart 中的分支版本這一場(chǎng)景：

開發(fā)人員（圖中的 Edeltraud 和 Eberhardt）分別在不同的分支中工作，并且想要在開發(fā)環(huán)境中測(cè)試他們的更改以及圖表更改——所以他們還需要分支 chart。同時(shí)，DevOps 工程師在他的共享 chart 的分支中更新一些常用組件。

如果沒有人將他們的 chart 更改更新到各個(gè)分支，那么就有可能破壞另一個(gè)服務(wù)部署。

不久前，我們正好遇到了這個(gè)問題。Chart 維護(hù)者用一個(gè)新的條件塊更新了共享 chart。該語句檢查了一個(gè)新的變量“foo”是否被設(shè)置為“啟用”。然而，變量“foo”還沒有在所有服務(wù)的值文件中定義。對(duì)于缺少該變量的服務(wù)，部署中斷了。不幸的是，當(dāng)時(shí) chart 中沒有定義默認(rèn)的回滾行為。

如果 chart 和代碼位于同一個(gè)倉庫中，并且可以在同一個(gè)分支中進(jìn)行測(cè)試，則針對(duì)這些問題的測(cè)試將更加容易。

即使一開始似乎是矯枉過正，我們也會(huì)這樣做。我們的工作對(duì)象是很少有依賴項(xiàng)的服務(wù)。對(duì)于每個(gè)服務(wù)，Helm chart 只部署一個(gè)帶有特定 Docker 標(biāo)簽的主容器。chart 的名稱和 docker 標(biāo)簽是通過變量傳遞進(jìn)來的。盡管如此，我們?nèi)匀槐苊饬耸褂霉蚕?chart，而是選擇在每個(gè)服務(wù)倉庫中放置單獨(dú)的 chart。

這主要是因?yàn)槲覀冎惶幚砹怂膫€(gè)服務(wù)。但我們的開發(fā)人員也更喜歡掌控所有能夠影響 CI/CD 的配置。然而情況并非總是如此，所以現(xiàn)在是研究另一個(gè)維度的好時(shí)機(jī)。

團(tuán)隊(duì)結(jié)構(gòu)

Chart 維護(hù)的問題同時(shí)也取決于誰管理部署流程。

這里推薦另一篇文章，由 Helm 維護(hù)者 Matt Farina 撰寫的，在文章中他闡述了關(guān)于 Helm 正在嘗試解決復(fù)雜性的話題。

他闡明了必須處理 Kubernetes 復(fù)雜性的三個(gè)主要角色。為了清楚起見，我將對(duì)其內(nèi)容進(jìn)行一些解釋，并將角色描述如下：

App 開發(fā)人員——這個(gè)角色主要構(gòu)建服務(wù)、添加特性以及修復(fù) bug

Deployer——這個(gè)角色負(fù)責(zé)將應(yīng)用程序推向世界。理想情況下，有一個(gè)不錯(cuò)的自動(dòng)化程序可以為他們部署應(yīng)用程序，但是他們知道它的工作方式，可以根據(jù)需要進(jìn)行修改。

系統(tǒng)工程師——這一角色負(fù)責(zé)維護(hù) deployer 部署的 Kubernetes 環(huán)境。他們是管理計(jì)算機(jī)資源的專家，并且可以盡量減少任何服務(wù)的停機(jī)時(shí)間。

第一個(gè)和第三個(gè)角色你都能在公司里找到與其負(fù)責(zé)內(nèi)容相符的職位，而 Deployer 這個(gè)角色則有些模糊，這個(gè)角色所負(fù)責(zé)的內(nèi)容常常會(huì)被其他兩個(gè)角色的人接管——這會(huì)影響你如何管理你的 Helm chart。

尚在早期階段的初創(chuàng)公司的 DevOps

如前所述，我們的業(yè)務(wù)是為初創(chuàng)企業(yè)提供運(yùn)維支持，這些企業(yè)往往需要快速擴(kuò)大規(guī)模。我們見過很多“非常規(guī)”的設(shè)置和分工。在早期階段，App 開發(fā)者可能會(huì)負(fù)責(zé)各種事情，有些人甚至?xí)兔ν瓿上到y(tǒng)管理員的任務(wù)，比如設(shè)置打印機(jī)或配置辦公室網(wǎng)絡(luò)等。他們會(huì)盡力去了解其他兩個(gè)角色所需要負(fù)責(zé)的內(nèi)容，因?yàn)闆]有人可以幫助他們（直到我們參與進(jìn)來）。

一旦他們想了解 Helm，大多數(shù)應(yīng)用開發(fā)者會(huì)把他們的 chart 放在最容易處理的地方——也就是他們維護(hù)的同一個(gè) repo。

在大型企業(yè)中的 DevOps

你可能在一個(gè)更大的、架構(gòu)更分明的團(tuán)隊(duì)中工作，

在這種情況下，你可能有自己的 DevOps 工程師甚至是整個(gè) DevOps 部門。而這個(gè)人或團(tuán)隊(duì)經(jīng)常會(huì)覺得自己也要負(fù)責(zé)“Deployer”的角色。很有可能，他們會(huì)傾向于采用更集中的方法，比如將所有的 chart 存儲(chǔ)在 ChartMuseum 這樣的 chart 倉庫中。更不愿意讓應(yīng)用開發(fā)者過多地參與到 Helm chart 中來（往往是有合理緣由的）。

例如，我最近看了一個(gè)經(jīng)典的技術(shù)講座，叫《從頭開始構(gòu)建 Helm chart》，由 VMWare 系統(tǒng)工程師 Amy Chen 主講。在她的開場(chǎng)白中，她說：在基礎(chǔ)設(shè)施方面，你的主要目標(biāo)是時(shí)刻準(zhǔn)備著應(yīng)對(duì)故障，沒有信任——在這個(gè)意義上說，就像我不太愿意信任我的 APP 開發(fā)者，并且我也不太需要信任我的 APP 開發(fā)者。

這是可以理解的。你不想讓應(yīng)用開發(fā)者去搞亂設(shè)置，比如 CPU 和內(nèi)存限制，或者是 pod 中斷預(yù)算。但整個(gè)“DevOps 文化”的概念是專門為了改善基礎(chǔ)設(shè)施維護(hù)者和開發(fā)者之間有時(shí)會(huì)出現(xiàn)的疏離關(guān)系而演化出來的。

實(shí)踐 DveOps 文化

Atlassian（JIRA 和 Trello 的所有者）出版了一本“團(tuán)隊(duì)手冊(cè)”，其中定義了 DevOps 文化：

DevOps 文化是關(guān)于開發(fā)者和運(yùn)維之間的共同理解，并為他們所構(gòu)建的軟件分擔(dān)責(zé)任。這意味著增加透明度、溝通和協(xié)作，并在開發(fā)、IT/ 運(yùn)維和“業(yè)務(wù)”之間進(jìn)行合作。

如果將其實(shí)際應(yīng)用到 Helm chart 維護(hù)和一般的基礎(chǔ)架構(gòu)配置中，就會(huì)把大部分的責(zé)任放在應(yīng)用開發(fā)者的手中。他們也會(huì)承擔(dān)起“Deployer”的角色，并改變他們擁有的倉庫中的配置。

系統(tǒng)工程師仍然可以把他們專門維護(hù)的設(shè)置集中起來。例如，一些團(tuán)隊(duì)也會(huì)維護(hù)一個(gè)中央基礎(chǔ)架構(gòu) repo，該 repo 中保存著 Terraform 配置或 Helm 文件等常用資源，這些資源是啟動(dòng)新項(xiàng)目所需要的（例如，用于設(shè)置 ingress controller 和 cert manager）。Helm 3 還支持所謂的“l(fā)ibrary chart”，它只能作為另一個(gè) chart 的一部分進(jìn)行部署。這讓我們更容易區(qū)分常見的和服務(wù)特定的變更責(zé)任。

即使當(dāng) chart 存儲(chǔ)在服務(wù)倉庫中，系統(tǒng)工程師仍然可以作為重要更改的把關(guān)人。例如，你可以使用 GitHub CODEOWNERS 文件來確保系統(tǒng)工程師在你的 repo 中的 chart 目錄中的任何更改都會(huì)被添加為審核者。

如果系統(tǒng)工程師需要主動(dòng)做一些與應(yīng)用開發(fā)無關(guān)的改動(dòng)，可以指導(dǎo)開發(fā)人員為他們做更改，并解釋為什么這些改動(dòng)是必須的。以下圖片也許能反映這種情況：

開發(fā)者可以了解更多關(guān)于基礎(chǔ)設(shè)施的內(nèi)容以及這些更改如何影響他們的服務(wù)。

經(jīng)驗(yàn)法則

如果有簡單的經(jīng)驗(yàn)法則，那就是：先了解選項(xiàng) 3。嘗試為服務(wù)倉庫中的每個(gè)服務(wù)維護(hù)一個(gè) Helm chart?；蛘咧辽倏紤]一下我之前描述的混合方法。

如果你有幾十個(gè)服務(wù)都非常相似，那么共享 chart 是更好的選擇。只是要記住，你必須把它維護(hù)在一個(gè)中心 repo 中。但是這增加了意外耦合的風(fēng)險(xiǎn)，可能會(huì)破壞一個(gè)服務(wù)部署。風(fēng)險(xiǎn)增加意味著你在部署的時(shí)候需要更加謹(jǐn)慎，這反過來又意味著你會(huì)減少部署的頻率。

即使你有特定服務(wù)的 chart，你可能也需要集中存儲(chǔ)，因?yàn)槟銢]有足夠的人員或?qū)I(yè)知識(shí)以分布式的方式來管理這些 chart。或者，也許你的團(tuán)隊(duì)需要在“Deployer”和“應(yīng)用開發(fā)者”之間明確劃分責(zé)任。

無論你決定做什么，我希望我已經(jīng)說明清楚了你在做最后決定時(shí)需要考慮的問題。做一個(gè)“Deployer”并不容易，尤其是當(dāng)它不是你的日常工作時(shí)。

關(guān)于怎樣選出適合自己的管理 Helm Chart 的最佳方式就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。