使用K8s托管gRPC服务遇连接重置错误，咨询故障原因

你遇到的具体错误信息：

rpc error: code = Unavailable desc = closing transport due to: connection error: desc = "error reading from server: read tcp <ipaddr>:52220-><internal ip addr>:8070: read: connection reset by peer", received prior goaway: code: NO_ERROR

这个错误包含两个关键线索：TCP层面的connection reset by peer（对端主动重置连接），以及gRPC层的received prior goaway: code: NO_ERROR（服务端之前发送了正常关闭的GOAWAY帧）。下面是可能的原因，其中包含K8s网络相关的诱因：

一、K8s集群/网络层面的可能原因 #

• 后端Pod被驱逐或重启：K8s因节点资源不足、HPA缩容、节点维护等原因终止服务端Pod时，操作系统会主动重置该Pod上所有未关闭的TCP连接。如果请求发起后不久Pod刚好被重启，就会触发这个错误。
• Service/Endpoint更新延迟：当后端Pod上下线时，K8s的Endpoint列表更新存在短暂延迟，客户端此时可能仍在连接已下线的Pod，导致连接被重置。
• 网络策略或防火墙拦截：K8s网络策略、节点防火墙规则的变更，可能中途切断已建立的TCP连接，触发连接重置。
• 负载均衡超时：如果使用Ingress或Service的负载均衡器，若超时配置过短，负载均衡器会主动断开空闲或超时的连接，进而引发这个错误。

二、gRPC连接管理层面的可能原因 #

• 服务端主动回收连接：服务端可能因连接空闲超时、资源回收策略，发送NO_ERROR的GOAWAY帧通知客户端不要再复用该连接，但客户端仍用旧连接发起请求，服务端会直接重置连接。
• 客户端连接复用逻辑问题：如果客户端未正确处理GOAWAY帧，没有及时切换到新连接，继续复用已被标记为关闭的连接，就会出现这类错误。

三、其他非K8s因素 #

• 服务端进程崩溃：服务端程序异常退出时，操作系统会自动重置所有未关闭的TCP连接。
• 节点硬件/网络故障：节点网卡故障、跨节点网络波动等底层问题，也会导致TCP连接被异常中断。

针对你的问题：这个错误完全有可能是K8s网络故障导致的，比如上述Pod驱逐、Endpoint更新延迟、网络策略拦截、节点网络波动等场景，都属于K8s环境下的网络相关诱因。

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