初步理解Operator

1. Kubernetes简单构建业务应用

k8s提供诸如Deployment, pod, service以及configmap等标准资源对象，并提供声明式API对这些资源对象进行生命周期管理。基于这种原子能力，开发者以yaml等格式文件定义，并组合这些资源对象构建业务应用。

2. 为什么需要Helm与Operator

虽然所有应用都可以通过定义组合k8s内各种资源文件进行构建部署，但是如果应用自身依赖较多，部署环境多样性，导致应用部署复杂度增高。这时以这种最原始的部署方式就显得低效复杂，维护难度高，成本大，不利于应用本身发展。
所以就需要在应用和k8s声明式API之间增加一个构建标准，此时helm与operator应运而生。helm与operator逐渐成为方便k8s构建业务应用的两种主要方式。

3. Helm

Helm是k8s的包管理工具，类似于apt与ubuntu，yum与Centos的关系。Helm就是通过helm chart把需要定义的上述说的k8s资源定义文件打包，对这些应用所需的资源文件进行统一管理，以模板化，配置分离的模式提高应用部署效率，实现了应用封装，版本管理，应用分发和共享等，但缺乏对应用资源的全生命周期的监控管理和运维。

4. Operator

operator通俗的理解，功能和helm一样，都是为了更方便的去部署和管理应用，可以理解为一个部署及管理应用的控制器。能力是由operator扩展了k8s的API来实现的，其实质就是用户先向k8s注册自定义资源CRD(Custom Resource Definition), 然后再创建对应资源实例（Custom Resource，简称CR），相当于向k8s提交一个自定义资源实例的yaml文件，并提供一个controller来不断检测CR在k8s中的状态，如果状态与预期不一致，则controller会一直去协调（Reconcile）CR的状态，直到与预期一致。底层的协调逻辑其实就是调k8s的api server客户端去根据预期和当前状态比较去做增删改。其优势在于自定义资源，支持应用的全生命周期管理和故障自动修复，高效的运维能力。