目前我们部署的 Kubernetes 微服务都是通过 Yaml 文件来维护的。每个微服务都需要维护⼀套 Yaml 文件, 但是每个环境下的配置文件也不太⼀样。对于单体服务,部署一套测试环境还是非常快的;但是对于微服务架构的应用,要部署一套新的环境,就非常麻烦了;微服务越多、管理越麻烦。如果我们能够使用类似于 Yum 的工具来安装应⽤的话是不是就很方便呢? Helm 就相当于 kubernetes 环境下 的 Yum 包管理工具。
1、什么是Helm?
Helm 是 Kubernetes 的软件包管理工具。类似于我们在 Ubuntu 中使用的apt、Centos中使用的 Yum 或者 Python 中的 pip 一样,能快速查找、下载和安装软件包。Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。
在 Kubernetes 中部署一个可以使用的应用,需要涉及到很多的 Kubernetes 资源的共同协作。例如我们前面讲解的 WordPress 安装部署,用到了一些 Kubernetes 的一些资源对象,包括 Deployment 用于部署应用、Service 提供服务发现、Secret 配置 WordPress 的用户名和密码,可能还需要 pv 和 pvc 来提供持久化服务。并且 WordPress 数据是存储在 MySQL 里面的,所以需要 MySQL 启动就绪后才能启动 WordPress。这些 Kubernetes 资源过于分散,不方便进行管理,直接通过 kubectl 来管理一个应用,你会发现这非常麻烦。所以我们在 Kubernetes 中部署一个应用,通常面临以下几个问题:
- 如何统一管理、配置和更新这些分散的 Kubernetes 的应用资源文件;
- 如何分发和复用一套应用模板;
- 如何将应用的一系列资源当做一个软件包进行管理。
于是 Helm 包管理工具应用而生、接下来我们来详细的看看 Helm 的概念、用途、组件、原理等内容。
Helm概念
Helm 有三个重要概念:
- chart:包含了创建 Kubernetes 的⼀个应⽤实例的必要信息
- config:包含了应⽤发布配置信息
- release:是⼀个 chart 及其配置的⼀个运⾏实例
Helm用途
做为 Kubernetes 的⼀个包管理工具, Helm 具有如下功能:
- 创建新的 chart
- chart 打包成 tgz 格式
- 上传 chart 到 chart 仓库或从仓库中下载 chart
- 在 Kubernetes 集群中安装或卸载 chart
- 管理用 Helm 安装的 chart 的发布周期
Helm组件
Helm 有以下两个部分组成,分别是 helm 客户端 和 Tiller 服务器:
Helm Client 是⽤户命令行工具,其主要负责如下:
- 本地 chart 开发;
- 仓库管理;
- 与 Tiller sever 交互;
- 发送预安装的 chart;
- 查询 release 信息;
- 要求升级或卸载已存在的 release。
Tiller Server 是⼀个部署在 Kubernetes 集群内部的 server,其与 Helm client、Kubernetes API server 进⾏交互。Tiller server 主要负责如下:
- 监听来⾃ Helm client 的请求;
- 通过 chart 及其配置构建⼀次发布;
- 安装 chart 到 Kubernetes 集群,并跟踪随后的发布;
- 通过与 Kubernetes 交互升级或卸载 chart;
- 简单的说,client 管理 charts,而 server 管理发布 release。
2、Helm安装
从2019年11月开始、Helm就正式开始升级到了Helm3。但是Helm2和Helm3之间还是有很大的区别。比如Helm3中移除了Tiller、Helm 2 是 C/S 架构,主要分为客户端 helm 和服务端 Tiller; 与之前版本相同,Helm 3 同样在 Release 页面提供了预编译好的二进制文件。差别在于原先的二进制包下载下来你会看到 helm 和 tiller 。而 Helm 3 则只有 helm 的存在了。Tiller 主要用于在 Kubernetes 集群中管理各种应用发布的版本,在 Helm 3 中移除了 Tiller, 版本相关的数据直接存储在了 Kubernetes 中。
下面我们就来看看Helm3的安装和基础使用方法。
Helm项目地址:https://github.com/helm/helm/releases
首先我们去上面的Helm Github地址把Helm3的二进制包下载到本地,然后通过tar -zxvf 命令进行解压、解压完成之后直接通过mv或者cp命令把Helm包移动到 /usr/local/bin/helm ,然后Helm3就已经安装完成了、我们可以通过helm version 命令查看Helm安装版本、我这里安装的是v3.1.2:
要安装 Helm 的服务端程序,我们需要使用到 kubectl 工具,所以先确保 kubectl 工具能够正常访问kubernetes 集群的 apiserver。 然后我们需要先执行 helm init 来进行初始化。Helm3的初始化就简单了很多,不再需要给集群中部署 Tiller 了。
原先,由于有 RBAC 的存在,我们在开始使用时,必须先创建一个 ServiceAccount 而现在 Helm 的权限与当前的 KUBECONFIG 中配置用户的权限相同,非常容易进行控制。这样也大大增强了使用 Helm 的安全性。至此, Helm 已经配置完成了,接下来我们看看如何使用吧(关于Helm2和Helm的区别、我们在文末详细总结)。
3、使用Helm
我们现在尝试创建一个Chart:
我们通过查看 templates 目录下⾯的 deployment.yaml 文件可以看出默认创建的 Chart 是⼀个 nginx 服务,具体的每个文件是干什么用的,我们可以前往 Helm 官方文档进行查看,当然后面我们也会详细讲解的。比如这里我们来安装 1.7.9 这个版本的 nginx。我们直接更改 value.yaml 文件下面的 image tag 即可,将默认的 stable 更改为 1.7.9,为了测试方便,我们把 Service 的类型也改成 NodePort:
现在我们来尝试安装一下这个 Chart 。在 Helm 2 中,如果没有指定 release 的名称,则会自动随机生成一个名称。但是在 Helm 3 中,则必须主动指定名称,或者增加 –generate-name 的参数。比如:
等到 Pod 创建完成后,我们可以根据创建的 Service 的 NodePort 来访问该服务了,然后在浏览器中 打开 http://172.16.200.1:30652 就可以正常的访问我们刚刚部署的 nginx 应用了。
当然我们可以通过下面的命令来操作Helm:
查看Release:
helm list
打包Chart:
helm package hello-helm
注:我们可以将打包的 tgz ⽂件分发到任意的服务器上,通过 helm fetch 就可以获取到该 Chart了。
删除Release:
helm delete hello-helm-1584972412
当然,还有更多关于 Helm 的使用命令,我们可以前往官方文档查看。
4、Helm2和Helm3的区别
Helm2和Helm3的区别有下面几条:
- 移除Tiller(前面已经讲解过了、这里不再重复);
- Release 名称可在不同 ns 间重用;
- 必须指定Release名称;
- 支持将 Chart 推送至 Docker 镜像仓库中;
- 移除 helm serve。