从Milvus Operator聊聊，手动运维终将被淘汰

前言

周一早会，老板发话："小M啊，客户那边要上线一个向量搜索服务，你把Milvus集群部署一下，今天下班前搞定啊！对了，要高可用，要能扩展，要监控齐全...（省略八百字需求）"

你强颜欢笑地点头，心里却在盘算：手动配置一大堆yaml文件，改一个配置要改好几个地方，还得担心改错了整个集群就挂。想扩展节点？那得手动调度资源、配均衡，搞不好还会数据丢失。更别提监控告警了，光是配置Prometheus和Grafana就够喝一壶的。

但在Kubernetes的世界里，这活儿的环，闭了，但没完全闭。

与其像原始人一样手动搭建每一块积木，不如用现代工具一键生成高楼大厦。今天我们就来聊聊Milvus Operator这个"懒人神器"，如何让你的集群部署从"处处是坑"变成"一键搞定"，让老板的变态需求变成你的得心应手。

毕竟老运维都知道，针对脱发，一次Milvus Operator部署，顶十瓶米诺地尔。

01

Kubernetes Operator概述

（1）Operator设计初衷

Kubernetes Operator是一个用于管理和自动化Kubernetes应用程序的框架。它的设计初衷是为了简化Kubernetes应用程序的部署、管理和升级过程。

（2）Operator工作原理

3.27-1.png

自定义资源（CRD）

Operator 会定义一种“自定义资源”（Custom Resource Definition，简称 CRD）。你可以把它理解为一个新的“配置文件类型”，专门用来描述你的应用程序。

比如，你有一个数据库应用，Operator 可以定义一个叫 Database 的 CRD，你只需要在这个文件里写清楚你想要什么样的数据库（比如多大、什么版本等）。

控制器（Controller）

Operator 的核心是一个“控制器”。这个控制器会一直盯着你定义的 CRD，看看你有没有创建新的资源，或者有没有修改现有的资源。

比如，你创建了一个 Database 资源，控制器会看到这个资源，然后开始按照你写的配置去部署数据库。

自动化操作：

控制器会根据 CRD 里的配置，自动执行一系列操作。比如，创建 Pod、配置网络、设置存储等等。

如果出了问题，控制器还会尝试自动修复。比如，如果数据库崩溃了，控制器会自动重启它。

状态管理

Operator 还会持续监控应用程序的状态，确保它一直按照你期望的方式运行。

如果发现状态不符合预期，Operator 会自动进行调整，直到一切恢复正常。

（3）为什么要选用Operator管理Milvus而不是Helm或YAML？

Milvus作为一个分布式向量数据库，其运维管理可以通过YAML、Helm或Operator三种方式实现。相比前两者，Operator在自动化程度、状态管理和运维效率上具有显著优势。

运维自动化

YAML和Helm这类传统方式需要运维人员手动处理大量日常任务。比如集群扩容时，需要手动修改配置、检查资源状态、调整负载均衡。版本升级更是个精细活，要确保服务不中断，还得准备回滚方案。

Operator则把这些繁琐的任务都自动化了。它能自动检测负载情况进行扩缩容，执行滚动升级时自动处理服务切换，甚至在发现异常时自动进行故障转移。这就像从手动挡换成了自动挡，让运维工作轻松很多。

状态管理

YAML只能描述期望状态，但不知道实际运行状态。Helm虽然能管理配置版本，但也不了解应用健康状况。要靠运维人员去监控、判断、处理问题。

Operator则像个尽职的管家，时刻关注着集群的每个组件。哪个节点负载高了、哪个服务响应慢了，它都能立即发现并采取措施。这种主动式的状态管理大大提高了集群的可靠性。

长期维护成本

用YAML维护大规模集群时，配置文件会越来越多，改一处可能要动好几个地方。Helm虽然通过模板简化了一些工作，但复杂场景下仍需要大量人工操作。

Operator把Milvus运维的最佳实践都编码到了控制器中，新手也能轻松管理好集群。它提供了一致的操作接口，无论集群规模多大，维护成本都不会显著增加。

选择Operator管理Milvus，就是选择了更智能、更可靠的运维方式。它不仅降低了运维团队的工作负担，还通过自动化和智能化手段保障了集群的稳定运行。在云原生时代，这样的运维效率提升是很有价值的。

（4）Milvus 部署架构图

3.27-2.png

架构图说明

架构图清晰展示了Milvus Operator在Kubernetes集群中的部署结构。左侧蓝色区域展示了Operator的核心组件，包括Controller和Milvus-CRD。右侧绿色区域展示了Milvus集群的各个组件，如Proxy、Coord和Node等。中间通过'创建/管理'的箭头说明了Operator如何控制Milvus集群。底部橙色区域显示了依赖服务etcd和MinIO/S3/MQ。整体架构通过不同的颜色区块和箭头，直观地展示了组件间的交互关系和数据流向。

