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 博云理解更多解决方案