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 通过处理不断变化来处理云原生系统的动态特性。 为实现预期状态而执行的修改示例包括：

1. 注意节点何时出现故障并要求一个新节点。
2. 检查是否需要复制 pod。
3. 如果需要，创建一个新的负载平衡器。

Kubernetes Operator如何工作？

Operator 是一个特定于应用程序的控制器。 它扩展了 Kubernetes API 以代表人类（运营工程师或站点可靠性工程师）创建、配置和管理复杂的应用程序。 让我们看看 Kubernetes 文档是怎么说的。

“Operator 是 Kubernetes 的软件扩展，它利用自定义资源来管理应用程序及其组件。 Operators 遵循 Kubernetes 原则，尤其是控制回路。

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

Operator 持续跟踪与特定类型的自定义资源相关的集群事件。 可以跟踪的这些自定义资源上的事件类型是：

添加

更新

删除

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

如何添加自定义资源

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

1. 通过 API 聚合，这是一种高级方法，需要您构建自己的 API 服务器，但会给您更多控制权
2. 通过自定义资源定义 (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 服务器对上述任何对象的更改，并确保匹配的部署和配置保持同步。

这篇好文章是转载于：学新通技术网