一、背景
阿里云k8s容器，在发布java应用程序的时候，客户端访问出现500错误。
后端服务是健康且可用的，网关层大量500错误请求，slb没有流入和流出流量。
经过回滚，仍未能解决错误。可谓是一次血的教训，特此记录下来，如果你也使用的是阿里云slb来实现k8s的service，值得一看，希望对你有所帮助。
在讲述这个事故前，我们还是照旧把系统架构交待清楚。
二、系统架构
1、kong upsteam
配置的是slb的内网IP+端口号
2、k8s的服务service
3、slb监听虚拟服务器
下面是重点需要关注的，，虚拟服务器组下的四个服务器，对应的就是4个pod的ip地址。
本文所述的发布事故，就是这里的服务器没有及时更新导致。
4、pod的ip地址
绿色的“Running”，表示Pod节点运行健康。
我这里使用了服务注册中心consul，从consul也能佐证java服务是健康无疑。
当然我还进一步验证，直接访问pod的接口，比如/info和/health接口，返回的版本号和健康状态也都是正常。
三、问题排查
1、kong网关报错
23937#0: *2832787172 connect() failed (111: Connection refused) while connecting to upstream
request: request: "PUT /api/v3/pub/user/extend HTTP/1.1"
2、slb监控
可以看到，出现故障之后，连接数和流量将至零。也就是说，http请求没有能够进入后端pod节点。
3、k8s容器的服务service
Error syncing load balancer [lb-bpxxxxxxxxxx6ndspgh]: Message: There is backend server has reached to the quota limit number of load balancers that it could be related to.
根据错误信息，查找阿里云的帮助文档，https://help.aliyun.com/zh/slb/classic-load-balancer/developer-reference/api-slb-2014-05-15-errorcodes
见下：
由此可见，是配额限制了。
继续查找文档，
https://help.aliyun.com/zh/slb/classic-load-balancer/product-overview/limits-1
可以看到，这里是默认50，所以我们到slb的配额设置查看，并申请调整至80。
申请调额：
四、踩过的坑
比较明确的一点是，问题出在slb。所以我们的思路，先是换一个，不行之后，又新建一个全新的slb。其实，问题在于我们忽视了k8s对很多指标的配额阈值。
1、slb的每个实例可以保有的监听数量超过了限制
所以尝试把k8s的服务service修改到另外一个slb，结果还是一样报错。
2、新建一个slb，跟上面的报错一样。
service状态一直是创建中
3、配额限制
我们缺少监控和报警，导致我们的思路，一直不能理解发布为啥会突然出错。
五、总结
1、Kong upstream配置pod IP
在没有解决问题前，只能在Kong的upstream配置pod IP，而非slb ip。虽然能解决，但是不够动态，显然是临时解决方案。
因为我们没有去做动态注册kong upstream。
2、阿里云的限额配置不直观
说同一台服务器可以重复添加为slb后端服务器的次数使用了53，可是到底是哪些，并不知晓。。为啥不弄个明细给用户可以查看。
3、架构的优化
- 去slb的依赖
- kong部署到k8s
- 引入ingress网关
- 使用k8s内部的发现机制
