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

186次閱讀

共計 3970 個字符，預(yù)計需要花費(fèi) 10 分鐘才能閱讀完成。

這篇文章將為大家詳細(xì)講解有關(guān) Helm 如何解決 Kubernetes 中部署應(yīng)用的問題，文章內(nèi)容質(zhì)量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(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è)界的實際應(yīng)用情況又是怎樣的呢？在今年召開的 JFrog SwampUp 用戶大會上，Codefresh 公司為大家展示了一些有意思的數(shù)據(jù)。如下圖：

據(jù) Codefresh 公司統(tǒng)計，在目前 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)用上的大量實踐證明，“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 實施 Helm 和 Kubernetes 的實踐來介紹和分析 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 把組件的配置信息也直接記錄到 yaml 文件當(dāng)中。從描述組件的角度來講，這種方式確實比較清晰。但是，當(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 文件是不包含具體的配置信息的，只保留了對配置項（key）的引用。真正與目標(biāo)環(huán)境對應(yīng)的配置信息（value）是存儲在 values.yaml 文件里的。當(dāng)然，values.yaml 只是存儲了一些缺省的、靜態(tài)的配置信息，在部署的過程中也可以動態(tài)地增加或修改這些配置信息。這種配置與應(yīng)用分離的設(shè)計使得同一套 templates 可以方便地部署到不同的目標(biāo)環(huán)境中，只需要更新 values.yaml 文件或部署時動態(tài)修改配置信息就可以了。

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

3、版本化

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

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

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

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

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

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

3、在實際部署前檢查 Helm Chart

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

· helm lint chart path

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

· helm install –debug –dry-run chart

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

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

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

目前有很多開發(fā)者都在研究和實踐 Helm，我們應(yīng)該充分利用他們的經(jīng)驗和成果，并積極地和他們溝通交流，從而提升我們使用 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)一制品倉庫管理和安全漏洞掃描，在實現(xiàn)基于 Helm 的 CI/CD 流水線和自動化部署方案起到了重要的作用。Codefresh 公司就利用 JFrog 的產(chǎn)品和相關(guān)工具搭建了自己產(chǎn)品的流水線并廣泛使用。