共计 2375 个字符，预计需要花费 6 分钟才能阅读完成。
在上一篇监控问题排查的文章中，笔者剖析了 KubeSphere 3.1.0 集成 KubeEdge 中的边缘监控原理和问题排查思路，在介绍 EdgeWatcher 组件时提到了“边缘节点的内网 IP 须要集群内惟一”这样的限度条件。本文就来深入分析一下这个问题，并尝试给各位边缘开发者提供一些解决的倡议和思路。
失常场景
在边缘节点退出云端集群时，须要指定“Node Name”和“Internal IP”，顾名思义，就是边缘节点的节点名称和内网 IP 地址。这里的内网 IP 地址就是本文的主题，该地址须要在集群内惟一。
KubeSphere 在 EdgeWatcher 中提供了用户指定的内网 IP 是否被占用的验证性能。验证失败 (IP 已被占用) 的状况下，则不会为该边缘节点提供退出集群的命令行输入。上面两张图展现了验证胜利和失败的场景。
验证胜利：
验证失败：
能够说，KubeSphere 在这一点上曾经做的十分用心了，给用户提供了 UI 的“Validate”按钮和后盾 API，不论是间接应用还是基于 KubeSphere 的二次开发都会十分便捷。
非法场景
在上一节中展现了内网 IP 被占用的后果就是不能退出集群，因为该 IP 曾经被注册在了 EdgeWatcher 中，不能再被其余边缘节点应用。
那么如果一个 IP 还没有被注册到 EdgeWatcher 中，也就是边缘节点没有被真正接入集群时，还是能够跳过这一步验证，将雷同内网 IP 的两个边缘节点退出同一个集群中，制作这个非法的应用场景。
这个非法场景带来的问题就是：雷同 IP 的“较早退出集群”的边缘节点在 logs exec 和 metrics 的性能上都会生效。即下图的运维性能都是没有数据的。
之前，笔者也在 KubeSphere 的开发者社区提过这个问题，同时也和负责边缘模块的社区开发者有过交换，确认了在 KubeSphere 的产品设计上，内网 IP 须要管理员或者用户自行按需进行布局，保障不反复。
潜在问题
公有部署的场景下，做到 IP 的统一规划是比拟容易的。那么如果基于 KubeSphere 的边缘解决方案在私有云场景中会怎么样呢？
私有云用户不受布局限度，同时并发量比拟大，呈现“雷同 IP 退出集群”这个问题的概率会十分大。最终会导致局部用户的 logs exec 和 metrics 性能生效，大量问题工单随之而来，用户黏度降落。所以私有云场景下，这个问题是必须要解决的，上面咱们就详细分析一下问题的根本原因和解决思路。
根本原因
解决问题前，要把问题产生的根本原因摸清楚，这样能力对症下药地去解决和解决问题。
在上一篇文章中，其实也简要介绍了 metrics 数据获取在 KubeEdge 边缘场景下的实现原理：kube-apiserver 上的 iptables 转发给云端的 Cloudcore，Cloudcore 通过和 Edgecore 之间的 WebSocket 通道向边缘端进行音讯和数据传递。
logs 和 exec 性能的实现原理与 metrics 是一样的。上面这张图简要的形容了这几项性能在 KubeEdge 下的工作流程。
联合下面这张图的 cloudcore (KubeEdge 云端组件)的红色局部，来解释一下为什么内网 IP 须要集群内惟一。
边缘节点 (edgecore，即 KubeEdge 边缘组件) 在连贯到云端集群时，和云端之间会建设一个 websocket 通道。云端为了后续通过该 websocket 通道和边缘节点通信，须要将这个通道作为 session 保留在云端。体现在数据结构上就是一个“内网 IP”为 key，session (websocket 通道)为 value 的 map。
看到这里，各位开发者应该就很容易了解了，如果内网 IP 雷同，则会笼罩较早退出集群的边缘节点的 session 记录。这时云端去查找“被笼罩了 session 的边缘节点”上 POD 的监控和运维数据，必定是找不到的。
问题的根本原因找到了，解决的思路也就比拟明确了，下一大节笔者简略论述下这个问题的解决思路。
下图是在 KubeEdge 的边缘场景下，logs 性能的时序图，感兴趣的开发者能够进一步理解。
解决思路
上一节梳理分明了根本原因，解决思路也就比拟清晰明了。本着非侵入式的革新准则，尽量少改变 KubeSphere 和 KubeEdge，对下层业务逻辑进行加强和扩大是笔者心目中的最佳抉择。
既然根本原因是 IP 抵触导致 session 被笼罩，那就很天然的想到提供集群内不反复 IP 的调配服务，也就是常说的 IPAM。在云端的业务逻辑层引入 IPAM 服务，为用户边缘节点提供集群内惟一的 IP 调配能力。
同时还须要关注一点的是，IPAM 服务调配进去的惟一 IP 属于外部实现，不能当作“Internal IP”展现给用户。用户看到的边缘节点内网 IP 地址依然是用户自行布局和填写的 IP，只不过革新后的内网 IP 不再作为 session 的 key，也不再须要进行抵触查验，只在页面上展现不便用户搜寻，进步产品的易用性。
上面就是该思路下的节点退出流程图，供各位开发者参考。
依据下面的流程图，笔者也大略列举一下上述解决方案，须要批改的点：
- 新建集群内 IPAM 服务，提供调配，回收 IP 等性能，留神并发解决。
- 新建业务层节点服务，提供节点名称，展现用 IP，惟一 IP 等长久化能力。
- 批改 keadm 和 edgecore，反对 node IP 可选
- 批改 cloudcore，在节点注册时通过节点名称查问惟一 IP，作为 Internal IP 注册节点。
- 在业务层北向接口暗藏惟一 IP(K8s 上的 internal IP)，替换成用户输出的展现 IP。
后记
通过对景象和原理的剖析，咱们提出了在私有云环境下基于 KubeSphere 的边缘节点 IP 抵触问题的解决方案。限于笔者的技术能力，有可能还存在着更为简略无效的解决办法，欢送各位开发者提出宝贵意见，让咱们一起把基于 KubeSphere 的边缘解决方案做大做强。
本文由博客一文多发平台 OpenWrite 公布！
