「Kubernetes12」Helm释放部署生产力 Kubernetes是一个强大的容器调度

Kubernetes 是一个强大的容器调度系统，你可以通过一些声明式的定义，很方便地在 Kubernetes 中部署业务。
现在你一定很想尝试在 Kubernetes 中部署一个稍微复杂的系统，比如下面这个典型的三层架构：前端、后端和数据层。
也许你内心里已经开始跃跃欲试，但是转念一想，事情好像没那么简单啊。你感觉到这里面要写一堆的 YAML 文件，每一层架构都至少要写 2 个 YAML 文件，写的时候还需要理解各种对象、注意各种缩进的层级关系、还要设置一堆配置参数等。这对于刚接触 Kubernetes 的人来说是一个很高的门槛，简直无法跨越。同时，对于业务交付的同学，也将是一个大灾难，因为如果缺少任何一个 YAML 文件，都会导致整个系统无法正常工作。
看到这里，你也许会想到能不能通过一种包的方式进行管理呢，类似于 Node.js 通过 npm 来管理包， Debian 系统通过 dpkg 来管理包，而 Python 通过 pip 来管理包。
那么在 Kubernetes 中，这个答案就是Helm 。
Helm 降低了使用 Kubernetes 的门槛，你无须从头开始编写应用部署文件，甚至都不需要了解 Kubernetes 中的各个对象以及相应的 YAML 语义。直接通过 Helm 就可以在自己的 Kubernetes 中一键部署需要的应用。
对于开发者而言，通过 Helm 进行打包，管理应用内部的各种依赖关系，极其方便。并且可以借助于版本化的概念，方便自身的迭代和分发。除此之外， Helm 还有一些其他强大的功能，请跟我一起开始今天 Helm 的学习之旅。
Helm 中的几个概念在 Helm 中，有三个非常核心的概念—— Chart、Config 和 Release 。
Chart 可以理解成应用的安装包，通常包含了一组我们在 Kubernetes 要部署的 YAML 文件。一个 Chart 就是一个目录，我们可以将这个目录进行压缩打包，比如打包成 some-chart-version.tgz 类型的压缩文件，方便传输和存储。
每个这样的 Chart 包内都必须有一个 Chart.yaml 文件。这个 Chart.yaml 主要用来描述该 Chart 的名字、版本号，以及关键字等信息。
有了这个 Chart ，我们就可以在 Kubernetes集群中部署了。每一次的安装部署，我们称为一个 Release 。在同一个 Kubernetes 集群中，可以有多个 Release 。你可以将 Release 理解成是 Chart 包部署后的一个 Chart（应用）实例。
同时，为了能够让 Chart 实现参数可配置，即 Config ，我们在每个 Chart 包内还有一个 values.yaml 文件，用来记录可配置的参数和其默认值。在每个 Release 中，我们也可以指定自己的 values.yaml 文件用来覆盖默认的配置。
此外，我们还需要统一存放这些 Chart ，即 Repository（仓库）。这个概念和我们以前的 yum repo 是一样的。本质上来说， Repository 就是一个 Web 服务器，不仅保存了一系列的 Chart 软件包让用户下载安装使用，还有对应的清单文件以供查询。
通过 Helm ，我们可以同时使用和管理多个不同的 Repository ，就像我们可以给 yum 配置多个源一样
掌握了这些概念，我们现在再拉远视角，整体来看一下。
Helm 的安装及架构组成首先， Helm 的安装非常简单，你可以通过如下的命令安装最新版本的 Helm 可执行文件：
$ curl| bash
安装完成后，我们来查看下 Helm 的版本：
$ helm version
version.BuildInfo{Version:"v3.3.1", GitCommit:"249e5215cde0c3fa72e27eb7a30e8d55c9696144", GitTreeState:"clean", GoVersion:"go1.14.7"}
可以看到目前我们安装的版本是v3.3.1 ，这是 Helm 3 的一个版本。其实在 Helm 3 之前，还有 Helm 2 ，目前还有不少人在继续使用 Helm 2 的版本。现在我们来简单了解下 Helm 2 和 Helm 3。
Helm 2【「Kubernetes12」Helm释放部署生产力】Helm 2 于 2015 年在 KubeCon 上亮相。是个常见的 CS 架构，由 Helm Client 和 Tiller 两部分组成。
Tiller 是 Helm 的服务端，用于接收来自 Helm Client 的请求，主要负责部署 Helm Chart、管理 Release（比如升级、删除、回滚等操作），以及在 Kubernetes 集群中创建应用。 TIller 通常部署在 Kubernetes 中，直接通过helm init就可以在 Kuberentes 集群中拉起服务。
Helm Client 主要负责跟用户进行交互，通过命令行就可以完成 Chart 的安装、升级、删除等操作。 Helm Client 可以从公有或者私有的 Helm 仓库中拉取 Chart 包，通过用户指定的 Config ，就可以直接传给后端的 Tiller 服务，使之在集群内进行部署。
这里，我们可以看到 Tiller 在 Helm 2 和 Kubernetes 集群中间其实起到了一个中转的作用，因此 Tiller 实际上是代替用户在 Kubernetes 集群中执行操作，所以 Tiller 在运行中往往需要一个很高的权限。这里 Tiller 存在着两大安全风险：