冒死分析：不能访问自己的 SLB 是一个坏设计

[easterfan]

目前在做的专有云领域，一个基于 k8s 的容器云迁云项目， 部署 k8s 底座集群时，需要使用某专有云厂商提供的 slb 产品， 不小心踩到的坑，写了一篇博客记录； 但是对 slb 产品了解不深，观点可能有失偏颇

所以发到 v2 上，给大佬们批评指正

原文地址（博客托管在 github pages 上，加载可能很慢，请见谅）：👇🏻

冒死分析：不能访问自己的 SLB 是一个坏设计

[Alliot]

感谢分享， 有个与原文的问题： 博客这篇文章的布局有点奇怪，阅读起来字体和图很小，cmd++了几次才够看清😂

另外就是集群自发的请求到自身集群在设计的时候为什么不是一开始就走内部 svc 呢？这是出于什么考虑

[Reficul]

这个好像是 lvs snat 转发模式的限制

[perfectlife]

确实遇到过这个问题，还是挺恶心的，但是嘛只能忍了

[ttvast]

不同的技术方案有不同的优缺点。
LVS 就是有很多优势，自然也有这样的缺点。你完全可以调整业务逻辑，让 RIP 服务器不要访问自己的 VIP 。

[cyaki]

记得 AWS 的可以访问自己

[opengps]

slb 的出发点就是内网集群提高负载，所以这个产品从一出来就不能配置连接外边的节点加入集群

[FabricPath]

为什么不能访问自己？ 你注意观察一下你 RS 收到的报文，源 IP 是不是就是你真正的 IP ，L4LB 并没有给你做 SNAT ；
那问题来了，如果你自己访问自己，10.0.10.1 访问 VIP 172.16.0.1 ，RS 是 10.0.10.1 ，那你收到的报文是什么样子的？
是 10.0.10.1 -> 10.0.10.1 ，那么你回的报文在本地就终结了，不会回到 L4LB ，所以就不通了。

为什么 L7 的可以？因为 L7 是用户态代理，通过 TOA 或者 Header 的方式传递真正的 ClientIP ，Upstream 收到的报文的 SrcIP 是 L7LB 实例的 IP 。

为什么有的 L4LB 可以？因为 L4LB 分好几种模式，FULLNAT 模式的可以，但是 FULLNAT 一般是低端技术的代名词，限制非常多。

[FabricPath]

L4LB 一般都是做公网接入，IN-CLUSTER LB 方案太多，一般也不会去买云上 LB 实例，所以说到底，还是这个场景需求太小（小到忽略不计，基本没见过这么用的），但是对 L4LB 的稳定性、扩展性、性能都是个巨大挑战，并且还会有”怎么看到真实的 ClientIP“的问题，不能告诉用户”你要在你机器上装一个 TOA 模块“吧。

[rrfeng]

这又不是设计出来的……

[isno]

这几天正在写这方面的内容，https://www.thebyte.com.cn/balance/balance4-net.html 略微说几句。

@FabricPath 的回复说明了原因，L4LB 的定位做公网集群入口的。

我不知道你们为何要 RS 访问 DS ，但武断地说一句：集群内部机器再通过公网入口访问内部服务，这才是一个坏的设计。

[dropdatabase]

这个问题很多年了。自建 k8s 时遇到过，最后 apiserver 换成了公网 SLB.....

[devopsdogdog]

集群内部 肯定是走内网吧，只能说你有需求，或者是场景限制，算不上坏。

[easterfan]

@Alliot
博客是直接从本地导出 html ，样式比较极简😂

一开始没用 svc ，主要是考虑到有环路依赖，kubelet apiserver 依赖 ipvs ipvs 依赖 kubeproxy 写入规则 kubeproxy pod 的存活依赖 kubelet ，如果 kubeproxy 挂了规则被刷新了，会有死锁问题~

[easterfan]

@cyaki 感谢提醒，过两天试试 aws

[fairytale]

家用路由器也是，好像要搞什么端口回流。

[Reficul]

我记得 lvs 的这个限制可以通过某个内核参数控制，但是可能会存在安全问题。 另外，FULLNAT 模式也可以解决，但是代价是可能看不到真实的 sip 。

[CheckMySoul]

阿里云不是有内网负载均衡吗，试试那个呢。