/ /

配置MongoDB自定义资源

MongoDB自定义资源是您通过Kubernetes Operator 定义和管理MongoDB部署的主节点 (primary node in the replica set)方式。您无需直接配置MongoDB实例，而是在 YAML 清单中声明所需的状态，然后操作符会协调集群的实际状态以进行匹配。本指南将引导您了解该清单的概念构建基块，不仅帮助您了解每个配置区域的作用，还帮助您在规划适合团队要求的部署时，为什么以及何时需要它。

无论您是首次建立开发副本集，还是迭代生产分片集群，此处概述的决策都是在Kubernetes上MongoDB 部署的基础。

有关完整的字段规范，请参阅MongoDB数据库资源规范。

选择部署类型

您需要做的第一个决定是创建哪种类型的MongoDB 部署。 spec.type字段接受三个值，每个值针对一设立不同的工作负载和操作要求。在写入任何 YAML 行之前，了解它们之间的权衡至关重要。

独立实例运行单个 mongod进程。它们最适合本地开发、测试场景或评估不考虑冗余的功能。由于独立运行部署没有复制，因此不支持自动故障转移，不建议用于生产数据。

副本集是MongoDB的默认生产拓扑结构。副本集由多个mongod 成员（通常为三个或更多）组成，这些成员维护相同的数据副本。如果主节点 (primary node in the replica set)节点发生故障，幸存的节点会选举新的主节点 (primary node in the replica set)，而无需人工干预。选择副本集可为您提供高可用性、通过从节点(secondary node from replica set)读取实现的读取可扩展性以及执行滚动维护的能力。对于大多数团队来说，可以从这里开始：

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-replica-set
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

分片集群将数据分发到多个分片，每个分片本身就是一个副本集。分片前面有用于引导客户端流量的mongos 路由器，以及用于存储集群元数据的专用配置服务器副本集。如果数据集的增长超出了单个副本集可以有效提供服务的范围，或者您需要水平扩展写入，那么分片集群是正确的选择。此配置较为复杂，因为您必须指定分片计数、每个分片的mongod 个实例、mongos 个路由器和配置服务器：

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  type: ShardedCluster
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

有关每种部署类型的每个字段的完整详细信息，请参阅规范参考中的“独立运行”、“副本集”和“分片集群”部分。

连接到Ops Manager

每个MongoDB自定义资源都必须链接到一个Ops Manager项目。 Kubernetes Operator 就是通过这种连接来注册您的部署以进行监控、自动化和备份的。有两项配置使连接正常运行：标识项目的 ConfigMap 和存储API凭证的密钥。

ConfigMap 告知Kubernetes Operator 将部署在哪个Ops Manager项目中。它至少必须包含一个 projectName 和一个指向Ops Manager实例的baseUrl。或者，您可以使用 orgId 将部署固定到特定组织：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-project-configmap
data:
  projectName: "MyKubernetesProject"
  baseUrl: "https://ops-manager.example.com"
  orgId: "5e8f8b8b8b8b8b8b8b8b8b8b"

该密钥包含Kubernetes Operator 用来代表您向Ops Manager API进行身份验证的编程API密钥对：

kubectl create secret generic my-credentials \
  --from-literal="publicKey=<public-api-key>" \
  --from-literal="privateKey=<private-api-key>"

然后，您可以在MongoDB CR 中引用两者：

spec:
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials

MongoDB版本和功能兼容性

spec.version字段设置Kubernetes Operator 部署的MongoDB服务器版本（示例，"8.0.0"）。选择正确的版本不仅仅是为了获得最新的功能。您还应考虑驾驶员程序库的版本兼容性矩阵、正在运行的Ops Manager版本以及团队的升级节奏。

在主要版本之间升级时，featureCompatibilityVersion (FCV)字段可为您提供安全网。 FCV控制哪些存储引擎和复制功能处于活动状态，并且可以将其设立为低于二进制版本本身。这样，您可以先升级二进制文件，验证稳定性，然后通过单独的深思熟虑的步骤提高FCV以解锁新功能。如果需要回滚，较低的FCV可确保数据文件与之前的二进制版本保持兼容。

spec:
  version: "8.0.0"
  featureCompatibilityVersion: "7.0"

作为参考，请参阅规范中的spec.version 和spec.featureCompatibilityVersion 。

保护部署

