本文主要是介绍阿里云SLB监听虚拟服务器组时，既有部署在k8s容器里的应用，又有部署在ecs机器上的应用，k8s应用无法连接部署在ecs机器上的应用，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、背景
阿里云SLB可以添加多个监听端口，包括http和tcp，但是当被添加的后端应用，既有部署在k8s里，也有部署在ecs机器里。同一个slb下，这种混合方式的监听，会导致部署在k8s应用中的应用无法连接后者，只能连接前者。
业务服务和通道服务都部署在阿里云的内网，同一个slb的监听，既有部署在ECS上的通道服务，也有部署在K8S容器里的通道服务。
而业务服务也是部署在K8S容器里，所以在业务服务配置的是内网slb的地址。
二、问题描述
外网通过外网SLB访问部署在ECS机器上和K8S容器的通道服务都正常。
但是部署在K8S容器里的业务服务，访问部署在K8S容器里的通道服务正常，却连接不了部署在ECS机器上的通道服务。
- 通过内网slb，访问部署在K8S容器里的通道服务端口，正常。
- 通过内网slb，访问部署在ECS上的通道服务端口，异常，连接被拒绝。
对比上面的两个测试，可以看到，前者正常，后者异常。
所以，下一步，我尝试对比测试外网SLB。
- 通过外网slb，访问部署在K8S容器里的通道服务端口，正常。
- 通过外网slb，访问部署在ECS上的通道服务端口，异常，连接被拒绝。
在外网访问部署在ECS上的通道服务都正常，但是在k8s容器里的业务应用访问却被拒绝。
这是什么原因？
同一个slb，为什么能访问部署在k8s容器里的通道服务，却不能访问部署在ecs上的通道服务呢？
ws连接被拒绝的报错详情见下：
org.java_websocket.exceptions.WebsocketNotConnectedException: nullat org.java_websocket.WebSocketImpl.send(WebSocketImpl.java:628)at org.java_websocket.WebSocketImpl.send(WebSocketImpl.java:605)at org.java_websocket.client.WebSocketClient.send(WebSocketClient.java:410)
三、内外网slb
阿里云SLB监听虚拟服务器组时，既有部署在k8s容器里的应用，又有部署在ecs机器上的应用。
见下面的两个截图示意，8888是部署在k8s容器里的应用端口，8889是部署在ecs机器上的应用端口。
四、总结
本文我们通过一个实际案例，踩到了一个slb使用过程中的大坑，特别对于混合式部署的场景。
在使用slb监听虚拟服务器组的时候，不要混用，否则出现非常诡异的现象，真让人莫名其妙。。
由于我们无法得到阿里云slb的实现逻辑，跟k8s有关，下面是我根据结果逆向猜测：
当K8S容器中的应用要访问同样部署在k8s容器里的另外一个应用时，它会遵循k8s的内部网络机制，而且忽略了slb下的非k8s容器里的应用。（并没有去判断，被监听的类型是ecs还是k8s，而是一棍子打死，认为同一个slb下的所有监听，要么都是ecs机器上的应用，要么都是k8s容器里的应用）
还是那句话，这个坑真的很深很深。
虽然很苦，还是建议阿里云控制台在运维人员对slb添加监听的时候，可以对此作一个提示或者限制。 以免出现外网能访问得通的一个地址，内网却被拒绝连接。（出现问题后，真的是一头雾水啊）
要想解决此问题，只有把k8s和ecs上的后端应用，分开监听虚拟服务器组。
这篇关于阿里云SLB监听虚拟服务器组时，既有部署在k8s容器里的应用，又有部署在ecs机器上的应用，k8s应用无法连接部署在ecs机器上的应用的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
