详解Kubernetes Operators

您是否想知道站点可靠性工程（SRE）团队如何有效地管理复杂的应用程序？在Kubernetes生态系统中，只有一个答案：Kubernetes Operator！在本文中，我们将研究它们是什么以及它们如何工作。

Kubernetes Operator概念是由CoreOS的工程师于2016年提出的，它是在Kubernetes集群上构建和驱动每个应用程序的高级原生方法，需要特定领域的知识。通过与Kubernetes API的密切合作，它提供了一种一致的方法来自动处理所有应用程序操作流程，而无需任何人工响应。换句话说，Operator是打包，运行和管理Kubernetes应用程序的一种方式。

Kubernetes Operator模式的行为遵循核心Kubernetes原理之一：控制理论。在机器人技术和自动化中，它是一种连续运行动态系统的机制。它依赖于一种能力，即尽可能准确地根据可用资源快速调整工作负载需求。目的是开发具有必要逻辑的控制模型，以帮助应用程序或系统保持稳定。在Kubernetes世界中，该部分由控制器处理。
控制器是一种特殊的软件，可以在循环中响应更改并在集群中执行调整操作。第一个Kubernetes控制器是kube-controller-manager。它被视为所有Operator的始祖。

什么是控制循环?

简而言之，控制器循环是控制器动作的基础。想象一下，一个非终止过程（在Kubernetes中称为reconciliation 循环）反复发生，如下图所示：

该过程观察至少一个Kubernetes对象，该对象包含有关所需状态的信息。诸如...的对象

• Deployments
• Services
• Secrets
• Ingress
• Config Maps

…由配置文件定义，这些配置文件由JSON或YAML的清单组成。然后，控制器根据内置逻辑通过Kubernetes API进行连续调整，以模仿所需状态，直到当前状态变为所需状态。

这样，Kubernetes通过处理不断的变化来应对Cloud Native系统的动态特性。为达到预期状态而执行的修改示例包括：

• 注意节点何时出现故障并需要新的节点。
• 检查是否需要复制Pod。
• 如果需要，请创建一个新的负载均衡器。

Kubernetes Operator如何工作？

Operator是特定于应用程序的控制器。它扩展了Kubernetes API以代表人员（操作工程师或站点可靠性工程师）创建，配置和管理复杂的应用程序。让我们看看Kubernetes文档对此有何评论。
Operator是Kubernetes的软件扩展，它利用自定义资源来管理应用程序及其组件。Operator遵循Kubernetes原则，尤其是控制回路。

到目前为止，您知道Operator利用了观察Kubernetes对象的控制器。这些控制器有点不同，因为它们跟踪的是自定义对象，通常称为自定义资源（CR）。 CR是Kubernetes API的扩展，它提供了一个可以存储和检索结构化数据（应用程序的期望状态）的地方。下图显示了整个操作原理。

Operator连续跟踪与特定类型的定制资源有关的集群事件。可以跟踪的这些自定义资源上的事件类型为：

• Add
• Update
• Delete

当Operator接收到任何信息时，它将采取行动将Kubernetes集群或外部系统调整为所需状态，作为其自定义控制器中reconciliation 循环的一部分。

如何增加一个Custom Resource

自定义资源通过添加对你的应用程序有帮助的新对象，扩展了Kubernetes的功能。 Kubernetes提供了两种向集群添加自定义资源的方法：

• 通过API聚合，这是一种高级方法，需要您构建自己的API服务器，但可以为您提供更多控制权
• 通过自定义资源定义（CRD），这是一种无需任何编程知识即可创建的简单方法，是对原始Kubernetes API服务器的扩展。

这两个选项可满足不同用户的需求，他们可以在灵活性和易用性之间进行选择。 Kubernetes社区创建了一个比较，可以帮助您确定适合您的方法，但是最受欢迎的选择是CRD。

Custom Resource Definitions

自定义资源定义已经存在了很长一段时间。 Kubernetes 1.16.0发布了第一个主要的API规范。以下清单提供了一个示例：

apiVersion: apiextensions.k8s.io/v1beta1 
kind: CustomResourceDefinition
metadata:
  name: application.stable.example.com 
spec:
  group: stable.example.com 
  version: v1 
  scope: Namespaced 
  names:
    plural: application 
    singular: applications 
    kind: Application 
    shortNames:
    - app 

通过此CRD，您可以创建一个称为“Application”的CR。前两行定义要创建的对象类型CustomResourceDefinition的apiVersion apiextensions.k8s.io/v1beta1。
元数据描述了资源的名称，但最重要的地方是“ spec”字段。它使您可以指定组和版本以及可见性范围（命名空间或集群范围）。
之后，您可以使用多种格式定义名称并创建一个方便的简称，该名称使您可以执行命令kubectl get app来获取现有的CR。

Custom Resource

上面的CRD允许您创建以下自定义资源清单。

apiVersion: stable.example.com/v1 
kind: Application
metadata:
  name: application-config
spec:
  image: container-registry-image:v1.0.0
  domain: teamx.yoursaas.io
  plan: premium

如您所见，我们可以在此处包含针对特定情况运行应用程序所需的所有必要信息。我们的Operator将观察到该自定义资源，确切地说，将由Operator的自定义控制器来观察。根据控制器中的内置逻辑，必要的动作将模仿所需的状态。它可以为我们的应用程序创建一个Deployment，Service和必要的ConfigMap。运行它并通过特定域上的入口公开它。这只是用例的一个例子，但是它可以完成设计的任何事情。
Operator还可以用来调配Kubernetes以外的资源。您可以在不离开Kubernetes平台的情况下控制外部路由器的配置或在云中创建数据库。

Kubernetes Operators: 案例

为了全面了解Kubernetes Operator，让我们看一下Prometheus Operator，它是最早也是最受欢迎的Operator之一。它简化了Prometheus，Alertmanager和相关监视组件的部署和配置。
Prometheus Operator的核心功能是监视Kubernetes API服务器对特定对象的更改，并确保当前Prometheus部署与这些对象匹配。Operator根据以下自定义资源定义（CRD）进行操作：

• Prometheus, 其定义一个期望的 Prometheus 部署。
• Alertmanager, 其定义一个期望的 Alertmanager 部署。
• ServiceMonitor, 声明性地指定应如何监视Kubernetes服务组。Operator根据API服务器中对象的当前状态自动生成Prometheus抓取配置。
• PodMonitor, 以声明方式指定应如何监视一组Pod。Operator根据API服务器中对象的当前状态自动生成Prometheus抓取配置。
• PrometheusRule, 它定义了一组所需的Prometheus警报和/或记录规则。Operator生成一个规则文件，Prometheus实例可以使用该文件。

Prometheus Operator自动检测Kubernetes API服务器中对上述任何对象的更改，并确保匹配的部署和配置保持同步。

PS: 本文属于翻译，原文