Kubernetes Operator基础入门

本文转自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/concepts/extend-kubernetes/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources

自定义资源定义（CRD）

自定义资源定义（CRD）的出现已经有一段时间了，第一个主要的API规范是与Kubernetes 1.16.0一块儿发布的。下面的manifest介绍了一个例子：

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和你要建立的对象种类。

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

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

自定义资源

以上CRD可让你建立如下自定义资源的manifest。

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