对于 AI 代理：可在 https://www.mongodb.com/zh-cn/docs/llms.txt 获取文档索引—通过在任何 URL 路径后添加 .md 可获取所有页面的 Markdown 版本。
Docs 菜单
Docs 主页
Docs 主页
Docs 主页

规划您的 Ops Manager 资源

MongoDB MongoDB Ops Manager 是一款企业应用程序，用于管理、备份和监控MongoDB部署。借助MongoDB Ops Manager，您可以扩展和升级MongoDB、优化查询、执行时间点恢复、接收性能警报以及监控部署。 要管理和维护MongoDB Ops Manager及其根本的数据库，您可以使用Kubernetes Operator 的MongoDB控制器将MongoDB Ops Manager作为部署在Kubernetes容器中的资源来运行。

您可以通过以下方式之一部署MongoDB Ops Manager资源：

  • 单 Kubernetes 集群模式。 您可以部署单个MongoDB Ops Manager 实例来支持Kubernetes MongoDB资源的单个 集群部署。

  • 多种Kubernetes集群模式。您可以在多个Kubernetes集群中部署多个Ops Manager和应用程序数据库实例。在此模式下， Ops Manager资源的多集群支持在多个Kubernetes集群上部署Ops Manager 应用程序和应用程序数据库。

在单个或多个Kubernetes集群中部署Ops Manager资源之前，查看Ops Manager资源架构和注意事项，并完成先决条件。

架构

有关MongoDB Ops Manager资源架构的详细信息，请参阅：

  • Ops Manager资源的单个Kubernetes集群部署： Ops Manager资源架构。

  • Ops Manager资源的多个Kubernetes集群部署：多集群架构。

MongoDBOpsManager 自定义资源定义

Kubernetes Operator 使用部署该资源的每个Kubernetes集群中的 MongoDBOpsManager 自定义资源 来管理MongoDB Ops Manager部署。Kubernetes Operator 监视资源规范的更改。当规范发生变化时， Kubernetes Operator 会验证这些更改，并对部署MongoDB Ops Manager组件的每个Kubernetes集群中的资源进行适当更新。

MongoDBOpsManager 自定义资源规范定义了以下MongoDB Ops Manager组件：

  • 应用程序数据库

  • MongoDB Ops Manager应用程序

  • 备份守护进程

下图描述了MongoDB Ops Manager部署的相关组件：

  • 在单集群部署中，您可以将这些组件部署在安装 Kubernetes Operator 的同一个 Kubernetes 集群中。 该集群称为“operator 集群”。

  • 在多集群部署中，您可以：

    • 将每个组件部署在不同的 Kubernetes 集群（称为“成员集群”）中。 您还可以使用单个成员 Kubernetes 集群来部署简化的多集群部署。 要了解更多信息，请参阅单集群和多集群模式。

    • 在一个 Kubernetes 集群（称为“operator 集群”）中安装 Kubernetes Operator，Kubernetes Operator 在此集群中管理所有其他成员集群。 Operator 集群也可以被视为成员集群，因为它也可以托管MongoDB Ops Manager组件。 请参阅多集群架构图。

显示 MongoDB Enterprise Kubernetes Operator 的高级架构的图表（单个 Kubernetes 集群）

Ops Manager资源的应用程序数据库

对于应用程序数据库， Kubernetes Operator 将MongoDB副本集部署为 StatefulSet 。

应用程序数据库的每个 Pod 都包含以下容器：

  • mongod.

  • MongoDB Agent 。 要覆盖MongoDB Agent版本，请使用 $AGENT_IMAGE 环境变量或用于安装Kubernetes Operator 的 Helm 图表中的 agent.version。

  • 监控代理。 您无法覆盖监控代理的版本。 Kubernetes Operator 使用的版本确保与MongoDB Ops Manager版本向后兼容。

    要查看监控代理的版本，请执行以下操作：

    • 检查 Pod 内的/usr/local/om_version_mapping.json是否有 Kubernetes Operator，或检查 Kubernetes Operator 的映像。

    • 检查部署应用程序数据库的 Pod 上的监控代理的容器映像。

在多集群部署中（当您将spec.applicationDatabase.topology设置为MultiCluster时），Kubernetes Operator 在为spec.applicationDatabase.clusterSpecList中的应用程序数据库指定的每个 Kubernetes 集群中创建 StatefulSet。

