Helm如何解決Kubernetes中部署應(yīng)用的問題

這篇文章將為大家詳細(xì)講解有關(guān)Helm如何解決Kubernetes中部署應(yīng)用的問題，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

一、背景

Kubernetes(k8s)是一個基于容器技術(shù)的分布式架構(gòu)領(lǐng)先方案。它在Docker技術(shù)的基礎(chǔ)上，為容器化的應(yīng)用提供部署運(yùn)行、資源調(diào)度、服務(wù)發(fā)現(xiàn)和動態(tài)伸縮等一系列完整功能，提高了大規(guī)模容器集群管理的便捷性。

在容器云環(huán)境及容器化服務(wù)在業(yè)界開始大規(guī)模部署應(yīng)用的前提下，Kubernetes在業(yè)界的實(shí)際應(yīng)用情況又是怎樣的呢？在今年召開的JFrog SwampUp用戶大會上，Codefresh公司為大家展示了一些有意思的數(shù)據(jù)。如下圖：

據(jù)Codefresh公司統(tǒng)計(jì)，在目前JFrog的企業(yè)用戶當(dāng)中，有80%已經(jīng)使用了Kubernetes，這說明Kubernetes已經(jīng)得到了業(yè)界的認(rèn)可并開始了廣泛的應(yīng)用。然而，只有5%的JFrog用戶在生產(chǎn)環(huán)境中使用Kubernetes。也就是說，企業(yè)更多的只是在自己的研發(fā)、測試環(huán)境中去使用 Kubernetes。這是什么原因呢？JFrog通過自身在Kubernetes應(yīng)用上的大量實(shí)踐證明，“Kubernetes is hard”，直接使用Kubernetes去部署和管理容器化的云服務(wù)，尤其是基于微服務(wù)的云服務(wù)，是非常具有挑戰(zhàn)性的工作。

那如何才能更便捷地應(yīng)用Kubernetes呢？JFrog選擇了Helm，Kubernetes的官方包管理工具。我們再來看Codefresh提供的另一組數(shù)據(jù)，如下圖：

和上一組數(shù)據(jù)一樣，只有5%的JFrog企業(yè)用戶在生產(chǎn)環(huán)境使用了Kubernetes。但同時，也有5%的JFrog用戶使用了Helm?？梢?，當(dāng)把Kubernetes應(yīng)用到生產(chǎn)環(huán)境的時候，眾多企業(yè)也和JFrog一樣，選擇了Helm這一“利器”。

為什么Helm會受到這樣的青睞？本文將通過JFrog實(shí)施Helm和Kubernetes的實(shí)踐來介紹和分析Helm的優(yōu)勢所在。

二、Helm是什么

在介紹Helm之前，我們先來看看直接應(yīng)用Kubernetes部署云服務(wù)會遇到哪些困難。

Kubernetes使用yaml文件來描述和管理服務(wù)中各個組件的配置和部署需求，每個組件對應(yīng)一個yaml文件。當(dāng)下的云服務(wù)通常都是由多個組件構(gòu)成的，如何配置和處理好這些組件，也就是多個yaml文件之間的關(guān)聯(lián)關(guān)系，成為了Kubernetes應(yīng)用的額外任務(wù)。而當(dāng)云服務(wù)升級，卻僅僅涉及其中一個或某幾個模塊時，升級模塊的新yaml文件和已有yaml文件之間的關(guān)聯(lián)關(guān)系就會變得更加錯綜復(fù)雜，從而更增加了使用Kubernetes來配置和管理升級的難度。

其次，Kubernetes把組件的配置信息也直接記錄到y(tǒng)aml文件當(dāng)中。從描述組件的角度來講，這種方式確實(shí)比較清晰。但是，當(dāng)云服務(wù)的部署面對多個環(huán)境，如不同的開發(fā)、測試、產(chǎn)品環(huán)境（這也是當(dāng)前比較常見的應(yīng)用場景）時，要如何處理這些環(huán)境配置之間的差別？要為每個環(huán)境都開發(fā)和維護(hù)一套不同的yaml文件？這顯然大大增加了應(yīng)用Kubernetes的難度和工作量。

而且，Kubernetes的yaml文件本身是沒有版本的概念的。那么當(dāng)某次部署失敗，需要回滾到上一個穩(wěn)定版本時，該選擇哪一套yaml文件來處理？顯然，這需要很多額外的工作來處理。

那Helm是如何來解決這些問題的呢？

Helm（https://helm.sh）是Kubernetes的官方包管理工具。Helm是通過被稱作Helm Chart的包來描述和管理云服務(wù)的。Helm Chart對應(yīng)的是一組結(jié)構(gòu)化的目錄和yaml文件，而這些目錄和文件大致可分為三個部分：

1、模板

在templates目錄下存放著一組用來描述云服務(wù)當(dāng)中各個組件的yaml文件，這和目前Kubernetes的用法類似。Helm把這些yaml文件組織在同一目錄，能夠很方便地了解當(dāng)前云服務(wù)的組成，結(jié)構(gòu)清晰且便于管理。

2、配置與依賴

templates目錄下的yaml文件是不包含具體的配置信息的，只保留了對配置項(xiàng)（key）的引用。真正與目標(biāo)環(huán)境對應(yīng)的配置信息（value）是存儲在values.yaml文件里的。當(dāng)然，values.yaml只是存儲了一些缺省的、靜態(tài)的配置信息，在部署的過程中也可以動態(tài)地增加或修改這些配置信息。這種配置與應(yīng)用分離的設(shè)計(jì)使得同一套templates可以方便地部署到不同的目標(biāo)環(huán)境中，只需要更新values.yaml文件或部署時動態(tài)修改配置信息就可以了。

