Docs 菜单
Docs 主页
/
MongoDB Enterprise Kubernetes Operator
/ /

Considerations

在此页面上

  • 部署多个MongoDB副本集
  • 指定 CPU 和内存资源要求
  • 考虑推荐的存储实践
  • 使用静态容器(公共预览版)
  • mongos Pod 与您的应用程序共置一地
  • 根据其用途为 MongoDB 服务命名
  • 使用标签区分部署
  • 自定义 Kubernetes Operator 监视的 CustomResourceDefinitions
  • 确保正确的持久性配置
  • 为 Kubernetes 操作符 Pod 设置 CPU 和内存利用率边界
  • 为 MongoDB Pod 设置 CPU 和内存利用率边界
  • 使用多个可用区
  • 增加线程数以并行运行多个调节进程

本页详细介绍了 MongoDB Enterprise Kubernetes Operator 在生产环境中运行时的最佳实践和系统配置建议。

我们建议您使用Kubernetes Operator 的单个实例来部署和管理MongoDB副本集。

要并行部署超过10个MongoDB副本集,您可以增加Kubernetes Operator实例的线程数。

注意

以下注意事项适用:

  • 本节中通过 Kubernetes Operator 进行常见 MongoDB 部署的所有大小调整和性能建议均可能更改。 请勿将这些建议视为任何类型的保证或限制。

  • 这些建议反映了性能测试结果,也是我们对生产部署的建议。 我们在一个集群上运行了测试,该集群由七个类型为 t2.2xlarge的 AWS EC2 实例和一个类型为t2.medium的主节点组成。

  • 本节中的建议不讨论任何特定部署的特征。 您的部署特征可能与创建这些建议时所做的假设不同。 请联系MongoDB支持部门以获取有关大小调整的更多帮助。

在Kubernetes中,每个 Pod 都包含允许您指定 CPU 资源 的参数 内存资源 Pod 中的每个容器。

为了指示资源边界,Kubernetes 使用 请求和限制 参数,其中:

  • request表示资源的下限。

  • limit表示资源的上限。

以下部分说明如何:

对于托管 的MongoDB Ops Manager Pod,请使用 默认资源限制配置。

以下建议适用于MongoDB MongoDB Ops ManagerOperator托管的 部署和Kubernetes 应用程序数据库部署。

注意

  • 存储类不需要冗余,因为MongoDB会自动在副本集或分片的成员之间复制数据。

  • 您不能在副本集或分片的成员之间股票存储。

  • 根据您的限制,使用可提供最佳性能的存储类。 请参阅扩展部署以学习;了解更多信息。

  • 配置 ReadWriteOnce持久卷 支持存储类的 。

  • 在工作线程节点级别,应用Linux上MongoDB的最佳实践。

  • 确保使用支持 卷扩展 的存储类 以启用数据库卷大小调整。

静态容器比非静态容器更简单、更安全。 静态容器在运行时是不可变的,这意味着它们不会从用于创建容器的映像中更改。 此外:

  • 运行时,静态容器不会通过网络连接下载二进制文件或运行脚本或其他实用程序。 静态容器仅下载运行时配置文件。

  • 运行时,静态容器不会修改除存储卷挂载之外的任何文件。

  • 您可以对容器映像运行安全扫描,以确定实际运行的容器,并且运行的容器不会运行映像中定义以外的二进制文件。

  • 静态容器不要求您在MongoDB MongoDB Ops Manager或其他 HTTPS 服务器上托管 二进制文件,如果您有气隙环境,这一点尤其有用。

  • 您无法为静态容器运行大量CMD脚本。

  • 您无法使用initContainer在静态容器之间复制文件。

要学习;了解更多信息,请参阅静态容器(公共预览版)。

您可以在同一mongos 节点 上运行轻量级 实例 作为使用 MongoDB 的应用程序。Kubernetes Operator 支持标准 Kubernetes 节点关联和反关联 功能。利用这些功能,您可以在与应用程序相同的节点上强制安装mongos

以下简短示例显示了关联性和多个可用区配置。

podAffinity键确定是否将应用程序安装在与其他应用程序相同的 Pod、节点或数据中心上。

