周一早会，老板发话："小M，客户那边要上线一个向量搜索服务，你把Milvus集群部署一下，今天下班前搞定啊！对了，要高可用，要能扩展，要监控齐全...（省略八百字需求）"
你强颜欢笑地点头，心里却在盘算：手动配置一大堆yaml文件，改一个配置要改好几个地方，还得担心改错了整个集群就挂。想扩展节点？那得手动调度资源、配均衡，搞不好还会数据丢失。更别提监控告警了，光是配置Prometheus和Grafana就够喝一壶的。
但在Kubernetes的世界里，这活儿的环，闭了，但没完全闭。
与其像原始人一样手动搭建每一块积木，不如用现代工具一键生成高楼大厦。今天我们就来聊聊Milvus Operator这个"懒人神器"，如何让你的集群部署从"处处是坑"变成"一键搞定"，让老板的变态需求变成你的得心应手。
毕竟老运维都知道，针对脱发，一次Milvus Operator部署，顶十瓶米诺地尔。
Kubernetes Operator是一个用于管理和自动化Kubernetes应用程序的框架。它的设计初衷是为了简化Kubernetes应用程序的部署、管理和升级过程。
Operator 会定义一种“自定义资源”（Custom Resource Definition，简称 CRD）。你可以把它理解为一个新的“配置文件类型”，专门用来描述你的应用程序。
比如，你有一个数据库应用，Operator 可以定义一个叫 Database 的 CRD，你只需要在这个文件里写清楚你想要什么样的数据库（比如多大、什么版本等）。
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，就是选择了更智能、更可靠的运维方式。它不仅降低了运维团队的工作负担，还通过自动化和智能化手段保障了集群的稳定运行。在云原生时代，这样的运维效率提升是很有价值的。
架构图清晰展示了Milvus Operator在Kubernetes集群中的部署结构。左侧蓝色区域展示了Operator的核心组件，包括Controller和Milvus-CRD。右侧绿色区域展示了Milvus集群的各个组件，如Proxy、Coord和Node等。中间通过'创建/管理'的箭头说明了Operator如何控制Milvus集群。底部橙色区域显示了依赖服务etcd和MinIO/S3/MQ。整体架构通过不同的颜色区块和箭头，直观地展示了组件间的交互关系和数据流向。
实战环境涉及软件版本信息
操作系统：openEuler 22.03 LTS SP3 x86_64
Kubernetes：v1.28.8
Milvus：v.2.5.4
确认 k8s 集群存在存储类(StorageClass)，本试验环境存在两个存储类：
默认的使用本地盘的存储类local
使用 NFS 的存储类nfs-sc，生产环境不建议使用 NFS
kubectlgetsc
NAMEPROVISIONERRECLAIMPOLICYVOLUMEBINDINGMODEALLOWVOLUMEEXPANSIONAGElocal(default)openebs.io/localDeleteWaitForFirstConsumerfalse284dnfs-sck8s-sigs.io/nfs-subdir-external-provisionerDeleteImmediatefalse230d
参阅Milvus 官网安装文档，我们可以看到安装Milvus Operator有以下两种方式:
With Helm
With kubectl
本文使用简单、方便的 Kubectl 安装 Operator。
下载 Operator 部署资源清单
wgethttps://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。
kubectlapply-fdeployment.yaml
安装过程结束后，您将看到类似以下内容的输出。
namespace/milvus-operatorcreatedserviceaccount/milvus-operatorcreatedcustomresourcedefinition.apiextensions.k8s.io/milvusclusters.milvus.iocreatedcustomresourcedefinition.apiextensions.k8s.io/milvuses.milvus.iocreatedcustomresourcedefinition.apiextensions.k8s.io/milvusupgrades.milvus.iocreatedclusterrole.rbac.authorization.k8s.io/milvus-operator-manager-rolecreatedclusterrolebinding.rbac.authorization.k8s.io/milvus-operator-manager-rolebindingcreatedrole.rbac.authorization.k8s.io/milvus-operator-leader-election-rolecreatedrolebinding.rbac.authorization.k8s.io/milvus-operator-leader-election-rolebindingcreatedservice/milvus-operator-metrics-servicecreatedservice/milvus-operator-webhook-servicecreateddeployment.apps/milvus-operatorcreated
运行以下命令，检查 Milvus Operatordeployment 和 pod资源是否创建成功
kubectlgetdeployment,pod-nmilvus-operator
NAMEREADYUP-TO-DATEAVAILABLEAGEdeployment.apps/milvus-operator1/11110mNAMEREADYSTATUSRESTARTSAGEpod/milvus-operator-54d4fb854b-7hprh1/1Running097s
一旦 Milvus Operator pod 正确运行，您就可以按如下方式部署 Milvus 集群。
下载 Milvus 集群部署资源清单。
wgethttps://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml
默认文件内容如下：
Thisisasampletodeployamilvusclusterinmilvus-operator'sdefaultconfigurations.apiVersion:milvus.io/v1beta1kind:Milvusmetadata:name:my-releaselabels:app:milvusspec:mode:clusterdependencies:{}components:{}config:{}本文考虑以下几个常用场景，修改配置文件，实现自定义需求：
自定义集群名字： 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/v1beta1kind:Milvusmetadata:name:milvus-release-v25labels:app:milvusspec:mode:clusterconfig:{}components:image:registry.milvus-mirror.cn/milvusdb/milvus:v2.5.4resources:limits:cpu:2memory:8Gidependencies:etcd:inCluster:deletionPolicy
eletepvcDeletion:truevalues:global:imageRegistry:registry.milvus-mirror.cnstorageClass:nfs-scstorage:inCluster:deletionPolicyeletepvcDeletion:truevalues:resources:limits:cpu:2memory:8Giimage:repository:registry.milvus-mirror.cn/milvusdb/miniotag:RELEASE.2023-03-20T20-16-18Zpersistence:storageClass:nfs-scaccessMode:ReadWriteOncesize:10Gipulsar:inCluster:chartVersion:pulsar-v3deletionPolicyeletepvcDeletion:truevalues:existingStorageClassName:nfs-scpulsar_metadata:image:repository:registry.milvus-mirror.cn/apachepulsar/pulsartag:3.0.7zookeeper:replicaCount:3volumes:data:size:5GistorageClassName:nfs-scbookkeeper:volumes:journal:size:5GistorageClassName:nfs-scledgers:size:5GistorageClassName:nfs-scimages:zookeeper:repository:registry.milvus-mirror.cn/apachepulsar/pulsartag:3.0.7proxy:repository:registry.milvus-mirror.cn/apachepulsar/pulsartag:3.0.7broker:repository:registry.milvus-mirror.cn/apachepulsar/pulsartag:3.0.7bookie:repository:registry.milvus-mirror.cn/apachepulsar/pulsartag:3.0.7autorecovery:repository:registry.milvus-mirror.cn/apachepulsar/pulsartag:3.0.7运行以下命令，部署 Milvus 集群。
kubectlapply-fmilvus_cluster_default.yaml
Milvus Operator 首先会创建 Milvus 依赖的中间件，例如 Etcd、Zookeeper、Pulsar 和 MinIO，然后创建 Milvus 组件，例如代理、协调器和节点。
kubectlgetdeployment
NAMEREADYUP-TO-DATEAVAILABLEAGEmilvus-release-v25-milvus-datanode1/11152mmilvus-release-v25-milvus-indexnode1/11152mmilvus-release-v25-milvus-mixcoord1/11152mmilvus-release-v25-milvus-proxy1/11152mmilvus-release-v25-milvus-querynode-01/11152mmilvus-release-v25-milvus-querynode-10/00052mmilvus-release-v25-milvus-standalone0/00052m
特别说明：
查看结果中发现Milvus Operator 会创建一个副本数为 0的standalone和querynode-1。
为什么会出现这2个副本数为0的服务呢？带着疑问向Milvus Operator仓库 提交了一个 Issue
官方的回复如下：
答复的结果大概意思是：
a、它像预期的那样工作。我们保留了独立部署，以便在不停止服务的情况下从集群扩展到独立部署。
b、对于querynode-1和querynode-0，它们在滚动升级时很有用。最终，正如您在本期中所粘贴的那样，两者中只有一个会运行。
一旦您的 Milvus 集群准备就绪，Milvus 集群中所有 pod 的状态应类似于以下内容。
kubectlgetpods
NAMEREADYSTATUSRESTARTSAGEmilvus-release-v25-etcd-01/1Running07m15smilvus-release-v25-etcd-11/1Running07m15smilvus-release-v25-etcd-21/1Running07m15smilvus-release-v25-milvus-datanode-65bff7b4d9-9h2xv1/1Running04m35smilvus-release-v25-milvus-indexnode-5b5cbb4cdc-cxvwj1/1Running04m35smilvus-release-v25-milvus-mixcoord-64488898b5-r76rw1/1Running04m35smilvus-release-v25-milvus-proxy-5c7fbcb69-cqmq41/1Running04m35smilvus-release-v25-milvus-querynode-0-bc6f57d64-k2wnt1/1Running04m35smilvus-release-v25-minio-01/1Running07m14smilvus-release-v25-minio-11/1Running07m14smilvus-release-v25-minio-21/1Running07m14smilvus-release-v25-minio-31/1Running07m14smilvus-release-v25-pulsar-bookie-01/1Running07m12smilvus-release-v25-pulsar-bookie-11/1Running07m12smilvus-release-v25-pulsar-bookie-21/1Running07m12smilvus-release-v25-pulsar-bookie-init-5zf2z0/1Completed07m12smilvus-release-v25-pulsar-broker-01/1Running07m12smilvus-release-v25-pulsar-broker-11/1Running07m12smilvus-release-v25-pulsar-proxy-01/1Running07m12smilvus-release-v25-pulsar-proxy-11/1Running07m12smilvus-release-v25-pulsar-pulsar-init-twznd0/1Completed07m12smilvus-release-v25-pulsar-recovery-01/1Running1(6m25sago)7m12smilvus-release-v25-pulsar-zookeeper-01/1Running07m12smilvus-release-v25-pulsar-zookeeper-11/1Running07m12smilvus-release-v25-pulsar-zookeeper-21/1Running07m12s
验证是否使用了自定义的 storageClass：nfs-sc及自定义容量大小是否正确。
kubectlgetpvc
NAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEdata-milvus-release-v25-etcd-0Boundpvc-3273f9ec-819f-4e84-bdbe-3cd9df697a5f10GiRWOnfs-sc36mdata-milvus-release-v25-etcd-1Boundpvc-01743e13-a989-4aea-8fd0-632ea8b13f9810GiRWOnfs-sc36mdata-milvus-release-v25-etcd-2Boundpvc-594f1a63-efba-4993-89e6-3ee5e333073d10GiRWOnfs-sc36mexport-milvus-release-v25-minio-0Boundpvc-477d4e3b-69d7-4bbe-80f7-b747dc4c79f710GiRWOnfs-sc36mexport-milvus-release-v25-minio-1Boundpvc-b12e46fa-8d29-48fb-9ac1-98f80d67b54310GiRWOnfs-sc36mexport-milvus-release-v25-minio-2Boundpvc-2e67893e-9611-43dd-9550-b3a7705699ae10GiRWOnfs-sc36mexport-milvus-release-v25-minio-3Boundpvc-572c4565-bc38-4215-a13c-061d9199fdea10GiRWOnfs-sc36mmilvus-release-v25-pulsar-bookie-journal-milvus-release-v25-pulsar-bookie-0Boundpvc-183eff99-7a87-406d-9f17-b0fb30c7c0b35GiRWOnfs-sc36mmilvus-release-v25-pulsar-bookie-journal-milvus-release-v25-pulsar-bookie-1Boundpvc-ebe32304-7d92-44d1-b6fb-4cbaf3207d255GiRWOnfs-sc36mmilvus-release-v25-pulsar-bookie-journal-milvus-release-v25-pulsar-bookie-2Boundpvc-2ead9186-3d44-4faa-9ae7-784be7ecf6d25GiRWOnfs-sc36mmilvus-release-v25-pulsar-bookie-ledgers-milvus-release-v25-pulsar-bookie-0Boundpvc-ff1b632d-0a66-4c13-a3bb-2550f93076145GiRWOnfs-sc36mmilvus-release-v25-pulsar-bookie-ledgers-milvus-release-v25-pulsar-bookie-1Boundpvc-57159e85-bb48-48a9-9706-7a95af8da1575GiRWOnfs-sc36mmilvus-release-v25-pulsar-bookie-ledgers-milvus-release-v25-pulsar-bookie-2Boundpvc-eb235f29-afbd-4a40-9a7d-0340a96860535GiRWOnfs-sc36mmilvus-release-v25-pulsar-zookeeper-data-milvus-release-v25-pulsar-zookeeper-0Boundpvc-40e02974-3b7d-4f42-bfa7-3252b7615a365GiRWOnfs-sc36mmilvus-release-v25-pulsar-zookeeper-data-milvus-release-v25-pulsar-zookeeper-1Boundpvc-75904229-3bbf-458e-b0e3-3982e430621b5GiRWOnfs-sc36mmilvus-release-v25-pulsar-zookeeper-data-milvus-release-v25-pulsar-zookeeper-2Boundpvc-2e068b79-75ac-4aa9-9e90-423ff399bad05GiRWOnfs-sc36m
以mixcoord 组件为例，验证资源限制resources.limits配置是否正确。
kubectlgetdeploymentmilvus-release-v25-milvus-mixcoord-ojsonpath='{.spec.template.spec.containers[*].resources.limits}'|jq{"cpu":"2","memory":"8Gi"}kubectlgetdeploymentmilvus-release-v25-milvus-mixcoord-ojsonpath='{.spec.template.spec.containers[0].image}'registry.milvus-mirror.cn/milvusdb/milvus:v2.5.4经常有人问我，如何在 k8s 集群外部访问Milvus 服务？
我们使用 Operator 部署的 Milvus 服务默认使用了 ClusterIP 类型。因此，Milvus 只能被 k8s 集群内部应用访问，如果开放给集群外部，需要定义外部访问方式，本文选择最简单的 NodePort 对外发布 Milvus 服务。
创建并编辑外部访问 Milvus 服务的 svc 资源清单
vimilvus-external-svc.yaml
kind:ServiceapiVersion:v1metadata:name:milvus-release-v25-external-svcnamespace:defaultlabels:app:dmilvus-release-v25-external-svcspec:ports:-name:milvusprotocol:TCPport:19530targetPort:19530nodePort:31530-name:milvus-webprotocol:TCPport:9091targetPort:9091nodePort:31531selector:app.kubernetes.io/component:proxyapp.kubernetes.io/instance:milvus-release-v25app.kubernetes.io/name:milvusclusterIP:type:NodePort
kubectlapply-fmilvus-external-svc.yaml
kubectlgetsvc
NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGEmilvus-release-v25-external-svcNodePort10.233.8.166<none>19530:31530/TCP,9091:31531/TCP43smilvus-release-v25-etcdClusterIP10.233.27.134<none>2379/TCP,2380/TCP16mmilvus-release-v25-etcd-headlessClusterIPNone<none>2379/TCP,2380/TCP16mmilvus-release-v25-milvusClusterIP10.233.55.194<none>19530/TCP,9091/TCP13mmilvus-release-v25-minioClusterIP10.233.1.56<none>9000/TCP16mmilvus-release-v25-minio-svcClusterIPNone<none>9000/TCP16mmilvus-release-v25-pulsar-bookieClusterIPNone<none>3181/TCP,8000/TCP16mmilvus-release-v25-pulsar-brokerClusterIPNone<none>8080/TCP,6650/TCP16mmilvus-release-v25-pulsar-proxyClusterIP10.233.30.132<none>80/TCP,6650/TCP16mmilvus-release-v25-pulsar-recoveryClusterIPNone<none>8000/TCP16mmilvus-release-v25-pulsar-zookeeperClusterIPNone<none>8000/TCP,2888/TCP,3888/TCP,2181/TCP16m
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 界面。
使用Milvus Operator管理，日常运维工作量大幅减少，特别是管理大型集群时效果更明显。手动配置容易出错的问题基本消失了，集群配置变得更可靠。需要扩容时，只需修改几个参数，资源利用率自然提高。系统出现故障时，Operator能自动修复，不用半夜爬起来救火。版本升级也从原来的漫长折腾变成了简单几步，回滚风险也小多了。
Operator使用成本
团队需要学习Kubernetes基础知识，这对传统运维人员来说需要时间适应。你还得有一个成熟的Kubernetes环境，小团队可能觉得有点小题大做。第一次设置也需要额外投入时间，而且会增加对Kubernetes生态的依赖。
从实用角度看，不同规模团队的收益差别很大。如果你只有几个节点的小集群，可能学习成本比收益还高。中等规模的集群大概半年到一年能看到回报。而大型集群则能很快体会到好处，通常几个月就能收回投资。
使用Opeartor存在的风险
使用Operator也有一些风险需要注意。过度依赖自动化可能导致团队对底层原理理解不足。Kubernetes与Operator版本不匹配有时会出问题。当系统出现故障，调试可能比传统方式更复杂。从手动部署迁移到Operator也需要谨慎规划，避免数据丢失。某种程度上，你也会更依赖特定的技术路线。
Operator使用建议
该不该用Operator？这要看你的实际情况。小团队资源有限，可以先用简单的手动部署，等业务稳定再考虑升级。正在快速发展的团队应该尽早学习Operator，为将来扩展做准备。大型团队则应该把Operator作为标准配置，投入资源构建自动化运维能力。
无论选择哪种方式，关键是要根据自身情况做出合理决策。Operator不是万能药，而是一种强大的工具。明智的做法是在充分了解自身需求和能力的基础上，逐步引入自动化，平衡短期成本和长期收益。
随着向量数据库在AI时代的重要性日益凸显，选择合适的运维策略将成为技术团队的关键竞争力。Milvus Operator为我们提供了一条高效之路，但每个团队都需要找到适合自己的节奏，在自动化与可控性之间取得平衡。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |