Helm - K8s的包管理器
11.1 Why Helm
K8s能够很好的组织和编排容器,但它缺少一个更高层次的应用打包工具,Helm就是干这个的。
比如对于一个MySQL服务,K8s需要部署如下对象:
(1)Service,让外界能访问MySQL
(2)Secret,定义MySQL的密码
(3)PersisentVolumeClaim,为MySQL申请持久化存储空间。
(4)Deployment,部署MySQL Pod,并使用上面的这些支持对象。
可以将上面这些配置保存到文件中,或几种写进一个文件,然后通过kubectl apply -f 部署。
如果服务少,这样问题也不大,但是如果是微服务架构,服务多达数十个甚至上百个,这种组织和管理应用的方式就不好使了:
(1)很难管理、编辑和维护如此多的服务。每个服务有若干个配置,缺乏更高层次的工具将这些配置组织起来。
(2)不容易将这些服务作为一个整体统一发布。部署人员需要首先理解应用都包含哪些服务,然后按照逻辑顺序依次执行kubectl apply, 缺少一种工具定义应用与服务,已经服务之间的依赖。
(3)不能高效的共享和重用服务。比如两个应用都用到MySQL服务,但是配置参数不一样,这两个应用只能分别复制一套标准MySQL配置文件,修改后通过kubectl apply部署。也就是不支持参数化配置和多环境部署。
(4)不支持应用级别的版本管理。虽然可以通过kubectl rollout undo进行回滚,但这只针对单个deployment,不支持整个应用的的回滚。
(5)不支持对部署的应用状态进行验证。比如是否能通过预定义账号访问MySQL。虽然K8s有健康检查,但那时针对单个容器,我们需要应用(服务)级别的健康检查。
Helm能够解决上面这些问题。
11.2 Helm架构
Helm有两个重要概念:chart和release
- chart: 是创建一个应用的信息集合,包括各种k8s对象的配置模板、参数定义、依赖关系、文档说明等。chart是应用部署的自包含逻辑单元。可以将char想象成apt、yum中的软件安装包。
- release: 是chart的运行实例,代表了一个正在运行的应用。当chart被安装到k8s集群,就生成一个release。chart能够多次安装到同一个集群,每次安装都是一个release。