linuxea:kubernetes helm概述(49)

此前,不管是无状态还是有状态的应用在部署在系统之上,如果是无状态的,使用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自动支持滚动更新机制,并且可以一键回滚。

0 分享

您可以选择一种方式赞助本站

支付宝扫码赞助

支付宝扫码赞助

日期: 2018-12-14分类: kubernetes

标签: kubernetes

发表评论