MongoDB Controllers for Kubernetes Operator 将MongoDB Enterprise、 Ops Manager和MongoDB Community部署到Kubernetes。此页面可帮助您在安装前选择部署路径和安装方法。如果您不熟悉Kubernetes Operator，请从快速入门开始。
选择部署路径
Kubernetes Operator 支持范围本地评估集群到跨多个Kubernetes集群的生产部署。选择适合您目标的路径。
将Ops Manager和MongoDB副本集到本地计算机上的单节点 Kind集群。 当您想要端到端评估Kubernetes Operator、学习；了解如何组合自定义资源或在本地重现问题时，请选择快速入门。 当您需要一种在节点或集群丢失后仍然有效的部署时，它就不太理想了，因为 Kind 运行在一个节点。 | |
将Ops Manager和MongoDB资源部署到一个生产Kubernetes集群。 当您的可用性要求在一个Kubernetes集群中得到满足，并且您希望运行的基础架构数量最少时，请选择单集群部署。 当您必须在整个Kubernetes集群或地区丢失后仍能幸存时，这就不太理想了。 | |
跨多个Kubernetes集群部署一个MongoDB 部署 ，无论是否有服务网格。 当需要跨区域或数据中心分布副本集成员以实现更高可用性和灾难恢复时，请选择多集群部署。 当您评估Kubernetes Operator 时，它不太理想，因为它需要您配置和操作多个Kubernetes集群。 |
要将MongoDB Community部署到Kubernetes，请参阅 GitHub 上的MongoDB Community文档。由于MongoDB Enterprise和Ops Manager可用的配置选项范围很广，因此本指南将介绍这些部署。
选择安装方法
每种方法都会安装相同的Kubernetes Operator。要学习；了解有关每种方法的更多信息，请参阅安装Kubernetes Operator 的MongoDB控制器。
应用MongoDB发布的 YAML 清单。 当您将清单保留在源代码管理中，或者当您想在应用之前查看和编辑清单时，请选择 如果您想在不编辑 YAML 的情况下设立配置，则不太理想。 | |
安装 当您想通过值而不是清单配置Kubernetes Operator 时，或者当您需要仅 Helm 公开的选项（例如监视命名空间子集）时，请选择 Helm。 当您的组织不允许 Helm 时，它就不太理想。 | |
将 运行OpenShift Container Platform 时选择此方法，这需要 对于任何非OpenShift Kubernetes发行版，它都不太理想。 |
Kubernetes Operator 的工作原理
企业版MongoDB部署由两种不同的资源类型组成：数据库本身和负责备份数据、自动化（部署、配置、升级）、实时监控等的外部数据库管理资源。此外部资源可以是Ops Manager （自托管资源）或Cloud Manager （托管等效资源）。
社区MongoDB部署仅包含数据库资源，不包含外部管理资源。
Kubernetes 操作符允许您根据特定需求，在一个或多个 Kubernetes 集群中以多种配置创建这些资源并管理部署的所有方面。
Kubernetes Operator 是一个Kubernetes控制器，其工作原理是有效扩展原生Kubernetes API ，将上述MongoDB元素作为自定义资源包含在内，这样您就可以使用 YAML 清单来定义和部署它们，就像部署到Kubernetes 的任何其他资源一样。
尽管 MongoDB 和 MongoDB Ops Manager 自定义资源可以作为独立运行的实例部署，但推荐的部署拓扑是将数据库和 MongoDB Ops Manager 部署为 StatefulSet，如上图所示。此外，Kubernetes 操作符 要求在 Kubernetes 集群中提供 storageClass（在托管集群中默认可用），以创建负责存储和备份数据的 PersistentVolumes。
要了解有关使用 Kubernetes 操作符在 Kubernetes 中部署 MongoDB 的具体系统要求和前提条件，请参阅前提条件页面。
MongoDB Controllers for Kubernetes Operator 是一个操作符替换之前的MongoDB Enterprise Kubernetes Operator 和MongoDB Community Operator 的 Operator。有关Kubernetes Operator 第一个版本的更多信息，请参阅发布说明。