当咱们聊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项目就是为此目标而生。其经过模板和参数对多种资源进行编排，实现了对一个完整服务的建立、部署、修改、删除等生命周期管理。

在k8s中，也有许多编排项目，目前比较热门的是包管理工具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这些公共的资源基础上，将应用集群也视为了一种资源，能够向用户提供。而且借助于k8s已有的工做机制和框架，从而更为便捷灵活的实现。

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

写在最后

使用operator的前提就是能够实现容器化。即应用可使用容器来进行应用的自动化的部署。operator化不只仅是开发一个operator的程序，还须要结合镜像的制做、交付、封装等工做。仍然是须要大量的开发工做的。可是一旦成熟稳定，也会带来巨大的运维收益和长期的效果。

注: 本文已在InfoQ上首发，原文连接为https://www.infoq.cn/article/SJMUvMg_0H7BS5d99euR。