什么是 Operator？
操作符是一种标准机制，可扩展 Kubernetes 的控制平面以管理自定义 Kubernetes 资源。由于每个 Operator 都是针对自己的自定义资源 (CR) 构建的，因此它可以包含解决 Operator 所针对的服务类型的逻辑。 对于 Kubernetes Operator，该 Operator 包括部署 MongoDB Server 和 Ops Manager 实例的逻辑。
Kubernetes 操作符使用的每个 CR 代表 Kubernetes 中 MongoDB Server 部署的一个元素，并具有用于自定义该部署部分的选项。在 Kubernetes 部署中配置这些对象后，Operator 就会构建原生 Kubernetes 对象，例如根据您对 MongoDB Server 的指定要求创建 Pod 所需的状态集。 Kubernetes 操作符还通过与 MongoDB Cloud Manager 或 Ops Manager 交互，促进配置 MongoDB Server 功能，例如数据库备份。
为什么在 Kubernetes 上运行 MongoDB Enterprise Advanced？
在Kubernetes上运行MongoDB可简化自托管MongoDB的设置和管理。
Kubernetes Operator 与MongoDB和MongoDB Ops Manager配合使用，使用您为定义设置而创建的自定义资源文件来自动执行配置。 这样，您就可以使用现有的用于管理Kubernetes中应用程序的任何工具来管理配置，包括启用在 Git存储库中托管配置的 GitOps 工作流程的工具。 高度的自动化和对复杂性的抽象使得Kubernetes和Kubernetes Operator 特别适合运行MongoDB作为服务，无论是为内部用户还是外部客户。
Kubernetes允许MongoDB利用Kubernetes提供的可扩展性和自动韧性，例如自动替换构成副本集或分片集群的丢失 Pod。 这使得MongoDB在Kubernetes中运行时具有高度可扩展的和弹性。
MongoDB在Kubernetes中的可扩展的如何？
Kubernetes中的MongoDB与裸机或虚拟机上的MongoDB一样可扩展的。 对于许多客户来说，在Kubernetes中更容易实现可扩展性。 Kubernetes Operator 和Kubernetes无缝协作，启用轻松实现水平扩展，包括跨多个能力集群部署MongoDB ，Kubernetes实现多集群和多站点韧性。
垂直扩展就像在定义部署的自定义资源中更改部署的资源一样简单。
所有这些使MongoDB能够扩展以满足任何需求。
在Kubernetes中运行MongoDB有什么缺点吗？
从技术角度来看没有缺点。 Kubernetes中的MongoDB与在任何硬件或基础架构上运行的MongoDB一样具有性能和可扩展的。
但是，与任何基础架构一样，客户必须熟悉并拥有相关技术的专业知识，在本例中Kubernetes。 虽然Kubernetes Operator 简化并自动化了设置中MongoDB的设置，但仍然依赖于Kubernetes集群的根本的资源和功能，Kubernetes状态存储、网络、安全和计算等。 这意味着客户仍然需要确保这些服务和资源可用并正确配置以支持MongoDB，就像在裸机或虚拟机上运行一样。
MongoDB Server 部署支持哪些 Kubernetes 平台？
MongoDB Server支持任何基于原生Kubernetes构建的平台，而无需更改默认逻辑或行为。实际上，这意味着MongoDB Server支持任何经 Cloud Native Compute Foundation 认证的Kubernetes平台。要学习；了解更多信息，请参阅MongoDB Kubernetes Operator 兼容性。
MongoDB Enterprise Kubernetes Operator 可以支持多少个部署？
Kubernetes Operator 可以支持数百个部署。 为了促进并行协调操作并避免延长协调时间，请增加Kubernetes Operator实例的线程数。
我是否应该在 Kubernetes 中与使用 MongoDB Server 的应用程序在同一集群中运行？
为了帮助最大限度地减少延迟，如果您的部署架构允许，请考虑将数据库和应用程序并置在同一个 Kubernetes 集群上。
我是否可以跨多个 Kubernetes 集群部署 MongoDB Server？
是的。 要了解更多信息，请参阅在多个 Kubernetes 集群上部署 MongoDB 资源。 如需帮助，请联系MongoDB 支持部门。
使用 Kubernetes Operator 管理多 Kubernetes 集群 MongoDB 部署与管理单个 Kubernetes 集群有什么区别？
要使用Kubernetes Operator 管理多 Kubernetes集群MongoDB 部署，您必须设立一设立特定的Kubernetes角色、ClusterRoles、RoleBindings、ClusterRoleBindings 和 ServiceAccounts。
用于多 Kubernetes 集群 MongoDB 部署的 Kubernetes Operator 还可以协调单个 Kubernetes 集群资源。 要了解更多信息，请参阅MongoDB 是否支持运行多个 Kubernetes Operator 实例？。
MongoDB 是否支持运行多个 Kubernetes 操作符实例？
如果可能，我们建议您设立单个Kubernetes Operator实例来监视Kubernetes集群中的一个、多个或所有命名空间。默认下， Kubernetes Operator 会监控您选择部署的所有自定义资源类型，您无需将其配置为监控特定资源类型。
但是，一旦达到单个 Kubernetes 操作符实例可以支持的部署数量的性能限制，您可以设置额外的 Kubernetes 操作符实例。此时，请考虑如何划分 Kubernetes 集群中的资源管理。 使用按优先级顺序列出的以下建议：
确保每个 Kubernetes 操作符实例都监视 Kubernetes 集群内不同且不重叠的命名空间。
或者，配置 Kubernetes 操作符的不同实例以监控不同命名空间或重叠命名空间中的不同资源类型。
如果您选择使用重叠的命名空间，请确保每个 Kubernetes 操作符实例监视不同类型的资源，以避免导致两个 Kubernetes 操作符实例尝试托管相同资源的冲突。
注意
在配置另一个 Kubernetes 操作符实例之前，请验证现有 Kubernetes 操作符实例的命名空间子集中是否包含其任何命名空间。