当我们聊 Kubernetes Operator 时，我们在聊些什么

不聊什么

在开始聊 Operator 前，先说说这篇文章里我们不聊什么。我们这里不聊 Operator 的具体实现，不聊 Operator 的由来历史，不聊 Operator 的 hello world。如果想了解这些，其实可以从别的很多文章中可以查找到。这里我们把一些常见的概念，如 Docker、Controller、Helm、编排等，与 Operator 进行一下对比，从这些概念的不同角度来聊聊 Operator，并聊聊在我眼中的 Operator 的核心价值。

Operator 与 Docker

我们先聊一聊 Docker。Docker 有非常多的优点，比如隔离、执行效率等等。但是在我看来，Docker 的核心价值，或者说颠覆性的成果就是设计了镜像流程，提供标准化的交付方式。就从单个的应用实例来讲，标准化、一致性的环境解决了应用的 runtime 的问题，将应用的部署、应用的依赖进行了统一的封装。将应用的部署方式从手工作坊的部署方式带入了标准化的工业时代。当然这也带来了一定的磁盘额外损耗。但是在硬件飞速发展的今天，这点磁盘损耗几乎不成问题。而且借助于联合文件系统和镜像优化，磁盘的损耗问题几乎不用考虑。

时至今日，越来越少的项目采用源码进行部署。以前一个开源项目往往配上一篇冗长的安装文档，教你如何安装、如何运行。现在，基本上活跃的开源项目都提供了基于容器的部署方式，你只需要拉下镜像 run 一下就可以使用。Docker 大大提升了交付的效率，降低了使用的门槛，有效避免了部署的故障。

Operator 跟 Docker 是相似的，而其主要的交付对象从单个的应用实例，扩展到了多实例、分布式的系统上。以往部署一个分布式系统需要启动多个容器，然后进行复杂的配置，而现在只要创建一个 CRD。Operator 将自动进行分布式系统中需要的各个资源的创建和部署。从这个角度上来说，Operator 的目标是实现分布式系统的标准化交付。

Operator 与编排/Helm

现在我们一般意义上的编排，也就是 orchestration，还有另一种翻译就是编配。在维基百科的定义为描述复杂计算机系统、中间件（middleware）和业务的自动化的安排、协调和管理。根据我个人的经验，总结编排的典型特征主要包括服务的版本管理、服务的生命周期管理、多个资源多种资源的管理、参数化以及模板化。

最早接触编排概念，是通过 OpenStack 的 Heat 项目。Openstack 中从计算、存储到网络有很多的系统。而如果部署一个完整的应用虚拟机，需要多种资源的协同参与。Heat 项目就是为此目标而生。其通过模板和参数对多种资源进行编排，实现了对一个完整服务的创建、部署、修改、删除等生命周期管理。

在 Kubernetes 中，也有许多编排项目，目前比较热门的是包管理工具 Helm。如果说 Docker 是奠定的单实例的标准化交付，那么 Helm 则是集群化多实例、多资源的标准化交付。

Operator 的管理不仅限于容器(Pod)，也可以是多个资源(比如 SVC 域名等等)，从这个角度上来说，Operator 跟 Helm 一样，也是具有编排的能力的。从编排角度来看，在初学者看来，Helm 跟 Operator 有非常多的共性，很难对两者的作用进行区分。Helm 也可以完成分布式系统的部署。那么 Operator 跟 Helm 又有什么样的区别呢？Helm 的侧重点在于多种多个的资源管理，而对生命周期的管理主要包括创建更新和删除。Helm 通过命令驱动整个的生命周期。

而 Operator 对于资源的管理则不仅是创建和交付。由于其可以通过 watch 的方式获取相关资源的变化事件，因此可以实现高可用、可扩展、故障恢复等运维操作。因此 Operator 对于生命周期的管理不仅包括创建，故障恢复，高可用，升级，扩容缩容，异常处理，以及最终的清理等等。

那你说这些功能能不能用 Helm 来实现，其实我觉得有一部分功能应该也是可以的。但是这里面就涉及到一个问题，就是这些功能无法在编排中直接实现，就需要通过脚本或者程序的方式固化到镜像中。大量的运维代码被脚本化。会导致维护这些脚本的复杂度提高，可读性变差。除此之外，还有一个潜在的风险无法解决的就是，当这些容器实例全部挂掉的时候，则完全无法自动恢复了，即使有备份数据。这时候最终还会依赖于人工的介入，仍然无法达到自动化、智能化的目标。

