阿里云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: null
	at 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上的后端应用，分开监听虚拟服务器组。