关于kubernetes:Kubernetes-Operator基础入门

2次阅读

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

本文转自 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 动作的根底。设想一下，有一个非终止的过程（在 Kubernetes 中称为和解循环）在一直地产生，如下图所示：

这个过程至多察看一个 Kubernetes 对象，该对象蕴含无关所需状态的信息。比方：

Deployment

Services

Secrets

Ingress

Config Maps

这些对象由 JSON 或 YAML 中的 manifest 组成的配置文件定义。而后 controller 依据内置逻辑，通过 Kubernetes API 进行继续调整，模拟所需状态，直到以后状态变成所需状态。

通过这种形式，Kubernetes 通过解决一直的更改来解决 Cloud Native 零碎的动静性质。为达到预期状态而执行的批改实例包含：

留神到节点宕机时，要求更换新的节点。
查看是否须要复制 pods。
如果须要，创立一个新的负载均衡器。

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/co…

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

正文完