Operator 则在实现自动化的同时实现了智能化。其主要的工作流程是根据当前的状态，进行智能分析判断，并最终进行创建、恢复、升级等操作。而位于容器中的脚本，因为缺乏很多全局的信息，仅靠自身是无法无法达实现这些全部的功能的。而处于第三方视角的 Operator，则可以解决这个问题。他可以通过侧面的观察，获取所有的资源的状态和信息，并且跟预想/声明的状态进行比较。通过预置的分析流程进行判断，从而进行相应的操作，并最终达到声明状态的一个目的。这样所有的运维逻辑就从镜像中抽取出来，集中到 Operator 里去。层次和逻辑也就更加清楚，容易维护，也更容易交付和传承。

如果把 Helm 比作 RPM，那么 Operator 就是 Systemd。RPM 负责应用的安装、删除，而 Systemd 则负责应用的启动、重启等等操作。当然二者并不是互斥的，目前 Operator 一种比较便捷的部署方式就是通过 Helm 进行部署。

Operator 与 Controller

Operator 可以说是另外一种 Controller。目前的 Controller Manager 集合的主要是基础的、通用的资源概念，比如 RS/Deployment，而对于特定的应用或者服务（如 etcdcluster，都可以认为是一种资源），则放权给了第三方，也就是 CRD。用户可以通过自定义的资源描述，以及自研的 Controller/Operator 进行接入。因此 Controller 和 Operator 的关系有点类似于标准库和第三方库的关系。

一般来说，对于不同的应用一般来说需要不同的 Operator 进行处理。这时我们再来想下，以 ReplicaSet Controller 为例。RS 的主要功能是保持副本数。当有 Pod 因某种原因挂掉/删除，对于无状态的应用来说，恢复的方式就是再增加对应的 Pod 数量。那么从这个角度来说，对于无状态的应用来说，RS Controller 其实就是无状态应用的 Operator。

Operator 的核心价值

我们原先常常讲 DevOps，就是运维和开发的结合，提升开发交付的效率和质量。这也带来了一个趋势，就是运维和开发一体化。比如原来开发应用的人，通过 docker 镜像的制作，将应用的部署启动等固化在了 dockerfile/镜像中，分担了运维的许多部署工作。但是实际上运维的工作内容和范围其实非常广，特别是现在的分布式的系统，包括集群化部署、高可用、故障恢复、系统升级等等工作。而这些是无法仅用 dockerfile/镜像进行固化的。

Operator 提供了一种可能，或者说是提供了一个很好的框架，就是把运维的经验沉淀为代码，实现运维的代码化、自动化、智能化。以往的高可用、扩展收缩，以及故障恢复等等运维操作，都通过 Operator 进行沉淀下来。从长期来看，将会推进 Dev、Ops、DevOps 的深度一体化。将运维经验、应用的各种方案和功能通过代码的方式进行固化和传承，减少人为故障的概率，提升整个运维的效率。

Operator 的许多理念并不是现在才有的。在 Yarn 中的 Application Manager，Mesos 中的 Framework，都可以寻找到 Operator 的一些蛛丝马迹。而之所以说 Operator 将可能成为 Docker 之后的又一项重大变革，其另外一个重要的因素就是 Operator 是站在 Kubernetes 的巨人肩膀上。

Kubernetes 强化了基础资源的封装，并保持了灵活性和可定制性。Kubernetes 从传统的资源(CPU/MEM)的交付，转为了 Pod/SVC/PV/PVC 等资源的交付，扩展了资源的概念，将域名、负载均衡、存储等等必要或相关的概念也都进行了封装。而 Operator 这些公共的资源基础上，将应用集群也视为了一种资源，可以向用户提供。并且借助于 Kubernetes 已有的工作机制和框架，从而更为便捷灵活的实现。

Operator 的变革虽然重大，但是由于分布式应用主要限于工业生产领域，因此对一般的开发而言可能最终使用场景有限。因此我判断从全局看，Operator 的最终影响力有限，但在许多分布式应用的垂直领域，会产生巨大的影响。

作者简介

徐新坤，京东 JDOS 团队架构师。2013 年加入京东，2014 年开始从事容器化方面工作。目前主要从事 JDOS 2.0 及阿基米德调度平台的研发和架构，当前主要关注领域为大规模/超大规模的容器集群管理与调度。