Helm vs Operator
Kubernetes提供声明式API对标准对象进行生命周期管理，例如Deployment，Pod，Service以及ConfigMap等。基于这种原子能力，开发人员可以*组合各种对象，以Yaml，Json等格式文件进行定义，构建自己的业务应用。
随着应用自身的复杂度增加，依赖条件变多，部署环境的多样性，这种原始的声明式API使用方式显得低效且不够灵活；另外，在应用与声明式API之间缺少一个构建标准，也不利于应用的共享，分发，以及应用市场的发展。Helm和Operator应运而生，在声明式API之上进行了一层抽象和封装，成为解决这种困境的两个主要流派。
Helm Chart
Helm是基于Kubernetes的应用包管理工具，可实现应用程序封装、版本管理、依赖检查、应用分发，是对容器应用所需资源组件进行集中管理，并通过模板化和配置分离提高声明式API的开发和使用效率。Chart包则是应用的载体，实现了应用的分发和共享，支撑了应用市场的发展。
Operator
Operator主要包含CRD和Controller两个部分：
- CRD是在Kubernetes的标准对象之上构建一层直接面向应用的扩展对象，例如Mysql Operator提供的InnoDBCluster和MySQLBackup这两个扩展对象。
- Controller是指自定义控制器，以Deployment的形式在Kubernetes中运行，监听CRD的配置变化，并转换成标准对象进行实现。控制器自动化智能化的灵活实现应用生命周期管理能力以及运维能力，是Site Reliability Engineering (SRE)思想在容器集群领域的一个落地实践。
Helm与Operator的比较
Helm和Operator从不同角度衔接了应用和声明式API，两者之间有着明显的差异，下面从不同角度对Helm以及Operator进行了一个比较：
| Helm | Operator | |
|---|---|---|
| 资源类型 | 标准对象，自定义对象 | 自定义对象 |
| 编排能力 | 支持应用全生命周期管理 | 支持应用全生命周期管理 |
| 运维能力 | 手工，较弱 | 自动故障恢复及异常处理 |
| 设计理念 | 资源模板化，配置分离 | 复杂应用的自动化管理 |
| 实现方式 | 传统镜像 | k8s控制器 |
| 实现难度 | 较低 | 偏高 |
| 灵活性 | 高度灵活修改yaml文件 | 依赖控制程序，不太灵活 |
| 适宜场景 | 通用，普适 | 有状态服务，较复杂应用场景 |
关于应用场景方面，其实不太好区分，因为这两项技术本身就致力于解决不同的问题：
- Helm本质是包管理工具，适合于安装标准的通用的应用程序。
- Operator本质是一种设计模式，强项在于支持有状态应用的复杂生命周期管理，将运维过程中的知识和方法固化在控制器中，实现自动化运维。