所属技术领域：
K8s
|名词定义|
operator是描述、部署和管理kubernetes应用的一套机制，从实现上来说，operator=CRD+webhook+controller
|技术特点|
常见operator工作模式
1.用户创建一个CRD
2.apiserver转发请求给webhook
3.webhook负责CRD的缺省值配置和配置项校验
4.controller获取到新建的CRD，处理“创建副本”等关联逻辑
5.controller实时检测CRD相关集群信息并反馈到CRD状态
Operator应用场景
在传统运维环境中，中间件都是基于非容器部署，我们往往会面对各种部署及运维需求：
- 备份&数据恢复。备份分为冷备和热备。冷备通常可以通过定时任务执行，对于即时的备份需求，大公司内部往往有成熟的平台支撑，但中小企业往往是运维人员手动执行操作，数据恢复也是如此
- 扩容。又分scaleup、scaleout。对于数据库，如果只是scaleout，增加从节点，相对较容易；但是如果是scaleup，升级主节点cpu、内存呢？往往涉及比较复杂的一系列运维操作，且风险极大
- 故障恢复。对于特定中间件，通常都有比较成熟的高可用集群部署方案，但对于运维而言，依然存在诸多问题。对于异常节点，如何恢复？对于不同中间件之间的依赖，如何处理？（比如断电重启中，hadoop对zk的依赖，hbase对hadoop的依赖等）
- 声明式部署。对于POC环境，单节点即可；对于生产环境，使用集群方式，节点数多少等等，都使用声明式地配置，通过helm/ansible方式一键安装
- 安全。网络访问限制、加密协议及秘钥管理等
- 版本升级。如何平滑升级，一直是部署运维人员面对有状态系统头疼的问题，所以通常这些系统比较稳定，一方面是自身问题，另一方面是升级困难风险高，不得不压住升级需求。
以上场景都是可以通过Operator解决，使用方式上，只需要创建指定格式的K8S CRD即可，至于Operator内部如何执行具体的部署/运维逻辑，交付人员无需关心。
Operator作用域
Operator比运维人员的人工判断要敏捷的多，它可以观测集群/应用的当前状态并在若干毫秒之内作出合理的运维决定。
Operator遵循如下成熟度模型：
Helm通常用于Charts的部署于升级，Ansible则可以触及到应用的生命周期管理，而高级的Operator可以实现无缝升级、自动处理故障，真正达到Auto-pilot，自运维、自巡航。
Operator与K8S Controller的关系
几个tips：
• 所有的Operator都是用了Controller模式，但并不是所有Controller都是Operator。只有当它满足: controller模式 + API扩展 + 专注于某个App/中间件时，才是一个Operator。
• Operator就是使用CRD实现的定制化的Controller. 它与内置K8S Controller遵循同样的运行模式(比如 watch, diff, action)
• Operator是特定领域的Controller实现
所以要了解Operator的工作原理，首先要先了解K8S controller的原理。控制器是一个永不终止的控制循环，它持续管理着集群的状态，通过apiserver获取系统的状态，并且不断尝试以达到预期状态，比如副本控制器，namespace控制器，service-accounts控制器，Ingress也是一个典型的Controller实现
Informer和workqueue是两个核心组件。Controller可以有一个或多个informer来跟踪某一个resource。Informter跟API server保持通讯获取资源的最新状态并更新到本地的cache中，一旦跟踪的资源有变化，informer就会调用callback。把关心的变更的Object放到workqueue里面。然后woker执行真正的业务逻辑，计算和比较workerqueue里items的当前状态和期望状态的差别，然后通过client-go向API server发送请求，直到驱动这个集群向用户要求的状态演化。
|资料来源|
名词定义：https://blog.csdn.net/bbwangj/article/details/82355337
技术特点：https://www.jianshu.com/p/10a86e54309e
技术特点：https://coreos.com/operators/