在托管应用程序数据库的 MongoDB 副本集节点的每个 Kubernetes 成员集群中，会发生以下操作：

  • Kubernetes 在 StatefulSet 中为组成应用程序数据库副本集的每个节点创建一个 Pod。 StatefulSet 中的每个 Pod 都运行 mongod 和MongoDB Agent 。

    启用每个MongoDB 助手能够在mongod StatefulSet 中的 Pod 上启动 ，您必须使用 设置为应用程序数据库指定特定的MongoDB Server版本。spec.applicationDatabase.version您在此设置中指定的版本必须与容器注册表中的标签相对应。

  • 每个MongoDB Agent都会在其应用程序数据库 Pod 上启动mongod 。 MongoDB Agent将mongod进程添加到应用程序数据库副本集。

    您可以在 MongoDBOpsManager 自定义资源的 spec.applicationDatabase 集合中配置副本集的副本数和其他配置选项。Kubernetes Operator 使用密钥将此配置传递给MongoDB助手， Kubernetes Operator 将该密钥挂载到应用程序数据库 StatefulSet 中的每个 Pod。

    在多集群应用程序数据库部署中（其中spec.applicationDatabase.topology设置为MultiCluster ），您可以在spec.applicationDatabase.clusterSpecList中为每个成员集群单独指定每个成员集群中的节点数。 在多集群部署中， spec.applicationDatabase中的replicas设置将被忽略。

  • 每次更新spec.applicationDatabasecollection时，Kubernetes Operator 都会将更改应用于 MongoDB Agent 配置和 StatefulSet 规范（如果适用）。如果 StatefulSet 规范发生变化，Kubernetes 会以滚动方式升级 Pod 并重新启动每个 Pod。

  • 为了从托管应用程序数据库的每个Kubernetes集群内提供到每个应用程序数据库 Pod 的连接， Kubernetes 操作符 创建了一项无头服务。在应用程序数据库的多集群部署中， Kubernetes Operator 还会为每个 Pod 创建一个名为 <om_resource_name>-db-N-svc 的服务（这对应于 metadata.name ），并使用其 FQDN （例如 <om_resource_name>-db-0.<namespace>.svc.cluster.local ）作为主机名来连接到特定的 mongod。

  • 根据 StorageClass 或部署Kubernetes Operator 的环境，Kubernetes可能会使用 动态卷预配。 来创建 持久卷 。

    您可以使用 或spec.applicationDatabase.podSpec.persistence.single 为应用程序数据库spec.applicationDatabase.podSpec.persistence.multiple Pod 自定义 持久卷声明 。

应用程序数据库拓扑

要选择主节点，应用程序数据库副本集的大多数节点必须可用。 如果副本集的大多数节点发生故障，则副本集无法形成投票多数来选举主节点。 要了解更多信息，请参阅副本集部署架构。

如果可能，请使用奇数个 Kubernetes 成员集群，并跨数据中心、区域或 Kubernetes 集群分布应用程序数据库节点。 要了解更多信息，请参阅分布在两个或多个数据中心的副本集。

请考虑以下应用程序数据库拓扑示例：

对于有五个成员的应用程序数据库，可能的成员分布包括：

  • 两个集群：三名成员为Cluster 1 ，两名成员为Cluster 2 。

    • 如果Cluster 2失败， Cluster 1会托管足够数量的应用程序数据库副本集成员来选举主节点 (primary node in the replica set)节点。

    • 如果Cluster 1失败，则Cluster 2没有足够的应用程序数据库成员来选择主节点。

  • 三个集群：两名成员为Cluster 1 ，两名成员为Cluster 2 ，一名成员为Cluster 3 。

    • 如果任何单个集群发生故障，其余集群上有足够的成员来选举主节点。

    • 如果两个集群发生故障，则剩余集群上的成员数量不足，无法选举主节点。

对于有七个成员的应用程序数据库，请考虑以下成员分布：

  • 两个集群：四名成员为Cluster 1 ，三名成员为Cluster 2 。

    • 如果Cluster 2失败，则Cluster 1上有足够的节点来选举主节点 (primary node in the replica set)节点。

    • 如果Cluster 1失败，则Cluster 2上的节点不足，无法选举主节点 (primary node in the replica set)节点。

尽管Cluster 2满足应用程序数据库至少三个成员的要求，但应用程序数据库的七个成员中的大多数都必须可用于选举主节点 (primary node in the replica set)节点。

要了解更多信息，请参阅MongoDB Ops Manager和 AppDB 资源的灾难恢复。

Ops Manager 应用程序服务器

