1.4.2　Tiller

Tiller作为Helm Server端的实现，初始化时就以Pod的形式部署在Kubernetes集群内部。Tiller通过集群内的service account与Kubernetes apiServer通信。Tiller需要的权限很高，能够管理所有namespace的资源，因此在多租户环境下，Tiller的存在会让权限管理变得异常复杂。

Tiller会接受从Helm Client发来的数据，这就是经过渲染后的一个全量yaml。Tiller会直接将该yaml文件投递给Kubernetes apiServer，同时根据传递来的一些原始数据，在Kubernetes集群中创建一个configmap资源来记录创建的Release信息。在将yaml文件提交给Kubernetes apiServer后，用户的应用就能够在集群中正常地创建和运行了。

Tiller还会接收客户端遍历当前所有已经安装的应用，以及回滚某个应用的请求，因此Tiller会在configmap中记录每一个版本的详细信息，并以版本号作为标识。这样每一个版本都有全量的信息留存，用户可以很方便地遍历到当前所有的版本号，而且能够跨版本回滚或更新。

Tiller还提供了很多Hooks功能，在用户安装某些资源前后都能触发一些动作，通过这样的功能让安装过程更加自主可控，后文会详细解析这个Hooks功能的实现原理与使用方式。