03

部署实践

实战环境涉及软件版本信息

• 操作系统：openEuler 22.03 LTS SP3 x86_64

• Kubernetes：v1.28.8

• Milvus： v.2.5.4

（1）前置条件

确认 k8s 集群存在存储类(StorageClass)，本试验环境存在两个存储类：

• 默认的使用本地盘的存储类local

• 使用 NFS 的存储类nfs-sc，生产环境不建议使用 NFS

kubectl get sc

NAME              PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGElocal (default)   openebs.io/local                              Delete          WaitForFirstConsumer   false                  284dnfs-sc            k8s-sigs.io/nfs-subdir-external-provisioner   Delete          Immediate              false                  230d

（2）安装 Milvus Operator

参阅 Milvus 官网安装文档，我们可以看到安装 Milvus Operator 有以下两种方式:

• With Helm

• With kubectl

本文使用简单、方便的 Kubectl 安装 Operator。

• 下载 Operator 部署资源清单

wget https://raw.githubusercontent.com/zilliztech/milvus-operator/main/deploy/manifests/deployment.yaml

• 替换镜像地址（可选）

当访问 DockerHub 受限，或是想使用自己镜像仓库时，执行以下命令替换镜像。

说明：本文中的镜像仓库地址为测试，请替换真实可用的仓库地址。

sed -i 's#milvusdb/milvus-operator:v1.2.1#registry.milvus-mirror.cn/&#g' deployment.yaml

• 运行以下命令，安装 Milvus Operator。

kubectl apply -f deployment.yaml

• 安装过程结束后，您将看到类似以下内容的输出。

namespace/milvus-operator createdserviceaccount/milvus-operator createdcustomresourcedefinition.apiextensions.k8s.io/milvusclusters.milvus.io createdcustomresourcedefinition.apiextensions.k8s.io/milvuses.milvus.io createdcustomresourcedefinition.apiextensions.k8s.io/milvusupgrades.milvus.io createdclusterrole.rbac.authorization.k8s.io/milvus-operator-manager-role createdclusterrolebinding.rbac.authorization.k8s.io/milvus-operator-manager-rolebinding createdrole.rbac.authorization.k8s.io/milvus-operator-leader-election-role createdrolebinding.rbac.authorization.k8s.io/milvus-operator-leader-election-rolebinding createdservice/milvus-operator-metrics-service createdservice/milvus-operator-webhook-service createddeployment.apps/milvus-operator created

• 运行以下命令，检查 Milvus Operator deployment 和 pod 资源是否创建成功

kubectl get deployment,pod -n milvus-operator

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE

（3）部署 Milvus 集群

3. 1部署 Milvus 集群

一旦 Milvus Operator pod 正确运行，您就可以按如下方式部署 Milvus 集群。

下载 Milvus 集群部署资源清单。

wget https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml

默认文件内容如下：

This is a sample to deploy a milvus cluster in milvus-operator's default configurations.

本文考虑以下几个常用场景，修改配置文件，实现自定义需求：

• 自定义集群名字： milvus-release-v25

• 自定义镜像（使用其它在线镜像或是本地离线镜像）： registry.milvus-mirror.cn/milvusdb/milvus:v2.5.4

• 自定义存储类的名字： 当 k8s 集群有多个存储时，可以需要指定持久化存储组件比如 Minio、etcd等，使用的存储类名称，本文使用 nfs-sc 作为示例

• 自定义 resource： 修改 Milvus 相关服务使用的 CPU 和内存上限，默认没有上限，设置 resource 上限，避免资源使用率激增导致 k8s 节点宕机

• 自动删除所有相关资源： 默认的配置删除 Milvus 集群时，不会删除已经创建的相关资源

参数配置参考链接：

• Milvus Custom Resource Definition

  https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

• Pulsar Values：：https://artifacthub.io/packages/helm/apache/pulsar/3.3.0?modal=values

修改后的内容如下：

apiVersion: milvus.io/v1beta1

运行以下命令，部署 Milvus 集群。

kubectl apply -f milvus_cluster_default.yaml

3.2 .验证 Milvus 集群状态

Milvus Operator 首先会创建 Milvus 依赖的中间件，例如 Etcd、Zookeeper、Pulsar 和 MinIO，然后创建 Milvus 组件，例如代理、协调器和节点。

3.2.1.查看 Deployment

kubectl get deployment

NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE

特别说明：

查看结果中发现Milvus Operator 会创建一个副本数为 0 的 standalone 和querynode-1 。

为什么会出现这2个副本数为0的服务呢？带着疑问向Milvus Operator仓库 提交了一个 Issue

