您是否想晓得站点可靠性工程（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: CustomResourceDefinitionmetadata:  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: Applicationmetadata:  name: application-configspec:  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: 本文属于翻译，原文