KubernetesOperator基础入门

本⽂转⾃

你是否曾经想过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对象，该对象包含有关所需状态的信息。⽐如：

DeploymentServicesSecretsIngressConfig 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会持续跟踪与特定类型的⾃定义资源相关的集群事件。可以跟踪的关于这些⾃定义资源的事件类型有：

AddUpdateDelete

当Operator接收任何信息时，它将采取⾏动将Kubernetes集群或外部系统调整到所需的状态，作为其在⾃定义controller中的和解循环（reconciliation loop）的⼀部分。

如何添加⼀个⾃定义资源

⾃定义资源通过添加对你的应⽤有帮助的新型对象来扩展Kubernetes功能。Kubernetes提供了两种向集群添加⾃定义资源的⽅法：通过API Aggregation添加，这是⼀种⾼级⽅法，需要你建⽴⾃⼰的API服务器，但你有更多的控制权限。

通过⾃定义资源定义（CRD）添加，⼀种不需要复杂编程知识就可以创建的简单⽅式，作为Kubernetes API服务器的扩展。

这两种⽅案满⾜了不同⽤户的需求，他们可以在灵活性和易⽤性之间进⾏选择。Kubernetes社区对两者进⾏了⽐较，将帮助你决定哪种⽅法适合你，但⽬前最受欢迎的选项是CRD：

⾃定义资源定义（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服务器中对上述任何对象的更改，并确保匹配的部署和配置保持同步。