库伯内特控制器和库伯内特算子的区别是什么？

据我所知，Kubernetes 控制器的目的是确保当前状态等于所需的状态。尽管如此，库伯内特操作员做同样的工作。

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

  • 部署
  • ReplicaSet
  • 一切就绪
  • DaemonSet
  • 等等

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

  • 操作员
  • 普罗米修斯号操作员
  • 港营办商

However, I was not able to understand why it cannot be done using Controller?

操作员是否对控制器进行补充？

这两种设计的目的和功能有什么不同。

在控制员和操作员之间选择时需要记住哪些特定的事情？

26797 次浏览
小开
最佳答案

我相信术语“库伯内特算符”是由 CoreOS 公司的人来了引入的

Operator 是一个特定于应用程序的控制器，它扩展了 Kubernetes API，以代表 Kubernetes 用户创建、配置和管理复杂有状态应用程序的实例。它建立在基本的 Kubernetes 资源和控制器的概念，但也包括领域或应用程序特定的知识，以自动化的公共任务更好地由计算机管理。

所以基本上，Kubernetes 操作符是一个模式的名称，该模式由一个 Kubernetes 控制器组成，该控制器向 Kubernetes API 添加新对象，以便配置和管理应用程序，比如 Prometheus 或 etcd。

一句话: 操作符是特定于域的控制器。

更新

There is a new discussion on Github about this very same topic, linking to the same blog post. Relevant bits of the discussion are:

所有的操作符都使用控制器模式，但并非所有的控制器都是操作符。只有当它具有: 控制器模式 + API 扩展 + 单应用程序焦点时，它才是一个 Operator。

Operator 是一个用 CRD 实现的定制控制器。它遵循与内置控制器相同的模式(即手表、差异、操作)。

Update 2

我发现 一篇新的博客文章也试图解释这种差异。

小开

在 Kubernetes，多数业务都是以异步方式进行的。

例如，当创建 ReplicaSet 对象(选择一个更简单的对象)时，发生的顺序如下:

  1. 我们将请求发送到 Kube api-server。
  2. Kube-api 服务器有一个复杂的验证
    • 确保用户具有 RBAC 凭证，可以在给定的命名空间中创建 RS
    • The request is validated by all the configured admission controllers
  3. 最后，对象被写入 ETCD -没有更多，没有更少

Now, it is the responsibility of the various Kubernetes controllers to watch the ETCD changes and actually execute the necessary operations. In this case, the ReplicaSet controller would be watching for the changes in ETCD (e.g. CRUD of ReplicataSets) and would create the Pods as per the replica count etc.

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

小开

TL;DR:

  • Controller = = 在普通的 K8s 资源上工作
  • Operator = = 一个增加其操作所需的自定义资源(CRD)的控制器

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


提交答案