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 上用 Kubectl 操作 YAML 的方式来装软件配置软件?老夫早已熟悉各种 ini xml json toml 等乌七八糟的配置方式。要这东西有什么用呢?
为了示范 Operator 的功能,CoreOS 特意开放了两个 Operator:ETCD 和 Prometheus。
例如 ETCD Operator,通过一定的 YAML 定义,可以完成以下功能:
同时 CoreOS 还提供了 Operator Framework 进行 Operator 的开发。
Operator 的功能,稍微理解一下,就看得出它提出了一个新的运维方式:使用 Kubernetes 原生 API 或者 Kubectl 等基于这种 API 的工具来替换原本各走各路的运维方式。把原有的各种系统的部署和配置方式,转换为 Kubernetes 世界中的 CRD,利用 CRD 的资源对象来完成各种运维任务。
这实际上是将运维操作进行了一次抽象,用一致的界面来完成各种不同的运维动作,在理想情况下,一个软件系统提供的 Operator 丰富到覆盖其所有应用场景,那么他的所有运维操作都是可以通过 API Server 接口来进行控制,这给运维工作带来很大的便利:
上述种种优势,对运维工作来说都是很有帮助的,然而面对现实,还是有一些限制的:
最大的一个问题,Operator 是需要开发的,谁来负责他的工作量呢?
对开发来说,Operator 如果流行,可能不是一个好消息。
目前的企业系统开发中,通常对于最终用户的界面、以及应用之间的 API 管理都有详尽的需求、设计和测试等文档要求,然而在运维是自己人的情况下,因为并不影响交付,很多中间、自用系统的运维工作设计,往往就糊弄了事了
如果 Operator 落地开花,就产生了一个副作用——需要修改交付标准:
通过上面粗浅的分析,可以看出要落地使用 Operator,对 DevOps 的两端都需要有一点点的变化:Dev 的交付标准,和 Ops 的工作方式。
带来的好处也可能不太赚钱:声明化、标准化和自动化。