一、背景

Kubernetes 是目前最为风行、成为事实标准的容器集群治理平台，为容器化利用提供了部署运行、资源调度、服务发现和动静伸缩等一系列残缺性能。在 Kubernetes 当中，用户通过应用 API 对象，如 Pod、Service、Deployment 等，来形容利用的程序规定，而这些资源对象的定义个别须要写入一系列的 YAML 文件中，而后通过 Kubernetes 命令行工具 Kubectl 进行部署。因为通常应用程序都波及到多个 Kubernetes API 对象，而要形容这些 API 对象就可能要同时保护多个 YAML 文件，从而在进行 Kubernetes 软件部署时，通常会面临下述几个问题：

· 如何治理、编辑和更新这些这些扩散的 Kubernetes 利用配置文件

· 如何把一套相干的配置文件作为一个利用进行治理

· 如何散发和重用 Kubernetes 的利用配置

Helm（https://helm.sh）的呈现就是为了很好地解决下面这些问题，是 Kubernetes 官网提供的包管理工具，次要是是通过治理被称作 Helm Chart 的包来形容和治理云服务的。应用 Helm 后就不须要再编写简单的利用部署文件，能够以简略的形式在 Kubernetes 上查找、装置、降级、回滚、卸载应用程序。

在当初罕用的 Helm V2 架构中，有一个称为“Tiller”的服务端组件。Tiller 是一个集群内服务器，可与 Helm 客户端进行交互，并与 Kubernetes API 服务器连贯。但因为 Tiller 具备 root 用户拜访权限，使得有人能够未经受权拜访 Kubernetes 服务器你，从而形成了很大的危险。

JFrog 的专家，也是 Helm 的联结创始人，Rimas Mocevicius，提供了一种翻新的、优雅的办法——Tillerless Helm，来解决这种状况，从而爱护用户的 Kubernetes 集群。

二、Helm V2 的利用架构

从 Helm v2 开始，Helm 的架构中有一个名为 The Tiller Server 的服务器局部，该服务器局部是一个与 helm 客户端交互并与 Kubernetes API 服务器连贯的集群内服务器。服务器负责以下各项工作：

· 监听来自 Helm 客户端的传入申请

· 联合 Chart 和配置以创立公布版本

· 将 Chart 装置到 Kubernetes 中，而后跟踪后续版本

· 通过与 Kubernetes 交互来降级和卸载 Chart

简而言之，客户端负责管理 Chart，Tiller 负责管理公布版本，其架构如下图所示:

默认状况下，执行如下命令将 Tiller 部署装置到 Kubernetes 集群：

helm init

同时还须要为 Tiller 创立并部署 RBAC 受权，使其领有执行工作的权限。Tiller 罕用的 RBAC 受权如下所示：

目前这样的架构工作得很好，为用户提供了灵便和不便，但同时也存在一些平安问题。从下面的 RBAC 文件中能够看出，Tiller 被授予了 cluster-admin 的角色，也就是说，Tiller 在用户的 Kubernetes 集群中具备齐全的管理权限，这就具备了有人未经受权而拜访和管制集群的危险。

三、Helm V2 中的 Tillerless 计划

其实，在 Helm V2 中创立 Tillerless 的架构也并不艰难，可能为 Helm 的利用提供更高的平安保障。JFrog 的专家 Rimas 给出了优化的解决方案，而本节将通过细节的形容来解释该计划如何运行。

首先，能够将 Helm 客户端和 Tiller 都部署在工作站上，或者运行在 CI/CD 流水线中，而不须要将 Tiller 装置到 Kubernetes 集群之中。示例的装置形式如下：

$ export TILLER_NAMESPACE=my-team-namespace

$ export HELM_HOST=localhost:44134

$ tiller –storage=secret

[main] 2018/07/23 15:52:29 Starting Tiller v2.10.0 (tls=false)

[main] 2018/07/23 15:52:29 GRPC listening on :44134

[main] 2018/07/23 15:52:29 Probes listening on :44135

[main] 2018/07/23 15:52:29 Storage driver is Secret

[main] 2018/07/23 15:52:29 Max history per release is 0

在这种装置形式下，Helm 的运行架构如下图所示：

在这种架构下，Tiller 应用和 Helm 客户端一样的配置（kubeconfig）连贯到 Kubernetes 集群，并依照指定的命名空间（namespace）存储和治理 Helm 的发行版本信息。用户能够通过这种形式创立许多名称空间，并在 Tiller 启动时指定应该应用哪个命名空间。用户定义的 RBAC 规定能够存储在运行指定的名称空间中的密钥 / 配置映射中，而不再须要为 Tiller 创立和指定 ServiceAccount。而这个架构的另一个益处就是不再限定 Kubernetes 集群中只能运行一个 Tiller 实例。

留神，在这种架构下，必须应用如下的命令来初始化 Helm 客户端，否则 Tiller 依然被装置到 Kubernetes 集群中：

helm init –client-only

