我们被一个 kong 的性能 bug 折腾了一个通宵

最新推荐文章于 2024-02-28 21:34:02 发布

尔达 Erda

最新推荐文章于 2024-02-28 21:34:02 发布

阅读量1.9k

点赞数

文章标签： bug 运维 kubernetes 云原生程序员

本文链接：https://blog.csdn.net/m0_59358648/article/details/125994496

版权

在升级Kong到2.2.0版本后，我们遭遇了一个严重的问题：调用admin接口时，Kong实例内存持续上涨，甚至触发worker OOM，影响业务性能。尝试参数调优、数据清理、读写分离和迁移RDS等措施无效。通过复现问题，我们确定是Kong内部LRUCache未正确释放导致的内存泄漏，此问题在最新版本中依然存在。解决方案是限制route/service数量并增大Kong Pod内存。

摘要由CSDN通过智能技术生成

故事背景

在 Erda 的技术架构中，我们使用了 kong 作为 API 网关的技术选型。因其具备高并发低延时的特性，同时结合了 Kubernetes Ingress Controller，基于云原生的声明式配置方式，能够实现丰富的 API 策略。

在我们最早交付的集群中，kong 还是较为早期的 0.14 版本，随着业务层面对安全的要求日益趋增，我们需要基于 kong 实现安全插件，帮助系统能够具备更好的安全能力。由于较为早期的 0.14 版本不能使用 go-pluginserver 来扩展 kong 的插件机制，我们不得不在古老的集群中将 kong 升级为相对较新的 2.2.0 版本。

升级过程就不在此赘述了，基本就是照着官方文档一步步顺利的升级上去，但是在升级上去之后的几天里，我们的 SRE 团队收到了非常密集的咨询甚至是声讨，部署在该集群上的业务间歇性的无法访问，延迟非常高。

一系列失败的尝试

参数调优

最开始为了快速修复这个问题，我们对 kong 的 NGINX_WORKER_PROCESSES、MEM_CACHE_SIZE、 DB_UPDATE_FREQUENCY、WORKER_STATE_UPDATE_FREQUENCY 参数以及 postgres 的 work_mem、 share_buffers 都进行了适当的调优。

但是，没有任何效果 😓。