本文介绍了在k8s集群中，由于gRPC服务的长连接特性导致的负载不均衡问题，分析了问题的原因并提出了包括客户端负载均衡和服务网格在内的解决方案。同时，文中还涉及了内存泄漏的排查和解决，以及如何通过iptables和netfilter理解k8s的负载均衡机制。
在k8s集群中部署gRPC服务并使用k8s中的Service来对外暴露服务，这是比较常见的用法，但是这种方式却会导致gRPC服务负载不均衡，进而影响整个系统的负载能力甚至‘雪崩’。
背景
第一次，线上遇到大量接口RT超过10s触发了系统告警，运维反馈k8s集群无异常，负载无明显上升。将报警接口相关的服务重启一番后发现并无改善。但是开发人员使用链路追踪系统发现，比较慢的请求总是某个gRPC服务中的几个POD导致，由其他POD处理的请求并不会出现超时告警。
第二次，同样遇到接口RT超过阈值触发告警，从k8s中查到某个gRPC服务（关键服务）重启次数异常，查看重启原因时发现是OOM Killed，OOM killed并不是负载不均衡直接导致的，但是也有一定的关系，这个后面再说。前两次由于监控不够完善（于我而言，运维的很多面板都没有权限，没办法排查）。期间利用pprof分析了该服务内存泄漏点，并修复上线观察。经过第二次问题并解决之后，线上超时告警恢复正常水平，但是该 deployment 下的几个POD占用资源（Mem / CPU / Network-IO），差距甚大（参见后文）。
最低0.47元/天 解锁文章
996
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
