对于 AI 代理：可在 https://www.mongodb.com/zh-cn/docs/llms.txt 获取文档索引—通过在任何 URL 路径后添加 .md 可获取所有页面的 Markdown 版本。
Docs 菜单
Docs 主页
/ /
架构
Docs 主页
/
管理
/
Kubernetes Operator 的控制器
/
架构
Docs 主页
/
管理
/
Kubernetes Operator 的控制器
/
架构

Ops Manager资源架构

Ops Manager是任何 Enterprise MongoDB 部署的必需组件。 Ops Manager可自动执行、监控和执行MongoDB数据库备份。 MongoDBOpsManager 自定义资源定义了三个组件：

  • Ops Manager 应用程序— Ops Manager主组件和前端用户界面。

  • 应用程序数据库 — Ops Manager的后端MongoDB 数据库。

  • 备份守护程序— 在备份和恢复过程中支持Ops Manager 应用程序。

Kubernetes Operator 管理 MongoDBOpsManager 资源的规范。当规范发生变化时， Kubernetes Operator 会验证这些更改，并在您部署Ops Manager组件的每个Kubernetes集群中应用适当的更新。

下图显示了单个Kubernetes集群上的Ops Manager部署的架构：

显示单个Kubernetes集群上的MongoDB Enterprise Kubernetes Operator 的高级架构的图表

应用程序数据库

对于应用程序数据库， Kubernetes Operator 将MongoDB副本集部署为 StatefulSet。每个 Pod 都有以下容器：

  • mongod —数据库进程。

  • MongoDB 助手— 管理mongod 生命周期。您可以使用$AGENT_IMAGE 环境变量或agent.version Helm图表中的 覆盖MongoDB 助手版本。

  • 监控代理— 将监控数据发送到Ops Manager。系统会自动选择该版本以实现向后兼容，并且无法覆盖。

Kubernetes Operator 通过挂载到每个 Pod 的密钥 (<om_resource_name>-db-config) 将应用程序数据库配置传递给代理。

Kubernetes为每个成员创建一个 Pod。每个MongoDB 助手都会启动 mongod 并将其添加到副本集。 Kubernetes Operator 为每个 Pod 创建 PersistentVolumeClaims，您可以使用 spec.applicationDatabase.podSpec.persistence 进行自定义。

Kubernetes Operator 为内部连接创建无头服务。在多集群部署中， Kubernetes Operator 还会为每个 Pod (<om_resource_name>-db-N-svc) 创建一项服务，以实现单独的 mongod 可寻址性。

应用程序数据库拓扑注意事项

要选举主节点 (primary node in the replica set)，应用程序数据库副本集的大多数节点必须可用。如果可能，请使用奇数个成员Kubernetes集群，并跨数据中心、区域或集群分布节点。

考虑以下分布示例：

  • 五成员应用程序数据库，两个集群：将 3成员放在集群1 中，将2 放在集群2 中。如果集群2 发生故障，则集群1 拥有多数。如果集群1 发生故障，则集群2 不会发生故障。

  • 五成员应用程序数据库，三个集群：将 21个成员分别放入集群2 和1 3中，并将 放入集群 中。任何单集群故障都会导致多数集群失效。

  • 七节点应用程序数据库，两个集群：将 置于集群 中，并将4 13置于集群2 中。只有丢失集群2 才能保留多数。

要学习；了解更多信息，请参阅Ops Manager和 AppDB 资源的副本集部署架构和灾难恢复。

Ops Manager 应用程序资源

应用程序数据库进入“正在运行”状态后， Kubernetes Operator 开始部署MongoDB Ops Manager应用程序：

  • Kubernetes Operator 在每个成员Kubernetes集群上配置一个 StatefulSet。

  • Kubernetes为每个Ops Manager副本创建一个 Pod。

  • 每个 Pod 包含一个MongoDB Ops Manager应用程序进程。

要使单集群部署能够灵活应对 Pod 故障，请增加 spec.replicas。要使多集群部署能够弹性应对数据中心故障，请将 spec.topology设立为 MultiCluster 并跨Kubernetes集群分配实例。

备份守护程序资源

如果 spec.backup.enabled 为 true， Kubernetes Operator 将在Ops Manager 应用程序进入“正在运行”状态后启动备份守护程序。 Kubernetes Operator 在每个成员集群上为备份守护程序部署一个 StatefulSet。 Kubernetes会创建 spec.backup.members 中指定数量的备份守护程序Pod。

如果启用了备份， Kubernetes Operator 会在每个成员集群上为备份守护程序的头部数据库创建一个 PersistentVolumeClaim。您可以通过 spec.backup.headDB 配置头部数据库。

Kubernetes Operator 调用Ops Manager API，确保Ops Manager应用程序的备份配置与自定义资源定义匹配。在全局 spec.backup 级别（而不是按集群）配置oplog存储、块存储或 S3快照存储。

您还可以加密备份作业，但当同一Kubernetes Operator实例不能同时管理MongoDBOpsManager 和MongoDB 自定义资源时，应用限制。

Ops Manager调节

下图描述了Kubernetes Operator 如何协调对 MongoDBOpsManager CRD 的更改：

显示 MongoDBOpsManager 自定义资源调节流程的图表
点击放大

协调通过以下步骤进行：

  1. 创建或更新 <om_resource_name>-db-config 包含MongoDB 助手用于启动应用程序数据库副本集的配置的密钥。

  2. 创建或更新 <om_resource_name>-db 应用程序数据库的 StatefulSet。此 StatefulSet 包含至少三个 Pod。每个 Pod 运行一个MongoDBmongod 助手，该助手会在其 Pod 上启动 。配置密钥会挂载到每个 Pod。

    在多集群部署中，StatefulSet 名为 <om_resource_name>-db-<cluster-idx>（例如 om-db-1）。

  3. 创建或更新 <om_resource_name> Ops Manager应用程序的 StatefulSet。每个副本都连接到应用程序数据库。大多数更改触发滚动升级。为应用程序数据库启用 TLS 也会触发滚动重启，因为连接字符串发生了变化。对spec.backup 的更改不会触发滚动升级。

    在多集群部署中，StatefulSet 名为 <om_resource_name>-<cluster-idx>（例如 om-1）。

  4. 通过Ops Manager API创建管理员用户，并将凭证保存在<om_resource_name>-admin-key 密钥中。此步骤仅在初始部署时执行。

  5. 通过执行应用程序数据库 StatefulSet 的滚动升级来启用监控。这种情况也只发生在初始部署。

  6. 如果spec.backup.enabled 为true ，则部署备份守护程序。 StatefulSet 名为<om_resource_name>-backup-daemon （在多集群部署中为<om_resource_name>-backup-daemon-<cluster-idx> ）。

  7. 通过Ops Manager API 配置备份，确保备份配置与自定义资源定义匹配。

后退

MongoDB自定义资源架构

来年

多集群架构

在此页面上