Kubernetes Controller与Kubernetes运营商？

Question

据我所知,Kubernetes控制器的目的是确保当前状态等于所需状态.尽管如此,Kubernetes运营商也做了同样的工作.

控制平面中的控制器列表:

• 部署
• ReplicaSet
• StatefulSet
• DaemonSet
• 等等

从谷歌搜索,我发现有K8s运营商,如

• etcd运营商
• 普罗米修斯运营商
• kong运营商

但是,我无法理解为什么使用Controller无法完成？

运营商是否补充了控制器？

这两个设计作为目的和功能之间的区别是什么.

在控制器和操作员之间进行选择需要注意哪些事项？？

Answer 1

我相信"kubernetes运营商"一词是由CoreOS人员在这里介绍的

Operator是一个特定于应用程序的控制器,它扩展了Kubernetes API,以代表Kubernetes用户创建,配置和管理复杂有状态应用程序的实例.它建立在基本的Kubernetes资源和控制器概念的基础上,还包括域或特定于应用程序的知识,以自动执行由计算机更好地管理的常见任务.

基本上,kubernetes运算符是一个模式的名称,该模式由kubernetes控制器组成,该控制器向Kubernetes API添加新对象,以便配置和管理应用程序,如Prometheus或etcd.

用一句话:运算符是特定于域的控制器.

更新

关于这个相同主题的Github有一个新的讨论,链接到同一个博客文章.讨论的相关部分是:

所有操作员都使用控制器模式,但并非所有操作员都是操作员.它只是一个运算符,如果它有:控制器模式+ API扩展+单应用程序焦点.

Operator是一个带CRD的自定义控制器工具.它与内置控制器(即手表,差异,动作)遵循相同的模式.

Answer 2

在 Kubernetes 中，大多数操作以异步方式发生。

例如，当创建一个 ReplicaSet 对象（选择一个更简单的对象）时，发生的顺序是：

1. 我们将请求发送到 Kube api-server。
2. kube-api 服务器有一个复杂的验证
   • 确保用户拥有 RBAC 凭据以在给定的命名空间中创建 RS
   • 该请求由所有配置的准入控制器验证
3. 最后，对象只是写入 ETCD - 仅此而已

现在，各种 Kubernetes 控制器有责任观察 ETCD 的变化并实际执行必要的操作。在这种情况下，ReplicaSet 控制器将监视 ETCD（例如 ReplicataSet 的 CRUD）中的变化，并将根据副本计数等创建 Pod。

现在，谈到 Operator，它们在概念上与 Kubernetes 控制器非常相似。但它们与第三方实体一起使用。在 Kubernetes 中，有一个 CRD 的概念，供应商可以在其中定义他们自己的 CRD，它只是一个自定义的（例如供应商特定的）kubernetes 对象类型。与 Kubernetes 控制器读取 Kubernetes 对象的 CRUD 的方式非常相似，这些操作符响应相应 CRD 上的操作。例如，当在 Kubernetes 集群中创建新的 API CRD 对象时，Kong 操作员可以在 Kong API 服务器中创建新的 API 条目。

Answer 3

长话短说：

• 控制器 == 适用于普通 K8s 资源
• Operator == 一个添加其操作所需的自定义资源（CRD）的控制器

改变我的想法，但在我看来，差异可以忽略不计，而且这些术语会让人们感到困惑，然后实际上为讨论增加价值。因此我会互换使用它们。