本文转自Rancher Labs

你是否已经想过SRE团队是如何无效地胜利治理简单的利用？在Kubernetes生态系统中，Kubernetes Operator能够给你答案。在本文中，咱们将钻研Operator是什么以及它们如何工作。

Kubernetes Operator这一概念是由CoreOS的工程师于2016年提出的，这是一种原生的形式来构建和驱动Kubernetes集群上的每一个利用，它须要特定畛域的常识。它提供了一种统一的办法，通过与Kubernetes API的严密单干，主动解决所有利用操作过程，而不须要任何人工干预。换句话说，Operator是一种包装、运行和治理Kubernetes利用的形式。

Kubernetes Operator模式遵循Kubernetes的外围准则之一：管制实践（control theory）。在机器人和自动化畛域，它是一种继续运行动静零碎的机制。它依赖于一种疾速调整工作负载需要的能力，进而可能尽可能精确地适应现有资源。其指标是开发一个具备必要逻辑的管制模型，以帮忙应用程序或零碎保持稳定。在Kubernetes世界中，这部分由controller解决。

在循环中，Controller是个非凡的软件，它能够对集群的变动做出响应，并执行适应动作。第一个Kubernetes controller是一个kube-controller-manager。它被认为是所有Operator的前身，Operator是起初建设的。

什么是Controller Loop？

简略来说，Controller Loop是Controller动作的根底。设想一下，有一个非终止的过程（在Kubernetes中称为和解循环）在一直地产生，如下图所示：

这个过程至多察看一个Kubernetes对象，该对象蕴含无关所需状态的信息。比方：

Deployment

Services

Secrets

Ingress

Config Maps

这些对象由JSON或YAML中的manifest组成的配置文件定义。而后controller依据内置逻辑，通过Kubernetes API进行继续调整，模拟所需状态，直到以后状态变成所需状态。

通过这种形式，Kubernetes通过解决一直的更改来解决Cloud Native零碎的动静性质。为达到预期状态而执行的批改实例包含：

  • 留神到节点宕机时，要求更换新的节点。
  • 查看是否须要复制pods。
  • 如果须要，创立一个新的负载均衡器。

Kubernetes Operator如何工作？

Operator是一个特定应用程序的controller，它扩大了一个Kubernetes API，代替运维工程师或SRE工程师来创立、配置和治理简单的应用程序。在Kubernetes官网文档中对此有以下形容：

Operator是Kubernetes的软件拓展，它利用自定义资源来管理应用程序及其组件。Operator遵循Kubernetes的准则，尤其遵循control loop。

到目前为止，你曾经理解Operator会利用察看Kubernetes对象的controller。这些controller有点不同，因为它们正在追踪自定义对象，通常称为自定义资源（CR）。CR是Kubernetes API的扩大，它提供了一个能够存储和检索结构化数据的中央——你的应用程序的冀望状态。整个操作原理如下图所示：

Operator会继续跟踪与特定类型的自定义资源相干的集群事件。能够跟踪的对于这些自定义资源的事件类型有：

  • Add
  • Update
  • Delete

当Operator接管任何信息时，它将采取行动将Kubernetes集群或内部零碎调整到所需的状态，作为其在自定义controller中的和解循环（reconciliation loop）的一部分。

如何增加一个自定义资源

自定义资源通过增加对你的利用有帮忙的新型对象来扩大Kubernetes性能。Kubernetes提供了两种向集群增加自定义资源的办法：

通过API Aggregation增加，这是一种高级办法，须要你建设本人的API服务器，但你有更多的管制权限。

通过自定义资源定义（CRD）增加，一种不须要简单编程常识就能够创立的简略形式，作为Kubernetes API服务器的扩大。

这两种计划满足了不同用户的需要，他们能够在灵活性和易用性之间进行抉择。Kubernetes社区对两者进行了比拟，将帮忙你决定哪种办法适宜你，但目前最受欢迎的选项是CRD：

https://kubernetes.io/docs/co...

自定义资源定义（CRD）

自定义资源定义（CRD）的呈现曾经有一段时间了，第一个次要的API标准是与Kubernetes 1.16.0一起公布的。上面的manifest介绍了一个例子：

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（咱们将会在下一个局部应用它）。前两行定义了apiVersion和你要创立的对象品种。

Metadata形容了资源名称，但这里最重要的局部是“spec”字段。它让你能够指定组、版本以及可见性范畴——命名空间或集群范畴。

而后，你能够用多种格局定义名称，并创立一个不便的缩写，让你执行命令kubectl get app来获取现有的CR。

自定义资源

以上CRD能够让你创立以下自定义资源的manifest。

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的自定义controller察看到。依据controller中的内置逻辑，将模拟所需的状态。它能够为咱们的应用程序创立部署、服务和必要的ConfigMaps。运行它，并在特定的域上通过 ingress 裸露它。这只是一个简略的用例，但你能够依据本人的需要对它进行任何设计。

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 scrape配置。
  • PodMonitor：申明性地指定了应如何监控一组 pod。Operator 会依据 API 服务器中对象的以后状态主动生成 Prometheus scrape 配置。
  • PrometheusRule：定义了一组所需的 Prometheus 告警和/或记录规定。Operator会生成一个规定文件，可供 Prometheus 实例应用。

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