一、背景

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