您可以在 Kubernetes 集群中部署 MongoDB Search 和 向量搜索，以直接在应用程序内构建强大的搜索体验。使用 MongoDB Search 和 Vector Search，您可以构建传统的文本搜索和 AI 驱动的向量搜索功能，这些功能会与本地部署的 MongoDB 数据库自动同步。这种方法无需维护同步的独立系统，同时提供高级搜索功能。要了解更多信息，请参阅：
要在本地部署中启用全文和语义搜索等搜索功能，必须部署MongoDB搜索和向量搜索进程(mongot)，并将其与MongoDB 数据库部署(mongod) 连接。部署 mongot 是可选的，仅当您计划使用其提供的搜索功能时才需要部署。
MongoDB 数据库进程 (mongod) 充当 mongot 的所有搜索查询的代理。mongod 将查询转发到 mongot，由其处理查询。mongot 将查询结果返回给 mongod，后者再将结果转发给您。您从不与 mongot 直接交互。
每个 mongot进程都有自己的持久卷，不与数据库或其他搜索节点共享。存储用于维护根据持续源自数据库的数据构建的索引。索引定义（元数据）存储在数据库中。
mongot 执行以下操作：
管理索引。
mongot负责更新数据库中的索引定义。从数据库中获取数据。
mongot节点与数据库建立永久连接，以便实时更新数据库中的索引。处理搜索查询。
When
mongodreceives a$search,$searchMeta, or$vectorSearchquery, it directs the query to one of themongotnodes. Themongotthat receives the query processes the query, aggregates the data, and returns the results tomongod, which it forwards to the user.
mongot 组件与单个MongoDB副本集紧密耦合，不能在多个数据库或副本集之间共享。对于副本集部署，由一群组专用搜索节点为副本集提供服务。对于分片集群，每个分片都维护自己独立的 mongot 节点群组。分片不股票mongot 实例。
mongot 和 mongod 之间的网络连接是双向的：
mongot建立与副本集的连接，以获取用于构建索引和运行查询的数据。mongod连接到mongot以转发索引管理和查询数据等搜索相关操作。
spec.clusters[].replicas字段控制Kubernetes Operator 部署的 mongot 实例数量。对于副本集源，spec.clusters[].replicas 设置 mongot Pod 的总数。对于分片集群源，spec.clusters[].replicas 设置每个分片的 mongot Pod 数量。
如果将 spec.clusters[].replicas设立为大于 1 的值，则必须在 mongod 和 mongot Pod 之间放置一个 L7 负载负载均衡器。mongod进程打开一个与 mongot 的长期 TCP 连接，因此 L4 负载负载均衡器无法在多个 mongot 实例之间分配查询 — 所有流量都流经该一个连接。L7 负载负载均衡器支持HTTP /2 和 gRPC，因此可以跨 mongot Pod 分发单个 gRPC 流，同时在查询游标运行期间将每个流固定到单个 mongot。
MongoDB Search 和 Vector Search 部署
有无 Kubernetes 操作符 的搜索部署架构没有太大区别。Kubernetes 操作符 简化了部署功能完全的搜索节点所需的步骤，尤其是当数据库也由 Kubernetes 操作符 管理时。
要部署，请应用MongoDBSearch 自定义资源 (CR)， Kubernetes 操作符 会选择该资源并开始部署 mongot Pod，并请求 spec 中指定的持久存储。通过Kubernetes 操作符 部署的MongoDB Search 和 向量搜索 可以针对Kubernetes 操作符 在同一Kubernetes 集群内部署的MongoDB 副本集或集群，或完全独立的外部MongoDB 部署（副本集或集群）。要学习；了解如何部署和配置 mongot 以使用：
Kubernetes中的MongoDB副本集，详见使用MongoDB Community Edition安装和使用或使用MongoDB Enterprise Edition安装和使用搜索
外部MongoDB副本集，请参阅使用外部MongoDB Enterprise版安装搜索。
先决条件
要在以下位置使用MongoDB Search 和 Vector Search：
MongoDB Community部署，您必须使用Kubernetes 操作符 在Kubernetes集群内部署功能齐全的MongoDB 8.3 或更高版本副本集或分片集群。
MongoDB Enterprise部署，必须通过以下方式之一部署功能齐全的MongoDB 8.3 或更高版本的副本集或分片集群：
使用Kubernetes Operator 在Kubernetes集群内部
Kubernetes集群外部
Cloud Manager或MongoDB Ops Manager实例
开始之前，请考虑以下事项：
您必须有有效的
StorageClass，才能在Kubernetes集群中创建持久卷。如果没有它，您的PersistentVolumeClaims可能会保持待处理状态，并且MongoDB可能没有持久性存储。您必须具有正确配置的集群网络。ClusterIP、NodePort 或 LoadBalancer 等服务必须能够路由流量。如果外部客户端需要访问权限，设立设置入口或负载负载均衡器。
必须为数据库和搜索节点分配足够的 CPU、内存和磁盘空间，因为 MongoDB 数据库、MongoDB 搜索和向量搜索工作负载属于资源密集型工作负载。MongoDB 建议在 Pod 规范中使用请求和限制，以避免驱逐或限制。
您要使用的MongoDB操作符或Helm图表必须支持您的Kubernetes版本。某些 CRD 或 API 因版本而异。要了解更多信息，请参阅Kubernetes 操作符兼容性的 MongoDB 控制器。
您必须创建任何所需的 RBAC 角色和角色绑定，这样 Kubernetes 操作符和 Pod 中运行的进程才能管理资源。
如果您需要多个
mongot实例（spec.clusters[].replicas大于1），则需要一个负载负载均衡器。Kubernetes 操作符 可以自动部署和管理Envoy 代理 (spec.clusters[].loadBalancer.managed: {})，您也可以提供自己的 L7 负载均衡器(spec.clusters[].loadBalancer.unmanaged)。If you want a sharded cluster with multiple
mongotinstances, ensure that you have sufficient cluster resources for the total number of pods across all shards. Each shard gets its own independent group ofmongotpods. The load balancer dispatches traffic to the correctmongotgroup. It reads the TLS SNI field on incoming traffic to identify the originating shard and routes the traffic tomongotpods that belong to that shard. Therefore, you must configure each shard with a distinct search hostname.
配置任务
下表显示了Kubernetes 操作符 自动执行的配置任务以及您必须执行的操作，才能在Kubernetes中成功部署MongoDB Search 和 向量搜索，以及连接到Kubernetes或外部MongoDB 部署中的MongoDB副本集或集群。
任务 | （在 Kubernetes 内） 执行者 | （外部 MongoDB） 执行者 |
|---|---|---|
在Kubernetes内部署MongoDB Ops Manager | Kubernetes Operator | Kubernetes Operator |
在Kubernetes外部部署Cloud Manager或MongoDB Ops Manager | 您 | 您 |
部署MongoDB副本集或分片集群 | Kubernetes Operator | 您 |
创建 MongoDBSearch 自定义资源 | 您 | 您 |
为MongoDB 部署提供连接字符串 | Kubernetes Operator | 您 |
创建 | Kubernetes Operator | Kubernetes Operator |
在每个 | Kubernetes Operator | 您 |
为 | Kubernetes Operator 和您通过应用 MongoDBUser资源 | 您 |
使用具有查询搜索所需权限的用户配置MongoDB副本集 | 您 | 您 |
创建MongoDB Search 和 Vector Search 索引 | 您 | 您 |
向外部公开搜索Pod 或负载负载均衡器，以便从每个 | 没有必要 | 您 |
向外部公开 | 没有必要 | 您 |
配置托管负载负载均衡器（当 | Kubernetes Operator | Kubernetes Operator |
配置非托管负载负载均衡器（当 | 您 | 您 |
预配每个分片的TLS证书（具有TLS的分片的集群） | 您 | 您 |
向外部公开负载负载均衡器（外部MongoDB + 托管负载均衡器） | 没有必要 | 您 |
下图显示了Kubernetes集群中具有MongoDB Enterprise副本集的单个MongoDB Search 和 Vector Search实例的部署架构。
下图显示了Kubernetes Operator 在Kubernetes集群中为带有MongoDB Enterprise版副本集的MongoDB Search 和 Vector Search 部署的组件。
当 mongot 和 mongod 进程同时部署在Kubernetes集群内时， Kubernetes Operator 会自动为这两个进程执行配置。具体来说， Kubernetes Operator 执行以下操作：
Finds the MongoDB CR referenced by MongoDBSearch using
spec.source.mongodbResourceRef, or by a naming convention by looking for MongoDB CR with the same name as MongoDBSearch. For sharded clusters, the Kubernetes Operator auto-discovers the shard topology (shard names, replica set members, and mongos routers) from the referencedMongoDBresource.Generates
mongotconfiguration in a YAML file and saves it to a config map named<MongoDBSearch.metadata.name>-search-config.The Config map is mounted by the search pods and the YAML configuration is used by
mongot's process on startup. The generated YAML contains all the information about how to connect to the replica set, TLS settings, and so on.Deploys MongoDB Search and Vector Search stateful set named
<MongoDBSearch.metadata.name>-searchwith storage and resource requirements configured according to thespec.clusters[].persistenceandspec.clusters[].resourceRequirementssettings in the CR. For sharded cluster sources, the Kubernetes Operator creates one StatefulSet per shard. Each StatefulSet uses the naming pattern<name>-search-0-<shardName>and containsspec.clusters[].replicaspods, which defaults to1. The0in the naming pattern is the cluster index, which is0in single-cluster deployments. In multi-cluster deployments, the Kubernetes Operator uses each cluster'sspec.clusters[].indexvalue in that cluster's StatefulSet names.如果需要负载负载均衡器(
spec.clusters[].loadBalancer.managed)，请为MongoDB 集群部署单个 Envoy 代理 Deployment。Envoy 代理处理mongod和mongotPod 之间的 L7 路由、mTLS 终止以及 gRPC流固定。通过添加必要的
setParameter选项（包括mongot主机的主机名和端口号）来更新每个mongod进程的配置。配置负载均衡器时，mongotHost和searchIndexManagementHostAndPort点指向负载均衡器终结点，而不是mongotPod。对于分片的集群，每个分片的mongod进程接收该分片的负载均衡器终结点。
您必须执行以下操作：
使用
MongoDBUser自定义资源在副本集创建用户。mongot使用该用户的凭证连接到副本集以获取数据：用户名是任意的（示例使用
search-sync-source-user），但必须设置searchCoordinator角色。该用户的用户名和密码分别在
MongoDBSearch.spec.source.username和MongoDBSearch.spec.source.passwordSecretRef中传递。密码密钥可以指用于创建
MongoDBUser规范（在MongoDBUser.spec.source.passwordSecretKeyRef中）的包含用户密码的相同密钥。
配置并应用MongoDBSearch 自定义资源。
To learn more about the CR settings for the mongot process, see MongoDB Search and Vector Search Settings.
下图展示了使用外部MongoDB Enterprise版副本集的Kubernetes集群中MongoDB Search 和 Vector Search 的部署架构。
下图显示了Kubernetes Operator 在Kubernetes集群中为MongoDB Search 和 Vector Search 部署的组件。
当您的 MongoDB 部署在 Kubernetes 之外时，若要使用 MongoDB Search 和向量搜索，请使用 Kubernetes 操作符部署 mongot，并手动执行一些步骤。Kubernetes 操作符处理搜索节点的配置。但是，当 MongoDB 部署在 Kubernetes 之外时，必须重新配置 MongoDB 节点和网络。
您负责以下手动配置：
外部副本集配置
在外部副本集的每个
mongod进程上使用setParameter配置以下参数。配置时，将<search-service-hostname>:27028替换为 MongoDBSearch 服务的实际可解析主机名和端口。setParameter: mongotHost: "<search-service-hostname>:27028" searchIndexManagementHostAndPort: "<search-service-hostname>:27028" skipAuthenticationToSearchIndexManagementServer: false searchTLSMode: "disabled" # or "requireTLS" for TLS deployments useGrpcForSearch: true 对于单个
mongot实例（无负载负载均衡器），mongotHost直接指向mongot服务主机名 (<name>-search-0-svc:27028)。对于具有负载均衡器的多个
mongot实例，mongotHost改为指向负载均衡器终结点。对于托管负载均衡器， Kubernetes 操作符 使用
spec.source.mongodbResourceRef自动配置mongotHost。对于外部MongoDB部署，必须将
mongotHost设立为您在spec.clusters[].loadBalancer.managed.externalHostname或spec.clusters[].loadBalancer.unmanaged.endpoint中指定的负载均衡器终结点。
在外部副本集为搜索同步进程创建一个用户。此用户必须具有
searchCoordinator角色。- userName: "search-sync-source" password: "<your-search-sync-password>" database: "admin" roles: - role: "searchCoordinator" db: "admin"
外部分片集群配置
重要
在标准MongoDB分片集群部署中，客户端仅连接到 mongos 路由器，而从不直接连接到分片副本集。但是，当您部署mongot 时，每个分片群组中的 mongot 进程将同时连接到 mongos 路由器和该分片的所有 mongod 进程。因此，您必须将每个分片的副本集直接公开给 mongot 进程。确保您的网络和防火墙规则允许从Kubernetes集群直接连接到每个分片的 mongod 实例，而不仅仅是 mongos 路由器。
您在 spec.source.external.shardedCluster.shards 中指定的 shardName 值必须遵循Kubernetes命名规则：
仅包含小写字母数字字符、
-或.。以字母字符开头，以字母数字字符结尾。
不包含下划线。如果您的MongoDB分片名称使用下划线，请将其替换为破折号。
MongoDBSearch.metadata.name和shardName的总长度必须小于 50 个字符。
shardName 不需要与MongoDB中的确切分片名称匹配。Kubernetes 操作符 仅使用它来命名Kubernetes资源。
当您将 MongoDBSearch 连接到外分片集群时，您必须：
Configure
spec.source.external.shardedClusterin the MongoDBSearch CR with themongosrouter hosts and per-shard replica set hosts.在每个分片的
mongod进程上设置mongotHost和searchIndexManagementHostAndPort参数。将每个分片指向自己的mongot群组（如果使用多个mongot实例，则指向自己的负载均衡器终结点）。确保以下之间的双向网络连接：
每个分片的
mongod节点和相应的mongotPod（或负载负载均衡器）。mongotPod 和mongos路由器（用于查询路由）。mongotPod 和每个分片的mongod节点（用于数据同步）。
If you use a managed load balancer with an external sharded cluster, specify spec.clusters[].loadBalancer.managed.externalHostname with a {shardName} placeholder (for example, {shardName}.search-lb.example.com). Expose the Envoy service externally so that each shard's mongod nodes can reach it using a hostname unique to that shard. The load balancer reads the TLS SNI field from incoming connections to determine which shard the traffic originates from and dispatches it to the mongot pods that belong to that shard. This SNI-based routing is the only mechanism the load balancer uses to distinguish traffic between shards, which is why each shard must connect through a different hostname.
Kubernetes配置
Configure and apply the MongoDBSearch CR with
spec.source.externalpointing to your external MongoDB hosts.为搜索同步用户的密码创建Kubernetes密钥。
apiVersion: v1 kind: Secret metadata: name: search-sync-source-password stringData: password: "your-search-sync-password" Configure networking and DNS to ensure bidirectional connectivity between your external MongoDB and the search pods. Your external MongoDB environment must be able to resolve your search service hostname (
<search-service-hostname>).
To learn more about the CR settings for the mongot process to connect to an external mongod process, see MongoDB Search and Vector Search Settings.
安全性
The following image illustrates the security configuration for the mongot process. If the MongoDB deployment is inside the Kubernetes cluster, the Kubernetes Operator automatically sets up keyfile authentication for MongoDB Search and Vector Search. If the MongoDB deployment is external, you must create a Kubernetes Secret containing the replica set's keyfile credential and reference it in the MongoDBSearch CR.
身份验证
mongot 流程使用 mTLS 对 mongod 连接进行身份验证。当您启用 TLS 时，mongot 进程会将 MongoDB 部署的 TLS 证书用作身份验证的客户端证书。此证书根据 mongot 所配置的 CA 证书进行验证。为了使身份验证正常工作，您必须将 mongot 和 mongod 都配置为启用 TLS。
当配置为索引同一 Kubernetes 集群中的 MongoDB 资源时，Kubernetes 操作符会自动将 mongod CA 证书传播到 mongot，并为搜索查询连接启用 mTLS（如果 MongoDB 和 MongoDBSearch 资源都配置了 TLS）。如果MongoDB副本集部署在Kubernetes外部，则必须创建一个包含副本集 CA 证书的kubernetes secret，并在 MongoDBSearch.spec.source.external.tls.ca字段中引用它，以便为搜索查询请求启用mTLS身份验证。
传输层安全
MongoDBSearch can protect data and credentials in transit using TLS. For index management commands and search queries, set the spec.security.tls field and provide a TLS certificate. You can set this field to an empty object ({}) to enable TLS with default settings.
自版本 1.8.0 起已弃用： spec.security.tls.certificateKeySecretRef is deprecated. For replica set deployments, the Kubernetes Operator still supports certificateKeySecretRef, but you should migrate to spec.security.tls.certsSecretPrefix. For sharded cluster deployments, you cannot use certificateKeySecretRef because the Kubernetes Operator reads a separate mongot server certificate secret for each shard.
spec.security.tls.certsSecretPrefix 是可选字段。指定后， Kubernetes 操作符 会在其读取的所有证书密钥名称前加上 <certsSecretPrefix>-。Kubernetes 操作符 读取以下证书密钥：
mongot 证书
集群拓扑结构 | mongot 证书 |
|---|---|
副本集 |
|
分片集群 |
|
负载均衡器证书
如果设立spec.clusters[].loadBalancer.managed，则负载负载均衡器客户端证书为 [<certsSecretPrefix>-]<name>-search-lb-0-client-cert。下表显示了负载负载均衡器服务器证书：
集群拓扑结构 | 证书 |
|---|---|
副本集 |
|
分片集群 |
|
TLS 证书必须由颁发MongoDB副本集使用的 CA 证书的同一 CA 颁发和签名。
当 MongoDBSearch 和 MongoDB 都由Kubernetes 操作符 部署时，根本的mongot 和 mongod 配置主要由Kubernetes 操作符 本身处理。如果将MongoDB副本集部署在Kubernetes集群之外：
.spec.source.external.tls字段必须使用Kubernetes密钥填充，该密钥包含您用于配置mongod的相同 CA 证书。searchTLSMode参数必须在mongod配置中设立为requireTLS。
负载均衡器 mTLS
在没有负载负载均衡器的情况下，mongod 使用 mTLS 直接连接到 mongot。mongod 提供自己的客户端证书，mongot 根据受信任的 CA 对其进行验证。
如果您配置托管负载负载均衡器(spec.clusters[].loadBalancer.managed)，Envoy 代理会终止与 mongod 的 mTLS 连接，并与 mongot 建立新的 mTLS 连接。由于负载负载均衡器会终止并重新建立连接，因此在连接到 mongot 时，它会使用自己的客户端证书，而不是原始的 mongod 证书。mongot CA 必须信任颁发负载均衡器客户端证书的证书颁发机构。Kubernetes 操作符 自动管理 Envoy TLS 配置。它需要以下证书：
mongod连接到的 Envoy 代理的 服务器证书。负载负载均衡器使用此证书终止传入的 mTLS 连接。Envoy 代理的客户端证书，负载负载均衡器在建立上游 mTLS 连接时向
mongot提供该证书。
遵循 spec.security.tls.certsSecretPrefix 定义的命名约定，将这些证书预配为Kubernetes Secret。有关完整的命名模式，请参阅MongoDB Search 和 向量搜索 Settings。
诊断数据
Each mongot pod continuously writes FTDC files to /mongot/data/diagnostic.data/ inside the pod. FTDC is a binary diagnostic stream that captures detailed mongot internal state and is the primary artifact MongoDB Support uses to diagnose Search issues. FTDC is enabled by default. To learn how to copy FTDC files for a support case, see Troubleshoot mongot Deployment.
Kubernetes 操作符通过在 search StatefulSet 上使用 volumeClaimTemplate 将 PersistentVolumeClaim 挂载到每个 mongot pod 的 /mongot/data 位置，并且 mongot 会将其 FTDC 文件写入到该卷上的 /mongot/data/diagnostic.data/ 中。由于数据驻留在 PersistentVolumeClaim 上，因此它可以在 Pod 重启和重新调度后依然存在：当 StatefulSet 替换 Pod 时，它会重新挂载相同的 PersistentVolumeClaim。您可以使用 spec.clusters[].persistence 配置此卷MongoDBSearch 资源上的设置。