应用程序数据库进入“正在运行”状态后， Kubernetes Operator 开始部署MongoDB Ops Manager应用程序：

  • 它在每个成员 Kubernetes 集群上配置一个 StatefulSet。

  • 对于要部署的每个MongoDB Ops Manager副本集， Kubernetes都会在 StatefulSet 中创建一个 Pod。

  • 每个 Pod 包含一个MongoDB Ops Manager应用程序进程。

要使单个集群MongoDB Ops Manager 部署能够灵活应对单个 Pod 故障，请使用 增加托管MongoDB Ops Manager spec.replicas应用程序的副本数量。

为了使多集群MongoDB Ops Manager 部署能够弹性应对整个数据中心或区域故障，请通过将MongoDB Ops Manager Kubernetes和 设置为spec.topologyspec.applicationDatabase.topology ，在多个 集群中部署MultiCluster 应用程序。另请参阅MongoDB Ops Manager和 AppDB 资源的灾难恢复。

Ops Manager资源的备份守护程序

如果spec.backup.enabled为true ，则在每个成员Kubernetes集群上， Kubernetes Operator 会在MongoDB Ops Manager应用程序进入“正在运行”阶段后启动备份守护进程。 对于备份守护程序，Kubernetes Operator 会将 StatefulSet 部署到每个成员 Kubernetes 集群。 在每个成员集群中，Kubernetes 在 StatefulSet 中创建spec.backup.members中指定数量的备份守护程序 Pod。 在单集群部署中，这些操作发生在您用于安装Kubernetes Operator 和部署MongoDB Ops Manager组件的 Operator 集群上。

如果启用备份，请在全局 级别配置 oplog 存储 、块存储或 S3 快照存储 spec.backup，而不是为每个 Kubernetes 成员集群配置。

您还可以 加密备份作业 ，但在同一 Kubernetes 操作符 实例不同时管理 MongoDBOpsManager 和 MongoDB 自定义资源的部署中会 受到限制 。

如果启用备份， Kubernetes Operator 会在每个成员Kubernetes集群上为备份守护程序的头部数据库创建持久卷声明。您可以使用 spec.backup.headDB 设置配置头部数据库。

Kubernetes Operator 调用MongoDB Ops Manager API，以确保MongoDB Ops Manager应用程序的备份配置与您在每个成员Kubernetes集群的自定义资源定义中定义的配置相匹配。

Considerations

加密密钥

Kubernetes Operator 生成加密密钥来保护MongoDB Ops Manager应用程序数据库中的敏感信息。Kubernetes Operator 将此密钥保存在与 MongoDB Ops Manager 资源相同的命名空间中的密钥中。Kubernetes Operator 将密钥命名为 <om-resource-name>-gen-key。

注意

为避免在单集群Kubernetes部署中存储密钥，您可以将所有密钥迁移到密钥存储工具。多个Kubernetes集群上的部署不支持将密钥存储在密钥存储工具中，例如 HashiCorp Vault 。

如果删除MongoDB Ops Manager资源，该密钥仍会存储在Kubernetes集群上的密钥中。 如果您将应用程序数据库存储在持久卷中，并创建另一个同名的MongoDB Ops Manager资源，则Kubernetes Operator 会重复使用该密钥。如果使用不同名称创建MongoDB Ops Manager资源，则Kubernetes Operator 会创建新的密钥和应用程序数据库，并且不会重复使用旧密钥。

应用程序数据库

拓扑结构

监控

Kubernetes Operator 会自动配置 Ops Manager 以监控支持 Ops Manager 应用程序的应用程序数据库。Kubernetes 操作符会为您创建一个名为<ops-manager-deployment-name>-db的项目来监控应用程序数据库部署。

Ops Manager 会监控应用程序数据库部署，但并不对其进行管理。 您无法在 Ops Manager 应用程序中更改应用程序数据库的配置。

重要

Ops Manager 用户界面可能会在<ops-manager-deployment-name>-db项目中显示警告，说明应用程序数据库的代理已过期。您可以放心地忽略这些警告。

身份验证

Kubernetes Operator 对应用程序数据库强制执行SCRAM-SHA-256身份验证。

Kubernetes Operator 创建数据库用户，Ops Manager 使用该用户连接到应用程序数据库。 此数据库用户具有以下属性：

用户名

mongodb-ops-manager

身份验证数据库

admin

角色

