故事背景
在 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 都进行了适当的调优。
但是，没有任何效果