四、Helm V2 中的 Tillerless 插件

那么，有没有更加不便的装置形式呢？Rimas 为大家提供了一个简略的 Helm Tillerless 插件，请参见 https://github.com/rimusz/helm-tiller。

插件的装置十分不便，如下：

$ helm plugin install https://github.com/rimusz/helm-tiller

Installed plugin: tiller

该插件提供了四个简略的命令：start，start-ci，stop 和 run。

4.1 在本地应用 Tillerless 插件

对于在本地开发或拜访近程 Kubernetes 集群时，请应用 helm tiller start 命令：

$ helm tiller start

Client: &version.Version{SemVer:"v2.10.0", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

[main] 2018/07/23 16:08:07 Starting Tiller v2.10.0 (tls=false)

[main] 2018/07/23 16:08:07 GRPC listening on :44134

[main] 2018/07/23 16:08:07 Probes listening on :44135

[main] 2018/07/23 16:08:07 Storage driver is Secret

[main] 2018/07/23 16:08:07 Max history per release is 0

Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Tiller namespace: kube-system

该命令将在本地启动 Tiller，并利用 Tiller 默认的设置，在 kube-system 名称空间存储和治理 Helm 版本。

也能够通过下述命令指定 Tiller 应用的命名空间：

$ helm tiller start my-team-namespace

Client: &version.Version{SemVer:"v2.10.0", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

[main] 2018/07/23 16:08:38 Starting Tiller v2.10.0 (tls=false)

[main] 2018/07/23 16:08:38 GRPC listening on :44134

[main] 2018/07/23 16:08:38 Probes listening on :44135

[main] 2018/07/23 16:08:38 Storage driver is Secret

[main] 2018/07/23 16:08:38 Max history per release is 0

Server: &version.Version{SemVer:"v2.10.0", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Tiller namespace: my-team-namespace

该命令还会关上一个新 bash shell，带有预设的环境变量：

HELM_HOST=localhost:44134

这样，Helm 客户端就晓得如何连贯 Tiller 了。

当初，就能够开始部署或更新 Helm 的公布版本了。

当实现了所有工作之后，只须要运行下述命令，就能够敞开 Tiller 了。

$ exit

$ helm tiller stop

/Users/user/.helm/plugins/helm-tiller

Stopping Tiller..

接下来，用户也能够反复下面的过程，通过指定新的命名空间来部署和更新其余团队的公布版本。

4.2 在 CI/CD 流水线中应用 Tillerless 插件

那如何在 CI/CD 流水线当中应用该插件呢？有两种办法：

第一种 与下面的过程十分类似，只是没有启动带有预设变量的 bash shell。

$ helm tiller start-ci

$ export HELM_HOST=localhost:44134

而后，Helm 客户端将晓得连贯到 Tiller 的地位，而无需在 CI 流水线中进行任何更改。并且在流水线的结尾执行：

$ helm tiller stop

完结全副工作。

第二种 也很容易，就是运行 helm tiller run，能够使 Tiller 在指定命令之前或之后启动 / 进行：

$ helm tiller run helm list

$ helm tiller run my-team-namespace -- helm list

$ helm tiller run my-team-namespace -- bash -c 'echo running helm; helm list'

举例来看：

$ helm tiller run test -- bash -c 'echo running helm; helm list'

Installed Helm version v2.10.0

Installing Tiller v2.10.0 ...

x tiller

args=bash -c echo running helm; helm list

Client: &version.Version{SemVer:"v2.10.0", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

[main] 2018/07/25 17:33:54 Starting Tiller v2.10.0 (tls=false)

[main] 2018/07/25 17:33:54 GRPC listening on :44134

[main] 2018/07/25 17:33:54 Probes listening on :44135

[main] 2018/07/25 17:33:54 Storage driver is Secret

[main] 2018/07/25 17:33:54 Max history per release is 0

Server: &version.Version{SemVer:"v2.10.0", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Tiller namespace: test

running helm

[storage] 2018/07/25 17:33:55 listing all releases with filter

NAME    REVISION    UPDATED                     STATUS      CHART       NAMESPACE

keel    1           Sun Jul 22 15:42:43 2018    DEPLOYED    keel-0.5.0  default

Stopping Tiller...

附加性能：该插件还可能查看装置的 Helm 客户端和 Tiller 的版本，如果不匹配，则下载正确的 Tiller 版本文件。

五、总结

Helm 作为 Kubenetes 的官网包管理工具，为用户提供了不便、快捷的在 Kubernetes 集群里部署和治理本人应用程序的形式。然而，Helm V2 架构中的 Tiller 组件，在提供了操作便当的同时，也带来了平安上的隐患。

本文为大家介绍了一种在 Helm V2 中实现 Tillerless 的 Helm 部署和利用的解决方案，在保留了 Helm V2 灵活性和便利性的同时，也大大晋升了利用和治理的安全性。

欢送观看 JFrog 杰蛙每周二在线课堂，点击报名：

https://www.bagevent.com/even…

����p