第 1 章 了解 Operator

从概念上讲，Operator 会收集人类操作知识，并将其编码成更容易分享给消费者的软件。

Operator 是一组软件，可用于降低运行其他软件的操作复杂程度。它可以被看作是软件厂商的工程团队的扩展，可以在 Kubernetes 环境中（如 OpenShift Container Platform）监控软件的运行情况，并根据软件的当前状态实时做出决策。Advanced Operator 被设计为用来无缝地处理升级过程，并对出现的错误自动进行响应，而且不会采取“捷径”（如跳过软件备份过程来节省时间）。

从技术上讲，Operator 是一种打包、部署和管理 Kubernetes 应用程序的方法。

Kubernetes 应用程序是一款 app，可在 Kubernetes 上部署，也可使用 Kubernetes API 和 kubectl 或 oc 工具进行管理。要想充分利用 Kubernetes，您需要一组统一的 API 进行扩展，以便服务和管理 Kubernetes 上运行的应用程序。可将 Operator 看成管理 Kubernetes 中这类应用程序的运行时。

1.1. 为什么要使用 Operator？

Operator 可以：

  • 重复安装和升级。
  • 持续对每个系统组件执行运行状况检查。
  • 无线 (OTA) 更新 OpenShift 组件和 ISV 内容。
  • 汇总现场工程师了解的情况并将其传输给所有用户，而非一两个用户。
为什么在 Kubernetes 上部署？
Kubernetes（扩展至 OpenShift Container Platform）包含构建复杂分布式系统（可在本地和云提供商之间工作）需要的所有原语，包括 secret 处理、负载均衡、服务发现、自动扩展。
为什么使用 Kubernetes API 和 kubectl 工具来管理您的应用程序？
这些 API 功能丰富，所有平台均有对应的客户端，并可插入到集群的访问控制/审核中。Operator 会使用 Kubernetes 的扩展机制“自定义资源定义 (CRD)”支持您的自定义对象，如 MongoDB，它类似于内置的原生 Kubernetes 对象。
Operator 与 Service Broker 相比怎么样？
Service Broker 朝着实现应用程序的编程式发现和部署的目标前进了一步。但它并非一个长时间运行的进程，所以无法执行第 2 天操作，如升级、故障转移或扩展。它在安装时提供对可调参数的自定义和参数化，而 Operator 则可持续监控集群的当前状态。非集群服务仍非常适合于 Service Broker，但也存在合适于这些服务的 Operator。