Docs 菜单
Docs 主页
/
MongoDB Enterprise Kubernetes Operator

常见问题解答

在此页面上

  • 什么是 Operator?
  • 为何在 Kubernetes 上运行 MongoDB Enterprise Advanced?
  • MongoDB 在 Kubernetes 中的可扩展性如何?
  • 在 Kubernetes 中运行 MongoDB 有什么缺点吗?
  • MongoDB Server 部署支持哪些 Kubernetes 平台?
  • MongoDB Enterprise Kubernetes Operator 可以支持多少个部署?
  • 我是否应该在 Kubernetes 中与使用 MongoDB Server 的应用程序在同一集群中运行?
  • 我是否可以跨多个 Kubernetes 集群部署 MongoDB Server?
  • 使用 Kubernetes Operator 管理多 Kubernetes 集群 MongoDB 部署与管理单个 Kubernetes 集群有什么区别?
  • MongoDB 是否支持运行多个 Kubernetes 操作符实例?

操作符是一种标准机制,可扩展 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 可简化自托管 MongoDB 的设置和管理。

Kubernetes Operator 与 MongoDB 和 Ops Manager配合使用,使用您为定义设置而创建的自定义资源文件来自动执行配置。这样,您就可以使用现有的用于管理 Kubernetes 中应用程序的任何工具来管理配置,包括支持在 Git 存储库中管理配置的 GitOps 工作流程的工具。高度的自动化和对复杂性的抽象使得 Kubernetes 和 Kubernetes Operator 特别适合运行 MongoDB 作为服务,无论是为内部用户还是外部客户。

Kubernetes 允许 MongoDB 利用 Kubernetes 提供的可扩展性和自动弹性,例如自动替换构成副本集或分片集群的丢失 Pod。这使得 MongoDB 在 Kubernetes 中运行时具有高度可扩展性和弹性。

Kubernetes 中的 MongoDB 与裸机或虚拟机上的 MongoDB 一样可扩展。对于许多客户来说,在 Kubernetes 中更容易实现可扩展性。 Kubernetes Operator 和 Kubernetes 无缝协作,可轻松实现水平扩展,包括跨多个 Kubernetes 集群部署 MongoDB,实现多集群和多站点弹性。

垂直扩展就像在定义部署的自定义资源中更改部署的资源一样简单。

所有这些使 MongoDB 能够扩展以满足任何需求。

从技术角度来看没有缺点。 Kubernetes 中的 MongoDB 与在任何硬件或基础架构上运行的 MongoDB 一样具有性能和可扩展性。

但是,与任何基础架构一样,客户必须熟悉并拥有相关技术的专业知识,在本例中是 Kubernetes。虽然 Kubernetes Operator 简化并自动化了 Kubernetes 中 MongoDB 的设置,但仍然依赖于 Kubernetes 集群的底层资源和功能,例如状态存储、网络、安全和计算等。这意味着客户仍然需要确保这些服务和资源可用并正确配置以支持 MongoDB,就像在裸机或虚拟机上运行一样。

MongoDB Server 支持任何基于原生 Kubernetes 构建的平台,而无需更改默认逻辑或行为。实际上,这意味着 MongoDB Server 支持任何 经 Cloud Native Compass 认证的 Kubernetes 平台 。要了解详情,请参阅 MongoDB Kubernetes Operator 兼容性。

Kubernetes Operator 可以支持数百个部署。为了促进并行协调操作并避免延长协调时间,请增加 Kubernetes Operator 实例的线程数。

为了帮助最大限度地减少延迟,如果您的部署架构允许,请考虑将数据库和应用程序并置在同一个 Kubernetes 集群上。

是的。 要了解更多信息,请参阅在多个 Kubernetes 集群上部署 MongoDB 资源。 如需帮助,请联系MongoDB 支持部门

要使用 Kubernetes Operator 管理多 Kubernetes 集群 MongoDB 部署,您必须设置一组特定的 Kubernetes 角色、ClusterRoles RoleBindings、ClusterRoleBindings ServiceAccounts。

用于多 Kubernetes 集群 MongoDB 部署的 Kubernetes Operator 还可以协调单个 Kubernetes 集群资源。 要了解更多信息,请参阅MongoDB 是否支持运行多个 Kubernetes Operator 实例?。

如果可能,我们建议您设置单个 Kubernetes Operator 实例来监视 Kubernetes 集群中的一个、多个或所有命名空间。 默认情况下,Kubernetes Operator 会监控所有 自定义资源 类型,并且无需将其配置为监视特定资源类型。

但是,一旦达到单个 Kubernetes 操作符实例可以支持的部署数量的性能限制,您可以设置额外的 Kubernetes 操作符实例。此时,请考虑如何划分 Kubernetes 集群中的资源管理。 使用按优先级顺序列出的以下建议:

  • 确保每个 Kubernetes 操作符实例都监视 Kubernetes 集群内不同且不重叠的命名空间。

  • 或者,配置 Kubernetes 操作符的不同实例以监控不同命名空间或重叠命名空间中的不同资源类型。

    如果您选择使用重叠的命名空间,请确保每个 Kubernetes 操作符实例监视不同类型的资源,以避免导致两个 Kubernetes 操作符实例尝试托管相同资源的冲突。

注意

在配置另一个 Kubernetes 操作符实例之前,请验证现有 Kubernetes 操作符实例的命名空间子集中是否包含其任何命名空间。

后退

第三方许可