Considerations

部署建议数量的 MongoDB 副本集

我们建议您使用 Kubernetes Operator 的单个实例并行部署最多 20 个副本集。

您可以将此数字增加到 50，并预期 Kubernetes 操作符 下载、安装、部署和协调其资源所需的时间会合理增加。

对于 50 个副本集，部署时间各不相同，最长可能需要 40 分钟。 该时间取决于 Kubernetes 集群的网络带宽以及每个 MongoDB 助手从互联网上为每个 MongoDB 集群节点下载 MongoDB 安装二进制文件所需的时间。

要并行部署 50 个以上的 MongoDB 副本集，请使用 Kubernetes 操作符的多个实例。

指定 CPU 和内存资源要求

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

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

• request表示资源的下限。

• limit表示资源的上限。

以下部分说明如何：

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

• 为 MongoDB Pod 设置 CPU 和内存。

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

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

静态容器比非静态容器更安全、更简单。 静态容器在运行时是不可变的。 此外：

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

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

• 静态容器不要求扫描容器中的安全漏洞，而非静态容器则需要容器安全扫描。 如果使用静态容器，则只能对容器映像本身运行安全扫描，而不能对其容器运行安全扫描。

• 如果您有气隙环境，则静态容器不要求您在托管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 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

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

此目录还包含分片集群和独立运行的实例 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: "4.4.0-ent"
8
  service: drilling-pumps-geosensors
9
  featureCompatibilityVersion: "4.0"

使用标签区分部署

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

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

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

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

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

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

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

使用多个可用区

设置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 部署到所需的区域。

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

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