As Kubernetes adoption grows with the business around it, a single cluster often stops being enough. Teams start spreading workloads across multiple clusters, and then a practical question appears very quickly: how should those clusters talk to each other?
There is no single perfect answer. Some approaches extend the underlying network, some build tunnels at the CNI layer, and some avoid connecting pod IP space directly at all. Each option makes different trade-offs around compatibility, control, service discovery, protocol support, and operational complexity.
Below are five common approaches to cross-cluster communication in Kubernetes, along with how they work, where they fit well, and where they fall short.
1. Underlay networking
This category includes options such as macvlan, ipvlan, Kube-OVN underlay, and VPC CNI implementations on various clouds.
From a CNI perspective, this is the most straightforward model. The idea is simple: let the underlying infrastructure provide connectivity at the network layer, and the cluster networking becomes connected almost automatically. That might mean VPC peering in a public cloud, or physical network routing and L2 extension in an on-premises environment. Once the lower-layer network is reachable end to end, pods in different clusters can reach each other through that shared foundation.
Strengths
- It is the simplest option from the CNI side and usually requires no extra cross-cluster networking component.
- The architecture is easy to understand because responsibility for inter-cluster communication stays with the underlying network.
Limits
- It depends on specific kinds of CNI and infrastructure. Underlay networking is not always available, and in some environments only an overlay model is practical.
- It becomes hard to implement across heterogeneous environments, especially between different clouds or between public cloud and private infrastructure.
- It only solves basic pod-to-pod network reachability. Higher-level capabilities such as service discovery, DNS handling, and network policy across clusters are still missing.
- It typically opens connectivity across all cluster networks at once, without much fine-grained control.
2. Overlay CNIs with built-in multi-cluster support
When underlay networking is not an option, some CNIs provide cross-cluster communication at the overlay layer. Examples include Cilium Cluster Mesh, Antrea Multi-Cluster, and Kube-OVN with ovn-ic.
Even though these projects differ in implementation details, the general pattern is similar. A set of nodes inside each cluster is chosen as gateway nodes, and tunnels are established between those gateways. Traffic that needs to cross cluster boundaries is forwarded through them.
Strengths
- Multi-cluster connectivity is built into the CNI itself, so no separate system is required.
Limits
- The solution is tied to a specific CNI, so it does not help when clusters use different CNIs.
- Overlapping CIDRs are generally not handled, which means IP planning must be done carefully ahead of time.
- Cilium has a more complete implementation, including service discovery and network policy across clusters, but other options often provide only basic pod network connectivity.
- Like underlay-based approaches, these solutions usually connect all cluster networks as a whole, without fine-grained selection of what should communicate.
3. Submariner
Cross-cluster connectivity is a common enough requirement that many CNIs have ended up solving similar problems in similar ways. Submariner exists as a more general answer: a CNI-independent multi-cluster network plugin that can connect clusters even when they use different CNIs. The project was originally created by engineers from Rancher and is now a CNCF Sandbox project, with active participation from Red Hat engineers as well.
Submariner works by selecting gateway nodes inside each cluster and connecting those gateways over VXLAN. Cross-cluster traffic is carried through that VXLAN path. It relies on the CNI to send egress traffic back into the host network first, where Submariner can then intercept and forward it. For service discovery across clusters, it deploys CoreDNS components, and it uses Globalnet Controller to deal with overlapping CIDRs.
Strengths
- It is CNI-agnostic to a meaningful extent and can connect clusters running different CNIs.
- It supports cross-cluster service discovery, including Services and DNS resolution.
- It can handle overlapping CIDRs, which avoids the unpleasant situation where clusters are deployed independently and only later need to be interconnected.
Limits
- It is not compatible with every CNI. If traffic is invisible to the host, as with macvlan or Cilium fast-path behavior, Submariner cannot intercept that traffic and redirect it into its own tunnel.
- Gateway nodes currently operate in an active-standby model rather than horizontal load balancing, which may create performance bottlenecks under heavy traffic.
- It still tends to connect the full container networks between clusters, so control is not especially granular.
4. Skupper
Among these options, Skupper is one of the most interesting because it avoids the all-or-nothing nature of full network connectivity and instead connects services on demand. It also takes a very different path technically, using a Layer 7 message-queue model rather than relying on the underlying network or CNI. That gives it a low barrier to entry and makes it unusually easy to try out. Based on current contribution patterns, Red Hat engineers appear to be the main contributors.
The core concept in Skupper is a VAN, or Virtual Application Network. Instead of directly stitching together pod IP networks with tunnels, it connects communication at the application layer. Conceptually, this is somewhat similar to the later ideas behind ServiceExport and ServiceImport, although Skupper started earlier, before those community concepts had become established.
Its implementation is also quite unconventional. Rather than forwarding packets directly through a tunnel, Skupper builds a large message-queue fabric spanning multiple clusters. Data for cross-cluster communication is sent into that queueing system, and the remote side consumes it. In spirit, this resembles a reverse proxy, but using a message-queue architecture to implement it is a notably original design choice. Services effectively become subscription points for messages, so the communication path between client and server can be established and controlled through the queueing model.
Strengths
- It has strong CNI compatibility because it does not depend on CNI behavior and moves the problem up to the application layer.
- It is easy to get started with. It does not require heavy upfront network planning, and overlapping CIDRs are not a concern. A CLI is available for quick tests and demos.
- It does not connect the entire pod network. Instead, it exposes only the required services, which allows much finer control and reduces dependence on the underlying network.
Limits
- The documentation currently describes support for TCP only. UDP and lower-level protocols such as ICMP are problematic.
- Because communication is relayed through a message system, original IP information is lost.
- The message-forwarding model is clever but unusual, and it may cost performance in areas such as latency and throughput.
- TCP is stateful, so there is a real question about how completely it can be represented through a message-queue abstraction and how strong compatibility really is in edge cases.
5. KubeSlice
KubeSlice is another CNCF Sandbox project, and it tries to address the gap left by the other approaches. Tunnel-based solutions generally struggle with fine-grained control and full CNI independence, while application-layer solutions trade away complete protocol compatibility. KubeSlice introduces a different idea aimed at covering both.
At the lowest level, its approach is surprisingly direct: it dynamically adds an extra network interface to selected pods, builds a cross-cluster overlay on top of that interface, and then provides service discovery and network policy within that overlay. Users can create a network composed only of specific namespaces or even a subset of pods across clusters. Because the design uses an additional interface and a Layer 2-style network path, it offers both flexible scoping and broad protocol compatibility.
Strengths
- It is highly compatible with existing CNIs because it inserts a separate network interface and does not care what the original CNI is doing. Since the added network is independent, existing address conflicts are also less of a concern.
- Protocol compatibility is strong for the same reason: traffic is forwarded through an extra interface, so essentially all network protocols can work.
- It offers a high degree of flexibility. KubeSlice provides CLI tooling to create and join networks dynamically, allowing users to build multiple cross-cluster virtual networks around application needs.
- The feature set is quite complete. According to its documentation, the additional overlay includes service discovery, DNS, QoS, network policy, and monitoring.
Limits
- Because this is effectively a dual-NIC model, applications may need to be aware of which network to use. That can imply application changes.
- Since cross-cluster traffic uses a secondary interface rather than the pod’s primary IP, external systems such as monitoring and tracing may also need adjustments.
- The documentation suggests this was originally an internal project later opened to the public. Many usage patterns and APIs are not explained clearly, and some parameters are difficult to understand without reading reference material closely. The feature set looks broad, but the documentation still needs work before outside users can use it comfortably.
Choosing between them
These five approaches differ less in whether they can connect clusters, and more in what they assume and what they expose.
If the underlying infrastructure already gives you clean network reachability, underlay networking is the simplest answer. If you are committed to a specific CNI and it already supports multi-cluster operation, the built-in overlay features can be attractive. If you need a more general CNI-independent option with service discovery and support for overlapping CIDRs, Submariner is a strong candidate. If you only want to expose selected services and prefer not to merge pod networks at all, Skupper offers a very different and very practical model. And if you need fine-grained scope without giving up protocol compatibility, KubeSlice is worth a serious look.
None of them is universally best. The right choice depends on how much control you need, how mixed your environments are, whether your CIDRs overlap, and whether you are trying to connect networks, services, or only specific workloads.