另外，針對某些已被廣泛使用的云服務(wù)或組件，目前已經(jīng)存在比較成熟、經(jīng)過驗(yàn)證的Helm Chart了。當(dāng)使用到這些服務(wù)或組件時，可以直接在requirements.yaml文件里描述這種依賴關(guān)系。在部署的時候，Helm會自動獲取這些依賴的Helm Chart使用，并存儲在charts目錄。這種依賴性的設(shè)計(jì)，避免了很多重復(fù)性的工作，也使得Helm Chart的并行開發(fā)和共享成為可能。

3、版本化

每一個Helm Chart包都可以在Chart.yaml文件里定義自己的版本。另外，每一次 Helm的部署都會自動生成一個版本（release）。使用Helm的命令，可以方便地實(shí)現(xiàn)這些已部署版本的查詢、升級、回滾和其他管理任務(wù)。

三、Helm的應(yīng)用實(shí)踐

通過上面對Helm的介紹和分析可以看出，Helm能夠很好地解決Kubernetes應(yīng)用部署的難題。JFrog在自己的Kubernetes實(shí)踐當(dāng)中也充分使用了Helm。

目前，在JFrog各個產(chǎn)品自身的CI/CD流水線上都使用Helm進(jìn)行Kubernetes上的部署，已經(jīng)可以實(shí)現(xiàn)每周100+不同產(chǎn)品線的任意版本組合部署，每次部署超過50種微服務(wù)。JFrog也將為客戶提供這些Helm Chart，以幫助客戶在Kubernetes環(huán)境快速部署JFrog的各種產(chǎn)品。

在實(shí)踐Helm的過程中，JFrog也積累了一些經(jīng)驗(yàn)和最佳實(shí)踐。

1、配置與應(yīng)用分離

針對所有的環(huán)境使用同樣的Helm Chart，但是根據(jù)不同的環(huán)境配置自己特定的values.yaml文件。同時，根據(jù)目標(biāo)環(huán)境的變化對這些values.yaml文件進(jìn)行版本化的管理。

2、善用依賴

目前已經(jīng)有很多產(chǎn)品和通用組件都實(shí)現(xiàn)了比較完善、經(jīng)過驗(yàn)證的Helm Chart，可以在https://hub.kubeapps.com里找到。我們在開發(fā)自己的Helm Chart時，可以通過定義依賴來充分地利用這些已有的成果，在減少工作量的同時，也能提高產(chǎn)品的質(zhì)量。

3、在實(shí)際部署前檢查Helm Chart

Helm提供了很多實(shí)用的命令來幫助我們在實(shí)際部署之前檢查Helm Chart里的錯誤，降低使用的風(fēng)險。比如：

·       helm lint <chart path>

helm lint可以用來檢查下載的Helm Chart是否存在問題

·       helm install –debug –dry-run <chart>

helm install帶上dry-run參數(shù)可以在不實(shí)際執(zhí)行部署的情況下檢查Helm Chart的各種配置是否正確

Helm的各種命令及其具體用法請參考Helm的官方文檔，https://docs.helm.sh。

4、充分利用社區(qū)的力量

目前有很多開發(fā)者都在研究和實(shí)踐Helm，我們應(yīng)該充分利用他們的經(jīng)驗(yàn)和成果，并積極地和他們溝通交流，從而提升我們使用Helm的效率和質(zhì)量。

常用的用于Helm交流的社區(qū)包括：

·       GitHub issues: https://github.com/helm/charts/issues

·       Slack: #helm-users room in the Kubernetes Slack (https://kubernetes.slack.com/)

·       Slack: #helm-dev room in the Kubernetes Slack (https://kubernetes.slack.com/)

四、Helm倉庫

下圖是Helm的應(yīng)用架構(gòu)：

其中，Tiller部署在Kubernetes環(huán)境中，執(zhí)行應(yīng)用部署等操作。而Helm作為客戶端，完成Helm Chart的管理和部署任務(wù)的發(fā)布。在這個架構(gòu)中，Helm倉庫（Storage）保存了Helm部署所需要的各種Chart文件、依賴包和配置信息，在Helm部署過程中起到了十分重要的作用。

JFrog的Artifactory產(chǎn)品，作為全球唯一提供Helm倉庫支持的統(tǒng)一制品管理倉庫，可以在為Helm Chart提供倉庫支持的同時，為相關(guān)制品，如docker鏡像、版本化的配置信息，以及各種依賴制品等提供一站式的統(tǒng)一服務(wù)和管理。而JFrog的Xray產(chǎn)品，集成Artifactory的統(tǒng)一制品倉庫，能夠?qū)崿F(xiàn)安全漏洞的自動掃描及漏洞的影響范圍分析。

有關(guān)JFrog產(chǎn)品的詳細(xì)介紹、能力分析及用戶案例，請參考本公眾號的系列文章和官網(wǎng)的相關(guān)介紹（http://jfrogchina.com）。

五、總結(jié)

通過Kubernetes部署云服務(wù)已經(jīng)在業(yè)界的到了廣泛的應(yīng)用。Helm通過其統(tǒng)一管理、配置與應(yīng)用分離、版本化等特性能夠大大降低Kubernetes部署的難度，提升部署的效率和質(zhì)量，也逐漸得到了眾多的關(guān)注和應(yīng)用。

JFrog的Artifactory和Xray等產(chǎn)品能夠提供包含Helm倉庫在內(nèi)的統(tǒng)一制品倉庫管理和安全漏洞掃描，在實(shí)現(xiàn)基于Helm的CI/CD流水線和自動化部署方案起到了重要的作用。Codefresh公司就利用JFrog的產(chǎn)品和相關(guān)工具搭建了自己產(chǎn)品的流水線并廣泛使用。

關(guān)于Helm如何解決Kubernetes中部署應(yīng)用的問題就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。