Considerations

部署多个MongoDB副本集

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

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

指定 CPU 和内存资源要求

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

为了指示资源边界， Kubernetes使用 requests 和 limit 参数，其中：

• 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 与应用程序共置一地

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

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

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

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

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

2. 指定 mongos 在 spec.mongosPodSpec.podAffinity .requiredDuringSchedulingIgnoredDuringExecution.labelSelector YAML 集合中使用的标签。matchExpressions 集合定义了 Kubernetes 操作符用于识别托管 mongos 的 Pod 的 label。

1apiVersion: mongodb.com/v12kind: MongoDB3metadata:4  name: my-replica-set5spec:6  members: 37  version: 8.0.08  service: my-service9
10  ...11    podTemplate:12      spec:13        affinity:14          podAffinity:15            requiredDuringSchedulingIgnoredDuringExecution:16              - labelSelector:17                  matchExpressions:18                    - key: security19                      operator: In20                      values:21                        - S122                topologyKey: failure-domain.beta.kubernetes.io/zone23          nodeAffinity:24            requiredDuringSchedulingIgnoredDuringExecution:25              nodeSelectorTerms:26                - matchExpressions:27                    - key: kubernetes.io/e2e-az-name28                      operator: In29                      values:30                        - e2e-az131                        - e2e-az232          podAntiAffinity:33            requiredDuringSchedulingIgnoredDuringExecution:34            - podAffinityTerm:35                topologyKey: nodeId

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

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

根据其用途为 MongoDB 服务命名

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

1apiVersion: mongodb.com/v12kind: MongoDB3metadata:4  name: my-replica-set5spec:6  members: 37  version: "8.0.0"8  service: drilling-pumps-geosensors9  featureCompatibilityVersion: "8.0"

使用标签区分部署

使用Pod 关联性 Kubernetes功能可以：

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

• 将Pod放在某些特定节点上，以利用固态硬盘支持等功能。

1mongosPodSpec:2  podAffinity:3    requiredDuringSchedulingIgnoredDuringExecution:4      - labelSelector:5        matchExpressions:6        - key: security7          operator: In8          values:9          - S110        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/mongodb-kubernetes \  --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 。

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

1apiVersion: mongodb.com/v12kind: MongoDB3metadata:4  name: my-replica-cluster5spec:6
7  ...8  persistent: true9
10
11  shardPodSpec:12  ...13    persistence:14      multiple:15        data:16          storage: "20Gi"17        logs:18          storage: "4Gi"19          storageClass: standard

有关持久卷配置的完整示例，请参阅持久卷样本目录中的 replica-set-persistent-volumes.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 的配置文件中使用较小的数字。

1apiVersion: apps/v12kind: Deployment3metadata:4 name: mongodb-kubernetes-operator5 namespace: mongodb6spec:7 replicas: 18 selector:9  matchLabels:10     app.kubernetes.io/component: controller11     app.kubernetes.io/name: mongodb-kubernetes-operator12     app.kubernetes.io/instance: mongodb-kubernetes-operator13 template:14  metadata:15   labels:16     app.kubernetes.io/component: controller17     app.kubernetes.io/name: mongodb-kubernetes-operator18     app.kubernetes.io/instance: mongodb-kubernetes-operator19   spec:20     serviceAccountName: mongodb-kubernetes-operator21     securityContext:22       runAsNonRoot: true23       runAsUser: 200024     containers:25     - name: mongodb-kubernetes-operator26       image: quay.io/mongodb/mongodb-kubernetes-operator:1.9.227       imagePullPolicy: Always28       args:29        - "-watch-resource=mongodb"30        - "-watch-resource=opsmanagers"31        - "-watch-resource=mongodbusers"32       command:33        - "/usr/local/bin/mongodb-kubernetes-operator"34       resources:35         limits:36           cpu: 1100m37           memory: 1Gi38         requests:39           cpu: 500m40           memory: 200Mi

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

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

托管副本集或分片的集群的 Pod 的值映射到所创建 Pod 的 CPU 和内存的requests字段。这些值与针对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/v12kind: MongoDB3metadata:4name: my-replica-set5spec:6  members: 37  version: 8.0.08  service: my-service9  ...10
11  persistent: true12  podSpec:13    podTemplate:14      spec:15        containers:16        - name: mongodb-enterprise-database17          resources:18            limits:19              cpu: "0.25"20              memory: 512M

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

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

• sharded-cluster-podspec.yaml 中的分片集群。

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

使用多个可用区

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

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

1apiVersion: mongodb.com/v12kind: MongoDB3metadata:4  name: my-replica-set5spec:6  members: 37  version: 8.0.08  service: my-service9  ...10    podAntiAffinityTopologyKey: nodeId11    podAffinity:12      requiredDuringSchedulingIgnoredDuringExecution:13      - labelSelector:14        matchExpressions:15        - key: security16          operator: In17          values:18          - S119        topologyKey: failure-domain.beta.kubernetes.io/zone20
21    nodeAffinity:22       requiredDuringSchedulingIgnoredDuringExecution:23         nodeSelectorTerms:24         - matchExpressions:25           - key: kubernetes.io/e2e-az-name26           operator: In27           values:28           - e2e-az129           - e2e-az2

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

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

此目录还包含分片集群和独立运行的实例 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资源使用情况，并在必要时调整各自的资源分配。