OpenShift部署的Milvus 1.0插入向量时gRPC报Socket关闭错误

gRPC 状态码14（UNAVAILABLE）对应的 Broken pipe 报错，本质是客户端发起请求时，到 Milvus 服务端的 TCP 链路已被中间节点或服务端进程主动断开。结合环境特征，按排查优先级从高到低对应问题点与修复方案：

链路空闲超时匹配排查 #

首次插入操作完成约10分钟后报错复现的特征，和 OpenShift 平台默认的 NodePort 链路空闲超时阈值（常规为10分钟）完全匹配：

• 触发逻辑：Milvus 客户端默认复用 gRPC 长连接，不会在空闲状态下主动发送保活探测包。当链路空闲超过10分钟，OpenShift 节点上的 kube-proxy 或内部负载组件会直接静默丢弃该连接的流量，客户端和 Milvus 服务进程都不会立刻收到连接断开通知，下次发起插入请求时就会触发 Broken pipe 报错。
• 修复方案：
  • 客户端侧开启 gRPC 保活机制：配置grpc.keepalive_time_ms为30000（每30秒发送一次保活心跳）、grpc.keepalive_timeout_ms为10000，确保长连接不会被中间层因空闲超时回收。
  • 服务端调整 Milvus gRPC 配置：将grpc.max_connection_idle设置为5分钟、grpc.http2.max_pings_without_data设置为0，允许客户端的保活探测包正常透传。

持久卷残留权限异常排查 #

挂载过持久卷后，即便后续移除PV报错仍复现的特征，是 OpenShift 安全上下文机制引发的典型权限问题：

• 触发逻辑：OpenShift 默认给每个 Pod 分配随机的非root高UID用户运行容器进程。第一次挂载持久卷时，Milvus 进程会以当时的运行UID在PV存储目录下写入各类元数据、段文件；后续将PV从Pod配置中移除时，容器会使用节点本地空目录作为存储路径，但之前存储在容器可写层的Milvus配置文件、运行时残留元数据文件，属主仍为第一次挂PV时的随机UID。Pod重启后，OpenShift会为该Pod分配全新的随机高UID，当前运行用户没有权限读取/修改容器可写层的残留文件，会导致Milvus的存储组件、消息队列组件在后台静默崩溃，主API进程未主动断开客户端连接，但底层请求处理子进程已经终止，无规律触发Broken pipe报错。
• 修复方案：
  • 不要仅移除PV配置，需彻底删除整个Milvus的Pod资源，让OpenShift清空所有容器可写层的残留文件，重新拉起全新实例后再验证插入操作稳定性。
  • 固定Pod运行用户UID，避免随机UID带来的权限漂移：在Pod的securityContext配置中指定固定的runAsUser、fsGroup值，统一所有存储目录、可写层文件的属主，避免重启后出现权限不匹配问题。

旧版本已知缺陷验证 #

Milvus 1.0 属于已停止社区维护的旧版本，存在两个匹配当前场景的已知问题：

• 当插入向量的单请求大小超过gRPC默认的4MB消息上限时，服务端会直接断开连接触发Broken pipe，需调整Milvus配置中的grpc.max_send_message_length、grpc.max_receive_message_length为-1（无限制），或根据实际批量插入的数据包大小调整为对应阈值（如100MB）。
• 旧版本Milvus在存储组件刷盘失败时，不会向上层API进程抛出错误，而是直接触发进程崩溃。需查看Pod内所有组件的运行日志（不只是主API进程），确认是否存在permission denied、no space left on device这类刷盘报错，对应修复存储目录权限或磁盘容量问题。

内容的提问来源于stack exchange，提问作者paferllume