要指定 Pod 关联性,请执行以下操作:

  1. spec.podSpec.podTemplate.metadata.labels YAML集合中添加标签和值以标签部署。 请参阅spec.podSpec.podTemplate.metadataKubernetes PodSpec v1Core API 。

  2. 指定mongosspec.mongosPodSpec.podAffinity .requiredDuringSchedulingIgnoredDuringExecution.labelSelector YAML collection中使用的标签。matchExpressionscollection定义了label Kubernetes 操作符用来识别托管mongos

例子

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4 name: my-replica-set
5spec:
6 members: 3
7 version: 4.2.1-ent
8 service: my-service
9
10 ...
11 podTemplate:
12 spec:
13 affinity:
14 podAffinity:
15 requiredDuringSchedulingIgnoredDuringExecution:
16 - labelSelector:
17 matchExpressions:
18 - key: security
19 operator: In
20 values:
21 - S1
22 topologyKey: failure-domain.beta.kubernetes.io/zone
23 nodeAffinity:
24 requiredDuringSchedulingIgnoredDuringExecution:
25 nodeSelectorTerms:
26 - matchExpressions:
27 - key: kubernetes.io/e2e-az-name
28 operator: In
29 values:
30 - e2e-az1
31 - e2e-az2
32 podAntiAffinity:
33 requiredDuringSchedulingIgnoredDuringExecution:
34 - podAffinityTerm:
35 topologyKey: nodeId

请参阅 replica-set-affinity.yaml 中的多个可用区和节点关联性配置的完整示例 在 Affinity Samples 目录。

此目录还包含分片集群和独立运行的实例 MongoDB 部署的关联性和多区域配置示例。

提示

另请参阅:

spec.service参数设置为标识此部署用途的值,如以下示例所示。

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4 name: my-replica-set
5spec:
6 members: 3
7 version: "6.0.0-ent"
8 service: drilling-pumps-geosensors
9 featureCompatibilityVersion: "4.0"

提示

另请参阅:

使用 Pod 关联性 Kubernetes具有以下功能:

  • 分隔不同的 MongoDB 资源,例如teststagingproduction环境。

  • 放置 Pod 在某些特定节点上,以利用 SSD 支持等功能。

1mongosPodSpec:
2 podAffinity:
3 requiredDuringSchedulingIgnoredDuringExecution:
4 - labelSelector:
5 matchExpressions:
6 - key: security
7 operator: In
8 values:
9 - S1
10 topologyKey: failure-domain.beta.kubernetes.io/zone

提示

另请参阅:

您可以指定希望 Kubernetes Operator 监视哪些自定义资源。 这样,您就可以仅为希望 Kubernetes 操作符托管的资源安装 CustomResourceDefinition。

您必须使用helm将 Kubernetes Operator 配置为仅监视您指定的自定义资源。 按照相关的helm安装说明进行操作,但进行以下调整:

  1. 决定要安装哪个 CustomResourceDefinition。 您可以安装任意数量的以下内容:

    说明
    mongodb
    安装数据库资源的 CustomResourceDefinitions 并监视这些资源。
    mongodbusers
    为 MongoDB 用户资源安装 CustomResourceDefinitions 并监视这些资源。
    opsmanagers
    安装 Ops Manager 的 CustomResourceDefinitions 并监视这些资源。
  2. 安装 Helm Chart 并指定您希望 Kubernetes 操作符 监视的 CustomResourceDefinition。

    用逗号分隔每个自定义资源:

    helm install <deployment-name> mongodb/enterprise-operator \
    --set operator.watchedResources="{mongodb,mongodbusers}" \
    --skip-crds

Kubernetes Operator 编排的 Kubernetes 部署是有状态的。 Kubernetes 容器使用 持久卷 在两次重启之间保持集群状态。

为了满足有状态要求,Kubernetes Operator 执行以下操作:

  • 创建 持久卷 用于MongoDB 部署。

  • 将存储设备挂载到一个或多个称为挂载点的目录。

  • 为每个 MongoDB 挂载点创建一个持久卷。

  • 将每个 Kubernetes container中的默认路径设置为/data

为了满足 MongoDB 集群的存储需求,请对使用 Kubernetes Operator 部署的每个副本集的配置进行以下更改:

