The second option is to build two or more entirely separate Kubernetes clusters and configure Instant Connect to replicate data and messages between them (forming a single, logical instance of ICE). This is the mechanism officially supported by Instant Connect (although Instant Connect only supports a two-cluster deployment).

Clusters communicate with one another through a virtual private network (VPN) using WireGuard.

Instant Connect is unaware that it is operating across clusters. In much the same way that ICE does not know, monitor, or care how many physical nodes its software components may be orchestrated across, it has no knowledge of this dual-cluster 'plumbing.'

In this design, network requirements are much more lax than operating a single cluster across sites. Instead, ICE requires two forms of data to be replicated between clusters:

These tools—Kafka and Cassandra—are designed to be replicated over lower-bandwidth, higher latency network links and can easily adapt to intermittent and short-term partitions (referred to, broadly, as 'eventual consistency'). Low bandwidth and/or high latency network links between sites will produce a degraded user experience but not a system outage.