马后炮: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:ETCDPrometheus

例如 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 的工作方式。

带来的好处也不太醒目:声明化、标准化和自动化。

Avatar
崔秀龙

简单,是大师的责任;我们凡夫俗子,能做到清楚就很不容易了。

comments powered by Disqus
下一页
上一页

相关