«

grpc 异常并夯住的问题分析

在压力测试环境中,会出现了 kube-apiserver 连 etcd 报 grpc 异常并夯住的情况,此文做个简要分析。

其中核心错误是:

rpc error: code = 13 desc = stream terminated by RST_STREAM with error code: 1  

其中 code=13 表示:

checked the code 13:

    // Internal errors.  Means some invariants expected by underlying
    // system has been broken.  If you see one of these errors,
    // something is very broken.
    Internal

一、分析日志:

查看 kube-apiserver 前后日志,发现该异常出现的时间不固定,再重启后能恢复一段时间,间隔一段时间之后又可能出现或消失。

感觉该异常和当前请求压力关系比较大,就算重启后还是可能出现,压力小之后也不会自动恢复。

社区中同样记录了几个类似的issue,见下文。

二、etcd 社区

etcd社区记录的该issue非常类似:

https://github.com/coreos/etcd/issues/8179

描述中同样是 k8s 1.5 版本,报错一致:

rpc error: code = 13 desc = stream terminated by RST_STREAM with error code: 1  

原作者有回复说:

The assumption was internal error is not a fatal error.  

意思是认为该异常还不是 fatal 级别错误。

同时该 issue 中提到,该异常触发的机制通常也是高并发的访问同一个资源。

issue最后的回复说可能是 grpc 问题,解决方法是使用新版的 grpc。

But anyway, it seems it is grpc issue. We build our apiserver with newer version grpc, the hung issue has gone.  

三、k8s 社区

k8s社区也有几个相关的 issue 记录了该问题:

https://github.com/kubernetes/kubernetes/issues/45811

解决方案是替换 k8s 1.7 版本的 grpc 解决。

https://github.com/kubernetes/kubernetes/issues/57061

解决方案说是可能要把etcd升级到3.2.x,只需要修复 client 端即可。

四、方案讨论

1. 考虑 panic 方案:

如果此时使用 panic 机制,容易造成 apiserver 频繁 panic 重启,担心可能影响业务。

而且这种情况一般是压力比较大的情况下造成的,panic重启之后,还是有可能复现。

2. 考虑 告警 方案

如果考虑上报告警(告警需要添加新的类型),则要判断出现多少次开始上报,最关键是该如何处理此告警,一般来说还是需要降低压力并重启。

3. 考虑升级 grpc 版本,测试验证

通过社区的issue反馈,升级 grpc 版本是一种较为根本的解决方式,后续将升级 grpc 版本来试试效果。

分享