官方的回复如下：

3.27-3.png

3.27-4.png

答复的结果大概意思是：

a、它像预期的那样工作。我们保留了独立部署，以便在不停止服务的情况下从集群扩展到独立部署。

b、对于querynode-1和querynode-0，它们在滚动升级时很有用。最终，正如您在本期中所粘贴的那样，两者中只有一个会运行。

3.2.2.验证所有 Pod 是否正确运行

一旦您的 Milvus 集群准备就绪，Milvus 集群中所有 pod 的状态应类似于以下内容。

kubectl get pods

NAME                                                    READY   STATUS      RESTARTS        AGE

3.2.3.验证存储类

验证是否使用了自定义的 storageClass： nfs-sc及自定义容量大小是否正确。

kubectl get pvc

NAME                                                                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE

3.2.4.验证 Milvus 资源限制

以 mixcoord 组件为例，验证资源限制resources.limits配置是否正确。

kubectl get deployment milvus-release-v25-milvus-mixcoord -o jsonpath='{.spec.template.spec.containers[*].resources.limits}' | jq

3.2.5.验证自定义镜像

kubectl get deployment milvus-release-v25-milvus-mixcoord -o jsonpath='{.spec.template.spec.containers[0].image}'

3.3.对外发布 Milvus 服务

经常有人问我，如何在 k8s 集群外部访问Milvus 服务？

我们使用 Operator 部署的 Milvus 服务默认使用了 ClusterIP 类型。因此，Milvus 只能被 k8s 集群内部应用访问，如果开放给集群外部，需要定义外部访问方式，本文选择最简单的 NodePort 对外发布 Milvus 服务。

创建并编辑外部访问 Milvus 服务的 svc 资源清单

vi milvus-external-svc.yaml

kind: Service

3.3.1.执行命令，创建外部服务。

kubectl apply -f milvus-external-svc.yaml

3.3.2.查看服务状态

kubectl get svc

NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                       AGE

3.3.3访问 Milvus WebUI

Milvus 内置 GUI 工具，名为 Milvus WebUI，您可以通过浏览器访问。Milvus Web UI 通过简单直观的界面增强了系统的可观察性。您可以使用 Milvus Web UI 观察 Milvus 组件和依赖项的统计数据和指标，检查数据库和集合详细信息，并列出详细的 Milvus 配置。有关 Milvus Web UI 的详细信息，请参阅Milvus WebUI 官方文档。

Milvus 部署完成后，使用浏览器打开以下链接，http://k8s任意节点IP:31531/webui/，打开 Web UI 界面。

3.27-5.png

03

写在最后

使用Milvus Operator管理，日常运维工作量大幅减少，特别是管理大型集群时效果更明显。手动配置容易出错的问题基本消失了，集群配置变得更可靠。需要扩容时，只需修改几个参数，资源利用率自然提高。系统出现故障时，Operator能自动修复，不用半夜爬起来救火。版本升级也从原来的漫长折腾变成了简单几步，回滚风险也小多了。

Operator使用成本

团队需要学习Kubernetes基础知识，这对传统运维人员来说需要时间适应。你还得有一个成熟的Kubernetes环境，小团队可能觉得有点小题大做。第一次设置也需要额外投入时间，而且会增加对Kubernetes生态的依赖。

从实用角度看，不同规模团队的收益差别很大。如果你只有几个节点的小集群，可能学习成本比收益还高。中等规模的集群大概半年到一年能看到回报。而大型集群则能很快体会到好处，通常几个月就能收回投资。

使用Opeartor存在的风险

使用Operator也有一些风险需要注意。过度依赖自动化可能导致团队对底层原理理解不足。Kubernetes与Operator版本不匹配有时会出问题。当系统出现故障，调试可能比传统方式更复杂。从手动部署迁移到Operator也需要谨慎规划，避免数据丢失。某种程度上，你也会更依赖特定的技术路线。

Operator使用建议

该不该用Operator？这要看你的实际情况。小团队资源有限，可以先用简单的手动部署，等业务稳定再考虑升级。正在快速发展的团队应该尽早学习Operator，为将来扩展做准备。大型团队则应该把Operator作为标准配置，投入资源构建自动化运维能力。

无论选择哪种方式，关键是要根据自身情况做出合理决策。Operator不是万能药，而是一种强大的工具。明智的做法是在充分了解自身需求和能力的基础上，逐步引入自动化，平衡短期成本和长期收益。

随着向量数据库在AI时代的重要性日益凸显，选择合适的运维策略将成为技术团队的关键竞争力。Milvus Operator为我们提供了一条高效之路，但每个团队都需要找到适合自己的节奏，在自动化与可控性之间取得平衡。