Helm
Kubernetes 作为管理容器的这样一个工具,他的内部组件十分的复杂,包括容器基准、网络服务这些,提供了自动对于资源快速创建的能力,能够监测资源节点的状态,也就是一个 pod ,在其发生故障时按照预先的定义进行后续的操作,例如数量保障之类的功能。
上图是 Kubernetes 的组件架构图,内部是以 pod 作为最小的调度,而整体的资源信息是以一个 YAML 的文件进行定义的,对于这么大的一个生态系统,如果让人手动的去维护他的配置文件,反而会提高人工成本,起不到增效的目的,因此就需要一个能够自动管理这些资源配置的工具,而 Helm 就是这样的一个工具。
1、相关概念
1.1、简介
Helm 是由 Deis 开发的一个用于专门管理 Kubernetes 的包管理工具,类似于 Centos 中的 YUM 或者是 Python 中的 PIP ,如果有用过相关的管理工具的话,都会说一句棒,能够大量的简化日常开发中的资源管理问题。
他的主要功能就是为 K8S 的应用维护了一系列的 YAML 文件,只需要关注应用程序的元信息即可,而不用去手动维护一个及其复杂且晦涩的配置文件。
- 开发者可以通过其对应用资源进行管理维护和仓库发布。
- 使用者可以快速对应用生命周期进行操作,包括版本迭代、回滚这些问题。
1.2、组件
-
Tiller
是 Helm 的服务端,部署在集群当中,主要是接受客户端的请求,并根据
Chart创建对应的部署文件交由集群去创建应用,还提供了版本的升级、删除、回滚等功能。 -
Chart
是 Helm 的管理包,采用
TAR格式,包含了一组定义 Kubernetes 资源相关的 YAML 文件。 -
Repository
是 Helm 的软件仓库,类似于 Docker 的镜像仓库,提供从仓库中下载 Chart 的功能。
-
Release
使用
helm install命令在 Kubernetes 集群中部署的 Chart 称为 Release。
2、工作原理
由上面的图我们就可以发现,其实他的整个工作流程就是几个组件之间的相互交互和与外界集群的交互,我们着重来看一下组件之间交互的具体工作过程。
2.1、Chart Install
这个过程就是我们的应用发布的流程,首先我们需要有标准的 Helm 格式的应用文件格式,也就是需要先创建好数据或者说从远程仓库中拉取数据。
- 从目录或者是 TAR 文件中解析出 Chart 的结构信息;
- 将 Chart 和具体的元数据信息通过 gRPC 发送给 Tiller;
- Tiller 创建具体的配置文件,也就是一个 Release;
- 将生成的 Release 发送给集群进行应用的部署生成。
2.2、Chart Update
- 从目录或者是 TAR 文件中解析出 Chart 的结构信息;
- 将需要更新的 Release 的名称、Chart 结构和 Values 信息发送给 Tiller。
- Tiller 生成 Release 并更新传递过来指定名称 Release 的 History 版本信息。
- 将新的 Release 发送给 Kubernetes 用于更新应用数据。
2.3、Chart Rollback
- 将要回滚的 Release 的名称传递给 Tiller。
- Tiller 根据名称查找到具体 Release 的 History。
- 从 History 中获取上一个 Release。
- 将获取的 Release 发送给 Kubernetes 用于替换当前 Release,实现版本回滚。