您无法修改MongoDB Ops Manager数据库用户的名称和角色。 您可以创建一个密钥来设置数据库用户的密码。 您可以编辑密钥以更新密码。 如果您未创建密钥或删除现有密钥，Kubernetes Operator 会生成密码并存储它。

要学习；了解有关密钥存储的其他选项，请参阅配置密钥存储。多集群部署不支持在HashiCorp Vault中存储密钥。

离线部署

KubernetesOperator 要求您为MongoDB Enterprise 应用程序数据库 映像指定MongoDB Ops Manager 版本，以启用 资源的任何部署，包括离线部署。

简化的配置

部署MongoDB Ops Manager后，需要对其进行配置。 常规程序包括通过MongoDB Ops Manager 配置向导 设置 。如果在部署之前在对象规范中进行了一些基本设置，则可以绕过配置向导。

在 Ops Manager 对象规范的spec.configuration区块中，您需要：

例子

要禁用 Ops Manager 配置向导，请在spec.configuration区块中配置以下设置：

1spec:
2  configuration:
3    mms.ignoreInitialUiSetup: "true"
4    automation.versions.source: "remote"
5    mms.adminEmailAddr: cloud-manager-support@mongodb.com
6    mms.fromEmailAddr: cloud-manager-support@mongodb.com
7    mms.mail.hostname: email-smtp.us-east-1.amazonaws.com
8    mms.mail.port: "465"
9    mms.mail.ssl: "true"
10    mms.mail.transport: smtp
11    mms.minimumTLSVersion: TLSv1.2
12    mms.replyToEmailAddr: cloud-manager-support@mongodb.com

将示例值替换为您希望 Ops Manager 使用的值。

备份

Kubernetes Operator默认启用备份。Kubernetes Operator 部署一个由一个 Pod 组成的 StatefulSet 来托管 备份守护程序服务 ，然后为备份守护程序的 头部数据库 创建 持久卷声明 和 持久卷 。Kubernetes Operator 使用MongoDB Ops Manager API启用备份守护程序并配置头部数据库。

重要

要配置备份，必须为oplog存储和以下其中一项创建MongoDB资源或 MongoDBMultiCluster 资源：

  • oplog 存储 或 S3 oplog 存储。如果同时部署oplog存储和 S3 oplog存储， Ops Manager会随机选择一个用于备份。

  • S3 快照存储或块存储。 如果同时部署S3快照存储和块存储， MongoDB Ops Manager会随机选择一个用于备份。

在您配置这些备份资源之前，Ops Manager 资源将保持Pending状态。

您还可以 加密备份作业 ，但在同一 Kubernetes 操作符 实例不同时管理 MongoDBOpsManager 和 MongoDB 自定义资源的部署中会 受到限制 。

Oplog 存储

您必须部署一个三成员副本集来存储您的oplog 切片。

Oplog 数据库仅支持SCRAM身份验证机制。 您无法启用其他身份验证机制。

如果在 oplog 数据库上启用SCRAM身份验证，则必须：

  • 创建 MongoDB 资源以将 Ops Manager 连接到 oplog 数据库。

  • 在 Ops Manager 资源定义中指定用户的name 。

S3 Oplog 存储

要配置S3 oplog 存储，您必须创建Amazon Web Services S3或S3兼容存储桶来存储您的数据库备份 oplog。

您可以使用Ops Manager资源定义中的 设置为MongoDB资源和spec.backup.s3OpLogStores.mongodbResourceRef.name MongoDBMultiCluster资源配置oplog存储。

块存储

要配置块存储，必须部署副本集来存储快照。

S3 快照存储

要配置S3快照存储，您必须创建Amazon Web Services S3或S3兼容的存储桶来存储数据库备份快照。

默认配置将快照元数据存储在应用程序数据库中。 您还可以部署副本集来存储快照元数据，然后使用 Ops Manager 资源定义中的spec.backup.s3Stores.mongodbResourceRef.name设置对其进行配置。

您可以同时为 MongoDB 资源和 MongoDBMultiCluster 资源配置 S3 快照存储。

您可以更新 Operator 不通过 应用程序管理的任何其他 S3 配置设置 KubernetesMongoDB Ops Manager。

禁用备份

要在启用备份后禁用备份，请执行以下操作：

  1. 将MongoDB Ops Manager Kubernetes对象spec.backup.enabled 设置为 false。

  2. 在 应用程序中 禁用备份 。MongoDB Ops Manager

  3. 删除备份守护程序服务 StatefulSet ：

    kubectl delete statefulset <metadata.name> -backup-daemon \
     -n <metadata.namespace>

