Considerations

部署多个MongoDB副本集

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

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

指定 CPU 和内存资源要求

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

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

• request表示资源的下限。

• limit表示资源的上限。

以下部分说明如何：

• 为 操作符 Pod 设置 CPU 和内存。

• 为 MongoDB Pod 设置 CPU 和内存。

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

考虑推荐的存储实践

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

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

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

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

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

使用静态容器（公共预览版）

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

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

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

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

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

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

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

要学习；了解更多信息，请参阅静态容器（公共预览版）。

将mongos Pod 与应用程序共置一地

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

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

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

要指定 Pod 关联性，请执行以下操作：

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

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

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
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 部署的关联性和多区域配置示例。

根据其用途为 MongoDB 服务命名

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

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

使用标签区分部署

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

• 分隔不同的 MongoDB 资源，例如test 、 staging和production环境。

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

1
mongosPodSpec:
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 监视的 CustomResourceDefinitions

您可以指定希望 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 部署的每个副本集的配置进行以下更改：

• 验证是否在spec.persistent中启用了持久卷。 此设置默认为true 。

• 为 Kubernetes 操作符指定足够的存储量，以便为每个卷分配。卷存储数据和日志。

  • 要设置多个卷，每个卷用于数据、日志和oplog ，请使用spec.podSpec.persistence.multiple.data 。

  • 要设置单个卷来存储数据、日志和oplog ，请使用spec.podSpec.persistence.single 。

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

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-cluster
5
spec:
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 操作符 Pod 设置 CPU 和内存利用率边界

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

对于生产部署，为了满足与 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 的配置文件中使用较小的数字。

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
 name: mongodb-enterprise-operator
5
 namespace: mongodb
6
spec:
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 文件。

为 MongoDB Pod 设置 CPU 和内存利用率边界

托管副本集或分片集群的 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 和内存限制。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
name: my-replica-set
5
spec:
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 和内存限制配置示例，用于：

• 一个分片集群，位于 sharded-cluster-podspec.yaml 中。

• 独立运行MongoDB部署，位于 standalone-podspec.yaml 中。

使用多个可用区

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

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

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
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-az1或e2e-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资源使用情况，并在必要时调整各自的资源分配。