Operator 模式

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

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

    Kubernetes 上的 Operator

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

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

    • 按需部署应用
    • 获取/还原应用状态的备份
    • 处理应用代码的升级以及相关改动。例如，数据库 schema 或额外的配置设置
    • 模拟整个或部分集群中的故障以测试其稳定性
    • 在没有内部成员选举程序的情况下，为分布式应用选择首领角色

    想要更详细的了解 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。

    部署 Operator

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

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

    编写你自己的 Operator

    如果生态系统中没可以实现你目标的 Operator，你可以自己编写代码。在 接下来一节中，你会找到编写自己的云原生 Operator 需要的库和工具的链接。

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

    • 详细了解定制资源
    • 在 上找到现成的、适合你的 Operator
    • 借助已有的工具来编写你自己的 Operator，例如：
      • KUDO (Kubernetes 通用声明式 Operator)
      • Metacontroller，可与 Webhook 结合使用，以实现自己的功能。
    • 发布你的 Operator，让别人也可以使用
    • 阅读 ，其介绍了 Operator 介绍
    • 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的 文章