重要

删除备份守护程序服务 StatefulSet 时，不会删除备份守护程序头部数据库的持久卷声明和持久卷。您可以在删除这些Kubernetes资源之前检索存储的数据。

要学习；了解有关回收持久卷的信息，请参阅Kubernetes文档。

手动配置 KMIP 备份加密

对于同一 Kubernetes 操作符 实例不同时管理MongoDBOpsManager和MongoDB自定义资源的部署，您必须使用以下过程在 Ops Manager 中手动配置KMIP备份加密客户端设置。如果 Kubernetes 操作符正在管理这两种资源，请参阅为 Ops Manager 配置 KMIP 备份加密。

先决条件
步骤

  1. 将TLS密钥挂载到MongoDBOpsManager自定义资源。 例如：

    apiVersion: mongodb.com/v1
    kind: MongoDBOpsManager
    metadata:
      name: ops-manager-pod-spec
    spec:
      < ... omitted ... >
      statefulSet:
        spec:
          template:
            spec:
              volumes:
              - name: kmip-client-test-prefix-mdb-latest-kmip-client
                secretName: test-prefix-mdb-latest-kmip-client
              containers:
                - name: mongodb-ops-manager
                  volumeMounts:
                  - mountPath: /mongodb-ops-manager/kmip/client/test-prefix-mdb-latest-kmip-client
                    name: kmip-client-test-prefix-mdb-latest-kmip-client
                    readOnly: true
      ...

  2. 按照 配置项目以使用 KMIP MongoDB Ops Manager中的步骤，在 中配置项目的 KMIP 设置。

将 Ops Manager 配置为通过 HTTPS 运行

您可以将通过 Kubernetes Operator 创建的 Ops Manager 实例配置为通过HTTPS而不是HTTP运行。

要将 Ops Manager 实例配置为通过HTTPS运行，请执行以下操作：

  1. 创建包含TLS证书和私钥的密钥。

  2. 将此密钥添加到 Ops Manager 配置对象中。

有关详细说明，请参阅部署 Ops Manager 资源。

重要

如果您有现有部署，则必须在启用HTTPS后手动重新启动这些部署。 为避免重新启动部署，请在部署托管资源之前配置HTTPS 。

要了解更多信息，请参阅部署后启用 HTTPS。

Ops Manager 应用程序访问

默认情况下，Kubernetes Operator 不会创建 Kubernetes 服务来将源自 Kubernetes 集群外部的流量路由到 Ops Manager 应用程序。

要访问 Ops Manager 应用程序，您可以：

  • 配置 Kubernetes 操作符 以创建 Kubernetes 服务。

  • 手动创建 Kubernetes 服务。 如果您的云提供商支持，MongoDB 建议使用LoadBalancer Kubernetes 服务。

  • 如果您使用的是OpenShift，请使用路由。

  • 使用第三方服务，例如 Istio。

最简单的方法是配置Kubernetes Operator，以创建Kubernetes服务，将外部流量路由到MongoDB Ops Manager应用程序。 The MongoDB Ops Manager部署过程指导您将以下设置添加到对象规范中，以配置Kubernetes Operator 以创建服务：

此外，对于多个Kubernetes集群上的部署，请参阅多集群架构。

在远程或本地模式下部署 Ops Manager

如果您的环境不允许 集群中的主机访问互联网，则可以使用Kubernetes OperatorMongoDB Ops Manager 将单个 集群配置为在 本地 或 远程Kubernetes 模式下运行。在这些模式下，备份守护程序和托管MongoDB资源从MongoDB Ops Manager而不是从 Internet 下载安装存档：

管理外部 MongoDB 部署

当您使用 Kubernetes Operator 部署 Ops Manager 时，Ops Manager 可以托管已部署的 MongoDB database 资源：

  • 到与 Ops Manager 相同的 Kubernetes 集群。

  • 在 Kubernetes 集群之外。

如果 Ops Manager 管理部署到与 Ops Manager 不同的 Kubernetes 集群或 Kubernetes 集群外部的 MongoDB 数据库资源，您必须：

  1. 在 Ops Manager 资源规范中将mms.centralUrl设置添加到spec.configuration 。

    将该值设置为 Ops Manager 在 Kubernetes 集群外部公开的 URL：

    spec:
      configuration:
        mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/

  2. 更新使用 Kubernetes Operator 部署的 Kubernetes 集群内所有 MongoDB database 资源引用的 ConfigMaps 。

    将data.baseUrl设置为与 Ops Manager 资源规范中的spec.configuration.mms.centralUrl设置相同的值。

    重要

    这包括 和快照存储的 资源引用的 ConfigMap。MongoDB databaseoplog

