MongoDBOpsManager自定义资源定义
KubernetesKubernetes OperatorMongoDB Ops Manager MongoDBOpsManager使用部署资源的每个Kubernetes集群中的Kubernetes 自定义资源 来管理MongoDB Ops Manager部署。Kubernetes Operator 监视资源规范的更改。 当规范发生变化时，Kubernetes Kubernetes Operator 会验证这些更改，并对部署MongoDBKubernetes OpsMongoDB Ops Manager Manager组件的每个Kubernetes集群中的资源进行适当更新。
MongoDBOpsManager 自定义资源 规范定义了以下MongoDB 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 Agent
mongod能够在 StatefulSetMongoDB Server 中的 Pod 上启动spec.applicationDatabase.version，您必须使用 设置为应用程序数据库指定特定的 版本。您在此设置中指定的版本必须与 容器注册表中的标签相对应。每个MongoDB Agent都会在其应用程序数据库 Pod 上启动
mongod。 MongoDB Agent将mongod进程添加到应用程序数据库副本集。您可以在
MongoDBOpsManager自定义资源的spec.applicationDatabase集合中配置应用程序数据库副本集的副本数和其他配置选项。 Operator 使用 密钥 Kubernetes将此配置传递给MongoDB Agent 助手 OperatorKubernetes 挂载到应用程序数据库 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.local）作为主机名连接到特定的mongod。取决于 StorageClass 或部署 Kubernetes Operator 的环境，Kubernetes 可能会创建 持久卷 使用 动态卷预配。
您可以自定义 持久卷声明 使用
spec.applicationDatabase.podSpec.persistence.single或spec.applicationDatabase.podSpec.persistence.multiple的应用程序数据库 Pod。
应用程序数据库拓扑
要选择主节点，应用程序数据库副本集的大多数节点必须可用。 如果副本集的大多数节点发生故障，则副本集无法形成投票多数来选举主节点。 要了解更多信息，请参阅副本集部署架构。
如果可能，请使用奇数个 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集群的自定义资源定义中定义的配置相匹配。