在2025年，Percona Operator for MongoDB 专注于解决在 Kubernetes 中运行 MongoDB 最困难的部分：可靠的备份与恢复、选举和恢复期间更清晰的行为、大规模下更好的可观测性，以及随着 MongoDB 8.0 成为主流而设定的更安全的默认值。这一年包含了真正的方向调整，例如解决 PBM 连接泄漏问题，并明确了何时不应升级。其成果是一个对其保证更加透明、并且更适合多集群、多区域以及合规驱动环境的 Operator。

对于许多团队而言，2025 年的重点不在于首次学习 Kubernetes 或 MongoDB。而是在于用更少的人力运行更多集群，满足更严格的安全和合规期望，并确保日常运维保持日常化。社区的讨论反映了这种转变。问题较少是关于“我如何部署”，更多是关于：

• “在压力下恢复行为如何？”
• “当节点被排空时，选举期间会发生什么？”
• “如何查看 Operator 在众多集群中的实际活动？”

因此，让我们看看 Percona 是如何解决这些以及许多其他请求，以交付市场上最好的开源 Kubernetes MongoDB Operator 😉

备份和恢复变得更加灵活，压力更小

年初，随着 1 月份发布的 1.19.0 版本，Operator 在两个方面扩展了其存储灵活性。除了作为技术预览添加基于 NFS 的文件系统备份外，它还引入了 PVC 调整大小的可扩展性，以配合外部自动扩缩器。这些变化共同解决了在受限或高度监管环境中的常见现实问题，即可能无法使用 S3 兼容对象存储，以及需要动态处理存储增长而无需手动干预。

同一版本还移除了一个长期存在的限制，允许在未管理的副本集群中进行备份，从而简化了依赖辅助或远程集群的灾难恢复设计。

5月，1.20.0版本主要关注备份工作流。改进了时间点恢复功能，以便可以从任何配置的存储执行恢复，而无需等待集群重新配置。这减少了那些根据用途轮换或分离存储的环境中的摩擦。大约此时，增量物理备份也作为技术预览引入。其动机很直接：更小的备份、更快的完成时间，以及针对更大数据集的更好的恢复时间目标。其边界保持明确，包括需要基础备份以及备份链的单一存储位置。

全年中，恢复行为根据实际使用情况进行了改进，特别是在平衡器处理和 PBM 集成方面。这些变化使恢复更加可预测，即使它们并不总是作为“新功能”可见。

MongoDB 8.0 的采用变得更加轻松和有信心

对 Percona Server for MongoDB 8.0 的支持在年初就已到来，并在后续版本中稳步成熟。到 10 月，MongoDB 8.0 成为新集群的默认版本，反映了对其稳定性和就绪度的日益增长的信心。在此过程中，Operator 调整了监控角色、备份逻辑和恢复行为，以符合 MongoDB 8.x 的期望。

一个值得注意的添加是通过 logcollector 配置实现持久化的集群级 MongoDB 日志记录。这确保了日志在 Pod 重启后仍然存在，并且可以在集群级别访问，而不是绑定到单个容器，从而显著简化了调试和日常运维操作。

最终结果不仅仅是“支持新版本”，而是一个无需重写运维手册就能采用它的更清晰路径。

多集群和多区域操作更具目的性

随着越来越多的团队跨命名空间、区域甚至多个 Kubernetes 集群运行 MongoDB 集群，操作清晰度变得比原始功能更重要。年中改进使得在监控中为集群指定有意义的名称变得更加容易，这样即使在复杂环境中，PMM 仪表板也能保持可读性。这个小小的改变减少了事件期间的混乱，此时快速识别正确的集群至关重要。

今年晚些时候，引入了并发协调功能，使得单个 Operator 实例能够更高效地管理多个集群。更新不再相互排队，协调可以进行调整以适应环境的规模。

CRD 也获得了更清晰的版本标签，使得验证给定 CRD 定义与集群中运行的 Operator 版本是否一致变得更加容易。这帮助团队避免了当较新的 Operator 版本引入更新或扩展的 CRD 模式时可能出现的细微不匹配，特别是在升级和审计期间。

副本集行为变得更加平静和可预测

全年中的几项改进专注于减少选举和拓扑相关的意外情况。年初，Operator 添加了对手动调整副本集成员优先级的支持，使团队在维护或计划性故障转移期间拥有更多控制权。

今年晚些时候，隐藏节点变为可用。这些节点持有数据的完整副本，但不服务客户端流量，使其可用于备份或报告工作负载。

这些变化共同帮助 Operator 更贴近 MongoDB 在生产环境中的实际运维方式。

安全和访问管理变得更简单

2025 年与安全相关的改进侧重于减少手动工作，而非增加复杂性。为自定义 MongoDB 用户自动生成密码允许团队直接在 Custom Resource 中声明用户，并让 Operator 安全地处理密钥创建。

支持服务账户的 IAM 角色减少了对管理用于云存储访问的长期凭证的需求，更好地与现代云安全实践保持一致。

这些变化悄然消除了围绕 Operator 的许多自定义脚本。

我们作为社区学到的东西

有几个主题反复出现，2025 年的大部分工作直接源于这些经验教训：

• 恢复的正确性比恢复速度更重要
• 清晰的边界比隐藏的自动化更好
• 可观测性需要随集群数量扩展，而不仅仅是单个集群的大小
• 明确权衡利弊比假装它们不存在更能建立信任

下一步计划

2025 年是关于让 Percona Operator for MongoDB 感觉更少意外、更可靠。展望未来，优先事项仍然刻意务实，专注于生产现实。

备份和恢复工作流将继续加强，包括对使用 PVC 快照的备份的支持。这为更快、更原生的存储恢复路径打开了大门，尤其是在基于快照的工作流已成为标准的环境。

随着自动 PVC 调整大小，存储自动化将进一步推进，随着数据集增长减少手动干预，并使 Operator 更容易与外部自动扩缩器配对。

凭证管理是另一个积极投入的领域。集成 Vault 来管理系统用户凭证管理将帮助团队标准化密钥处理，并使 MongoDB 操作与更广泛的安全和合规实践保持一致。

恢复工作流也将变得更加灵活，计划支持在恢复期间重新映射副本集。这将使得恢复到不同的拓扑、区域或集群布局变得更加容易，而无需进行恢复后重新配置。

贯穿所有这些工作的指导目标保持不变：让在 Kubernetes 上大规模运行 MongoDB 更容易，在压力下恢复更容易，在出现问题时更容易信任。