Operator 模式

    Operator 模式 旨在记述（正在管理一个或一组服务的）运维人员的关键目标。 这些运维人员负责一些特定的应用和 Service，他们需要清楚地知道系统应该如何运行、如何部署以及出现问题时如何处理。

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

    Kubernetes 上的 Operator

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

    使用 Operator 可以自动化的事情包括：

    • 按需部署应用
    • 获取/还原应用状态的备份
    • 处理应用代码的升级以及相关改动。例如数据库 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，你可以自己编写代码。

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

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