以下简短示例显示了建议的持久存储大小。

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4 name: my-replica-cluster
5spec:
6
7 ...
8 persistent: true
9
10
11 shardPodSpec:
12 ...
13 persistence:
14 multiple:
15 data:
16 storage: "20Gi"
17 logs:
18 storage: "4Gi"
19 storageClass: standard

有关持久卷配置的完整示例,请参阅 副本集持久卷.yaml 持久卷样本 中 目录。此目录还包含分片的和独立运行运行部署的持久卷配置示例。

使用Kubernetes Operator部署MongoDB副本集时,初始协调进程会增加运行Kubernetes Operator 的 Pod 的 CPU 使用率。 但是,当副本集部署进程完成后, Kubernetes Operator 的 CPU 使用率会大幅降低。

注意

Kubernetes Operator 中 CPU 使用量峰值的严重性直接受Kubernetes Operator线程数的Kubernetes,因为线程数(由MDB_MAX_CONCURRENT_RECONCILES值定义)等于可以在任何给定时间并行运行的调节进程数。时间。

对于生产部署,为了满足与 Kubernetes 操作符并行部署最多 50 个 MongoDB 副本集或分片集群的需求,请为 Kubernetes 操作符 Pod 设置 CPU 和内存资源及限制,如下所示:

  • spec.template.spec.containers.resources.requests.cpu 至 500m

  • spec.template.spec.containers.resources.limits.cpu 至 1100m

  • spec.template.spec.containers.resources.requests.memory 至 200Mi

  • spec.template.spec.containers.resources.limits.memory 至 1Gi

如果使用 Helm部署资源,请在values.yaml文件中定义这些值。

以下简短示例显示了在 50 个副本集或分片集群部署中 Kubernetes 操作符 Pod 的建议 CPU 和内存边界配置。如果您部署的 MongoDB 集群少于 50 个,则可以在 Kubernetes 操作符 Pod 的配置文件中使用较小的数字。

例子

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4 name: mongodb-enterprise-operator
5 namespace: mongodb
6spec:
7 replicas: 1
8 selector:
9 matchLabels:
10 app.kubernetes.io/component: controller
11 app.kubernetes.io/name: mongodb-enterprise-operator
12 app.kubernetes.io/instance: mongodb-enterprise-operator
13 template:
14 metadata:
15 labels:
16 app.kubernetes.io/component: controller
17 app.kubernetes.io/name: mongodb-enterprise-operator
18 app.kubernetes.io/instance: mongodb-enterprise-operator
19 spec:
20 serviceAccountName: mongodb-enterprise-operator
21 securityContext:
22 runAsNonRoot: true
23 runAsUser: 2000
24 containers:
25 - name: mongodb-enterprise-operator
26 image: quay.io/mongodb/mongodb-enterprise-operator:1.9.2
27 imagePullPolicy: Always
28 args:
29 - "-watch-resource=mongodb"
30 - "-watch-resource=opsmanagers"
31 - "-watch-resource=mongodbusers"
32 command:
33 - "/usr/local/bin/mongodb-enterprise-operator"
34 resources:
35 limits:
36 cpu: 1100m
37 memory: 1Gi
38 requests:
39 cpu: 500m
40 memory: 200Mi

有关Kubernetes Operator Pod 满足并行部署最多50 个MongoDB副本集的 CPU 和内存利用率资源和限制的完整示例,请参阅 mongodb-enterprise.yaml 文件。

托管副本集或分片集群的 Pod 的值映射到 requests 字段 用于创建 Pod 的 CPU 和内存。这些值与针对 MongoDB 主机所述的注意事项一致。

Kubernetes Operator 使用分配的内存进行处理、WiredTiger 缓存以及在部署期间存储包。

对于生产部署,请按如下方式设置 MongoDB Pod 的 CPU 和内存资源及限制:

  • spec.podSpec.podTemplate.spec.containers.resources.requests.cpu 至 0.25

  • spec.podSpec.podTemplate.spec.containers.resources.limits.cpu 至 0.25

  • spec.podSpec.podTemplate.spec.containers.resources.requests.memory 至 512M

  • spec.podSpec.podTemplate.spec.containers.resources.limits.memory 至 512M

如果使用 Helm部署资源,请在values.yaml文件中定义这些值。

