K8s系列之：解释Kubernetes Operators

什么是控制器循环？
[Kubernetes Operator是如何工作的？](#Kubernetes Operator是如何工作的？)
如何添加自定义资源
自定义资源定义
[Kubernetes Operators：案例研究](#Kubernetes Operators：案例研究)

你是否曾想过，Site Reliability Engineering（SRE）团队如何成功地管理复杂应用程序？在Kubernetes生态系统中，答案只有一个：Kubernetes Operators！在本文中，我们将探讨什么是Operators以及它们的工作原理。

Kubernetes Operator的概念是由CoreOS的工程师在2016年开发的，作为在Kubernetes集群上构建和驱动每个应用程序的高级和本地化方式，需要领域特定的知识。它提供了一种一致的方法来自动处理所有应用程序的运行过程，通过与Kubernetes API的密切协作，无需人工干预。换句话说，Operator是一种打包、运行和管理Kubernetes应用程序的方式。

Kubernetes Operator模式遵循了Kubernetes的核心原则之一：控制理论。在机器人技术和自动化中，控制理论是一种连续操作动态系统的机制。它依赖于将工作负载需求尽可能准确地适应可用资源的能力。其目标是开发一个带有必要逻辑的控制模型，以帮助应用程序或系统保持稳定。在Kubernetes世界中，这一部分由控制器来处理。

控制器是一种特殊的软件，在循环中响应变化并在集群中执行适应性操作。第一个Kubernetes控制器是kube-controller-manager。它被视为后来构建的所有Operator的祖先。

什么是控制器循环？

简单来说，控制器循环是控制器操作的基础。想象一下，有一个不终止的过程（在Kubernetes中称为调谐循环）一遍又一遍地进行，如下图所示：

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

部署
服务
密钥
入口
配置映射
等对象由JSON或YAML格式的配置文件定义。然后，控制器通过Kubernetes API进行持续调整，以模拟期望状态，直到当前状态变为期望状态，根据内置的逻辑进行操作。

通过这种方式，Kubernetes处理了云原生系统的动态特性，处理不断变化的情况。实现期望状态的修改示例包括：

当节点下线时发出新节点的需求
检查是否需要复制Pod
根据请求创建新的负载均衡器。

Kubernetes Operator是如何工作的？

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

"Operator是Kubernetes的软件扩展，利用自定义资源来管理应用程序及其组件。Operator遵循Kubernetes的原则，特别是控制循环。"

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

Operator不断跟踪与特定类型的自定义资源相关的集群事件。可以跟踪的自定义资源上的事件类型包括：

添加
更新
删除

当Operator接收到任何信息时，它将采取行动，在自定义控制器的调谐循环中调整Kubernetes集群或外部系统以达到期望状态。

如何添加自定义资源

自定义资源通过添加新类型的对象来扩展Kubernetes的功能，这些对象对于您的应用程序可能很有帮助。Kubernetes提供了两种将自定义资源添加到集群的方法：

通过API聚合（API Aggregation）：这是一种高级方法，需要您构建自己的API服务器，但可以给您更多的控制权。
通过自定义资源定义（Custom Resource Definitions，CRD）：这是一种简单的方式，可以在不需要任何编程知识的情况下创建，作为对原始Kubernetes API服务器的扩展。

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

自定义资源定义

自定义资源定义已经存在一段时间了；第一个主要的API规范是在Kubernetes 1.16.0版本发布时引入的。下面的示例展示了一个清单：

bash 复制代码

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（我们将在下一节中使用它）。前两行定义了您要创建的对象的apiVersion apiextensions.k8s.io/v1beta1和kind CustomResourceDefinition。

元数据描述了资源的名称，但在这里最重要的地方是"spec"字段。它允许您指定组和版本以及可见性的范围 - 命名空间范围或集群范围。

然后，您可以以多种格式定义名称，并创建一个方便的缩写名称，这样您就可以执行"kubectl get app"命令来获取现有的CR。

Kubernetes Operators：案例研究

为了全面了解Kubernetes Operators，让我们来研究一个案例，即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服务器对上述任何对象的更改，并确保匹配的部署和配置保持同步。

致力于通过创建java-operator-sdk来简化使用Java创建Operator的过程。