# FabEdge: a Kubernetes data plane that reaches edge nodes over IPsec tunnels > FabEdge is a CNCF sandbox project that adds a layer-3 tunnel data plane between a cloud Kubernetes cluster and edge nodes or standalone edge clusters, with an operator that pushes per-node configuration and a DNS component that answers with the nearest reachable endpoint. It complements Calico or Flannel rather than replacing them. **FabEdge/fabedge** — Secure Edge Networking Solution Based On Kubernetes - Repository: https://github.com/FabEdge/fabedge - Website: http://www.fabedge.io/ - Stars: 527 · Forks: 58 - Language: Go - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/fabedge-fabedge ## The gap FabEdge is trying to close FabEdge is described as a secure container networking solution based on Kubernetes, focusing on edge computing. It enables cloud-edge and edge-edge collaboration and solves problems including complex configuration management, network isolation, and being unaware of the underlying topology. It supports weak networks such as 4G, 5G and WiFi, and the main use cases named are IoT, IoV and smart city. That last list is the key to reading the project correctly. FabEdge is not a general CNI. It exists for deployments where a container is running somewhere with a cellular radio and an unreliable uplink, and where the standard assumption that every node is on a fast local network does not hold. The design assumption is that the cloud cluster and the edge are separate realities joined by a wide-area link. The edge side may be an edge node, a remote node joined to the cluster via an edge computing framework such as KubeEdge, or an entire standalone Kubernetes cluster. FabEdge supports all of those, and the README says it supports the major edge computing frameworks, naming KubeEdge, SuperEdge and OpenYurt. The project is a sandbox project of the Cloud Native Computing Foundation, which is a meaningful statement about how the project is governed and how conservative you should expect the API to be. The primary language is Go, the licence is Apache-2.0, and the default branch is main. The homepage is fabedge.io, and there is a Chinese README as well as the English one. The release history deserves attention before anything else. The recent releases are v0.8.1 from 2023-06-21, v0.8.0 from 2023-04-21 and v0.7.0 from 2022-09-26, while the last push to the repository was on 2026-09-16. So there has been no tagged release in more than three years even though commits continue to land. That does not mean the code is dead, but it does mean there is no published artifact to pin. ## Four components and what each one does The README describes the architecture in terms of four components, and understanding their division of labour is the fastest way to understand the project. FabEdge consists of Operators, Connector, Agent, and Cloud-Agent. The Operator is the control plane piece. It monitors Kubernetes resources such as nodes, services and endpoints in the cloud, and creates a configmap for each edge node containing configuration information such as the subnet, the tunnel and the load balancing rules. The operator is also responsible for managing the life cycle of the agent pod for each edge node. The Connector is responsible for terminating the tunnels from edge nodes and forwarding traffic between the cloud and the edge. It relies on the cloud CNI plug-in to forward traffic to other non-connector nodes in the cloud, which is the detail that explains why FabEdge sits alongside Calico or Flannel rather than instead of them. The Cloud-Agent runs on the non-connector nodes in the cluster and manages the routes to remote peers. Each edge node runs an agent and consumes its own configmap, and the agent has three functions: managing the configuration file of the CNI plug-in for that node, managing the tunnels of the node, and managing the load balancing rules of the node. Fab-DNS runs in all the clusters to provide the topology-aware service discovery capability by intercepting the DNS queries. That last component is the one that changes user-visible behaviour rather than just plumbing. Because Fab-DNS intercepts DNS queries, a pod resolving a service name gets an answer that depends on where the request came from, and the topology-aware service discovery feature reduces service access latency by using the nearest available service endpoint. The four features the README leads with map onto this. Kubernetes native, meaning compatible with Kubernetes and transparent to applications. Automatic configuration management, where the addresses, certificates, endpoints and tunnels are automatically managed rather than configured by hand. Cloud-edge and edge-edge collaboration through the secure tunnels. And topology-aware service discovery. The claimed advantages are stated as three points: standard, suitable for any protocol and any application; secure, using mature and stable IPsec technology and a certificate-based authentication system; and easy to use, adopting the Operator pattern to automatically manage addresses, nodes and certificates, minimizing human intervention. ## How it relates to Calico, Flannel and the edge frameworks The section titled FabEdge vs. Calico/Flannel/etc answers the question that anyone evaluating this will have first, and the answer is that the two do different jobs. FabEdge is not to replace the traditional Kubernetes network plugins such as Calico or Flannel. As in the architecture diagram, Calico or Flannel is used within the cloud for communication between cloud nodes, while FabEdge is a complement to it for the edge-cloud and edge-edge communication. The architecture description reinforces this. The cloud can be any Kubernetes cluster with a supported CNI network plug-in, including Calico and Flannel. FabEdge builds a layer-3 data plane with tunnels in addition to the control plane managed by KubeEdge, SuperEdge, OpenYurt and others. So the picture is: inside the cloud, an ordinary CNI handles pod-to-pod traffic. Between the cloud and the edge, FabEdge's tunnels carry it. The edge framework, whichever of the three you use, handles how the edge node itself is joined to and managed by the cluster, and FabEdge handles the network connectivity for the workloads running there. Layer 3 is a deliberate choice worth noting. Because the data plane is IPsec tunnels rather than an overlay of its own, FabEdge is not tied to a particular CNI's addressing model and does not need to be the thing that gives pods their addresses. The go.mod reflects the same layering: strongswan/govici is an IPsec-related dependency, vishvananda/netlink handles the Linux routing and link management, and moby/ipvs provides IP virtual server support for the load balancing rules on each node. There is also a DNS component built on CoreDNS, with coredns/coredns and coredns/caddy as dependencies, and the repository has a coredns/ directory. CoreDNS is already the default cluster DNS, so Fab-DNS is an extension of something already running rather than a new DNS server to deploy. The examples directory contains communities.yaml, mysql.yaml and nginx.yaml, which are the workloads used to exercise the data plane. ## Building it, and the release cadence question The Makefile shows that FabEdge builds five binaries, and knowing their names tells you the component structure again. ```bash BINARIES := agent connector operator cloud-agent node ``` The build target compiles each of them into an output directory under the name fabedge-, and there are per-component image targets alongside it, including a strongswan-image target, which is the IPsec dependency packaged separately. The make help target lists the common entry points: make all, make agent, make connector, make operator, and the image and test targets including make e2e-test. ```bash make all make e2e-test ``` There is a QUICK variable that skips the fmt and vet steps, which is the kind of shortcut a developer adds to shorten a loop. The version stamping is thorough: the build takes the version from git describe --tags, the build time from the date, and the git commit, and passes all three into the binary through linker flags against a metadata package. The test target uses ginkgo if it is on the PATH and falls back to go test otherwise, and the e2e-test target compiles a separate binary from the ./test/e2e directory. What is missing from the README is a release process. The tag is derived from git describe --tags, and the most recent tag in the release list is v0.8.1 from June 2023. The repository has a CHANGELOG/ directory, a MAINTAINERS.md and a deploy/ directory with manifests, but the README does not describe how a released artifact is produced or where to obtain one. If you need an installable version, that is the question to ask the project. The documentation index in the README is short and useful: a getting started page, a user guide, an FAQ, an uninstall guide and a troubleshooting guide, all under docs/. There is also a community meeting on the second and fourth Thursday of every month, with notes on shimo.im and recordings on a bilibili channel, and contact through email, a Slack channel named #fabedge, and a WeChat group. ## Where FabEdge is the wrong choice There are three limits, and the first is the one that decides whether the project applies to your setup. The first is that FabEdge only helps if you already have the edge-computing problem it targets. Its scope is a cloud Kubernetes cluster plus remote nodes joined through an edge framework, on links that are slow or lossy enough that tunnels and topology-aware routing matter. If your nodes are in one datacentre on a fast network, the standard CNI plus the cluster's own service discovery is enough and FabEdge adds an operator, four agents, a DNS component and a tunnel layer for nothing. The second is the gap between the commit activity and the releases. The last push was on 2026-09-16, so work is happening, but the newest published release is v0.8.1 from 2023-06-21, and the go.mod pins go 1.17 with Kubernetes libraries at 0.22.5, which is a Kubernetes 1.22 era dependency set. On a current cluster you are building against a controller-runtime from that generation, which raises the practical question of whether the operator will work against a recent Kubernetes API server at all. The README does not say, and that is a question to ask the maintainers before you plan around it. The third is the operational surface. FabEdge runs an operator in the cloud cluster, a connector or cloud-agent on the cloud nodes, an agent on every edge node, and Fab-DNS in every cluster, all of which have to agree on tunnel state, certificates and routing. Every one of those is a thing that can be in a different state during an incident, and the troubleshooting guide in the docs exists because of it. The IPsec choice cuts both ways as well. Mature and stable is a fair description, and certificate-based authentication means the trust model is sound. It also means the data plane has a stateful cryptographic component in the path, and a tunnel that cannot re-establish across a network change is a hard failure rather than a degraded one. On a link that drops regularly, that is a real operational concern and the project offers no control plane for it beyond what the operator manages. The honest alternative depends on what you are solving. For many edge deployments the practical answer is a simpler one: keep the workload close to the data, use the edge framework's own networking, and accept that cross-site service calls are slow. Where you genuinely need cloud services reachable from a remote site with automatic configuration, the alternatives are a managed SD-WAN or VPN overlay in front of the cluster, which offloads the tunnel management to a vendor and removes the operator from your on-call rotation, at the cost of a per-site appliance and a recurring fee. What FabEdge offers that those do not is the Kubernetes-native path. The tunnel endpoints are pods managed by an operator, the addressing comes from the cluster's own CNI, and Fab-DNS integrates with the DNS that is already there. For a team that wants cloud-edge connectivity expressed in Kubernetes resources rather than in network appliances, that is a genuine advantage, provided you are prepared to run the operator yourself. ## Conclusion Adopt FabEdge if you run a Kubernetes cluster with nodes joined from remote sites over unreliable links and need those nodes to reach cloud services through a managed tunnel with automatic configuration. Do not adopt it as a replacement for an in-cluster CNI, because the README is explicit that Calico and Flannel still handle traffic between cloud nodes. Before you evaluate it, check that your edge framework is one of the supported ones and note the release history stops at v0.8.1 from 2023 even though the last push was on 2026-09-16. ## FAQ ### What is FabEdge and what problem does it solve? FabEdge is a secure container networking solution based on Kubernetes, focusing on edge computing, enabling cloud-edge and edge-edge collaboration. It addresses complex configuration management, network isolation and lack of topology awareness, and supports weak networks such as 4G, 5G and WiFi. ### Does FabEdge replace Calico or Flannel? No. The README states that FabEdge is not to replace traditional Kubernetes network plugins such as Calico or Flannel. Those plugins are used within the cloud for communication between cloud nodes, while FabEdge complements them for edge-cloud and edge-edge communication. ### What are the components of FabEdge? The README names four: Operators, which watch cloud resources and create a configmap of subnet, tunnel and load balancing rules per edge node and manage agent pod lifecycles; Connector, which terminates tunnels from edge nodes and forwards traffic between cloud and edge; Cloud-Agent, which runs on non-connector cloud nodes and manages routes to remote peers; and the per-node agent. Fab-DNS runs in all clusters for topology-aware service discovery by intercepting DNS queries. ### Which edge computing frameworks does FabEdge support? The README says FabEdge supports the major edge computing frameworks, naming KubeEdge, SuperEdge and OpenYurt. It supports both edge nodes, which are remote nodes joined to the cluster via one of those frameworks, and edge clusters, which are standalone Kubernetes clusters. ### How is FabEdge built and what are the release numbers? The Makefile builds five binaries named agent, connector, operator, cloud-agent and node into an output directory, with per-component image targets and an e2e-test target. The recent releases are v0.8.1 from 2023-06-21, v0.8.0 from 2023-04-21 and v0.7.0 from 2022-09-26, while the last push to the repository was on 2026-09-16. ## Sources - [FabEdge/fabedge on GitHub](https://github.com/FabEdge/fabedge) - [License: Apache-2.0](https://github.com/FabEdge/fabedge/blob/main/LICENSE) - [Project website](http://www.fabedge.io/) - [README](https://github.com/FabEdge/fabedge/blob/main/README.md) - [Releases](https://github.com/FabEdge/fabedge/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fabedge-fabedge