当前位置：首页 > news >正文

KubeBlocks for Milvus 揭秘

news 2025/9/2 8:16:55

背景

Milvus 是一款由 Zilliz 开发的分布式向量数据库，是业界主流的向量数据库之一。它主要用于相似性搜索（Similarity Search）和大规模向量检索，常见于如图像识别、推荐系统、自然语言处理、音频识别等 AI 场景中。Milvus 的本意是鸢，是一种猛禽。

Milvus 能够支持存储百亿级别的向量，这离不开它的云原生架构：

在这里插入图片描述

（此处放的是 2.5.x 的图，2.6.x 的架构有一些变化，但大致相同）

由上图可见，Milvus 将存储和运算组件分离，自身组件是完全无状态的，因而能够方便地进行水平扩容。Milvus 的工作节点遵循低耦合的原则，分为查询、数据、索引三种，分别处理向量搜索、压缩、索引任务。节点之间通过协调者分配任务。客户端流量通过代理节点进行负载均衡。

Milvus 依赖三个有状态外部组件工作，分别是：

etcd，存储 Milvus 的元数据，以此来实现各个组件之间的服务发现。例如数据节点会往 etcd 中写入如下数据：

laure-fc4d79455/meta/session/datanode-5
{"ServerID":5,"ServerName":"datanode","Address":"192.168.0.33:21124","TriggerKill":true,"Version":"2.5.13","IndexEngineVersion":{},"ScalarIndexEngineVersion":{},"LeaseID":2902455202693735596,"HostName":"laure-fc4d79455-datanode-0"}

其中包含了节点的 id、hostname、连接地址等信息。

消息队列，作为 Milvus 的 WAL 日志使用。在 2.5 版本中 Milvus 支持 Kafka 和 Pulsar 两种消息队列。
对象存储，作为 Milvus 的主要存储使用。WAL 日志中的数据会周期性地写入到对象存储中储存。

Milvus 对 Kubernetes 提供了良好的支持，官方也提供了 Milvus Operator 在 Kubernetes 上部署和管理 Milvus。然而，Milvus Operator 在管理 etcd/minio 等外部组件上还比较简陋，只提供了拉起对应 Pod 的功能，无法进行更多的 Day-2 运维操作。

KubeBlocks 是一个在 Kubernetes 上运行的数据库中立的管控平台。通过 Addon 的抽象，Kubeblocks 提供了支持任意类型数据库的统一接口，涵盖了启动脚本、生命周期钩子、配置管理等各个方面。KubeBlocks Milvus Addon 不仅能对 Milvus 进行生命周期管理和运维操作，也能够更好地管理 Milvus 所依赖的外部组件。通过 KubeBlocks 提供的数据库运维接口，用户能够在运维各种数据库时获得统一的体验。

KubeBlocks Addon 实现

由于 Milvus 无状态的特性，KubeBlocks Addon 的实现相当简单。然而，

KubeBlocks 中已经支持了 etcd/kafka/minio 这几个 Addon，所以我们可以复用这些 Addon，来使用它们提供的服务。这也是 KubeBlocks 中 “blocks” 的含义，我们能够通过搭积木的方式，构建一个复杂的数据库系统。

下面介绍 Addon 的具体实现，所有内容都基于 KubeBlocks 0.9 的 API 和 milvus 2.5 版本。KubeBlocks API 的解释可以参考官网的介绍。

首先我们通过 ClusterDefinition 定义两种拓扑结构：standalone 和 cluster，对应 milvus 的单机和分布式版本。前者用于小规模的测试，后者适用于大规模生产环境。

standalone 版本

单机版本下，Milvus 中所有组件运行在一个 Pod 中，消息队列使用内置的 rocksmq，这样只需要依赖 etcd 和对象存储两个外部组件。为了简化部署流程，我们将这两个组件作为 Component 运行。通过在 ClusterDefinition 中声明 etcd 和 minio 两个 Components，并引用相应的 ComponentDefinition，即可在 Milvus 集群启动时同时启动 etcd 和 minio。由于 KubeBlocks 创建的 Service 遵循 {clusterName}-{componentName} 的命名规则，且所有 Component 都会自带一个 headless 服务，我们可以在 Milvus 配置文件中构造类似这样的地址 {{ .KB_CLUSTER_NAME }}-etcd-headless.{{ .KB_NAMESPACE }}.svc.cluster.local:2379来连接对应的服务。

cluster 版本

分布式版本下，Milvus 拆分出了 proxy/query/data/index/coord 等不同的组件。但本质上，这些组件使用同一个容器镜像，所有组件也共享一份配置文件，只是启动命令不同。这一高度统一的部署流程也方便了我们对不同组件的管理。

在 cluster 版本中，我们不再将 etcd 和对象存储作为 Component 运行，而是作为外部服务在 Milvus 集群中引用。Milvus 分布式版本支持 Pulsar 和 Kafka 作为消息队列。在 KubeBlocks 中 Kafka Addon 的成熟度较高，因此我们使用 Kafka 作为消息队列。同样的，它作为外部服务在 Milvus 集群中引用。

