挑战
在生产环境中大规模运行 Milvus 带来了多项基础设施挑战：
- 固定容量 — 静态 Milvus 部署无法应对高峰时段 10 倍的查询负载峰值
- 数据丢失风险 — 临时存储上的 Pod 重启会导致大型集合的索引重建耗时数小时
- 成本效益低下 — 为峰值负载过度预配意味着 70% 的时间都在为闲置计算付费
- 存储成本 — 绑定到实例的块存储卷对于多 TB 的向量数据集而言成本高昂
- 索引重建 — 节点替换后重新索引数百万个向量会造成数小时的停机时间
- 多可用区 (Multi-AZ) 持久性 — 单可用区 (Single-AZ) 存储无法在可用区故障中幸存
我们的解决方案
我们部署了基于 Kubernetes (EKS) 的 Milvus，为查询节点配置了水平 Pod 自动扩缩容 (Horizontal Pod Autoscaling)，为计算配置了集群自动扩缩容 (Cluster Autoscaler)，并使用 Amazon S3 作为持久存储后端——从而消除了数据丢失风险，并将存储成本降低了约 80%。
架构
- 编排: Amazon EKS (Elastic Kubernetes Service)
- 计算: 由 Cluster Autoscaler 管理的 EC2 实例（混合实例类型）
- 向量数据库: 通过 Helm chart 以分布式模式部署的 Milvus
- 对象存储: Amazon S3，用于段文件、索引文件和 binlog 持久化
- 元数据: etcd 集群，用于 Milvus 协调和元数据
- 消息队列: 用于 Milvus 日志管道的消息流
- 监控: Prometheus + Grafana，用于 Milvus 指标和自动扩缩容信号
Kubernetes 上的 Milvus 分布式架构
组件部署
Milvus 以分布式模式运行，具有专用节点类型，每个类型都作为具有独立扩缩容能力的 Kubernetes 工作负载进行部署：
- 代理节点 (Proxy Nodes) — 处理客户端连接和请求路由
- 查询节点 (Query Nodes) — 执行向量搜索并将段加载到内存中
- 数据节点 (Data Nodes) — 处理写入路径并将段刷新到 S3
- 索引节点 (Index Nodes) — 构建向量索引并写入 S3
- 协调器 (Coordinator) — 集群协调和时间戳分配
- etcd — 元数据存储和服务发现
- 消息队列 (Message Queue) — 日志流和预写日志
水平 Pod 自动扩缩容 (HPA)
查询节点自动扩缩容
查询节点是主要的扩缩容目标——它们将向量段加载到内存中并执行搜索。扩缩容由多种指标驱动，包括 CPU 利用率、内存利用率、查询队列深度和 P99 查询延迟。HPA 配置了适当的最小/最大副本数、用于处理峰值的快速扩容以及避免抖动的逐步缩容。
索引节点自动扩缩容
索引节点根据待处理的索引构建作业进行扩缩容——当构建队列有待处理项时扩容，空闲时缩容。
EC2 集群自动扩缩容
实例策略
- 节点组: 多个具有不同实例类型的节点组，用于成本优化
- 查询工作负载: 内存优化型实例，用于内存中的向量段
- 索引工作负载: 计算优化型实例，用于 CPU 密集型索引构建
- Spot 实例: 索引节点和非关键数据节点在 Spot 实例上运行，以实现显著节省
- 按需实例 (On-Demand): 查询节点和协调器在按需实例上运行以确保稳定性
扩缩容行为
当 HPA 创建无法调度的 Pod 时，Cluster Autoscaler 会在适当的节点组中预置新的 EC2 实例。新的查询节点随后将它们分配的段从 S3 加载到内存中并开始提供查询服务，整个扩容过程在数分钟内完成。
S3 支持的持久存储
为什么选择 S3 而不是块存储
S3 为 Milvus 提供了优于块存储的显著优势：
- 大型数据集的存储成本降低约 80%
- 具有内置多可用区 (Multi-AZ) 复制功能的11个9的持久性
- 无限扩容，无需手动调整卷大小
- Pod 独立性 — 数据始终可用，不受 Pod 或节点生命周期的影响
- 无可用区 (AZ) 锁定 — 数据可从任何可用区访问
S3 数据流
- 写入路径: 数据节点在内存中缓冲插入，然后将密封段刷新到 S3
- 索引构建: 索引节点从 S3 读取段，构建索引，然后将索引文件写回 S3
- 查询路径: 查询节点从 S3 下载段和索引，加载到内存中，并提供查询服务
- 恢复: Pod 重启时，查询节点从 S3 重新下载分配的段（无数据丢失）
S3 性能优化
- 段大小调整 平衡 S3 请求成本与数据新鲜度
- 本地 SSD 缓存 在 NVMe 实例存储上，避免了对热点段的重复 S3 读取
- 并行下载 实现查询节点的快速启动
- 生命周期策略 将旧数据归档到更便宜的存储层
监控与可观测性
部署通过 Prometheus 和 Grafana 提供了全面的监控：
- 查询性能 — 延迟分布、QPS、缓存命中率
- 集群概览 — 节点数量、Pod 状态、资源利用率
- 存储健康 — S3 使用情况、段计数、刷新率
- 自动扩缩容事件 — HPA 事件、节点扩缩容、Pod 调度延迟
- 告警 — 针对高延迟、OOM 风险、刷新失败和容量限制的自动化告警
主要特点
- 查询节点 HPA — 基于 CPU、内存、延迟和队列深度的自动扩缩容
- EC2 Cluster Autoscaler — 混合实例类型的动态节点预置
- S3 持久性 — 11个9的持久性，比块存储便宜约 80%，可抵御 AZ 故障
- Spot 实例 — 索引和数据节点在 Spot 实例上运行，显著节省计算成本
- 本地 SSD 缓存 — NVMe 缓存消除了对热点段的重复 S3 读取
- 零停机恢复 — Pod 重启时从 S3 重新加载段，无数据丢失
- 多可用区 (Multi-AZ) — S3 存储 + 多可用区节点组，实现全面的 AZ 故障容忍
- 可观测性 — Prometheus + Grafana，提供 Milvus 特定指标和自动扩缩容可见性
成果
技术栈
常见问题
MicrocosmWorks configured horizontal pod autoscaling with custom metrics from Milvus's built-in memory usage exporter, triggering scale-out events when any query node exceeds 75% memory utilization. Collection segments are automatically redistributed across new nodes using Milvus's segment manager, preventing any single node from becoming a bottleneck.
MicrocosmWorks selected S3-backed storage using MinIO as the object storage layer because it decouples storage from compute, allowing query nodes to scale independently without provisioning new EBS volumes. This architecture reduces storage costs by approximately 60% compared to gp3 EBS volumes while maintaining sub-100ms segment load times from S3.
MicrocosmWorks configured the deployment with replica sets for each Milvus component, including query nodes, index nodes, and data nodes, with pod disruption budgets ensuring minimum availability during rolling updates. Since all persistent data resides in S3, a failed node's replacement can immediately access all segments without data migration.
MicrocosmWorks found that r6i.2xlarge instances provide the optimal cost-to-performance ratio for Milvus query workloads, offering 64GB of memory for in-memory segment caching at a competitive spot price. For GPU-accelerated index building, g5.xlarge instances with NVIDIA A10G GPUs reduced index build times by 8x compared to CPU-only builds.
MicrocosmWorks delivers Kubernetes infrastructure projects at rates of $30-$50/hr, with a Milvus autoscaling deployment including Helm chart customization, HPA configuration, S3 integration, and monitoring setup typically requiring 150-250 hours. Ongoing managed support for cluster optimization and upgrades is available at the same hourly rates.