Kubernetes Operator – 最值得关注的 5 个方面

by Canonical on 16 September 2022

软件 Operator 正在逐渐改变我们部署和运行复杂分布式系统的方式。它们通常承诺能够实现软件低干预、自动化运行 – 理想情况下，可提高服务可靠性、延长正常运行时间。有关 Kubernetes Operator 的介绍，请查看入门网络研讨会或下载Kubernetes Operator 指南。

目前，在 GitHub 和charmhub.io 等平台已发布了数百个现成 Operator – 面对如此多的选择，如何为您的部署找到最适合的 Operator？别担心 – 本篇博客将介绍最值得关注的五个方面，以作为您决策的基本准则。让我们开始吧！

出处

“出处”意指“事物出自某处”。作为软件术语，“出处”表示软件背后的开发者、开发社区或供应商。我的第一条建议是安装任何软件前，先验证这些软件的出处，尤其当该软件可以运行其他软件或提升权限时。

这不仅是因为您的服务环境有可能被黑客或 APT（高级持续性威胁）攻击，更因为以下实际问题：

• 您预计能为 Operator 提供什么级别的支持？是“尽最大努力”还是“仅社区支持”？如果 Operator 无法履行承诺，支持是否足够？请记住，软件 Operator 旨在封装真实运维人员的知识和智慧，其高效可靠运行对于您的最关键资产（例如数据库服务器和中间件）至关重要。
• 开发人员是否对 Operator 进行全面测试，以确保其可靠交付所声称的功能？测试是如何进行的？

许可证

大多数现代软件都按照某种软件发布许可证来进行发行。许可证决定了用户“可以”/“不可以”对软件进行的操作、用户对于软件的权利等。我推荐首先考虑带有自由免费、开源许可证授权的软件，例如 Apache 软件许可证，版本 2.0。 

开源软件 Operator 具有以下优势：

• 您可以检查在用 Operator 的代码 – 是否存在缺陷、漏洞、恶意代码、遥测以及许可证不合规问题，这些都可能导致您的服务和业务易受攻击。
• 即使软件开发人员因某种原因不再支持 Operator，您仍可以自行提供支持（只要您拥有必要的专业知识），这样就有了更多应对时间来确保业务连续性。
• 通常情况下（但并非总是如此），部署此类 Operator 时几乎没有限制。如果您想在测试环境中部署 Operator，并确保其软件和行为与生产环境完全一致，您也可以使用带有自由许可证的开源 Operator，而不是带有更严格或完全专有许可证的 Operator。

能力

我将“能力”列为 Operator 的第三属性。在这里，“能力”并不是指“Operator 能否满足所有要求”，而是指“Operator 能否实现所声称的功能”？

如果现在有两个 Operator：一个专用于 MySQL Server 且仅管理 MySQL 高可用，而另一个在管理高可用的同时还有 20 个其他功能，我会根据管理 MySQL 高可用（因为我更需要这个关键特性），来选择相对能力更高的 Operator。要是不清楚自己更需要哪个功能，就会造成追悔莫及的后果。

怎么了解 Operator 的能力？您可以检查开发人员对 Operator 进行测试的方法和环境。但最好是您自己对 Operator 进行彻底测试，例如使用故障注入框架 – 可以试试 Kube DOOM！

成熟度

成熟度并不代表能力，但是可作为其中一个指标。Operator 成熟度由以下三个层面决定：

• 为发布做好准备
• 为评估做好准备
• 为生产做好准备

为发布做好准备

在我看来，一个“为发布做好准备”的 Operator – 允许潜在用户查看 – 应具有产品的基本属性。例如：网页、开发者文档、部署和运营指南、贡献指南、许可证、问题跟踪器和开发者/支持联系方式。这意味着已使用类似 git 的 SCM 系统、已完成单元和集成测试并具有某种自动构建管道。“为发布做好准备”只是生产就绪的前提，因为 Operator 可能在关键时刻并未完全实现投入生产所需的全部功能 – 或者这些能力的实现并未达到 Operator 所需的信赖和可靠水平。

为评估做好准备

仅在 Operator 可靠且有能力覆盖编排高可用、有线和静态加密等场景时，才会被认为已处于生产部署就绪状态。但在这个更高级功能阶段之前，如果 Operator 已具备某些有用功能，例如执行应用程序升级、进入备份和恢复状态的能力，也可被称为“为评估做好准备” – 虽然没有完全生产就绪，但部分功能可用。

为生产做好准备

“为生产做好准备”的 Operator 必须符合各种要求：满足“为发布做好准备”、“为评估做好准备”的所有标准，提供足够的特性和能力以获取用户信任并可靠运行最关键资产（例如数据库、web 场、身份验证目录和中间件）。最好是这样！

压力下的性能

现在，您的 MySQL Server、OpenLDAP 目录和 Redis 缓存都部署在 Kubernetes 上并由 Operator 管理。大功告成 – 值得休息放松一下，是吧？当然可以。但请记住，当意外出现时，我们需要依靠这些 Operator 来做出有效响应：我们需要面对的不仅仅是软件运行的愉快路径测试，还可能包括在云上同时出现的七种不同类型混沌。如果您严重依赖 Kubernetes Operator 开发工程师团队的专业知识和智慧，则可能会遇到在现场无法获取真人专业知识和智慧的情况。就算是这样，既会高效规划和运行 OpenLDAP 容量扩展，又会 Redis 集群故障排除的专家 DBA（数据库管理员）也是极为少见的。所以，如果真遇到这种情况也没有办法。

无论如何，您需要相信软件 Operator 能够应对各种问题：它们已针对尽可能多的“极端场景”进行了全面测试。这就是所谓的“压力下的性能”。或者如前文所述，将 Operator 部署到生产服务环境前，您也可以使用故障注入框架（即 Chaos）来自行验证。

摘要

以下为考虑 Kubernetes Operator 时需要关注的五个方面：

1. 出处
2. 许可证
3. 能力
4. 成熟度
5. 压力下的性能

前往 charmhub.io 以查看 Charmed Operator 集