马后炮：Operator for Spark 之后
Google 宣布 Kubernetes Operator for Spark 之后，朋友们的评价主要集中在 GCP 对大数据的浓厚兴趣上；我觉得还有一个解读就是，我以前可能低估了 Operator 的重要地位，因此有了本文。
背景
CoreOS 最初在 2016 年底发布 Operator 概念时，称其主旨为：Putting Operational Knowledge into Software，也就是将运维技能融入软件，在翻译该声明时，也只是觉得这一说法很有趣，但是在 GCP 发布了 Spark Operator 之后，我觉得似乎有必要回顾一下，Operator 到底是要用来做什么的。
我们的团队正在 Kubernetes 社区进行一个概念的设计和实现，这一概念就是：在 Kubernetes 基础之上，可靠的创建、配置和管理复杂应用的方法。 我们把这种软件称为 Operator。一个 Operator 指的是一个面向特定应用的控制器，这一控制器对 Kubernetes API 进行了扩展，使用 Kubernetes 用户的行为方式，创建、配置和管理复杂的有状态应用的实例。他构建在基础的 Kubernetes 资源和控制器概念的基础上，但是包含了具体应用领域的运维知识，实现了日常任务的自动化。
上面一篇文字来自我对原文的译稿：Operator：固化到软件中的运维技能，这一段文字分析一下：
- 复杂应用：一般来说，Kubernetes 上的复杂应用，指的主要是两种：有状态或者有协作。
- 创建、配置和管理：在软件的开发阶段之后，就进入了 Operator 的管理范围了。
- 使用 Kubernetes 用户的行为方式：Kubectl、API Server、声明式的 API、资源、YAML。。。
- 特定应用的控制器：在软件的“本体”之外，还需要实现一个控制单元，用来完成对专属资源的解释和执行。
粗看上来，这东西有点多余，多学东西、多写东西，为的就是在 Kubernetes 上用 Kubectl 操作 YAML 的方式来装软件配置软件？老夫早已熟悉各种 ini xml json toml 等乌七八糟的配置方式。要这东西有什么用呢？
为了示范 Operator 的功能，CoreOS 特意开放了两个 Operator：ETCD 和 Prometheus。
例如 ETCD Operator，通过一定的 YAML 定义，可以完成以下功能：
- 创建集群
- 集群伸缩
- 故障应对
- 集群升级
- 备份和恢复
同时 CoreOS 还提供了 Operator Framework 进行 Operator 的开发。
当运维遇上 Operator
Operator 的功能，稍微理解一下，就看得出它提出了一个新的运维方式：使用 Kubernetes 原生 API 或者 Kubectl 等基于这种 API 的工具来替换原本各走各路的运维方式。把原有的各种系统的部署和配置方式，转换为 Kubernetes 世界中的 CRD，利用 CRD 的资源对象来完成各种运维任务。
这实际上是将运维操作进行了一次抽象，用一致的界面来完成各种不同的运维动作，在理想情况下，一个软件系统提供的 Operator 丰富到覆盖其所有应用场景，那么他的所有运维操作都是可以通过 API Server 接口来进行控制，这给运维工作带来很大的便利：
- 避免学习该软件的配置方言，降低上手难度。
- 使用模板渲染的方式，能够迅速的将该软件的运维需要转换为流程化、自动化操作。
- 增强的控制能力，能够方便的进行 CI/CD 集成。
- 声明式 API，对运维过程的管理，提供了更高的透明、可控、版本化等优势。
- 现有的控制门户等运维设施，也能完成新系统的快速接入。
上述种种优势，对运维工作来说都是很有帮助的，然而面对现实，还是有一些限制的：
- 平台限制：很明显，几乎只有 Kubernetes 上的应用才能享受 Operator 的优势。
- 数量稀少：目前有提供 Operator 的软件还是九牛一毛，未能产生规模效应，配置方言的学习并无法避免。
- 设计困难：Operator Controller 定义 CRD，然后使用 API 提交 CRD 资源对象的方式看上去很不错，但是要用 CRD 定义一个系统的所有场景，谈何容易，官方的 Prometheus Operator 基本无法生产应用就是明证。
- Operator 失败的情况下，其原始的方言配置未必能够在 Kubernetes + Operator 环境中奏效。
最大的一个问题，Operator 是需要开发的，谁来负责他的工作量呢？
当开发遇上 Operator
对开发来说，Operator 如果流行，可能不是一个好消息。
目前的企业系统开发中，通常对于最终用户的界面、以及应用之间的 API 管理都有详尽的需求、设计和测试等文档要求，然而在运维是自己人的情况下，因为并不影响交付，很多中间、自用系统的运维工作设计，往往就糊弄了事了
如果 Operator 落地开花，就产生了一个副作用——需要修改交付标准：
- 把运维当成用户
- 运维用户自然也应该有针对性的需求调研分析
- 要有详尽的运维场景设计
- 对于 Operator CRD 无法完整覆盖的情况下，要有降级的措施准备。
总结
通过上面粗浅的分析，可以看出要落地使用 Operator，对 DevOps 的两端都需要有一点点的变化：Dev 的交付标准，和 Ops 的工作方式。
带来的好处也不太醒目：声明化、标准化和自动化。