Running Kubernetes across AWS EKS and Google Cloud GKE has become a standard strategy for resilience, data locality, and avoiding vendor lock-in. But the networking layer often turns that strategy into a headache: VPC peering, VPN tunnels, and fragile service discovery mechanisms may work for small workloads, but they don’t scale to production-grade, latency-sensitive applications. That’s where Cilium Cluster Mesh cross-cloud Kubernetes networking comes in. By extending Cilium’s eBPF-based data plane across cluster boundaries, you get a unified mesh that treats EKS and GKE as one logical network — without sacrificing performance or security. This article explores how to make that work in 2026, with practical considerations for real-world deployments.
Why Cross-Cloud Kubernetes Networking Still Feels Hard
Even in 2026, connecting clusters across clouds remains a canyon of complexity. Traditional approaches rely on overlays that either route through a central gateway or require complex BGP peering between cloud providers. These solutions often introduce extra hops, higher latency, and a blast radius that spans the entire mesh if one edge fails.
More importantly, Kubernetes services are not designed to be globally resolved by default. A ClusterIP in EKS means nothing in GKE. DNS names are scoped to the cluster. You can work around that with external load balancers or manual endpoint exposure, but that changes the application architecture and often brings in cloud-specific APIs.
Cilium addresses this at the networking layer. Instead of stitching together multiple control planes, it creates a single identity-aware network that understands Kubernetes services, pods, and endpoints — even when they live in different clouds.
Cilium Cluster Mesh Architecture: Shared Gateway, Not Shared Fate
The key insight behind Cilium Cluster Mesh is that clusters remain independent. Each cluster retains its own Kubernetes control plane and Cilium agent. What gets shared is the cluster mesh control plane, which exchanges service and endpoint information over a secure, lightweight connection.
This architecture avoids the “shared fate” problem of stateful federation. If one cluster goes down, the others continue serving traffic. The mesh only affects how services are discovered and routed; it does not create a global control plane that can become a single point of failure.
Under the hood, Cilium uses a gateway node in each cluster to forward cross-cluster traffic. This is not a heavyweight proxy; it’s an eBPF-optimized forwarding path that maintains the same line-rate performance as intra-cluster communication.
Service Discovery and Global Load Balancing
When you enable cluster mesh, Cilium automatically pulls endpoints from all connected clusters and builds a unified service map. A service running in GKE becomes resolvable from EKS without any DNS tricks. Cilium’s DNS-aware policy engine makes sure that a pod in EKS can reach a service in GKE using the same Kubernetes service name, as long as the service is explicitly exported.
This is not just about DNS. Cilium also performs load balancing across clusters. You can weight traffic based on cluster locality, endpoint capacity, or even failover preferences. In 2026, this is particularly useful for active-active architectures where each cloud region is serving a specific geographic area but needs to handle sudden bursts from the other.
Security and Identity Across Clouds
Cross-cloud networking often means trusting cloud-provider credentials and network policies. Cilium treats that differently. Every pod, regardless of which cloud it runs in, receives a Cilium security identity. This identity is embedded in the packet metadata and used for authorization decisions by both the source and destination nodes.
Because the identity follows the pod, you can write Kubernetes NetworkPolicy-like rules that span clusters. A policy can say, “only allow HTTP GET requests from the frontend namespace in EKS to the backend service in GKE,” and Cilium will enforce that at the eBPF layer everywhere in the mesh. This eliminates the need for cloud-specific security groups or firewall rules to govern east-west traffic between clusters.
EKS-GKE Federation with Cilium: A Practical Walkthrough
Now let’s talk about the actual setup. While Cilium’s documentation is thorough, the community still struggles with a few edge cases that only become evident when combining AWS and GCP environments.
Prerequisites and Cilium Version Requirements
First and foremost, use a recent Cilium version. In 2026, that means Cilium 1.16 or later, which includes improved cluster mesh scalability and support for the latest kernel features on Google Cloud’s managed node pool. You also need to ensure that your cluster’s node kernel is eBPF-capable, which both EKS and GKE support out of the box for standard node images.
Networking-wise, you need to establish IP connectivity between the clusters. The most common approach is a VPN or VPC peering connection between the AWS VPC and the Google Cloud VPC. Alternatively, Google Cloud’s Virtual Private Cloud lets you set up dynamic routes without a full mesh of VPN tunnels. Just make sure that the pod CIDRs do not overlap.
Connecting Clusters: Cluster IDs and Tunnel Configuration
To join a cluster to the mesh, you assign a unique cluster ID and cluster name to each cluster, then configure Cilium to use the cluster mesh feature. For example:
> kubectl edit configmap -n kube-system cilium-config
cluster-id: 1
cluster-name: eks-prod-us-east
clustermesh-config:
Then, create the cluster mesh secret that contains the endpoint of the other cluster’s control plane. Cilium provides a clustermesh-apiserver that runs as a Deployment and exposes a service. The secret is just a list of these service endpoints, one per cluster. Once the secret is applied, the agents discover the mesh and start exchanging information.
The data plane tunnels between gateway nodes can be configured to use either VXLAN or Geneve. In cross-cloud scenarios, Geneve tends to perform better because it carries more metadata, especially when you rely on identity-aware policy enforcement across the tunnel.
DNS and Multi-Cluster Services
For services to be reachable across clusters, they need to be marked as global. In Cilium, you do this by setting the annotation cilium.io/global-service: "true" on the Kubernetes service. You can go a step further and set cilium.io/shared-service: "true" to allow all clusters to serve traffic, or keep it local-only with cilium.io/global-service: "false".
The mesh also includes a DNS-based service resolver that maps service names across clusters. But be careful with Kubernetes ExternalName services. They can interfere with Cilium’s service resolution. In 2026, the recommended pattern is to rely on Cilium’s built-in DNS proxy rather than kube-dns or CoreDNS for cross-cluster lookups. That way, you get consistent policies and better performance.
Performance Considerations for High-Throughput Workloads
The biggest concern when connecting EKS and GKE is added latency. Every packet that leaves a node in one cloud and arrives at a node in another cloud must traverse the public internet or a VPN. Cilium cannot eliminate physics, but it can minimize the overhead of that traversal.
Because the forwarding path is built on eBPF, Cilium avoids the kernel context switches that plague userspace proxies. When a pod sends traffic to a service in the remote cluster, the packet is encapsulated and forwarded by the local gateway node using the same high-performance path as native routing. The result is that the added cost is mostly network latency, not software latency.
One recommendation for high-throughput workloads is to place Cilium gateway nodes on dedicated machine types with high network bandwidth. On AWS, instances like c6gn or m6idn have enhanced networking and support for jumbo frames. On GKE, use the n2-highcpu or c3 machine families with Google Cloud’s virtual NIC. Also, enable jumbo frames on both the AWS VPC and Google Cloud VPC if possible. Even with a VPN, larger MTUs reduce protocol overhead and improve throughput.
Another important detail: avoid placing too many gateway nodes behind a cloud load balancer. Cilium’s gateway selection algorithm prefers the closest healthy node. If you put cloud LBs in front, you risk sending traffic through an extra hop. Instead, let the cluster mesh use its own node-to-node connectivity.
Observability and Troubleshooting in a Mesh
Cross-cloud networking is notoriously hard to debug. With Cilium, you have a few powerful tools at your disposal.
Hubble is the observability layer for Cilium. It gives you real-time flow logs that include source and destination identities, service names, and even HTTP metadata. In a cluster mesh, Hubble can trace a request from a pod in EKS to a pod in GKE, showing you the exact path and any dropped packets.
For network policy troubleshooting, cilium monitor still works, but you may want to use cilium-dbg in each cluster to check the service map and endpoint identities. A common mistake is forgetting to add the remote cluster’s node CIDR to the allowed route prefixes in the VPN configuration. Cilium’s health check endpoint (cilium-health) can help identify such misconfigurations quickly.
Another increasingly relevant feature in 2026 is the integration with Grafana and Prometheus for metrics. Cilium exports per-service metrics across clusters, so you can alert on cross-cluster latency percentile. The key, however, is to ensure that your metrics collection platform is not itself dependent on the cluster mesh; otherwise, you lose telemetry exactly when you need it most.
Managing Failover and Cluster Alignments
Cluster mesh also enables clever failover patterns. For example, you can run a stateful workload in GKE primary and a read-only replica in EKS. By controlling the service weights, you can direct all traffic to the primary under normal conditions and shift to the replica during a regional failure.
Cilium’s health checks are constantly probing the connectivity between clusters. If a gateway node becomes unreachable, the mesh marks the remote cluster as degraded and removes it from the load-balancing pool. This converges quickly because Cilium relies on eBPF maps and not on slow etcd updates. In practice, failover can happen in milliseconds, which is sufficient for most microservice applications.
However, it’s still important to think about stateful services. Do not assume that a global service is automatically able to handle sticky sessions. If you need persistence, make sure your application layer manages session affinity or use Cilium’s optional affinity annotations. Otherwise, a failover event might send a user to a cluster that does not hold their session state.
Breaking Cloud Provider Lock-In Without Breaking Your Network
What makes Cilium Cluster Mesh particularly attractive in 2026 is that it abstracts away the cloud provider completely. Your network policies, service discovery, and even load-balancing rules are defined once and applied to EKS and GKE alike. This not only simplifies operations but also gives you the freedom to repurpose a cluster from one cloud to another without rearchitecting the network layer.
The immediate benefit is visible in disaster recovery. You can run a hot standby in GKE that mirrors your primary production in EKS. Because the mesh handles the networking, you don’t need to expose internal services with cloud-specific load balancers. You just update the service weights or rely on automatic health checks.
That said, be mindful of API compatibility for cloud-specific services. Cluster mesh handles pod-to-pod networking, but if your application uses AWS S3 or Google Cloud Storage, those endpoints are still separate. The mesh is not a replacement for federated object storage or cloud-provider identity management.
Conclusion
Cilium Cluster Mesh has matured into a reliable, high-performance way to connect EKS and GKE clusters without the overhead of traditional overlay networks or global service mesh proxies. By leveraging eBPF, identity-aware security, and a distributed control plane, it gives platform teams the ability to run workloads across clouds with confidence. The setup requires careful planning — especially around IP CIDRs, VPN connectivity, and Cilium versioning — but the result is a unified networking layer that feels as close to a single Kubernetes cluster as you can get in a multi-cloud world. As 2026 unfolds, expect Cilium Cluster Mesh to become the default answer for cross-cloud Kubernetes networking questions in organizations that value both performance and independence.
