此前，不管是无状态还是有状态的应用在部署在系统之上，如果是无状态的，使用Deployment控制器进行应用伸缩是很容易。有状态的应用也可以做一些限制不进行规模的伸缩，并且也可以完成持久存储能力的。
但是一旦将有状态的应用扩展成多个副本，就会面临问题，不同的应用程序在扩展的时候，扩展的方式是各自都不相同的。如：redis主从，以及cluster都是不同的方式，etcd也是如此，这样的有状态应用部署在集群之上是一件不容易的事情。
kubernetes在配置一个应用程序的时候，是很麻烦的。首先，需要写一个很长的配置清单，从而去安装应用程序。在此前的管理方式里面，有直接使用命令创建，也有命令式配置文件和声明式配置文件。声明式配置文件借助本地的配置文件，也能够在很大程度上减轻前期的开发使用。
我们知道在linux系统之上，最初的时候也面临过这样的问题，程序包的维护代价非常大，安装一个应用程序的是时候就需要编译，而编译本身就比较复杂，且难以适配。如：版本问题等。后来就开发了包管理器RPM，但是RPM包单单解决了编译的问题，依赖包仍然匹配仍然让人头疼。后来又开发了如yum,apt这类解决依赖关系的工具。有了yum之后，对于安装程序来讲，基本上一键安装。同样，kubernetes在应用安装上，使用Helm也是可以的。
helm
helm是kubernentes的另外一个项目，专为kubernetes上的应用程序而开发。
heml的工作方式和yum和相似，首先是有一台仓库服务器，其中定义了配置，部署k8s的应用程序的清单文件。这一点和yum不一样的，yum本身不但解决依赖关系，也要提供应用程序包。但是在k8s中heml是不提供程序包的，而单单提供清单。而镜像由镜像仓库或者dockerhub和私有仓库等。
如一个应用在部署的时候所需要的所有清单文件。这个程序包只提供清单，不包含镜像。
如：nginx部署，对于nginx部署来将，首先需要nginx镜像，Deployment，还有service，如果有必要还有hpa的定义。将这三个文件打包在一起，就叫做一个应用程序包，在heml中称这个应用程序包为Chart。
不同的用户在部署Chart时也不尽相同，配置文件，证书都不尽相同。通常以模板的形式通过配置环境变量传递一些自定义的设定，也就意味着并不能够简单的一条命令安装完成，尤其是在做一些定制化配置时。
模板本身是不能进行修改，可通过赋值的方式修改，因此就会有一个值文件，用于模板引用给属性赋值，从而使得让用户能自定义安装。很多属性都是有默认值的，不赋值任何信息也可以基本的运行起来。
类似于这样的Chart有很多个，这样的Chart仓库在互联网上可以使用helm提供的官网仓库。当然，也允许用户自定义上传chart，和github，dockerhub类似。
要想成功部署chart应用，就需要k8s集群，而在k8s中，最终将期望请求操作落地的是api server，提交给api server是需要验证部署请求操作的。而helm是工作在k8s集群之外的，类似与Kubectl 客户端的形式。
但是helm不直接于api server交互。我们假设有一台笔记本用于kubernetes通讯，便于管理操作kubernetes，在这台机器上安装一个Helm，helm也是一个命令行客户端工具。当需要通过helm在k8s集群上部署应用程序时候，不直接操作api server，而是由一个中间件Tiller操作，并且tiller是一个服务端，而helm host是客户端。
Tiller是一个守护进程，监听在某个端口上，接收Helm的请求，Tiller可以运行在helm主机之上。但更好的方式是将Tiller运行在kubernetes集群之上(服务类的应用托管在k8s集群之上较为妥当)。tiller是于Helm之间完成的交互。
helm host是tiller的客户端，每一次部署应用发起请求的时候，helm提交请求给tiller,tiller再去链接api server，再由api server完成创建。这样一来，对于api server来讲，客户端程序不是helm ，而是tiller。
在helm之上，和docker的管理方式很相似，每一个chart在使用的时候一般都要从Helm仓库中下载到本地的helm主机上的运行helm用户的家目录下存放这个chart。当安装一个的应用的时候就会去helm下载存储在本地一个。也可以在本地开发，本地使用。这和很多场景下的情况相似，在helm仓库下载之前会在本地查看，如果本地有就使用，本地有和远程是否有是没有关系的。如果本地没有才会去远程下载存放本地。
而当试图去部署应用程序的时候，helm先联系Tiller，由Tiller联系api server来完成部署和应用。
helm可以将一个chart在kubernetes cluster上部署多份副本，对应名称或者名称空间各不相同。而部署到kubernetes 之后就不在叫做Chart了，Chart仅当作定义，我们需要把给定的值赋值到模板中以后，生成很多信息就有了的实例，通常我们称为对象。由此，Chart更像是某一种部署的类型的。这种类被赋值后就成为一个对象，不过他在kubernetes中不称为对象，而称为release。一旦被部署就不在叫做Chart，而是release。而同一个Chart给赋予不同的属性值后，完全可以部署出多个release来的。这便是helm的工作逻辑和架构形式。
helm从仓库拉下来赋值之后提交给Tiller,由Tiller认证到api server完成在本地对应资源的管理，每一个资源管理的对象叫做release。
helm将kuernetes资源打包到一个Chart当中，制作并测试完成各个Chart和Chart本身的依赖关系，并利用Chart参考对外实现分发，而helm可以通过vlues文件完成可配置的发布，同时支持配置程序的版本管理，而且还能简化kubernetes部署的版本控制，打包，发布，删除，更新操作。也就是说，如果Chart版本更新了，helm自动支持滚动更新机制，并且可以一键回滚。