Kubernetes中MongoDB 部署的安全性有两个方面：使用 TLS 加密网络流量，以及对客户端和集群成员进行身份验证。两者都在 spec.security区块下进行配置，了解它们如何交互对于获得安全且功能齐全的部署至关重要。

使用 TLS 加密连接

TLS加密可保护客户端和MongoDB服务器之间以及副本集成员之间传输的数据。当您启用TLS 时， Kubernetes Operator 需要一个包含服务器证书和私钥的密钥，以及一个（可选）带有对其进行签名的 CA 证书的 ConfigMap。

certsSecretPrefix字段告知Kubernetes Operator 如何派生证书密钥的名称。如果您将前缀设立为 mdb 且部署名为 my-replica-set，则Kubernetes Operator 会查找名为 mdb-my-replica-set-cert 的密钥。这种命名约定可避免多个部署股票命名空间时发生冲突，如以下示例所示：

spec:
  security:
    certsSecretPrefix: "mdb"
    tls:
      enabled: true
      ca: "custom-ca-configmap"

如果使用默认MongoDB CA，则可以省略ca 字段。否则，请将 CA 证书上传到 ConfigMap 并在此处引用。要学习；了解有关在Kubernetes中为MongoDB生成和管理 TLS 证书的更多信息（包括cert-manager 集成），请参阅配置加密和设置证书管理器集成。

选择身份验证机制

除了加密之外，您还需要决定客户端如何证明其身份。操作符支持四种身份验证模式，并且您可以同时启用多种身份验证模式：

SCRAM （Salted 挑战响应身份验证机制）的设立最简单。用户使用用户名和密码进行身份验证。它非常适合通过环境变量注入或Kubernetes密钥管理凭证的应用程序，并且不需要 PKI 基础架构。
X.509 使用 TLS客户端证书作为身份证明。如果您已经拥有证书基础架构并希望完全避免使用基于密码的凭证，这是一个不错的选择。它需要启用 TLS。
LDAP将身份验证委托给外部目录服务，非常适合集中管理用户身份的组织。此模式需要网络可访问的LDAP服务器和绑定档案。
OIDC (OpenID Connect) 与Azure AD、Okta 或 Google 等身份提供商集成，以进行基于令牌的身份验证。这是最现代的方法，非常适合云环境中的工作负载身份模式。

您可以在 spec.security.authentication 下配置身份验证：

spec:
  security:
    tls:
      enabled: true
    authentication:
      enabled: true
      modes: ["SCRAM", "X509"]
      internalCluster: "X509"

internalCluster字段控制副本集成员如何相互进行身份验证。将其设置为 "X509" 意味着节点到节点的流量使用 X.509 证书，即使客户端使用SCRAM进行身份验证也是如此。

有关详细的身份验证设置过程，请参阅启用身份验证。

存储和持久性

MongoDB是一种有状态的工作负载，存储配置方式会直接影响性能、持久性以及从故障中恢复的能力。对于任何不可接受数据丢失的环境（实际上是一次性测试之外的所有环境），spec.persistent字段必须设立为 true。启用持久性后， Kubernetes Operator 会创建在 Pod 重新启动和重新计划后仍然有效的 PersistentVolumeClaims (PVC)。

单个卷与多个卷

默认下， MongoDB为所有数据使用单个卷。这对于开发和许多生产工作负载来说已经足够了，但一些团队受益于将数据、日志和日志放在不同的卷上。将它们分开可以让您为性能关键路径（例如预写日志）分配更快的存储类，同时为日志使用更便宜的存储，如以下示例所示：

spec:
  podSpec:
    persistence:
      multiple:
        data:
          storage: "200Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "50Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "20Gi"
          storageClass: "standard"

如果单个卷就足够，配置会更简单：

spec:
  podSpec:
    persistence:
      single:
        storage: "100Gi"
        storageClass: "standard"

深思熟虑地选择存储类对于分片的集群尤其重要，因为其中的每个分片、每个配置服务器和 mongos 路由器都有自己的 Pod 规范 (shardPodSpec、configSrvPodSpec、mongosPodSpec)。这样，您就可以独立地为每个组件设置大小和层级存储。

有关完整的持久性字段设立，请参阅规范参考中的独立设置，其中涵盖spec.podSpec.persistence.single 、spec.podSpec.persistence.multiple.data 和相关字段。

资源分配和 Pod 模板

