为何需要 Helm
Kubernetes 在容器编排领域已经成为事实上的标准,一款云原生应用在开发周期的最后阶段都是会被部署到 k8s 集群之上。
部署在 k8s 上的应用在免去了拓展,迁移,服务发现等一系列工作的同时,也带来了其他的问题。
由于 Kubernetes 的资源都是声明式的,这意味着如果想要部署一款新的应用,那么就需要围绕应用所需的资源,以及其的元信息编写对应的 yaml 文件,包括不限于 service,deployment,configmap,secret 的资源定义。
如果是一款简单的应用还好,但是一旦应用比较复杂,依赖的资源比较多,那么编写资源文件就是一个痛苦的过程了,而且往往不是开发人员独自能够完成的,还需要和运维人员进行配合。
除此之外,每次升级应用,都需要一系列的工作,并且如果需要回滚应用的版本,那么就更加会运维开发人员感到痛苦了。
因此,为了解决这些问题,我们就需要 helm 来帮我们完成一些重复性的工作,根据模版来生成我们所需要的资源文件。
helm
helm 是一个Kubernetes 应用打包,管理工具。每个 kubernetes 上的应用被称之为一个 helm chart。
使用 helm 可以帮助我们来定义,升级,发布以及回滚应用。而不需要每次都复制粘贴,然后再修改。
如果将 Kubernetes 看作为一个操作系统话,那么 helm 就是系统的软件管理器,也可以将其看作是一个 APP store。
通过修改 helm 生成的模版值,完成应用的打包,之后就可以将应用推送到不同的仓库。在需要安装应用的集群上只需要运行 helm upgrade 就可以完成安装了。免去了一堆的烦恼。
helm 的一些概念
Chart
Chart 是 helm 的打包格式,它有一系列相关的 Kubernetes 资源文件组成。每个 chart 都相当于一个应用,不论是一个简单的单 pod 应用,还是一个包含多个服务,以及数据库,缓存等功能的复杂应用。
当完成资源文件的配置之后,就可以发布新版本的应用了。
chart 的文件结构
1 |
|
每个 chart 都需要有对应的版本号。例如:nginx-1.2.3.tgz
代表这是一个 1.2.3 版本的 nginx 应用。
Repository
Repository 是一个存放,分享 chart 的地方。在完成指定版本的 chart 后,可以将其推送到指定的 repository 中,其他需要使用的人就可以从对应的 repository 拉取到想要的 chart 并启动。
Release
Release 是一个运行在 Kubernetes 上的 chart 的实例。chart 是可以在集群上多次安装的,每次安装一个 chart 都会产生一个 release。
同样的,如果需要两个实例同时运行,那么只需要安装 chart 两次即可,这样集群上就会有两个 release,并且每个 release 都有着自己的名字。
以面向对象的思想来看的话,chart 就是一个类,而 release 就是 chart 的实例对象。
以上就是关于为什么需要 helm 以及 helm 的基本概念,需要了解更多的信息可以阅读官方文档。