Operator 模式

    Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。 负责特定应用和 service 的运维人员，在系统应该如何运行、如何部署以及出现问题时如何处理等方面有深入的了解。

    在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。 Operator 模式会封装你编写的（Kubernetes 本身提供功能以外的）任务自动化代码。

    Kubernetes 上的 Operator

    Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes 核心中获得许多内置的自动化功能。 你可以使用 Kubernetes 自动化部署和运行工作负载， 甚至 可以自动化 Kubernetes 自身。

    Kubernetes 的 概念允许你在不修改 Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联控制器 来扩展集群的能力。 Operator 是 Kubernetes API 的客户端，充当 的控制器。

    • 按需部署应用
    • 获取/还原应用状态的备份
    • 处理应用代码的升级以及相关改动。例如，数据库 schema 或额外的配置设置
    • 发布一个 service，要求不支持 Kubernetes API 的应用也能发现它
    • 在没有内部成员选举程序的情况下，为分布式应用选择首领角色

    想要更详细的了解 Operator？下面是一个示例：

    1. 有一个名为 SampleDB 的自定义资源，你可以将其配置到集群中。
    2. 一个包含 Operator 控制器部分的 Deployment，用来确保 Pod 处于运行状态。
    3. Operator 代码的容器镜像。
    4. 控制器代码，负责查询控制平面以找出已配置的 SampleDB 资源。
    5. Operator 的核心是告诉 API 服务器，如何使现实与代码里配置的资源匹配。
      • 如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供 持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job 来处理初始配置。
      • 如果你删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
    6. Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator 会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于 ConfigMap 和/或具有数据库连接详细信息和凭据的 Secret。
    7. 由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些 额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上， 如果是，则创建 Job 对象为你升级数据库。

    部署 Operator

    部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到你的集群中。 跟运行容器化应用一样，控制器通常会运行在 之外。 例如，你可以在集群中将控制器作为 Deployment 运行。

    部署 Operator 后，你可以对 Operator 所使用的资源执行添加、修改或删除操作。 按照上面的示例，你将为 Operator 本身建立一个 Deployment，然后：

    可以了！Operator 会负责应用所作的更改并保持现有服务处于良好的状态。

    编写你自己的 Operator

    你还可以使用任何支持 的语言或运行时来实现 Operator（即控制器）。

    以下是一些库和工具，你可用于编写自己的云原生 Operator。

    说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读。

    • 阅读 CNCF 。
    • 详细了解 定制资源
    • 在 上找到现成的、适合你的 Operator
    • 发布你的 Operator，让别人也可以使用
    • 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的

    本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅CNCF 网站指南了解更多细节。