什么是Operator？

Kubernetes平台是围绕控制器的软件设计模式构建的，该控制器是管理两个实体之间数据流的软件组件。在Kubernetes中，控制器监视在一个资源中发现的声明状态的更改，然后通过创建或更改其他下游资源来响应状态更改请求。由于控制器对帐过程连续发生，因此此过程称为“主动对帐”。如图1所示。

Operators Figure 1

创建部署时，可以观察到此行为的一个示例。创建新的部署资源后，将向部署控制器通知资源更改，并通过创建新的副本集做出反应。反过来，副本集控制器对副本集资源做出反应，并导致创建一个或多个Pod。稍后，如果您要修改部署的图像属性，则部署控制器将使用新的图像属性创建新的副本集，同时逐步淘汰旧的副本集。尽管对下游资源采取的操作根据资源而有所不同，但其他控制器的行为类似。

像其他控制器一样，操作员也要注意Kubernetes资源的修改。但是，与Kubernetes平台概念（如部署，状态集和服务（在许多类型的软件中通用））不同，操作员将特定于软件的知识体现在控制器中。考虑一个复杂的工作负载，例如集群数据库，其中需要按照该软件独有的精确顺序来组织常见的操作活动。

实践中的Operator

让我们考虑一个例子。也许升级数据库需要先启动数据格式的先决条件步骤，然后再启动最新版本的容器软件，并且所有吊舱都需要在数据迁移之前停止。或者，可能需要按特定顺序启动Pod，以确保共识算法可以识别所有群集成员。操作员负责协调这些活动，同时利用最终用户可以编辑的资源模型中的声明性或所需状态。

将声明的状态与特定于实现的活动分开，使用户可以在没有特定于软件的知识的情况下控制软件的实例。知识被编码到操作员提供的控制器中。同时，另一软件的操作特性以其自己的方式是独特的，因此具有自己的运算符。

规模化Operator

如果单独部署operator，他们将消耗很少的资源。实际上，我们通过使用Kube Builder SDK和golang语言生成控制器来进行一些分析。然后，我们分析了生成的控制器的实际CPU和内存使用情况，以及对生成的资源请求和限制进行自省。下表中汇总了此信息：

Operators Table 1

这些数目是针对单个控制器容器的，集群中容器的总数由以下各项确定：

软件包中特定于软件的运算符的数量（Redis的一个运算符，Postgres的一个运算符）。
单个运算符的唯一实例数。为了隔离起见，Redis运算符可能安装在一个命名空间中，而Redis运算符实例的另一个实例存在于另一个命名空间中。
上面的指标是针对每个Pod的，但是出于冗余的考虑，每个操作员部署可能会部署3次。
如果我们要计划由10个名称空间隔离的10个运算符，并且冗余为3，这将导致以下资源消耗：

我们可以对这些数据进行一些重要的观察：

在上述规模下，一个以上的内核将专门用于保持空闲操作员的运行。
除了实际的资源消耗外，operator还计入集群的资源配额。
您选择安装哪些操作程序，以及在什么作用范围内（例如名称空间或群集范围）进行大规模安装。

我们可以无服务器吗？

当然，许多操作员实例的资源利用率可能会影响集群资源需求，但是它是否非常适合无服务器？现实情况是，许多控制器的需求并不恒定，尤其是当单个操作员实例的范围已限于特定的名称空间时。

Kubernetes资源修改事件通常源于两个用户修改单个资源以及通过机器驱动或批处理作业。单个用户可能会强烈地操纵资源一段时间，然后一段时间不会。例如，您可以创建一个Redis集群，然后在根据自己的特定需求微调该集群时编辑各个参数，但是在此之后，您将继续编辑应用程序的其他部分。对于机器驱动的作业，其中一些按计划运行，而另一些则由源更改事件驱动，这些事件通常在工作日左右聚集。

单一资源或资源种类上的活动集群趋向于倾向于无服务器模型。在此模型中，容器进程仅在工作到达时才保持活动状态，但是可以在活动停止的时间段内停止这些容器。