首先随便翻看一本词典看一下operator 这个词的定义：操作员/运算符，是个名词。
那么，operator 描述的应该是一个围绕“操作、控制”概念的东西。为了让大家有个更直观的认识，我们来举一个例子，比如1+2=3，这个“+”就是一个operator（运算符），这个“+”让两个数字发生了一些互动（相加）。
有了词典里的概念铺垫后，我们继续往下分析，既然是一种操作或运算，那么在k8s中， 是谁来操作？而被操作的对象又是什么呢？让我们来看一下OperatorFramework 官网上对于Operator 的解释：
WHAT IS AN OPERATOR AFTER ALL?
An Operator represents human operational knowledge in software, to reliably manage an application. They are methods of packaging, deploying, and managing a Kubernetes application.
从这个定义中，我们可以看到，这个operator 是指由人发出的，对k8s 应用（Kubernetes application）展开的操作。一般围绕应用的操作有哪些？部署、升级、扩缩容、卸载等等。我们可以先这样理解，operator 应该就是一个类似控制器的东西，里面含有一些运维操作（后面会继续展开，其实不仅仅是这些）。
较真一点的读者可能会问，既然这样，这东西叫controller 是不是会更贴切一点呢？事实上，问出这个问题的读者，和真相很接近了，每个operator 基本都会有个控制器， 但又不仅仅只有一个控制器，还会有前面提到过的资源定义：CRD（CustomResourceDefinition）。每种自定义资源背后都会有一个或多个控制器，让这些资源看起来像活的一样，我们举一个比较切近生活的例子：
我们为家里的灯制作一个CRD 和operator，把这个operator 和灯开关连起来，当用户修改这个YAML 的时候，operator 会向开关转发指令。
从名字可以看出这盏灯被放在卧室（bedroom），当power=on 的时候电灯打开，power=off 的时候电灯关闭，修改亮度（brightness）和色温（colorTemperature）能操纵这盏灯在打开状态下的视觉效果。
通过上面这段灯的YAML 我们可以发现，在CRD+operator 的场景下，我们可以只关注对象终态，而不去关注其中的控制过程。比如当前家中网络不太稳定，要花1-2 秒，重试3 次operator 才能成功下发指令打开灯，这些重试我们是不感知的。我们只知道只要将power 设置为on，灯就会亮。类比到k8s 的日常实践，也是这样：
一个Pod 被放到集群后，控制器会想方设法去克服困难：从仓库拉取镜像，启动工作负载，如果crash 掉了就立即重试，直到稳定运行为止。我们只关心这个Pod 是否最终拉起可用。
所以，operator 其实是一种架构理念，它区别于常见的shell 等运维脚本方案：
operator 希望应用能够自己管理自己，而不是由运维人员写脚本从外围来控制他们。
不过，如果仅仅是这样，可能operator 也只能叫controller 了，只是一些自控制的逻辑而已。从最前面提到的operator 的概念可以看出，operator 能够让两种以上的资源产生一些互动关系，那么这是如何实现的呢？
我们继续用上面的灯的例子再加个YAML 让大家感受一下：
我们把自己的家也用一个自定义资源对象来描述，用来承载一些家中的全局设置。
当我们家中所有人都出门的时候，家中就没有人了，于是将nobody 设为true。然后Home 的operator 会遍历家中所有的开关、电器、灯等设备，全部都给关上（在YAML 上设置power=off）。同时也会根据常亮的策略（stayOpen），保持某些电器不关闭，比如冰箱。
从上面的例子可以看出，每个控制器只负责自己的那部分，但从顶层往下看，已经实现了级联控制，能够实现牵一发而动全身的效果。这个就是上面所提到的operator 的更深一层的机制：能够像运算符一样，让几种资源产生某种互动关系，一起协作完成一些复杂的工程动作。
以上内容摘自《SREWorks 云原生数智运维工程实践》电子书，点击https://developer.aliyun.com/ebook/download/7784可下载完整版。
胡嘞嘞
