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 时需要关注的五个方面:
- 出处
- 许可证
- 能力
- 成熟度
- 压力下的性能
前往 charmhub.io 以查看 Charmed Operator 集
订阅博客文章
查看更多内容
Canonical 宣布推出 12 年 Kubernetes LTS
Canonical 的 Kubernetes LTS(长期支持)将支持 FedRAMP 合规性,并在裸机、公共云、OpenStack、Canonical MicroCloud 和 VMware 上获得至少 12 年的承诺安全维护和企业支持。 Canonical 宣布,从 Kubernetes 1.32 开始,将提供 12 年的安全维护和支持。新版本易于安装、操作和升级,具有一流的开源网络、DNS、网关、度量服务器、本地存储、负载平衡器和入口服务。Canonical Kubernetes 使客户能够按照自己的节奏进行升级,对于喜欢快速行动的组织,将每四个月发布一次新的上游版本,对于需要长期支持环境的组织,则提供 12 年的承诺。 “Kubernetes 的不断升级是企业团队 […]
NIS2 合规指南:第 2 部 — 了解 NIS2 合规要求
在上一篇博客文章中,笔者详细介绍了 NIS2 及其适用对象。本系列的第二篇文章中将详细介绍 NIS2 中的主要要求,并将这些要求具体转化为切实可行的行动措施,助力企业组织满足 NIS2 合规要求。欢迎阅读本文,一同深入了解 NIS2 的内容。 NIS2 适用于您。那么,您需要做些什么来满足 NIS2 合规要求? 如果您正在阅读本文,想必已经意识到 EU NIS2 适用于您所在的公司。接下来,让我们深入探究其中的具体要求,以及为实现合规性需要采取的行动。 该指令规定,相关实体必须落实网络安全风险管理措施,且这些措施必须“适当适度”。尽管这一要求看似宽泛,存在一定的解释空间,但指令中明确规定了一系列必须落实的最低限度的网络安全风险管理措施。 下面将细入探讨这些措施,并将其转化 […]
最新 IDC 研究 — 70% 的 IT 团队每周在安全补丁方面耗费时间超 6 小时
Canonical 与国际数据公司(IDC)开展的最新研究表明,在严苛的 CVE 补丁更新规定下,企业组织难以笃定地应用补丁,并且在开源软件供应链方面也面临着其他严峻挑战。 今日,Ubuntu 发行商 Canonical 发布了一份与 IDC 合作完成并由 Google Cloud 联合赞助的研究报告,其揭示了有关企业组织在安全补丁和不断加重的监管负担方面所面临压力与挑战的全新见解。这份题为《软件供应链现状:安全挑战、机遇以及借助开源软件实现韧性的路径》的报告,对 500 家拥有 250 名以上全职员工的企业组织进行了调查,确定了他们所面临的最紧迫问题。最值得注意的是,这些问题都是企业组织在漏洞和补丁管理、软件依赖关系或软件供应链可视性不足以及软件来源可信度方面面临的难题 […]