在多集群中部署MongoDB Ops Manager

请参阅多集群架构。

密钥存储

为避免将密钥存储在Kubernetes中，请将Kubernetes Operator 创建的所有Kubernetes密钥迁移到密钥存储工具中。多集群部署不支持在HashiCorp Vault等密钥存储工具中存储密钥。

先决条件

  1. 如果尚未运行，请运行以下命令，在您创建的命名空间中运行所有kubectl命令：

    kubectl config set-context $(kubectl config current-context) \
      -n <metadata.namespace>

    注意

    MongoDB Ops Manager如果要在多 Kubernetes 集群 部署中部署MongoDB 资源：

    • 将 context 设置为操作符集群的名称，例如：kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"。

    • 将--namespace设置为您用于多 Kubernetes 集群 MongoDB 部署的相同范围，例如： kubectl config --namespace "mongodb" 。

  2. 为Kubernetes Operator 安装MongoDB控制器。

  3. 确保要部署 Ops Manager 的主机至少具有 5 GB 内存。

  1. 在与MongoDB Ops Manager资源相同的 命名空间 中为管理员用户创建Kubernetes 密钥 。如果要在多 Kubernetes集群MongoDB 部署中部署MongoDB Ops Manager，请使用为多 Kubernetes集群MongoDB 部署命名空间设立的同一范围。

    如果您使用 HashiCorp Vault 作为您的 Secret 存储工具，则可以创建 Vault Secret。

    要了解有关 Secret 存储的选项，请参阅配置 Secret 存储。

    部署MongoDB Ops Manager资源时， MongoDB Ops Manager会使用这些档案创建用户，并授予其Global Owner角色。 使用这些凭证首次登录MongoDB Ops Manager 。 部署MongoDB Ops Manager后，请更改密码或删除此密钥。

    注意

    管理员用户的密码必须符合MongoDB Ops Manager密码复杂性要求。

    kubectl create secret generic <adminusercredentials> \
      --from-literal=Username="<username>" \
      --from-literal=Password="<password>" \
      --from-literal=FirstName="<firstname>" \
      --from-literal=LastName="<lastname>"

  1. （ 可选 ）要为MongoDB Ops Manager数据库用户设立密码，请在与MongoDB Ops Manager资源相同的 命名空间 中创建 密钥 。

    如果您使用 HashiCorp Vault 作为您的 Secret 存储工具，则可以创建 Vault Secret。

    Kubernetes Operator 创建MongoDB Ops Manager用于连接到Ops Manager Application Database用户。 您可以通过调用以下命令创建密钥来为此数据库用户设置密码：

    kubectl create secret generic <om-db-user-secret-name> \
      --from-literal=password="<om-db-user-password>"

    注意

    如果选择为 Ops Manager 数据库用户创建密钥，则必须在 Ops Manager 资源定义中指定密钥的name 。 默认情况下，Kubernetes Operator 在password键中查找密码值。 如果将密码值存储在不同的密钥中，则还必须在 Ops Manager 资源定义中指定该key名称。

    如果您不创建密钥，Kubernetes Operator 会自动生成密码并在内部存储。 要了解更多信息，请参阅身份验证。

  2. （可选）。要将备份配置到S3快照存储，请在与MongoDB Ops Manager资源相同的命名空间中创建密钥。

    如果您使用 HashiCorp Vault 作为您的 Secret 存储工具，则可以创建 Vault Secret。

    此密钥存储您的S3档案，以便 Kubernetes 操作符可以将 Ops Manager 连接到您的Amazon Web Services S3或S3兼容存储桶。密钥必须包含以下键值对：

    键

    值

    accessKey

    拥有 S3 或 S3 兼容存储桶的 Amazon Web Services 用户的唯一标识符。

    secretKey

    拥有 S3 或 S3 兼容存储桶的 Amazon Web Services 用户的密钥。

    要创建密钥，请调用以下命令：

    kubectl create secret generic <my-aws-s3-credentials> \
      --from-literal=accessKey="<AKIAIOSFODNN7EXAMPLE>" \
      --from-literal=secretKey="<wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY>"

    要了解有关管理S 3快照存储的更多信息，请参阅先决条件。

在此页面上