据我所知，Kubernetes控制器的目的是确保当前状态等于所需状态。尽管如此，Kubernetes运营商也做了同样的工作。
控制平面中的控制器列表：
从谷歌搜索，我发现有K8s运营商，如
但是，我无法理解为什么使用Controller无法完成？
运营商是否补充了控制器？
这两个设计作为目的和功能之间的区别是什么。
在控制器和操作员之间进行选择需要注意哪些事项？ ？
我相信the CoreOS people here引入了“kubernetes operator”这个术语
Operator是一个特定于应用程序的控制器，它扩展了Kubernetes API，以代表Kubernetes用户创建，配置和管理复杂有状态应用程序的实例。它建立在基本的Kubernetes资源和控制器概念的基础上，还包括域或特定于应用程序的知识，以自动执行由计算机更好地管理的常见任务。
基本上，kubernetes运算符是一个模式的名称，该模式由kubernetes控制器组成，该控制器向Kubernetes API添加新对象，以便配置和管理应用程序，如Prometheus或etcd。
用一句话：运算符是特定于域的控制器。
有关于这个相同主题的a new discussion on Github，链接到同一篇博文。讨论的相关部分是：
所有操作员都使用控制器模式，但并非所有操作员都是操作员。它只是一个运算符，如果它有：控制器模式+ API扩展+单应用程序焦点。
Operator是一个带CRD的自定义控制器工具。它与内置控制器（即手表，差异，动作）遵循相同的模式。
在Kubernetes中，大多数操作都是以异步方式进行的。
例如，当一个人创建一个ReplicaSet对象（选择一个更简单的对象）时，这就是发生的序列：
现在，各种Kubernetes控制器负责观察ETCD变化并实际执行必要的操作。在这种情况下，ReplicaSet控制器将监视ETCD中的更改（例如ReplicataSets的CRUD），并根据副本计数等创建Pod。
现在，来到运营商，概念上它们与Kubernetes控制器非常相似。但它们与第三方实体一起使用。在Kubernetes中，有一个CRD概念，供应商可以定义自己的CRD，这只是一个自定义（例如特定于供应商）kubernetes对象类型。与Kubernetes控制器读取Kubernetes对象的CRUD的方式非常相似，这些运算符响应相应CRD上的操作。例如。当在Kubernetes集群中创建新的API CRD对象时，Kong运算符可以在Kong API服务器中创建新的API条目。