Kubernetes OperatorMongoDBOpsManager 使用部署资源的每个Kubernetes集群中的 自定义资源来管理Ops Manager部署。 Kubernetes Operator 监视资源规范的更改。当规范发生变化时， Kubernetes Operator 会验证这些更改，并对部署Ops Manager组件的每个Kubernetes集群中的资源进行适当更新。
MongoDBOpsManager 自定义资源规范定义了以下Ops Manager组件：
应用程序数据库
MongoDB Ops Manager应用程序
备份守护进程
下图描述了MongoDB Ops Manager部署的相关组件：
在单集群部署中，您可以将这些组件部署在安装 Kubernetes Operator 的同一个 Kubernetes 集群中。 该集群称为“operator 集群”。
在多集群部署中，您可以：
将每个组件部署在不同的 Kubernetes 集群（称为“成员集群”）中。 您还可以使用单个成员 Kubernetes 集群来部署简化的多集群部署。 要了解更多信息，请参阅单集群和多集群模式。
在一个 Kubernetes 集群（称为“operator 集群”）中安装 Kubernetes Operator，Kubernetes Operator 在此集群中管理所有其他成员集群。 Operator 集群也可以被视为成员集群，因为它也可以托管MongoDB Ops Manager组件。 请参阅多集群架构图。
应用程序数据库
对于应用程序数据库， Kubernetes Operator 将MongoDB副本集部署为 StatefulSet 。
应用程序数据库的每个 Pod 都包含以下容器：
MongoDB Agent 。 要覆盖MongoDB Agent版本，请使用
$AGENT_IMAGE环境变量或用于安装Kubernetes Operator 的 Helm 图表中的agent.version。监控代理。 您无法覆盖监控代理的版本。 Kubernetes Operator 使用的版本确保与MongoDB Ops Manager版本向后兼容。
要查看监控代理的版本，请执行以下操作：
检查 Pod 内的
/usr/local/om_version_mapping.json是否有 Kubernetes Operator，或检查 Kubernetes Operator 的映像。检查部署应用程序数据库的 Pod 上的监控代理的容器映像。
在多集群部署中（当您将spec.applicationDatabase.topology设置为MultiCluster时），Kubernetes Operator 在为spec.applicationDatabase.clusterSpecList中的应用程序数据库指定的每个 Kubernetes 集群中创建 StatefulSet。
在托管应用程序数据库的 MongoDB 副本集节点的每个 Kubernetes 成员集群中，会发生以下操作：
Kubernetes 在 StatefulSet 中为组成应用程序数据库副本集的每个节点创建一个 Pod。 StatefulSet 中的每个 Pod 都运行
mongod和MongoDB Agent 。启用每个MongoDB
mongod助手能够在 StatefulSet 中的 Pod 上启动 ，您必须使用 设置为应用程序数据库指定特定的MongoDB Server版本。您在此设置中指定的版本必须与容器注册表中的标签相对应。spec.applicationDatabase.version每个MongoDB Agent都会在其应用程序数据库 Pod 上启动
mongod。 MongoDB Agent将mongod进程添加到应用程序数据库副本集。spec.applicationDatabase您可以在MongoDBOpsManager自定义资源的 集合中副本集的副本数和其他配置选项。 Kubernetes Operator 使用密钥将此配置传递给MongoDB助手， Kubernetes Operator 将该密钥挂载到应用程序数据库 StatefulSet 中的每个 Pod。在多集群应用程序数据库部署中（其中
spec.applicationDatabase.topology设置为MultiCluster），您可以在spec.applicationDatabase.clusterSpecList中为每个成员集群单独指定每个成员集群中的节点数。 在多集群部署中，spec.applicationDatabase中的replicas设置将被忽略。每次更新
spec.applicationDatabasecollection时，Kubernetes Operator 都会将更改应用于 MongoDB Agent 配置和 StatefulSet 规范（如果适用）。如果 StatefulSet 规范发生变化，Kubernetes 会以滚动方式升级 Pod 并重新启动每个 Pod。为了从托管应用程序数据库的每个Kubernetes集群内提供到每个应用程序数据库 Pod 的连接， Kubernetes Operator 创建了一项无头服务。在应用程序数据库的多集群部署中， Kubernetes Operator 还会为每个 Pod 创建一个名为
<om_resource_name>-db-N-svc的服务（这对应于metadata.name），并使用其 FQDN （例如 ）作为主机名连接到特定的<om_resource_name>-db-0.<namespace>.svc.cluster.localmongod。根据 StorageClass 或部署Kubernetes Operator 的环境， Kubernetes可能会使用动态卷预配来创建持久卷。
您可以使用 或
spec.applicationDatabase.podSpec.persistence.single为应用程序数据库spec.applicationDatabase.podSpec.persistence.multiplePod 自定义持久卷声明。
应用程序数据库拓扑
要选择主节点，应用程序数据库副本集的大多数节点必须可用。 如果副本集的大多数节点发生故障，则副本集无法形成投票多数来选举主节点。 要了解更多信息，请参阅副本集部署架构。
如果可能，请使用奇数个 Kubernetes 成员集群，并跨数据中心、区域或 Kubernetes 集群分布应用程序数据库节点。 要了解更多信息，请参阅分布在两个或多个数据中心的副本集。
请考虑以下应用程序数据库拓扑示例：
对于有五个成员的应用程序数据库，可能的成员分布包括：
两个集群：三名成员为
Cluster 1，两名成员为Cluster 2。如果
Cluster 2失败，Cluster 1会托管足够数量的应用程序数据库副本集成员来选举主节点 (primary node in the replica set)节点。如果
Cluster 1失败，则Cluster 2没有足够的应用程序数据库成员来选择主节点。
三个集群：两名成员为
Cluster 1，两名成员为Cluster 2，一名成员为Cluster 3。如果任何单个集群发生故障，其余集群上有足够的成员来选举主节点。
如果两个集群发生故障，则剩余集群上的成员数量不足，无法选举主节点。
对于有七个成员的应用程序数据库，请考虑以下成员分布：
两个集群：四名成员为
Cluster 1，三名成员为Cluster 2。如果
Cluster 2失败，则Cluster 1上有足够的节点来选举主节点 (primary node in the replica set)节点。如果
Cluster 1失败，则Cluster 2上的节点不足，无法选举主节点 (primary node in the replica set)节点。
尽管Cluster 2满足应用程序数据库至少三个成员的要求，但应用程序数据库的七个成员中的大多数都必须可用于选举主节点 (primary node in the replica set)节点。
要了解更多信息，请参阅MongoDB Ops Manager和 AppDB 资源的灾难恢复。
Ops Manager 应用程序
应用程序数据库进入“正在运行”状态后， Kubernetes Operator 开始部署MongoDB Ops Manager应用程序：
它在每个成员 Kubernetes 集群上配置一个 StatefulSet。
对于要部署的每个MongoDB Ops Manager副本集， Kubernetes都会在 StatefulSet 中创建一个 Pod。
每个 Pod 包含一个MongoDB Ops Manager应用程序进程。
要使单个集群MongoDB Ops Manager 部署能够灵活应对单个 Pod 故障，请使用 增加托管MongoDB Ops Manager spec.replicas应用程序的副本数量。
为了使多集群MongoDB Ops Manager 部署能够弹性应对整个数据中心或区域故障，请通过将MongoDB Ops Manager Kubernetes和 设置为spec.topologyspec.applicationDatabase.topology ，在多个 集群中部署MultiCluster 应用程序。另请参阅MongoDB Ops Manager和 AppDB 资源的灾难恢复。
备份守护进程
如果spec.backup.enabled为true ，则在每个成员Kubernetes集群上， Kubernetes Operator 会在MongoDB Ops Manager应用程序进入“正在运行”阶段后启动备份守护进程。 对于备份守护程序，Kubernetes Operator 会将 StatefulSet 部署到每个成员 Kubernetes 集群。 在每个成员集群中，Kubernetes 在 StatefulSet 中创建spec.backup.members中指定数量的备份守护程序 Pod。 在单集群部署中，这些操作发生在您用于安装Kubernetes Operator 和部署MongoDB Ops Manager组件的 Operator 集群上。
如果启用备份，请在全局 级别配置 oplog 存储 、块存储或 S3 快照存储 spec.backup，而不是为每个 Kubernetes 成员集群配置。
您还可以 加密备份作业 ，但在同一 Kubernetes 操作符 实例不同时管理 MongoDBOpsManager 和 MongoDB 自定义资源的部署中会 受到限制 。
如果启用备份， Kubernetes Operator 会在每个成员Kubernetes集群上为备份守护程序的头部数据库创建持久卷声明。您可以使用spec.backup.headDB 设置配置头部数据库。
Kubernetes Operator 调用MongoDB Ops Manager API，以确保MongoDB Ops Manager应用程序的备份配置与您在每个成员Kubernetes集群的自定义资源定义中定义的配置相匹配。