kubernetes operator解析
您是否想过站点可靠性工程 (SRE) 团队如何有效地成功管理复杂的应用程序？ 在 Kubernetes 生态中，只有一个答案：Kubernetes Operators！ 在本文中，我们将研究它们是什么以及它们是如何工作的。
Kubernetes Operator 概念由 CoreOS 的工程师于 2016 年开发，作为一种在 Kubernetes 集群上构建和驱动每个应用程序的高级原生方式，这需要特定领域的知识。 它通过与 Kubernetes API 的密切合作，提供了一种一致的方法来自动处理所有应用程序操作过程，无需任何人为反应。 换句话说，Operator 是一种打包、运行和管理 Kubernetes 应用程序的方式。
Kubernetes Operator 模式根据 Kubernetes 核心原则之一：控制理论行事。 在机器人和自动化领域，它是一种持续运行动态系统的机制。 它依赖于尽可能准确地根据可用资源快速调整工作负载需求的能力。 目标是开发具有必要逻辑的控制模型，以帮助应用程序或系统保持稳定。 在 Kubernetes 世界中，该部分由控制器处理。
控制器是一种特殊的软件，它在循环中响应集群中的变化并执行适配动作。 第一个 Kubernetes 控制器是 kube-controller-manager。 它被认为是后来建立的所有operator的祖先。
什么是控制器循环？
简而言之，控制器循环是控制器动作的基础。 想象一下，有一个非终止过程（在 Kubernetes 中称为协调循环）一遍又一遍地发生，如下图所示：
此过程至少观察一个 Kubernetes 对象，其中包含有关所需状态的信息。 对象如…
- Deployments
- Services
- Secrets
- Ingress
- Config Maps
…由配置文件定义，配置文件由 JSON 或 YAML 中的清单组成。 然后控制器根据内置逻辑通过 Kubernetes API 进行持续调整以模仿所需状态，直到当前状态变为所需状态。
通过这种方式，Kubernetes 通过处理不断变化来处理云原生系统的动态特性。 为实现预期状态而执行的修改示例包括：
- 注意节点何时出现故障并要求一个新节点。
- 检查是否需要复制 pod。
- 如果需要，创建一个新的负载平衡器。
Kubernetes Operator如何工作？
Operator 是一个特定于应用程序的控制器。 它扩展了 Kubernetes API 以代表人类（运营工程师或站点可靠性工程师）创建、配置和管理复杂的应用程序。 让我们看看 Kubernetes 文档是怎么说的。
“Operator 是 Kubernetes 的软件扩展，它利用自定义资源来管理应用程序及其组件。 Operators 遵循 Kubernetes 原则，尤其是控制回路。
到目前为止，您已经知道operator利用控制器来观察 Kubernetes 对象。 这些控制器有点不同，因为它们跟踪自定义对象，通常称为自定义资源 (CR)。 CR 是 Kubernetes API 的扩展，它提供了一个可以存储和检索结构化数据（应用程序的所需状态）的位置。 整个操作原理如下图所示。
Operator 持续跟踪与特定类型的自定义资源相关的集群事件。 可以跟踪的这些自定义资源上的事件类型是：
添加
更新
删除
当操作员收到任何信息时，它将采取行动将 Kubernetes 集群或外部系统调整到所需状态，作为其在自定义控制器中的协调循环的一部分。
如何添加自定义资源
自定义资源通过添加对您的应用程序有帮助的新型对象来扩展 Kubernetes 的功能。 Kubernetes 提供了两种向集群添加自定义资源的方式：
- 通过 API 聚合，这是一种高级方法，需要您构建自己的 API 服务器，但会给您更多控制权
- 通过自定义资源定义 (CRD)，这是一种无需任何编程知识即可创建的简单方法，作为对原始 Kubernetes API 服务器的扩展。
这两个选项满足不同用户的需求，他们可以在灵活性和易用性之间进行选择。 Kubernetes 社区创建了一个比较，可以帮助您决定哪种方法适合您，但最受欢迎的选择是 CRD。
自定义资源定义
自定义资源定义已经存在了一段时间； 第一个主要的 API 规范与 Kubernetes 1.16.0 一起发布。 下面的清单提供了一个示例：
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 将允许您创建一个名为“应用程序”的 CR。 （我们将在下一节中使用它。）前两行定义了您要创建的对象类型 CustomResourceDefinition 的 apiVersion apiextensions.k8s.io/v1beta1。
元数据描述了资源的名称，但这里最重要的地方是“spec”字段。 它允许您指定组和版本以及可见范围——命名空间或集群范围。
之后，您可以定义多种格式的名称并创建一个方便的短名称，这样您就可以执行命令 kubectl get crds 来获取现有的 crd。
自定义资源
上面的 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。 运行它并通过特定域上的入口公开它。 这只是一个用例示例，但它可以做任何设计的事情。
Operators 也可用于配置 Kubernetes 外部的资源。 您可以在不离开 Kubernetes 平台的情况下控制外部路由器的配置或在云中创建数据库。
Kubernetes Operators：案例研究
为了全面了解 Kubernetes Operators，让我们来看看 Prometheus Operator，它是最早也是最受欢迎的 Operators 之一。 它简化了 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 服务器对上述任何对象的更改，并确保匹配的部署和配置保持同步。