以下简短示例显示了部署中托管 MongoDB 副本集成员的每个 Pod 的配置以及建议的 CPU 和内存限制。

例子

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4name: my-replica-set
5spec:
6 members: 3
7 version: 4.0.0-ent
8 service: my-service
9 ...
10
11 persistent: true
12 podSpec:
13 podTemplate:
14 spec:
15 containers:
16 - name: mongodb-enterprise-database
17 resources:
18 limits:
19 cpu: "0.25"
20 memory: 512M

有关托管 MongoDB 副本集成员的 Pod 的 CPU 和内存利用率资源和限制的完整示例,请参阅 replica-set-podspec.yaml MongoDB Podspec 样本 中的文件 目录。

此目录还包含 Pod 的 CPU 和内存限制配置示例,用于:

设置Kubernetes Operator 和 statefulSet 将一个副本集的所有成员分布到不同 节点 以确保高可用性。

以下简短示例显示了关联性和多个可用区配置。

例子

1apiVersion: mongodb.com/v1
2kind: MongoDB
3metadata:
4 name: my-replica-set
5spec:
6 members: 3
7 version: 4.2.1-ent
8 service: my-service
9 ...
10 podAntiAffinityTopologyKey: nodeId
11 podAffinity:
12 requiredDuringSchedulingIgnoredDuringExecution:
13 - labelSelector:
14 matchExpressions:
15 - key: security
16 operator: In
17 values:
18 - S1
19 topologyKey: failure-domain.beta.kubernetes.io/zone
20
21 nodeAffinity:
22 requiredDuringSchedulingIgnoredDuringExecution:
23 nodeSelectorTerms:
24 - matchExpressions:
25 - key: kubernetes.io/e2e-az-name
26 operator: In
27 values:
28 - e2e-az1
29 - e2e-az2

在此示例中,Kubernetes Operator 将 Pod 部署安排到e2e-az1e2e-az2可用区中具有标签kubernetes.io/e2e-az-name的节点。 更改nodeAffinity以安排将 Pod 部署到所需的区域。

请参阅 replica-set-affinity.yaml 中的多个可用区配置的完整示例 在 Affinity Samples 目录。

此目录还包含分片集群和独立运行的实例 MongoDB 部署的关联性和多区域配置示例。

如果计划并行部署超过10个MongoDB副本集,则可以通过在Kubernetes Operator部署中设置MDB_MAX_CONCURRENT_RECONCILES环境变量,或通过 .maxConcurrentReconciles 操作操作符,将Kubernetes Operator 配置为并行运行多个协调进程。 字段以配置更高的values.yaml文件。

增加Kubernetes Operator 的线程数可让您将Kubernetes Operator部署垂直扩展为Kubernetes集群内运行的数百个MongoDB资源,并优化 CPU 利用率。

请监控Kubernetes API 服务器和Kubernetes Operator资源使用情况,并在必要时调整各自的资源分配。

注意

  • MDB_MAX_CONCURRENT_RECONCILES 增加到超过10时,请务必谨慎。 特别是,您必须密切监控Kubernetes Operator 和Kubernetes API ,以避免因这些组件的负载增加而导致停机。

    要确定适合部署需求的线程数,请遵循以下准则:

    • 您对Kubernetes Operator 在协调大量资源时的响应速度的要求

    • Kubernetes环境中可用的计算资源以及Kubernetes计算资源承受的总处理负载,包括可能与MongoDB无关的资源

  • 在增加单个Kubernetes Operator实例的线程数的同时,增加Kubernetes集群中可支持的MongoDB资源数量的另一种方法是在Kubernetes集群中部署多个Kubernetes Operator 实例。 但是,部署多个Kubernetes Operator 实例需要确保没有两个Kubernetes Operator 实例监控相同的MongoDB资源。

    运行多个Kubernetes Operator实例时应小心谨慎,因为更多Kubernetes Operator 实例(尤其是启用了并行协调功能的情况下)会使API 服务器面临更大的过载风险。

  • Kubernetes API服务器的扩展不是运行多个Kubernetes Operator实例的正当理由。 如果您发现API 服务器的性能受到影响,则添加更多Kubernetes Operator 实例可能会使问题变得更加复杂。

后退

设置部署范围