关于k8s:详解Kubernetes-Operators

2次阅读

共计 3327 个字符，预计需要花费 9 分钟才能阅读完成。

您是否想晓得站点可靠性工程（SRE）团队如何无效地治理简单的应用程序？在 Kubernetes 生态系统中，只有一个答案：Kubernetes Operator！在本文中，咱们将钻研它们是什么以及它们如何工作。

Kubernetes Operator 概念是由 CoreOS 的工程师于 2016 年提出的，它是在 Kubernetes 集群上构建和驱动每个应用程序的高级原生办法，须要特定畛域的常识。通过与 Kubernetes API 的密切合作，它提供了一种统一的办法来主动解决所有应用程序操作流程，而无需任何人工响应。换句话说，Operator 是打包，运行和治理 Kubernetes 应用程序的一种形式。

Kubernetes Operator 模式的行为遵循外围 Kubernetes 原理之一：管制实践。在机器人技术和自动化中，它是一种间断运行动静零碎的机制。它依赖于一种能力，即尽可能精确地依据可用资源疾速调整工作负载需要。目标是开发具备必要逻辑的管制模型，以帮忙应用程序或零碎保持稳定。在 Kubernetes 世界中，该局部由控制器解决。
控制器是一种非凡的软件，能够在循环中响应更改并在集群中执行调整操作。第一个 Kubernetes 控制器是 kube-controller-manager。它被视为所有 Operator 的始祖。

简而言之，控制器循环是控制器动作的根底。设想一下，一个非终止过程（在 Kubernetes 中称为 reconciliation 循环）重复产生，如下图所示：

该过程察看至多一个 Kubernetes 对象，该对象蕴含无关所需状态的信息。诸如 … 的对象

Deployments
Services
Secrets
Ingress
Config Maps

…由配置文件定义，这些配置文件由 JSON 或 YAML 的清单组成。而后，控制器依据内置逻辑通过 Kubernetes API 进行间断调整，以模拟所需状态，直到以后状态变为所需状态。

这样，Kubernetes 通过解决一直的变动来应答 Cloud Native 零碎的动静个性。为达到预期状态而执行的批改示例包含：

留神节点何时呈现故障并须要新的节点。
查看是否须要复制 Pod。
如果须要，请创立一个新的负载均衡器。

Operator 是特定于应用程序的控制器。它扩大了 Kubernetes API 以代表人员（操作工程师或站点可靠性工程师）创立，配置和治理简单的应用程序。让咱们看看 Kubernetes 文档对此有何评论。
Operator 是 Kubernetes 的软件扩大，它利用自定义资源来管理应用程序及其组件。Operator 遵循 Kubernetes 准则，尤其是管制回路。

到目前为止，您晓得 Operator 利用了察看 Kubernetes 对象的控制器。这些控制器有点不同，因为它们跟踪的是自定义对象，通常称为自定义资源（CR）。CR 是 Kubernetes API 的扩大，它提供了一个能够存储和检索结构化数据（应用程序的冀望状态）的中央。下图显示了整个操作原理。

Operator 间断跟踪与特定类型的定制资源无关的集群事件。能够跟踪的这些自定义资源上的事件类型为：

Add
Update
Delete

当 Operator 接管到任何信息时，它将采取行动将 Kubernetes 集群或内部零碎调整为所需状态，作为其自定义控制器中 reconciliation 循环的一部分。

自定义资源通过增加对你的应用程序有帮忙的新对象，扩大了 Kubernetes 的性能。Kubernetes 提供了两种向集群增加自定义资源的办法：

通过 API 聚合，这是一种高级办法，须要您构建本人的 API 服务器，但能够为您提供更多控制权
通过自定义资源定义（CRD），这是一种无需任何编程常识即可创立的简略办法，是对原始 Kubernetes API 服务器的扩大。

这两个选项可满足不同用户的需要，他们能够在灵活性和易用性之间进行抉择。Kubernetes 社区创立了一个比拟，能够帮忙您确定适宜您的办法，然而最受欢迎的抉择是 CRD。

自定义资源定义曾经存在了很长一段时间。Kubernetes 1.16.0 公布了第一个次要的 API 标准。以下清单提供了一个示例：

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。前两行定义要创立的对象类型 CustomResourceDefinition 的 apiVersion apiextensions.k8s.io/v1beta1。
元数据形容了资源的名称，但最重要的中央是“spec”字段。它使您能够指定组和版本以及可见性范畴（命名空间或集群范畴）。
之后，您能够应用多种格局定义名称并创立一个不便的简称，该名称使您能够执行命令 kubectl get app 来获取现有的 CR。

下面的 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。运行它并通过特定域上的入口公开它。这只是用例的一个例子，然而它能够实现设计的任何事件。
Operator 还能够用来调配 Kubernetes 以外的资源。您能够在不来到 Kubernetes 平台的状况下管制内部路由器的配置或在云中创立数据库。

为了全面理解 Kubernetes Operator，让咱们看一下 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 服务器中对上述任何对象的更改，并确保匹配的部署和配置放弃同步。

PS: 本文属于翻译，原文

正文完