共计 1542 个字符，预计需要花费 4 分钟才能阅读完成。
3 月 21 日，FabEdge 正式公布了 V0.5 版本，该版本在 V0.4 的根底上，针对集群间拜访的需要，新增了 FabDNS 组件，实现了对跨集群服务拜访性能的反对。
FabEdge 一款基于 Kubernetes 构建的专一于边缘计算场景的容器网络计划，反对 KubeEdge / SuperEdge / OpenYurt 等支流边缘计算框架。旨在解决边缘计算场景下容器网络配置管理简单，网络割裂互不通信，短少拓扑感知能力，无奈提供就近拜访等问题。2022 年 3 月 8 日，FabEdge 被接收为 CNCF 沙箱级我的项目，成为 CNCF 沙箱中首个边缘容器网络我的项目。
1. 跨集群需要产生的背景
FabEdge 在 V0.4.0 时曾经反对多边缘集群通信，但集群间的互相拜访只能通过 IP 来拜访，即使拜访指标是一个服务也会如此，这与日常中应用 Kubernetes 的习惯极不相符。事实上，自多集群通信的需要存在以来，跨集群的服务发现和拜访的需要就始终存在，开源社区也始终在致力解决这个问题：
- Multi-cluster Service APIs
(https://github.com/kubernetes…) - Lighthouse
(https://submariner.io/getting…) - Cilium Load-balancing & Service Discovery
(https://docs.cilium.io/en/sta…)
既然曾经存在这些解决方案，为什么 FabEdge 要提出本人的解决方案呢？有如下起因：
- mcs-api 只是一套 API，须要其余实现者解决各个集群间服务信息的导出导入。
- Lighthouse 依赖于 submariner，而 submariner 并不是面向边缘场景的。
- Cilium 是一套整体解决方案，不能跟其余 CNI 共存，此外它也不是面向边缘场景。
2. FabDNS – FabEdge 的专属计划
为 FabEdge 提供跨集群服务拜访的组件叫 FabDNS (https://github.com/FabEdge/fa…)，它尝试达成以下指标：
- 它容许一个集群拜访其余集群提供的服务，服务类型仅限于 ClusterIP，Headless 两种。
- 一个服务能够部署于一个集群外部，也能够扩散在多个集群里。
- 提供肯定的具备拓扑感知的 DNS 解析，访问者能够就近拜访最近的服务节点。
FabDNS 有两个组件: service-hub 与 fab-dns。还提供了一个 CRD: GlobalService。一个集群若想将一个服务提供给其余集群，首先要将该服务标注为全局服务。service-hub 负责各个集群间全局服务的导出与导入，fab-dns 负责在集群外部提供全局服务的地址解析。每个集群部署时 FabDNS 时要标注拓扑信息，即 region 和 zone 信息，FabDNS 的拓扑感知就是基于这些拓扑信息来进行的。
3. 新个性实例解说
以上图为例，共有三个集群，北京集群是主集群，上海集群和苏州集群的 service-hub 都要通过北京集群的 service-hub 替换全局服务信息。北京和上海集群同时裸露了一个 nginx 服务和一个 mysql 服务，假如这些服务都是在 default 命名空间下。如果苏州集群的 pod 去拜访 nginx.default.global，那么它会被上海集群的 nginx 背地的 pod 响应，为什么呢？因为苏州和上海的 region 都是 south，而它本人自身并没有提供 nginx 服务或者没有裸露这个服务; 如果上海或北京的一个 pod 去拜访 nginx.default.global，那么响应的 pod 只会是各自集群的 pod，因为 zone 是匹配的。
以上即是 FabEdge V0.5.0 的新个性，欢送大家体验和提出贵重的意见。
点击 BoCloud 博云理解更多解决方案
