Kubernetes是目前最為流行、成為事實(shí)標(biāo)準(zhǔn)的容器集群管理平臺(tái)，為容器化應(yīng)用提供了部署運(yùn)行、資源調(diào)度、服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)伸縮等一系列完整功能。在Kubernetes當(dāng)中，用戶通過使用API對象，如Pod、Service、Deployment等，來描述應(yīng)用的程序規(guī)則，而這些資源對象的定義一般需要寫入一系列的YAML文件中，然后通過 Kubernetes 命令行工具Kubectl進(jìn)行部署。由于通常應(yīng)用程序都涉及到多個(gè)Kubernetes API對象，而要描述這些API對象就可能要同時(shí)維護(hù)多個(gè)YAML文件，從而在進(jìn)行 Kubernetes 軟件部署時(shí)，通常會(huì)面臨下述幾個(gè)問題：
· 如何管理、編輯和更新這些這些分散的 Kubernetes 應(yīng)用配置文件
· 如何把一套相關(guān)的配置文件作為一個(gè)應(yīng)用進(jìn)行管理
· 如何分發(fā)和重用 Kubernetes 的應(yīng)用配置
Helm （ https://helm.sh ）的出現(xiàn)就是為了很好地解決上面這些問題，是Kubernetes官方提供的包管理工具，主要是是通過管理被稱作Helm Chart的包來描述和管理云服務(wù)的。使用 Helm后就不需要再編寫復(fù)雜的應(yīng)用部署文件，可以以簡單的方式在 Kubernetes 上查找、安裝、升級、回滾、卸載應(yīng)用程序。
在現(xiàn)在常用的Helm V2架構(gòu)中，有一個(gè)稱為“Tiller”的服務(wù)端組件。Tiller是一個(gè)集群內(nèi)服務(wù)器，可與Helm客戶端進(jìn)行交互，并與Kubernetes API服務(wù)器連接。但由于Tiller具有root用戶訪問權(quán)限，使得有人可以未經(jīng)授權(quán)訪問Kubernetes服務(wù)器你，從而構(gòu)成了很大的風(fēng)險(xiǎn)。
JFrog的專家，也是Helm的聯(lián)合創(chuàng)始人，Rimas Mocevicius， 提供了一種創(chuàng)新的、優(yōu)雅的方法——Tillerless Helm，來解決這種情況，從而保護(hù)用戶的Kubernetes集群。
從Helm v2開始，Helm的架構(gòu)中有一個(gè)名為 The Tiller Server的服務(wù)器部分，該服務(wù)器部分是一個(gè)與helm客戶端交互并與Kubernetes API服務(wù)器連接的集群內(nèi)服務(wù)器。服務(wù)器負(fù)責(zé)以下各項(xiàng)工作：
· 監(jiān)聽來自Helm客戶端的傳入請求
· 結(jié)合Chart和配置以創(chuàng)建發(fā)布版本
· 將Chart安裝到Kubernetes中，然后跟蹤后續(xù)版本
· 通過與Kubernetes交互來升級和卸載Chart
簡而言之，客戶端負(fù)責(zé)管理Chart，Tiller負(fù)責(zé)管理發(fā)布版本，其架構(gòu)如下圖所示:
默認(rèn)情況下，執(zhí)行如下命令將Tiller部署安裝到Kubernetes集群：
helm init
同時(shí)還需要為Tiller創(chuàng)建并部署RBAC授權(quán)，使其擁有執(zhí)行任務(wù)的權(quán)限。Tiller常用的RBAC授權(quán)如下所示：
目前這樣的架構(gòu)工作得很好，為用戶提供了靈活和方便，但同時(shí)也存在一些安全問題。從上面的RBAC文件中可以看出，Tiller被授予了cluster-admin的角色，也就是說，Tiller在用戶的Kubernetes集群中具有完全的管理權(quán)限，這就具備了有人未經(jīng)授權(quán)而訪問和控制集群的風(fēng)險(xiǎn)。
其實(shí)，在Helm V2中創(chuàng)建Tillerless的架構(gòu)也并不困難，能夠?yàn)镠elm的應(yīng)用提供更高的安全保障。JFrog的專家Rimas給出了優(yōu)化的解決方案，而本節(jié)將通過細(xì)節(jié)的描述來解釋該方案如何運(yùn)行。
首先，可以將Helm客戶端和Tiller都部署在工作站上，或者運(yùn)行在CI/CD流水線中，而不需要將Tiller安裝到Kubernetes集群之中。示例的安裝方式如下：
在這種安裝方式下，Helm的運(yùn)行架構(gòu)如下圖所示：
在這種架構(gòu)下，Tiller使用和Helm客戶端一樣的配置（kubeconfig）連接到Kubernetes集群，并按照指定的命名空間（namespace）存儲(chǔ)和管理Helm的發(fā)行版本信息。用戶可以通過這種方式創(chuàng)建許多名稱空間，并在Tiller啟動(dòng)時(shí)指定應(yīng)該使用哪個(gè)命名空間。用戶定義的RBAC規(guī)則可以存儲(chǔ)在運(yùn)行指定的名稱空間中的密鑰/配置映射中，而不再需要為Tiller創(chuàng)建和指定ServiceAccount。而這個(gè)架構(gòu)的另一個(gè)好處就是不再限定Kubernetes集群中只能運(yùn)行一個(gè)Tiller實(shí)例。
注意，在這種架構(gòu)下，必須使用如下的命令來初始化Helm客戶端，否則Tiller仍然被安裝到Kubernetes集群中：
helm init --client-only
那么，有沒有更加方便的安裝方式呢？Rimas為大家提供了一個(gè)簡單的Helm Tillerless插件，請參見 https://github.com/rimusz/helm-tiller。
插件的安裝非常方便，如下：
該插件提供了四個(gè)簡單的命令：start，start-ci，stop和run。
對于在本地開發(fā)或訪問遠(yuǎn)程Kubernetes集群時(shí)，請使用helm tiller start命令：
該命令將在本地啟動(dòng)Tiller，并利用Tiller默認(rèn)的設(shè)置，在kube-system名稱空間存儲(chǔ)和管理Helm版本。
也可以通過下述命令指定Tiller使用的命名空間：
該命令還會(huì)打開一個(gè)新bash shell，帶有預(yù)設(shè)的環(huán)境變量：
HELM_HOST=localhost:44134
這樣，Helm客戶端就知道如何連接Tiller了。
現(xiàn)在，就可以開始部署或更新Helm的發(fā)布版本了。
當(dāng)完成了所有工作之后，只需要運(yùn)行下述命令，就可以關(guān)閉Tiller了。
接下來，用戶也可以重復(fù)上面的過程，通過指定新的命名空間來部署和更新其他團(tuán)隊(duì)的發(fā)布版本。
那如何在CI/CD流水線當(dāng)中使用該插件呢？有兩種方法：
第一種 與上面的過程非常相似，只是沒有啟動(dòng)帶有預(yù)設(shè)變量的bash shell。
然后，Helm客戶端將知道連接到Tiller的位置，而無需在CI流水線中進(jìn)行任何更改。并且在流水線的結(jié)尾執(zhí)行：
結(jié)束全部工作。
第二種 也很容易，就是運(yùn)行helm tiller run，可以使Tiller在指定命令之前或之后啟動(dòng)/停止：
舉例來看：
附加功能： 該插件還能夠檢查安裝的Helm客戶端和Tiller的版本，如果不匹配，則下載正確的Tiller版本文件。
Helm作為Kubenetes的官方包管理工具，為用戶提供了方便、快捷的在Kubernetes集群里部署和管理自己應(yīng)用程序的方式。然而，Helm V2架構(gòu)中的Tiller組件，在提供了操作便利的同時(shí)，也帶來了安全上的隱患。
本文為大家介紹了一種在Helm V2中實(shí)現(xiàn)Tillerless的Helm部署和應(yīng)用的解決方案，在保留了Helm V2靈活性和便利性的同時(shí)，也大大提升了應(yīng)用和管理的安全性。
重慶分公司
重慶分公司
