Milvus 滚动升级自动化测试实战指南基于 Kubernetes CRD 的无中断升级验证方案【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus本文以 Milvus 开源仓库中tests/python_client/rolling_upgrade目录下的滚动升级测试体系为主线系统讲解 Milvus 在 Kubernetes 环境下通过 Milvus Operator CRD 完成无中断版本升级的验证方案从默认整集群升级、组件逐一手动升级到升级期间并发/单类请求压测、成功率与 RTO 指标断言以及 Pod 状态监控与 parquet 结果归档。读完本文你将掌握这套测试套件的完整用法、每个命令行参数的默认值与语义、底层 kubectl patch 与 Python 探针的实现原理以及如何在自己的集群上复现升级不中断业务的验收流程。一、为什么需要滚动升级测试Milvus 是云原生向量数据库集群由 proxy、rootCoord、dataCoord、indexCoord、queryCoord、dataNode、queryNode、indexNode 等多个无状态/有状态组件组成。在生产环境中升级版本时若直接删除重建全部 Pod会造成服务中断和数据读写失败。滚动升级Rolling Upgrade的目标是在保持服务持续可用Continuous service availability的前提下逐批替换组件镜像同时保证数据完整性Data integrity升级过程中写入的数据不丢失、不损坏性能影响最小化Minimal performance impact请求成功率与恢复时间RTO维持在可接受范围客户端操作兼容Client operation compatibility升级前后客户端 API 行为一致insert/search/query/delete 等操作不报错。仓库在 tests/python_client/rolling_upgrade/README.md 中对这套测试体系给出了整体说明本文后续章节将逐层展开。二、测试套件全景目录结构与职责划分整个滚动升级测试套件位于 tests/python_client/rolling_upgrade共 6 个 Python 文件 2 个 CRD 配置文件类别职责test_rolling_update_by_default.py核心测试默认滚动升级通过 CRD 一次性更新所有组件镜像test_rolling_update_one_by_one.py核心测试逐组件升级按序逐个 patch 各组件镜像并等待就绪testcases/test_concurrent_request_operation_for_rolling_update.py操作测试升级期间并发压测 insert/search/query/deletetestcases/test_single_request_operation_for_rolling_update.py操作测试升级期间单类操作测试含 create/flush/indexmonitor_rolling_update.py工具独立的 Pod 状态轮询监控脚本conftest.py配置pytest 命令行参数注册与 fixturemilvus_crd/milvus_crd.yamlCRD标准集群部署配置cluster 模式milvus_crd/milvus_mixcoord_crd.yamlCRDMixCoord 合并协调器部署配置2.1 默认滚动升级测试test_rolling_update_by_default.py 中test_operations的核心流程读取milvus_crd.yaml将spec.components.image设置为目标镜像{new_image_repo}:{new_image_tag}将spec.components.imageUpdateMode设置为rollingUpgrade默认升级模式由 Milvus Operator 接管滚动替换清空各子组件indexNode、rootCoord、dataCoord、indexCoord、queryCoord、dataNode、queryNode、proxy、standalone、mixCoord中残留的image字段确保统一走顶层镜像通过kubectl patch kind name --patch-file milvus_crd_modified.yaml --type merge提交变更轮询kubectl get pod与kubectl get mi name直到 Milvus 自定义资源状态中出现TrueReady判定升级完成。该用例标注为pytest.mark.tags(CaseLabel.L3)属于 L3 级别的系统级验证。2.2 逐组件升级测试test_rolling_update_one_by_one.py 支持更精细的控制其默认升级顺序为[indexNode, rootCoord, [dataCoord, indexCoord], queryCoord, queryNode, dataNode, proxy]其中[dataCoord, indexCoord]表示这两个组件在同一批次内同时更新。执行时测试对每个组件单独 patch 镜像并等待集群恢复健康等待逻辑包括每 10 秒轮询kubectl get mi要求输出同时包含True和Healthy健康状态需连续稳定 1 分钟每 10 秒检查一次、共 6 次才视为通过对queryNode额外调用check_querynode_upgrade_complete确认旧的 queryNode Deployment 已缩到 0/0、新的 Deployment 已满副本 Ready才认为升级彻底完成。文件同时提供pause_and_resume_rolling函数通过向 CRD patchspec.components.paused: true/false实现暂停/恢复指定 Deployment 的滚动更新并支持传入updated_pod_count更新多少个副本后暂停与pause_seconds暂停秒数用于模拟升级中途停顿场景。三、关键配置参数详解3.1 命令行参数conftest.py所有核心参数均在 conftest.py 中通过pytest_addoption注册并通过同名 fixture 注入测试参数类型默认值语义--release_namestrdeploy-test部署测试使用的 Helm release 名--new_image_repostrharbor.milvus.io/dockerhub/milvusdb/milvus目标镜像仓库--new_image_tagstrmaster-20231031-ab6dbf76目标版本 tag--components_orderstr[indexNode, rootCoord, [dataCoord, indexCoord], queryCoord, queryNode, dataNode, proxy]组件更新顺序字符串形式传入测试内eval解析--paused_componentsstr[queryNode]升级期间需要暂停的组件列表--paused_durationint300暂停时长秒--prepare_databoolFalse是否通过 bulk insert 预写数据此外操作类测试依赖的--request_duration压测持续时间默认 1800 秒与--is_check是否强制执行成功率断言默认 True由更上层的 pytest 配置注册例如 tests/python_client/cdc/conftest.py 中的request_duration/is_checkfixture 就展示了这类参数的注册与 bool 兼容处理方式。注意--request_duration支持30m、1h30m这类人类可读写法测试内部会通过字符串替换h→*3600、m→*60、去掉s后eval换算为秒。3.2 CRD 关键字段milvus_crd.yamlmaster CRD 示例apiVersionmilvus.io/v1beta1kindMilvus中与滚动升级直接相关的字段spec: mode: cluster components: enableRollingUpdate: true # 开启 Operator 的滚动更新能力 imageUpdateMode: rollingUpgrade # 镜像更新模式rollingUpgrade / all / rollingRestart image: milvusdb/milvus:2.2.0-20231021-1f972292 # 当前运行版本 proxy: replicas: 1 dataNode: replicas: 3 indexNode: replicas: 3 queryNode: replicas: 3 resources: requests: { cpu: 2, memory: 8Gi } limits: { cpu: 4, memory: 16Gi } dependencies: msgStreamType: kafka # 消息流中间件类型 etcd: inCluster: deletionPolicy: Retain storage: type: Azure inCluster: deletionPolicy: Retain示例还展示了enableActiveStandby: truerootCoord/dataCoord/queryCoord/indexCoord 均启用主备与quotaAndLimits.enable: false关闭配额限制以便压力测试充分放量、log.level: debug等辅助配置。dependencies 部分配置了 inCluster 的 etcd3 副本、kafka3 副本以及可选的 pulsar、Azure 存储deletionPolicy: Retain保证升级期间元数据与对象存储不丢失。混部 MixCoord 版本则在 components 中以单个mixCoord组件replicas: 1取代了分散的 rootCoord/dataCoord/queryCoord/indexCoord适合验证 MixCoord 架构下的升级路径并额外演示了podAnnotationspyroscope 性能剖析注解等字段。四、运行测试4.1 前置条件一个已安装Milvus Operator的 Kubernetes 集群kubectl已配置好集群访问权限测试通过kubectlCLI 与 Kubernetes Python SDK 操作资源Python 环境已安装 pytest、pymilvus、kubernetes、pandas、PyYAML、loguru 等依赖套件位于 tests/python_client 体系内复用其common/utils/chaos等公共模块。4.2 基本用法# 运行默认滚动升级测试一次性更新全部组件 pytest test_rolling_update_by_default.py -v # 运行逐组件升级测试 pytest test_rolling_update_one_by_one.py -v # 自定义参数换目标镜像、暂停 queryNode 600 秒 pytest test_rolling_update_one_by_one.py \ --new_image_repomilvusdb/milvus \ --new_image_tagv2.4.1 \ --paused_componentsqueryNode \ --paused_duration600 # 升级期间并发压测持续 30 分钟强制断言 pytest testcases/test_concurrent_request_operation_for_rolling_update.py \ --request_duration30m --is_checktrue # 升级期间单类操作测试 pytest testcases/test_single_request_operation_for_rolling_update.py \ --request_duration1800升级操作测试文件还依赖--host默认 127.0.0.1、--port默认 19530、--user/--password、--minio_host等连接参数用于建立指向被测集群的 pymilvus 连接。4.3 监控 Pod 状态独立的监控脚本 monitor_rolling_update.py 会在指定时长内以固定间隔反复执行kubectl get pod | grep release_name并输出日志# 监控 10 分钟每 5 秒采样一次过滤 release 名 my-release python monitor_rolling_update.py --duration 600 --interval 5 --release my-release参数-d/--duration默认 600 秒、-i/--interval默认 5 秒、-n/--release_name。该脚本常与升级测试并行运行用于留存升级过程中 Pod 重建、ContainerCreating、Running 等状态的完整时间线。五、成功标准Success Criteria5.1 升级期间成功率Success Rate所有操作的成功率 ≥ 98%RTO每类操作的恢复时间Recovery Time Objective≤ 10 秒Pod 状态所有 Pod 最终达到 Ready。5.2 升级完成后成功率所有操作成功率 100%集群健康所有组件健康数据完整性无数据丢失或损坏。这些标准并非只是文档描述而是硬编码在测试断言中。以 test_concurrent_request_operation_for_rolling_update.py 为例if is_check: assert_statistic(self.health_checkers, succ_rate_threshold0.98) # 升级期间 ≥98% for k, v in self.health_checkers.items(): rto v.get_rto() pytest.assume(rto 10, f{k} rto expect 10s but get {rto}s) # RTO ≤ 10s ... assert_statistic(self.health_checkers, succ_rate_threshold1.0) # 升级后 100%同时测试在升级完成后会通过wait_pods_ready(chaos-testing, label_selector)等待所有 Pod 就绪并再压测 120 秒确认成功率回到 100%覆盖升级后集群恢复这一阶段。六、测试结果归档两类操作测试都会将结果以parquet 格式保存到/tmp/ci_logs/下便于 CI 收集与分析并发测试/tmp/ci_logs/concurrent_request_result.parquet单类测试/tmp/ci_logs/single_request_result.parquet每条记录包含字段op操作类型、failed request ts失败请求时间戳列表、failed request order失败请求序号列表、rto该类操作的恢复时间。文件在测试中通过 pandasdf.to_parquet()生成。七、底层原理从测试看滚动升级如何工作7.1 升级过程架构Rolling Upgrade Process: ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Old Image │ -- │ Upgrading │ -- │ New Image │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ v v v [Running Pods] [Mixed Pods] [Updated Pods] │ │ │ └────────────────────┴────────────────────┘ Continuous Operations升级过程经历旧镜像 Pod 全量运行 → 新旧 Pod 混合共存 → 新镜像 Pod 全量接管三个阶段期间业务请求持续打到集群上由测试的 monitor checker 线程持续发起这正是验证滚动升级无中断的关键。7.2 两种升级策略的实现差异从两个测试文件的源码可以清晰看到策略差异默认测试rollingUpgrade 模式只 patch 顶层spec.components.image与imageUpdateMode: rollingUpgrade由Milvus Operator统一编排所有组件的滚动替换顺序逐组件测试all 模式先删除顶层 image设置imageUpdateMode: all再按components_order逐个组件 patch 各自image字段每次 patch 后都等待集群健康稳定实现对升级顺序、停顿paused的完全手工控制。7.3 健康探针与稳定性判定逐组件测试对就绪的判定非常严格不仅要求kubectl get mi输出包含True与Healthy还要求该状态连续保持 60 秒6 次 × 10 秒采样不波动对 queryNode 这种数据面核心组件还需额外确认旧 Deployment 副本完全归零。这种稳定窗口 双状态检查的设计能有效避免升级中途的抖动被误判为成功。7.4 操作检查器Checker机制操作测试依赖chaos.checker模块的检查器类。单类测试注册了 7 类检查器checkers { Op.create: CollectionCreateChecker(collection_nameNone, schemaschema), Op.insert: InsertChecker(collection_namec_name, schemaschema), Op.flush: FlushChecker(collection_namec_name, schemaschema), Op.index: IndexCreateChecker(collection_nameNone, schemaschema), Op.search: SearchChecker(collection_namec_name, schemaschema), Op.query: QueryChecker(collection_namec_name, schemaschema), Op.delete: DeleteChecker(collection_namec_name, schemaschema), }并发测试则聚焦 insert/search/query/delete 四类高频操作bulk_insert检查器被注释保留便于按需启用。测试通过cc.start_monitor_threads(health_checkers)启动各检查器的监控线程在request_duration内持续施压期间每duration // 10秒调用一次check_result()汇总失败记录结束后调用pause()停止并读取fail_records与get_rto()。八、实战建议先跑单类测试再跑并发测试单类测试覆盖 create/flush/index 等 DDL 类操作能更早暴露升级对元数据面的影响并发测试更贴近真实负载。合理设置--paused_duration默认 300 秒。若需验证长暂停场景下客户端连接保持与重试机制可适当加大如 600 秒。组合使用监控脚本升级期间并行运行monitor_rolling_update.py可留存 Pod 重建时序便于失败时回溯是哪个组件、哪个阶段出现问题。利用 parquet 结果定位瓶颈failed request ts与rto字段可直接用于分析失败请求是否集中在某组件替换窗口从而判断是否需要调整components_order。注意 CRD 与脚本的路径约定套件运行时默认读取 CRD 文件并生成milvus_crd_modified.yaml临时 patch 文件默认生成在测试文件同目录提交到 CI 前请确认该目录可写且kubectl所在 namespace 与 CRD 中metadata.namespace示例为chaos-testing一致。九、小结Milvus 的滚动升级测试体系提供了一条从升级编排到业务验证的完整闭环通过milvus.io/v1beta1CRD 与kubectl patch驱动 Operator 完成整集群或逐组件的镜像替换通过基于 pymilvus 的 checker 线程在升级窗口内持续压测并断言 ≥98% 成功率与 ≤10s RTO最后以 parquet 形式归档结果。这套方案既可作为 Milvus 版本发布前的质量门槛也可直接借鉴到任何基于 Kubernetes Operator 的分布式系统升级验收中。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考