调整MongoDB Pod 的 CPU 和内存大小是您在部署时做出的最有影响力的决策之一，随着工作负载的发展，您可能会重新考虑这一决策。 Kubernetes Operator 通过 podSpec（对于副本集和独立实例）以及 shardPodSpec、configSrvPodSpec 和 mongosPodSpec（对于分片的集群）公开资源控制。

为 CPU 和内存设置 requests 和 limits 可确保Kubernetes将 Pod 调度到具有足够容量的节点上，并防止失控进程影响同一节点上的其他工作负载。以下示例说明了可以用作点的配置。在此配置中，您创建的生产副本集节点具有至少 2 个 CPU 核心和 4 GiB 内存作为请求，并将限制设立为等于或超过这些值：

spec:
  podSpec:
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "4Gi"
              limits:
                cpu: "4"
                memory: "8Gi"

Pod 模板还允许您设立标签、注解、容忍和关联性规则。关联性规则在生产中尤其重要，因为它们控制副本集成员在Kubernetes节点和故障域之间的分布式方式。

示例，以下关联性规则将成员分布在可用区域中，以防止出现区域级中断：

spec:
  podSpec:
    podTemplate:
      spec:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: my-replica-set
                topologyKey: "topology.kubernetes.io/zone"

有关 podTemplate 字段的完整列表，请参阅规范参考，特别是spec.podSpec.podTemplate.spec.affinity 。

配置备份

Kubernetes Operator 中的备份使用Ops Manager内置的连续备份功能。启用后， Ops Manager会实时捕获oplog并定期拍摄快照，从而为您提供时间点恢复。这意味着您可以恢复到配置的保留窗口内的任何秒，而不仅仅是上次快照的时间戳。

要对MongoDB资源启用备份，请将 spec.backup.mode设立为 enabled。您还可以配置快照安排，控制快照的拍摄频率和保留时间，如以下示例所示：

spec:
  backup:
    mode: enabled
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 24

如果您的组织需要对静态数据备份数据进行加密，则可以与符合 KMIP 的密钥管理服务器集成，如以下示例所示：

spec:
  backup:
    mode: enabled
    encryption:
      kmip:
        client:
          clientCertificatePrefix: "backup-kmip"

autoTerminateOnDeletion 标志控制删除MongoDB资源时是否清除备份数据。在非生产环境中将其设置为 true 以避免孤立备份状态；在生产环境中将其保留为 false，以便备份数据在资源意外删除的情况下仍然存在：

spec:
  backup:
    mode: enabled
    autoTerminateOnDeletion: false

分配标签可让您控制特定部署使用哪些备份基础架构（oplog存储、快照存储），这在多个部署股票单个Ops Manager实例时非常有用。

有关完整的备份设立，请参阅规范参考中的副本集设置。要学习；了解如何部署备份基础架构本身，请参阅配置MongoDB数据库备份。

向外部公开您的部署

默认下，只能在集群内访问Kubernetes中的MongoDB部署。许多团队需要从Kubernetes外部运行的应用程序、开发期间的客户端工具或多区域架构中的不同Kubernetes集群访问权限其数据库。

spec.externalAccess区块指示Kubernetes Operator 创建Kubernetes服务，将外部流量路由到MongoDB Pod。您可以选择 LoadBalancer 服务和 NodePort 服务，前者预配云提供商负载均衡器，后者在每个集群节点上公开静态端口，如以下示例所示：

spec:
  externalAccess:
    externalService:
      spec:
        type: LoadBalancer
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

对于副本集，您可以额外配置 externalDomain 为每个成员分配可预测的 DNS 主机名，从而简化客户端端连接字符串的构造：

spec:
  externalAccess:
    externalDomain: "mongodb.example.com"
    externalService:
      spec:
        type: LoadBalancer

调整MongoDB Server参数

并非每个MongoDB调优设置在自定义资源中都有一流字段。对于Kubernetes Operator 的显式模式中未包含的任何设置，spec.additionalMongodConfig区块允许您传递任意 mongod 配置选项。这些会直接转换为Ops Manager应用的服务器配置。

additionalMongodConfig 的常见用途包括调整WiredTiger缓存大小、限制 TLS协议版本或更改侦听端口，如以下示例所示：

spec:
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 4

在分片集群中，每个组件（分片、配置服务器、 mongos）都有自己的additionalMongodConfig 字段，因此您可以独立调整它们。有关支持选项的完整列表，请参阅MongoDB手册中的MongoDB Server参数。

MongoDB 助手配置