KubeBlocks 提供了 ServiceRef 来引用一个外部服务。我们首先在 ComponentDefinition 的 .spec.serviceRefDeclarations 字段中声明该 Component 需要的 ServiceRef, 例如：

- name: milvus-meta-storageserviceRefDeclarationSpecs:- serviceKind: etcdserviceVersion: "^3.*"optional: true

然后，在 Cluster CR 的 .spec.componentSpecs[*].serviceRefs 字段中，就可以传入相应的 ServiceRef。ServiceRef 支持两种引用方式：

引用一个由 KubeBlocks 管理的集群，并选择相应的服务。例如：

- name: milvus-meta-storage # <----- 和 serviceRefDeclarations 中的 name 对应namespace: kubeblocks-cloud-ns  # <----- 引用的 Cluster 所在的 namespaceclusterServiceSelector:cluster: rice6-849768d46service:component: etcdservice: headless # <----- 和 etcd ComponentDefinition 中的 .spec.services 对应port: client # <----- etcd ComponentDefinition 中 .spec.services[*].spec.ports 中定义的某个端口

.clusterServiceSelector.service 中的 service 字段除了使用常规定义的 service 之外，也可以使用一个特殊的 service headless，这是 InstanceSet 为每个 Component 默认创建的 Headless Service。这个 service 不需要在 ComponentDefinition 中定义，可以直接使用。

引用一个外部地址。在 KubeBlocks API 中，有一个单独的 ServiceDescriptor CR 来定义这个外部地址。例如：

apiVersion: apps.kubeblocks.io/v1alpha1
kind: ServiceDescriptor
metadata:name: etcdnamespace: kubeblocks-cloud-ns
spec:host:value: etcd-serviceport:value: "1234"serviceKind: etcdserviceVersion: 3.5.2

然后在 Cluster Object 中传入 ServiceRef：

- name: milvus-meta-storagenamespace: kubeblocks-cloud-ns # <----- 引用的 ServiceDescriptor 所在的 namespaceserviceDescriptor: maple-7b759bdb4c-minio

使用 ServiceRef 的好处在于：

用户可以使用一个非 KubeBlocks 管理的服务（如对象存储）
一个服务可以被多个集群共享
服务与引用它的集群之间解耦，方便这个服务单独进行运维操作

Milvus Addon 同时支持了这两种 ServiceRef 的引用方式。在配置完 ServiceRef 之后，我们通过 ComponentDefinition 中的 .spec.vars 字段引用这些 ServiceRef，例如：

- name: ETCD_HOST_SVC_REFvalueFrom:serviceRefVarRef:name: milvus-meta-storageoptional: truehost: Required
- name: ETCD_PORT_SVC_REFvalueFrom:serviceRefVarRef:name: milvus-meta-storageoptional: trueport: Required

这些 vars 将在渲染配置文件时被传入到模板中。由于 Milvus 的各个组件是无状态的，因此无需配置 Volume，也无需配置 roleProbe 等 lifecycleAction。

部署实践

我们可以使用如下的 Cluster CR 来部署一个 Milvus 分布式版本的集群：

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:namespace: kubeblocks-cloud-nsname: maple-7b759bdb4clabels: helm.sh/chart: milvus-cluster-0.9.2app.kubernetes.io/version: "2.5.13"app.kubernetes.io/instance: milvus
spec:clusterDefinitionRef: milvustopology: clusterterminationPolicy: Delete  componentSpecs:- name: proxyserviceVersion: 2.5.13replicas: 1      resources:limits:cpu: "1"memory: "1Gi"requests:cpu: "0.5"memory: "0.5Gi"env:        - name: MINIO_BUCKETvalue: kubeblocks-oss- name: MINIO_ROOT_PATHvalue: kubeblocks-cloud-ns/test-milvus- name: MINIO_USE_PATH_STYLEvalue: "false"serviceRefs:        - name: milvus-meta-storagenamespace: kubeblocks-cloud-nsclusterServiceSelector:cluster: rice6-849768d46service:component: etcdservice: headlessport: client- name: milvus-log-storage-kafkanamespace: kubeblocks-cloud-nsclusterServiceSelector:cluster: bambo-78dcc489cbservice:component: kafka-combineservice: advertised-listenerport: broker- name: milvus-object-storagenamespace: defaultserviceDescriptor: maple-554bfbfc6b-minioserviceAccountName:       disableExporter: true# mixcoord/index/query/data 组件的配置和 proxy 类似，这里省略

创建后查看 Pod 状态：

在这里插入图片描述

由于 Milvus 各个组件无状态的特性，它们无需额外额外配置就能够支持垂直伸缩、水平伸缩等运维操作。同时，KubeBlocks 原生提供的集群重启、停止、小版本升级等运维操作也适用于 Milvus。

总结

本文介绍了 Milvus 向量数据库及其在 KubeBlocks 上的部署实现。Milvus 采用无状态分布式架构，支持大规模向量检索，常用于 AI 场景。KubeBlocks 通过复用 etcd、Kafka、MinIO 等模块化 Addon，提供 standalone 和 cluster 两种部署模式，并借助 ServiceRef 引用外部服务，实现了灵活扩展与简化运维。

查看全文

http://www.dtcms.com/a/361547.html