# 马后炮：Operator for Spark 之后 > [Google 宣布 Kubernetes Operator for Spark](https://blog.fleeto.us/post/google-announces-k8s-operator-for-spark/) 之后，朋友们的评价主要集中在 GCP 对大数据的浓厚兴趣上；我觉得还有一个解读就是，我以前可能低估了 Operator 的重要地位，因此有了本文。 ## 背景 CoreOS 最初在 2016 年底发布 Operator 概念时，称其主旨为：[Putting Operational Knowledge into Software](https://coreos.com/blog/introducing-operators.html)，也就是将运维技能融入软件，在翻译该声明时，也只是觉得这一说法很有趣，但是在 GCP 发布了 Spark Operator 之后，我觉得似乎有必要回顾一下，Operator 到底是要用来做什么的。 > 我们的团队正在 Kubernetes 社区进行一个概念的设计和实现，这一概念就是：在 Kubernetes 基础之上，可靠的创建、配置和管理复杂应用的方法。 > 我们把这种软件称为 Operator。一个 Operator 指的是一个面向特定应用的控制器，这一控制器对 Kubernetes API 进行了扩展，使用 Kubernetes 用户的行为方式，创建、配置和管理复杂的有状态应用的实例。他构建在基础的 Kubernetes 资源和控制器概念的基础上，但是包含了具体应用领域的运维知识，实现了日常任务的自动化。 上面一篇文字来自我对原文的译稿：[Operator：固化到软件中的运维技能](https://blog.fleeto.us/post/operator-for-kubernetes/)，这一段文字分析一下： - 复杂应用：一般来说，Kubernetes 上的复杂应用，指的主要是两种：有状态或者有协作。 - 创建、配置和管理：在软件的开发阶段之后，就进入了 Operator 的管理范围了。 - 使用 Kubernetes 用户的行为方式：Kubectl、API Server、声明式的 API、资源、YAML。。。 - 特定应用的控制器：在软件的“本体”之外，还需要实现一个控制单元，用来完成对专属资源的解释和执行。 粗看上来，这东西有点多余，多学东西、多写东西，为的就是在 Kubernetes 上用 Kubectl 操作 YAML 的方式来装软件配置软件？老夫早已熟悉各种 ini xml json toml 等乌七八糟的配置方式。要这东西有什么用呢？ 为了示范 Operator 的功能，CoreOS 特意开放了两个 Operator：[ETCD](https://github.com/coreos/etcd-operator) 和 [Prometheus](https://github.com/coreos/prometheus-operator)。 例如 ETCD Operator，通过一定的 YAML 定义，可以完成以下功能： - 创建集群 - 集群伸缩 - 故障应对 - 集群升级 - 备份和恢复 同时 CoreOS 还提供了 [Operator Framework](https://github.com/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 的工作方式。 带来的好处也不太醒目：声明化、标准化和自动化。