每个MongoDB Pod 都运行一个MongoDB 助手，用于管理 mongod进程、处理自动化任务并向Ops Manager报告运行状况。您可以通过 spec.agent 调整MongoDB 助手行为，包括日志轮换限制和连接超时等初创企业选项，如以下示例所示：

spec:
  agent:
    startupOptions:
      maxLogFiles: "10"
      maxLogFileSize: "100"
      dialTimeout: "20"

spec.logLevel字段设置MongoDB助手的日志详细程度。在初始设置或故障排除期间，DEBUG 的价值可能无法估量；在稳态生产中，INFO 或 WARN 可避免日志量过多：

spec:
  logLevel: "DEBUG"

有关完整的MongoDB 助手相关设置，请参阅规范参考。

多集群部署

对于需要在多个Kubernetes集群分布单个MongoDB 部署的团队，可能是为了实现地理冗余、灾难恢复或数据主权， Kubernetes Operator 支持多集群拓扑结构。将 spec.topology 设置为 MultiCluster 会指示Kubernetes Operator 在 spec.clusterSpecList 中定义的副本集成员位于不同的Kubernetes集群中，如以下示例所示：

spec:
  topology: MultiCluster
  clusterSpecList:
    - clusterName: "cluster-us-east"
      members: 2
    - clusterName: "cluster-us-west"
      members: 2
    - clusterName: "cluster-eu-west"
      members: 1

多集群部署引入了额外的先决条件，包括跨集群网络和服务网格或外部 DNS 配置。在继续之前，查看多集群先决条件和多集群架构。

有关多集群规范字段，请参阅 Multi-Kubernetes-Cluster 规范。

随着时间的推移维护MongoDB自定义资源配置

MongoDB自定义资源不是一次性工件。随着团队需求的发展，您将扩展成员、添加分片、启用备份、轮换 TLS 证书、升级MongoDB版本或调整资源限制。 Kubernetes Operator 专为此目的：更新YAML 清单，应用kubectl apply 应用清单， Kubernetes Operator 会递增地协调更改。

安全迭代的一些准则：

逐步扩展成员。逐个添加或删除副本集成员可降低选举中断的风险。
分两步升级版本。首先对二进制版本进行碰撞，同时将 featureCompatibilityVersion保持在前一个水平，然后在验证稳定性后提高FCV 。
在证书到期前轮换证书。 TLS 证书的生命周期是有限的。规划轮换进程（最好使用cert-manager 实现自动化），并首先在非生产环境中进行测试。
仔细测试存储更改。某些存储更改（例如切换存储类）可能需要手动卷迁移。始终在暂存集群中进行验证。
监控资源状态。进行任何更改后，通过使用 检查资源状态并查看Kuberneteskubectl get mdb Operator 日志是否存在协调错误，验证Kubernetes Operator 是否已成功协调您的更改。

有关修改部署的实践过程，请参阅编辑数据库资源。

放到一起

以下示例将本页介绍的概念组合到一个可用于生产的副本集配置中。它包括 TLS、 SCRAM身份验证、备份、反关联性调度、分割数据/日志/日志卷以及WiredTiger调优：

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: prod-replica-set
  namespace: mongodb-production
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  featureCompatibilityVersion: "8.0"
  opsManager:
    configMapRef:
      name: prod-project-configmap
  credentials: prod-credentials
  persistent: true
  security:
    certsSecretPrefix: "prod-mdb"
    tls:
      enabled: true
      ca: "prod-ca-configmap"
    authentication:
      enabled: true
      modes: ["SCRAM"]
      internalCluster: "X509"
  backup:
    mode: enabled
    autoTerminateOnDeletion: false
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 48
  podSpec:
    persistence:
      multiple:
        data:
          storage: "500Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "100Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "50Gi"
          storageClass: "standard"
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "8Gi"
              limits:
                cpu: "4"
                memory: "16Gi"
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: prod-replica-set
                topologyKey: "topology.kubernetes.io/zone"
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 8

提示

MongoDB数据库资源规范 — 完整的MongoDB CR字段参考
部署副本集 — 分步副本集部署
部署分片集群 — 分分片集群部署
配置加密 — TLS 配置详细信息
启用身份验证 — 身份验证机制
配置MongoDB数据库备份 — 备份过程
从外部Kubernetes连接到MongoDB数据库资源 — 外部访问权限设置
多 Kubernetes 集群资源规范 — 多集群字段引用