1"use strict";(self.webpackChunkcilium_io=self.webpackChunkcilium_io||[]).push([[868],{1135:function(e,t,n){n.r(t),n.d(t,{Head:function(){return h},default:function(){return p}});var a=n(8453),i=n(6540),r=n(6452);function s(e){const t=Object.assign({h1:"h1",strong:"strong",p:"p",ul:"ul",li:"li",h2:"h2",a:"a",span:"span",em:"em",ol:"ol"},(0,a.RP)(),e.components),{BlogAuthor:n}=t;return n||function(e,t){throw new Error("Expected "+(t?"component":"object")+" `"+e+"` to be defined: you likely forgot to import, pass, or provide it.")}("BlogAuthor",!0),i.createElement(i.Fragment,null,i.createElement(t.h1,null,i.createElement(t.strong,null,"Multi-Cluster Kubernetes Explained")),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"Introduction")),"\n",i.createElement(t.p,null,"As enterprises scale their cloud native infrastructure, a single Kubernetes cluster often becomes not enough for meeting requirements related to isolation, availability, scale, and/or geographic distribution. Multi-cluster Kubernetes is an architectural approach that involves deploying and managing multiple independent clusters to support a unified application environment."),"\n",i.createElement(t.p,null,"By dividing resources into targeted groups, companies can localize for efficiency, isolate potential failures, and tailor specific technology or cluster needs without overlapping operational concerns."),"\n",i.createElement(t.p,null,"There are various ways to segment workloads from one another in Kubernetes. You can run them on different pods or set up different namespaces. But if you want the maximum level of granularity and the high availability and performance benefits that it can bring, a multi-cluster Kubernetes deployment is the way to go."),"\n",i.createElement(t.p,null,"Edge computing can also require connecting hundreds of clusters across disparate locations and infrastructures. Without a networking solution to manage this scale and complexity, you will just have a bunch of computers talking to themselves rather than each other and your customers."),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"I. Why Multi-Cluster?")),"\n",i.createElement(t.p,null,"Transitioning from a single large cluster to multiple smaller clusters can be driven by several critical operational concerns:"),"\n",i.createElement(t.ul,null,"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Low Latency"),": In a single-cluster architecture, workloads are deployed to one region or data center. This means users interacting with your application from across the globe will inevitably experience high network delays due to the physical distance data must travel. By adopting a multi-cluster approach, you can distribute workloads geographically, placing compute resources in regions closer to your end-users or edge devices. This drastically reduces round-trip times and ensures a highly responsive application experience."),"\n"),"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"High Availability and Disaster Recovery"),": Distributing workloads across clusters in different availability zones or regions ensures that the failure of a single cluster or provider region does not lead to total application downtime."),"\n"),"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Workload scalability:")," Running multiple clusters may enhance your ability to scale workloads up when necessary. If everything runs in a single cluster, itâs harder to determine which specific workloads require more resources or additional replicas, especially if you lack performance data for individual workloads (which may be the case if you are only tracking cluster-level health). You are also more likely to run into ânoisy neighborâ issues when running everything in a single cluster. And for very large clusters, you may hit the ceiling on the cluster size that Kubernetes supports; currently, you canât have more than 5,000 nodes per cluster."),"\n"),"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Compliance and Data Sovereignty:")," Specific clusters can be localized to certain
1jurisdictions to meet regulatory requirements regarding data residency."),"\n"),"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Hard Multitenancy"),": While namespaces provide soft isolation, separate clusters offer a stronger security boundary for different teams, environments (Dev/UAT/Prod), or sensitive workloads."),"\n"),"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Organizational Growth and Acquisitions"),": As companies scale organically or engage in Mergers and Acquisitions (M&A), they frequently inherit disparate infrastructure, different cloud providers, or existing Kubernetes environments. Instead of undertaking a massive, high-risk migration to consolidate these discrete workloads into a single monolith, connecting them via a multi-cluster architecture provides a seamless, non-disruptive path to infrastructure integration while allowing acquired teams to maintain their operational autonomy."),"\n"),"\n"),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"II. Multi-Cluster Architecture Patterns")),"\n",i.createElement(t.p,null,"Organizations deploy Kubernetes across multiple clusters for various reasons such as resilience, compliance, regulatory isolation, team autonomy, or geographic distribution. Before choosing a topology, it's important to understand the trade-offs each pattern introduces in terms of operational complexity, blast radius, latency, and cost."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Active-Active")),"\n",i.createElement(t.p,null,"In an active-active topology, two or more clusters simultaneously serve live production traffic. Workloads are replicated across all clusters, and load is balanced between them. This pattern reduces blast radius and enables failover, supporting resilience through active-active approaches. With Cilium ClusterMesh, global services can span clusters so that pods in Cluster A and Cluster B both act as backends for the same service; traffic flows to whichever is healthy."),"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Best for:")," High-availability applications, geo-distributed workloads, zero-downtime deployments.\n",i.createElement(t.strong,null,"Trade-off:")," Requires state synchronization between clusters; data consistency logic adds complexity."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Active-Standby")),"\n",i.createElement(t.p,null,"Here, one cluster handles all live traffic (active), while a second cluster sits warm and ready to take over (standby). The standby cluster runs replicated workloads but does not serve traffic under normal conditions. Failover is triggered manually or automatically when the active cluster degrades."),"\n",i.createElement(t.p,null,"With Cilium's service.cilium.io/affinity annotation, you can express topology-aware preference, for instance, pinning traffic to the local cluster under normal conditions and allowing spillover to the remote cluster only during failure. Setting the affinity to local marks local endpoints as preferred, and changing the value to remote shifts traffic to the remote cluster's endpoints."),"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Best for:")," Disaster recovery, regulated workloads requiring a clear primary/secondary designation.\n",i.createElement(t.strong,null,"Trade-off:")," Standby capacity is idle under normal operations, increasing cost."),"\n",i.createElement(t.p,null,i.createElement(t.a,{href:"https://docs.cilium.io/en/latest/network/clustermesh/affinity/"},"Read More About Service Affinity")),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Cluster per Environment")),"\n",i.createElement(t.p,null,"Each Software Development Lifecycle environment (development, staging, production) gets its own cluster. This is one of the most common patterns in enterprise Kubernetes adoption and provides hard boundaries between lifecycle stages."),"\n",i.createElement(t.p,null,"Separating environments (dev/staging/prod) or tenants into dedicated clusters avoids noisy-neighbor effects and misconfiguration leakage. ClusterMesh is not always required here; typically, inter-cluster communication between environments is intentionally restricted, but it can be used to mirror services or support integration testing across environment boundaries with a fine-grained network policy."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Cluster per Region")),"\n",i.createElement(t.p,null,"As enterprises diversify product offerings across the globe, itâs important to make sure that users connect to their services from the nearest access point. Hence, instead of attempting to stretch a single Kubernetes cluster across geographic regions, which often results in high latency, organizations deploy distinct cluster
1s in different geographic regions."),"\n",i.createElement(t.p,null,"Another reason for an enterprise to run a cluster per region is data residency compliance requirements. GDPR mandates strict data residency requirements, ensuring personal data of EU residents is stored and processed within specific geographic locations or under adequate safeguards."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Cluster per Tenant")),"\n",i.createElement(t.p,null,"Also known as hard multitenancy, this pattern provisions a dedicated Kubernetes cluster for each customer, business unit, or internal department. While Kubernetes namespaces, Network Policies, and RBAC offer soft isolation, they still share the same control plane and underlying host kernels, which might not meet strict compliance requirements."),"\n",i.createElement(t.p,null,"By assigning a cluster per tenant, you eliminate the noisy neighbor problem and ensure a strict security boundary. A common challenge here is IP exhaustion or overlapping IPs across dozens of tenant clusters."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Hub and Spoke Topology")),"\n",i.createElement(t.p,null,"In a hub-and-spoke topology, a central hub cluster acts as the core shared-services center, connecting out to multiple spoke clusters where the actual workloads run. Instead of deploying operational tooling in every single cluster, the hub hosts centralized services like observability stacks (Hubble/Prometheus), secrets management (HashiCorp Vault), CI/CD runners, or centralized DNS."),"\n",i.createElement(t.p,null,"With Cilium ClusterMesh, you can expose these specific shared services from the Hub to the Spokes without requiring the Spokes to be meshed with each other."),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"III. Implementing Inter-Cluster Connectivity via Cilium ClusterMesh")),"\n",i.createElement(t.p,null,"Cilium enables seamless multi-cluster connectivity through a feature called ",i.createElement(t.strong,null,"ClusterMesh"),"."),"\n",i.createElement(t.span,{dangerouslySetInnerHTML:{__html:'<span\n class="gatsby-resp-image-wrapper"\n style="position: relative; display: block; margin-left: auto; margin-right: auto; max-width: 1008px; "\n >\n <a\n class="gatsby-resp-image-link"\n href="/static/d6239fce0b5064d3646e870f795635e8/44899/inter-cluster-connectivity.png"\n style="display: block"\n target="_blank"\n rel="noopener"\n >\n <span\n class="gatsby-resp-image-background-image"\n style="padding-bottom: 80.95238095238095%; position: relative; bottom: 0; left: 0; display: block;"\n ></span>\n <picture>\n <source\n srcset="/static/d6239fce0b5064d3646e870f795635e8/2ff5b/inter-cluster-connectivity.webp 252w,\n/static/d6239fce0b5064d3646e870f795635e8/4d583/inter-cluster-connectivity.webp 504w,\n/static/d6239fce0b5064d3646e870f795635e8/905a7/inter-cluster-connectivity.webp 1008w,\n/static/d6239fce0b5064d3646e870f795635e8/bb9f8/inter-cluster-connectivity.webp 1512w,\n/static/d6239fce0b5064d3646e870f795635e8/5aae5/inter-cluster-connectivity.webp 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/webp"\n />\n <source\n srcset="/static/d6239fce0b5064d3646e870f795635e8/019e0/inter-cluster-connectivity.png 252w,\n/static/d6239fce0b5064d3646e870f795635e8/0dcb2/inter-cluster-connectivity.png 504w,\n/static/d6239fce0b5064d3646e870f795635e8/832a9/inter-cluster-connectivity.png 1008w,\n/static/d6239fce0b5064d3646e870f795635e8/19357/inter-cluster-connectivity.png 1512w,\n/static/d6239fce0b5064d3646e870f795635e8/44899/inter-cluster-connectivity.png 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/png"\n />\n <img\n class="gatsby-resp-image-image"\n src="/static/d6239fce0b5064d3646e870f795635e8/832a9/inter-cluster-connectivity.png"\n alt="Inter Cluster Connectivity"\n title=""\n loading="lazy"\n decoding="async"\n style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;"\n />\n </picture>\n </a>\n </span>'}}),"\n",i.createElement(t.p,null,i.createElement(t.em,null,"Fig 1: Cilium ClusterMesh connecting heterogeneous Kubernetes environments across Azure, AWS, Red Hat OpenShift, and VMware through unified Ingress, Egress, and Transit Gateways.")),"\n",i.createElement(t.p,null,"Cluster Mesh connectivity is high performance, as data flows directly from one worker node to another without intermediate proxies. It preserves the workload identity for cross-cluster traffic, meaning that network observability tooling, such as Ciliumâs Hubble, as well as network policies, continue to operate just as they do within a single cluster."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Key Capabilities of ClusterMesh")),"\n",i.createElement(t.ul,null,"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Multi-Cluster Connectivity:")," Cilium provides the ability to connect multiple cluster
1s across different cloud providers or on-premises environments."),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Identity-Based Security:")," Security identities assigned to pods are maintained across cluster boundaries, allowing for consistent L3/L4 and L7 network policies regardless of where a pod is running."),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Global Services:"),' Services can be defined as "global," enabling traffic to be load-balanced across pods in multiple clusters. This allows for automatic failover; if a service in Cluster A fails, traffic is redirected to the healthy backends in Cluster B.'),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Transparent Encryption:")," Cilium can enable node-to-node encryption across clusters without requiring application changes or sidecar proxies."),"\n"),"\n",i.createElement(t.span,{dangerouslySetInnerHTML:{__html:'<span\n class="gatsby-resp-image-wrapper"\n style="position: relative; display: block; margin-left: auto; margin-right: auto; max-width: 1008px; "\n >\n <a\n class="gatsby-resp-image-link"\n href="/static/07c23b1989a57c88bd3b2efb140f25db/44899/fail-over-service.png"\n style="display: block"\n target="_blank"\n rel="noopener"\n >\n <span\n class="gatsby-resp-image-background-image"\n style="padding-bottom: 32.14285714285714%; position: relative; bottom: 0; left: 0; display: block;"\n ></span>\n <picture>\n <source\n srcset="/static/07c23b1989a57c88bd3b2efb140f25db/2ff5b/fail-over-service.webp 252w,\n/static/07c23b1989a57c88bd3b2efb140f25db/4d583/fail-over-service.webp 504w,\n/static/07c23b1989a57c88bd3b2efb140f25db/905a7/fail-over-service.webp 1008w,\n/static/07c23b1989a57c88bd3b2efb140f25db/bb9f8/fail-over-service.webp 1512w,\n/static/07c23b1989a57c88bd3b2efb140f25db/5aae5/fail-over-service.webp 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/webp"\n />\n <source\n srcset="/static/07c23b1989a57c88bd3b2efb140f25db/019e0/fail-over-service.png 252w,\n/static/07c23b1989a57c88bd3b2efb140f25db/0dcb2/fail-over-service.png 504w,\n/static/07c23b1989a57c88bd3b2efb140f25db/832a9/fail-over-service.png 1008w,\n/static/07c23b1989a57c88bd3b2efb140f25db/19357/fail-over-service.png 1512w,\n/static/07c23b1989a57c88bd3b2efb140f25db/44899/fail-over-service.png 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/png"\n />\n <img\n class="gatsby-resp-image-image"\n src="/static/07c23b1989a57c88bd3b2efb140f25db/832a9/fail-over-service.png"\n alt="Failover Service"\n title=""\n loading="lazy"\n decoding="async"\n style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;"\n />\n </picture>\n </a>\n </span>'}}),"\n",i.createElement(t.p,null,i.createElement(t.em,null,"Fig 2: Cilium ClusterMesh global service load balancing, frontend and backend services spanning two clusters with automatic failover to healthy backends in Cluster 2.")),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Architectural Requirements Checklist")),"\n",i.createElement(t.p,null,"To successfully implement Cilium ClusterMesh and achieve inter-cluster connectivity, your infrastructure must meet a specific set of foundational network requirements:"),"\n",i.createElement(t.ol,null,"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Non-overlapping Pod CIDRs"),": In a standard ClusterMesh deployment, every cluster must be assigned a unique, non-overlapping Pod IP subnet (CIDR). This ensures that Pod IPs are globally unique across the entire mesh, allowing Cilium to route traffic directly to a specific pod without relying on complex Network Address Translation (NAT) rules."),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Node-to-node IP Connectivity"),": The worker nodes in all participating clusters must be able to reach each other over the network. Cluster
1s are connected and routed across cloud providers using native VPC peering, dedicated interconnects (like AWS Direct Connect or Azure ExpressRoute), or via secure IPSec/WireGuard tunnels."),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Native Routing CIDR"),": When using direct routing instead of encapsulation (tunneling), the network infrastructure must know how to route the Pod CIDRs. This requires configuring the underlying VPC network to recognize the pod IP ranges so that traffic can flow natively between nodes across different clusters."),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Consistent Datapath Mode:")," While it is possible to mix some configurations, it is highly recommended that meshed clusters use a consistent datapath mode (e.g., all clusters using VXLAN/Geneve tunneling, or all clusters using direct native routing). This reduces troubleshooting complexity and ensures consistent performance."),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"DNS Across Clusters:")," For seamless service discovery, the Kubernetes DNS service (like CoreDNS) needs to be aware of the ClusterMesh. Cilium integrates with the service routing plane underneath Kubernetes DNS. When CoreDNS resolves a global service hostname to a local virtual ClusterIP, Cilium's eBPF layer translates that IP target into a list of globally available backend pods, regardless of which cluster they reside in."),"\n"),"\n",i.createElement(t.span,{dangerouslySetInnerHTML:{__html:'<span\n class="gatsby-resp-image-wrapper"\n style="position: relative; display: block; margin-left: auto; margin-right: auto; max-width: 1008px; "\n >\n <a\n class="gatsby-resp-image-link"\n href="/static/bae50a9d2bd5650c8f707944bbf1a50a/44899/cilium-mesh.png"\n style="display: block"\n target="_blank"\n rel="noopener"\n >\n <span\n class="gatsby-resp-image-background-image"\n style="padding-bottom: 47.61904761904761%; position: relative; bottom: 0; left: 0; display: block;"\n ></span>\n <picture>\n <source\n srcset="/static/bae50a9d2bd5650c8f707944bbf1a50a/2ff5b/cilium-mesh.webp 252w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/4d583/cilium-mesh.webp 504w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/905a7/cilium-mesh.webp 1008w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/bb9f8/cilium-mesh.webp 1512w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/5aae5/cilium-mesh.webp 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/webp"\n />\n <source\n srcset="/static/bae50a9d2bd5650c8f707944bbf1a50a/019e0/cilium-mesh.png 252w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/0dcb2/cilium-mesh.png 504w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/832a9/cilium-mesh.png 1008w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/19357/cilium-mesh.png 1512w,\n/static/bae50a9d2bd5650c8f707944bbf1a50a/44899/cilium-mesh.png 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/png"\n />\n <img\n class="gatsby-resp-image-image"\n src="/static/bae50a9d2bd5650c8f707944bbf1a50a/832a9/cilium-mesh.png"\n alt="Cilium ClusterMesh"\n title=""\n loading="lazy"\n decoding="async"\n style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;"\n />\n </picture>\n </a>\n </span>'}}),"\n",i.createElement(t.p,null,i.createElement(t.em,null,"Fig 3: Cilium ClusterMesh internal architecture, two clusters connected via VPC Peering, showing etcd state synchronization, Cilium agents, Load Balancers, and the VXLAN encapsulated network packet structure for cross-cluster pod traffic.")),"\n",i.createElement(t.p,null,i.createElement(t.a,{href:"https://isovalent.com/blog/post/introducing-cilium-mesh/"},"Read More About Cilium Cluster Mesh")),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"IV. Deep Dive: How ClusterMesh Operates Under the Hood")),"\n",i.createElement(t.p,null,"Unlike traditional multi-cluster setups that rely on heavy routing layers or centralized API gateways, Cilium leverages the Linux kernel to create a seamless, flat network topology across your entire multi-cluster environment."),"\n",i.createElement(t.p,null,"In many traditional architectures, cross-cluster communication requires traffic to traverse a complex maze of ingress controllers, egress gateways, and sidecar proxies. Cilium fundamentally changes this paradigm. Cilium Cluster Mesh implements IP forwarding without proxies or gateways. Because the routing logic is embedded directly in the kernel, data flows directly from one worker node to another without intermediate proxies."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"The clustermesh-apiserver")),"\n",i.createElement(t.p,null,"At the heart of Cilium's multi-cluster architecture is the clustermesh-apiserver. Rather than relying on a single, global database that c
1ould act as a single point of failure, Cilium takes a decentralized approach."),"\n",i.createElement(t.p,null,"Cilium's Cluster Mesh uses etcd as an external key-value store to exchange information across multiple Cilium instances. The clustermesh-apiserver manages this dedicated etcd instance for the cluster, tracking the state of endpoints, services, and network identities. To allow other clusters to connect and read this state, the Cilium control plane is exposed to the VPCs using the service annotation 'Internal' for load balancer type."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"KVStoreMesh")),"\n",i.createElement(t.p,null,"Once the ",i.createElement(t.em,null,"cluster mesh-apiserver")," exposes the cluster's state, the clusters need a safe way to synchronize this data. This is where the KVStoreMesh concept comes in."),"\n",i.createElement(t.p,null,"Instead of pushing data directly into a remote cluster's primary database (which is risky), each cluster in the network operates its own etcd cluster with replication occurring on a read-only basis to ensure that failures in a cluster do not bring down other clusters. Cilium agents watch the remote KVStores in a pull-based, read-only fashion. If the network link between Cluster A and Cluster B goes down, both clusters simply continue operating securely using their locally cached state."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Identity Propagation")),"\n",i.createElement(t.p,null,"One of the most complex challenges in multi-cluster networking is maintaining the security context when a packet leaves one cluster and enters another. Traditional networks rely on IP addresses, which are ephemeral and lose meaning across cluster boundaries."),"\n",i.createElement(t.p,null,"Cilium solves this through identity propagation. The key to seamless pod-to-pod networking is Cilium's implementation of identity-based networking that identifies which pods and services can communicate using labels instead of IP addresses to enforce access controls. Because this identity is embedded in the eBPF datapath, Cilium preserves workload identity for cross-cluster traffic, meaning that network observability tooling, such as Cilium's Hubble, as well as network policies, continue to operate just as they do within a single cluster."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Certificate Management")),"\n",i.createElement(t.p,null,"Because ClusterMesh involves control plane data (etcd synchronization) and data plane traffic (pod-to-pod communication) traversing underlying networks often crossing different VPCs or public internet links, security is paramount."),"\n",i.createElement(t.ul,null,"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Control Plane Security"),": TLS authenticates the client and server with the certificates and keys that are managed as Kubernetes secrets. This ensures that only authorized clusters can connect to the remote clustermesh-apiserver to read the KVStore state."),"\n",i.createElement(t.li,null,i.createElement(t.strong,null,"Data Plane Encryption"),": For the actual application traffic flowing between nodes across clusters, encryption between all endpoints, clusters, pods, and services can be automatically and transparently applied at the platform level without requiring application modifications. This transparent encryption (using IPsec or WireGuard) ensures that data in transit remains fully secure regardless of the underlying cloud provider or network infrastructure."),"\n"),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"V. Pod-to-Pod Connectivity Across Clusters")),"\n",i.createElement(t.p,null,"The minimum requirement for a successful multi-cluster network is for Kubernetes pods to easily communicate with one another across clusters. Historically, connecting isolated Kubernetes clusters required exposing workloads via Ingress controllers, API gateways, or complex NAT rules."),"\n",i.createElement(t.p,null,"Cilium ClusterMesh eliminates this friction. Cluster Mesh connectivity is high performance, as data flows directly from one worker node to another without intermediate proxies. This flattens the network, allowing a pod in one cluster to directly address the IP of a pod in another cluster just as if they were on the same physical node."),"\n",i.createElement(t.span,{dangerouslySetInnerHTML:{__html:'<span\n class="gatsby-resp-image-wrapper"\n style="position: relative; display: block; margin-left: auto; margin-right: auto; max-width: 1008px; "\n >\n <a\n class="gatsby-resp-image-link"\n href="/static/fedd2d49d408a74060e590b8407eedb6/0d4f8/pod-to-pod-connectivity.png"\n style="display: block"\n target="_blank"\n rel="noopener"\n >\n <span\n class="gatsby-resp-image-background-image"\n style="padding-bottom: 56.34920634920635%; position: relative; bottom: 0; left: 0; background-image: url(\'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAsTAAALEwEAmpwYAAABt0lEQVR42l1Th5ajMBDj//9w36Ww2Q2QQncDF53GhNvN8Z5cJXlmbArIl3KLGBN8CJhnjePpE6fzBefyC4djiQPnMpb1P4czjLEI5Irm91dkv7QthhBhrIMmeVY6Qwm0gSZkLnsyt+QJVwIQ/e5RSFffW1zrB9zqsfiY4UPKCIwgvZJYuf75XaOfFFbuCc+t4R8k2iLSeVIW3TiTqGFpahaPSTvMxG30+LgMxMjxikc/4dFN3LNYaGKszzxLjXgVEqpyCc1T43a/03RBQ5P62eG7umPQkeSQo+/mgGbyaB4tqrpDNWo0/QNN84Rx62YojXEeyiwUroxwC1/x1HE2TDO8EmaK68ablYGyG9e4JZv9pMxGJto4DKzNnI1sTjsTJZUYMyRKTaM9AEXNSI3i5dj/DZ/diPKrQj/MW/0kYuez2L6wHbKZyaEt61leruzH90uR4u43u91y4C1utWt7hdtzYo0ntIPOEa8vzptmN9wfpE8RXdTok8FtGXEcK
1hy6Kw79FeXU4DzWHFdcr3HiWDh9slkj2reHnf8SFt0mFjoxrbhisAo9sfe9ec2dzhCOcEUT8fO3/AXw9lUhPvjRlAAAAABJRU5ErkJggg==\'); background-size: cover; display: block;"\n ></span>\n <picture>\n <source\n srcset="/static/fedd2d49d408a74060e590b8407eedb6/2ff5b/pod-to-pod-connectivity.webp 252w,\n/static/fedd2d49d408a74060e590b8407eedb6/4d583/pod-to-pod-connectivity.webp 504w,\n/static/fedd2d49d408a74060e590b8407eedb6/905a7/pod-to-pod-connectivity.webp 1008w,\n/static/fedd2d49d408a74060e590b8407eedb6/bb9f8/pod-to-pod-connectivity.webp 1512w,\n/static/fedd2d49d408a74060e590b8407eedb6/485a2/pod-to-pod-connectivity.webp 1600w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/webp"\n />\n <source\n srcset="/static/fedd2d49d408a74060e590b8407eedb6/019e0/pod-to-pod-connectivity.png 252w,\n/static/fedd2d49d408a74060e590b8407eedb6/0dcb2/pod-to-pod-connectivity.png 504w,\n/static/fedd2d49d408a74060e590b8407eedb6/832a9/pod-to-pod-connectivity.png 1008w,\n/static/fedd2d49d408a74060e590b8407eedb6/19357/pod-to-pod-connectivity.png 1512w,\n/static/fedd2d49d408a74060e590b8407eedb6/0d4f8/pod-to-pod-connectivity.png 1600w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/png"\n />\n <img\n class="gatsby-resp-image-image"\n src="/static/fedd2d49d408a74060e590b8407eedb6/832a9/pod-to-pod-connectivity.png"\n alt="Pod to Pod Connectivity"\n title=""\n loading="lazy"\n decoding="async"\n style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;"\n />\n </picture>\n </a>\n </span>'}}),"\n",i.createElement(t.p,null,i.createElement(t.em,null,"Fig 4: Pod-to-Pod connectivity across Cilium ClusterMesh, frontend pod in Cluster A (10.10.0.0/16) communicating directly with inventory pod in Cluster B (10.20.0.0/16) via eBPF datapath and VXLAN/native routing, with bidirectional control-plane synchronization of EndpointSlices, services, and identities.")),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"How Pod IPs become routable Across Clusters")),"\n",i.createElement(t.p,null,"To achieve this flat network topology, several networking prerequisites must align:"),"\n",i.createElement(t.ul,null,"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,"Non-Overlapping Pod CIDRs: The most critical requirement is that each cluster must be assigned a unique, non-overlapping Pod IP subnet (CIDR). If Cluster A uses 10.10.0.0/16, Cluster B must use something different, like 10.20.0.0/16. This ensures that every pod across your entire infrastructure has a globally unique IP address."),"\n"),"\n",i.createElement(t.li,null,"\n",i.createElement(t.p,null,"Node-to-Node Reachability: ClusterMesh does not magically bypass firewalls. The worker nodes across different clusters must be able to route traffic to one another. Clusters are connected and routed through VPCs using either the standard API from any cloud provider, an on-premise infrastructure via regular IPSec-based VPN gateways and tunnels, or directly through network headers."),"\n"),"\n"),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Encapsulation Mode vs Native Routing Across Cluster Boundaries")),"\n",i.createElement(t.p,null,"When a packet leaves a pod in Cluster A destined for a pod in Cluster B, Cilium can route the pod IPs in a few different ways. You must choose the right datapath mode based on your underlying infrastructure:"),"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Encapsulation Mode (Tunneling)"),": By default, Cilium wraps the pod traffic inside a VXLAN or Geneve tunnel. The underlying cloud provider or physical network only sees traffic moving from Node A's IP to Node B's IP; the internal pod IPs are hidden inside the tunnel."),"\n",i.createElement(t.p,null,"Pros: Incredibly easy to set up. It works on almost any infrastructure because the underlying network doesn't need to know how to route pod IPs.\
1nCons: The encapsulation process adds a small amount of overhead (header size and CPU cycles) to every packet."),"\n",i.createElement(t.p,null,i.createElement(t.strong,null,"Native Routing (Direct Routing)"),": In this mode, Cilium relies on the underlying network (like AWS VPC CNI, Azure Delegated IPAM, or on-premises BGP routers) to natively understand and route the pod IPs. No tunneling is used."),"\n",i.createElement(t.p,null,"Pros: Maximum performance. By avoiding the encapsulation overhead of tunnel mode, Native Routing provides the lowest possible latency and highest throughput, crucial for data-heavy workloads like AI/ML training or massive databases."),"\n",i.createElement(t.p,null,"Cons: Requires advanced configuration of the underlying network infrastructure to ensure it can natively route the distinct Pod CIDRs across cluster boundaries."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"EndpointSlice Synchronization")),"\n",i.createElement(t.p,null,"Routing packets is only half the battle; the clusters also need to know where to send them. This is where service discovery comes into play."),"\n",i.createElement(t.p,null,"In a single Kubernetes cluster, when you create a Service, the Kubernetes control plane generates an EndpointSlice, a scalable list of the healthy pod IPs backing that service. In a multi-cluster setup, Cilium agents securely synchronize these endpoint, identity, and service states across cluster boundaries."),"\n",i.createElement(t.p,null,"Recent advancements in Cilium have taken this a step further by natively supporting the Multi-Cluster Services API (MCS-API), a Kubernetes SIG standard. By using EndpointSlice synchronization, Cilium can dynamically reconcile EndpointSlices from remote clusters. If a backend pod in Cluster B scales up or crashes, the Cilium clustermesh-apiserver instantly synchronizes that state change over the etcd control plane, updating the available endpoints for Cluster A in real-time. This allows load balancing to shift dynamically without relying on external DNS polling."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Verifying Cross-Cluster Pod Connectivity")),"\n",i.createElement(t.p,null,"Once your ClusterMesh is established, verifying and troubleshooting the connectivity requires the right tools. Because Cilium preserves workload identity for cross-cluster traffic, you can use native Cilium and Hubble tooling to debug cross-cluster flows just as easily as local ones."),"\n",i.createElement(t.ul,null,"\n",i.createElement(t.li,null,"Verify the Mesh Status: Use the Cilium CLI to ensure the clusters are actively peering and the etcd control planes are synchronizing."),"\n",i.createElement(t.li,null,"Run the Multi-Cluster Connectivity Test: The Cilium CLI includes a robust, automated testing suite that deploys test pods in both clusters and validates IP routing, global service load balancing, and network policy enforcement across the boundary."),"\n",i.createElement(t.li,null,"Observe with Hubble: If a connection fails, you don't need to guess if a network policy or a routing rule dropped it. Because the network is fully observable without additional code changes, you can use the Hubble CLI to instantly trace the flow."),"\n"),"\n",i.createElement(t.p,null,i.createElement(t.a,{href:"https://isovalent.com/blog/post/topology-aware-routing-and-service-mesh-across-clusters-with-cluster-mesh/"},"Read More About Routing & Service Mesh")),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"VI. Global Services and Cross-Cluster Load Balancing")),"\n",i.createElement(t.p,null,"In a multi-cluster environment, developers need a way to expose an application running in multiple clusters under a single, unified service name. Cilium handles this natively without requiring complex external load balancers or API gateways."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Global Services")),"\n",i.createElement(t.p,null,"Cilium routes connections between pods in multiple clusters if a 'global services' annotation is added to a Kubernetes service deployment. To enable this, you deploy a standard Kubernetes Service in each cluster and attach the following metadata annotation: io.cilium/global-service: \"true\"."),"\n",i.createElement(t.p,null,"Implementing this annotation immediately solves the pod-to-pod communication problem and eliminates the need for internal load balancers and DNS records with cross-cluster identity-based networking. Cilium connects clusters without proxies or gateways by representing each global workload as if the workload runs as a pod."),"\n",i.createElement(t.span,{dangerouslySetInnerHTML:{__html:'<span\n class="gatsby-resp-image-wrapper"\n style="position: relative; display: block; margin-left: auto; margin-right: auto; max-width: 980px; "\n >\n <a\n class="gatsby-resp-image-link"\n href="/static/1f0873215fa3f95ca5fd952e8e44d77c/2b72d/global-services.png"\n style="display: block"\n target="_blank"\n rel="noopener"\n >\n <span\n class="gatsby-resp-image-background-image"\n style="padding-bottom: 42.857142857142854%; position: relative; bottom: 0; left: 0; background-image: url(\'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAJCAIAAAC9o5sfAAAACXBIWXMAAAsTAAALEwEAmpwYAAABIUlEQVR42mVRi3KDMAzj/39x2+22riuU8sjTdpzCZGh77S1nE
1pNYsaQ0Xde3XT9OTrVK0bLNiGVZ1qdhv9h42VubmHLM5EOcXSAW5ClTiKmorv/G8joatNJaiTgDWhRfJsmZnwHduT+151N3TvcarEgaFhWtMTMXEL4xt5pinUHzel1iIlwNdsM47bpwbuDM9TKmz+/22LmQdRdMrO9HfjuWj7YmuUICMMBD0V5gl++dQxIfGXNIe0sj4lKNtLpYSVCq4OUjiWi5m2rgjectAIXtu3MPyWg4zHT4vXz99D6r92Gc5ml2EI3OgmwYZzgMqzMLqCExQ7RCMNgMUwiJLSKUJ2YhOy/N42HN9i2Qb84Xg9rrLniL2XnMbGZbTdlu/gMcvAtA98SLMgAAAABJRU5ErkJggg==\'); background-size: cover; display: block;"\n ></span>\n <picture>\n <source\n srcset="/static/1f0873215fa3f95ca5fd952e8e44d77c/2ff5b/global-services.webp 252w,\n/static/1f0873215fa3f95ca5fd952e8e44d77c/4d583/global-services.webp 504w,\n/static/1f0873215fa3f95ca5fd952e8e44d77c/b2aca/global-services.webp 980w"\n sizes="(max-width: 980px) 100vw, 980px"\n type="image/webp"\n />\n <source\n srcset="/static/1f0873215fa3f95ca5fd952e8e44d77c/019e0/global-services.png 252w,\n/static/1f0873215fa3f95ca5fd952e8e44d77c/0dcb2/global-services.png 504w,\n/static/1f0873215fa3f95ca5fd952e8e44d77c/2b72d/global-services.png 980w"\n sizes="(max-width: 980px) 100vw, 980px"\n type="image/png"\n />\n <img\n class="gatsby-resp-image-image"\n src="/static/1f0873215fa3f95ca5fd952e8e44d77c/2b72d/global-services.png"\n alt="Global Services"\n title=""\n loading="lazy"\n decoding="async"\n style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;"\n />\n </picture>\n </a>\n </span>'}}),"\n",i.createElement(t.p,null,i.createElement(t.em,null,"Fig 5: Cilium Global Service load balancing across two clusters, Pod A in Cluster 1 (us-east) resolves web-service via DNS, with the Global Service LB distributing 50% of traffic to local endpoints and 50% to remote endpoints in Cluster 2 (us-west) through bidirectional ClusterMesh API state synchronization.")),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"How Global Load Balancing Works")),"\n",i.createElement(t.p,null,"When a pod in Cluster A attempts to reach a Global Service, the hostname resolves to a standard local ClusterIP via internal CoreDNS. The eBPF datapath then hooks the connection at the socket layer, dynamically translating that single virtual IP into the direct backend Pod IPs of healthy instances across the entire synchronized multi-cluster mesh."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Service Affinity")),"\n",i.createElement(t.p,null,"While load balancing across clusters is powerful, cross-cluster traffic often incurs higher latency and egress costs. Cilium solves this using the service.cilium.io/affinity annotation."),"\n",i.createElement(t.ul,null,"\n",i.createElement(t.li,null,"By setting affinity to local, Cilium will prioritize routing traffic to backend pods within the same cluster."),"\n",i.createElement(t.li,null,"It only spills traffic over to the remote cluster if all local endpoints fail or degrade, ensuring optimal performance under normal conditions while maintaining disaster recovery capabilities."),"\n"),"\n",i.createElement(t.span,{dangerouslySetInnerHTML:{__html:'<span\n class="gatsby-resp-image-wrapper"\n style="position: relative; display: block; margin-left: auto; margin-right: auto; max-width: 1008px; "\n >\n <a\n class="gatsby-resp-image-link"\n href="/static/f8a195b9434c6fa40db7add1ad2af562/5ece7/service-affinity.png"\n style="display: block"\n target="_blank"\n rel="noopener"\n >\n <span\n class="gatsby-resp-image-background-image"\n style="padding-bottom: 52.38095238095239%; position: relative; bottom: 0; left: 0; background-image: url(\'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAKCAIAAAA7N+mxAAAACXBIWXMAAAsTAAALEwEAmpwYAAABaklEQVR42nWQbW+bMBSF8///2CZVa0KGSSGAX7GvjXkLNKzblx7SNq0qTXqQjv3omGvvlus6TPM0L5d5GfpuGod5eR6nyzBdruv6vNlNzcsyDt04fNhxgtrVJv48ilJoKaRkDy1njbX7Q/LrcHQhwv5IRMGl4FymsJm19pAcH5PU+rjzsdPOaxeEa0/Sp7WtNMnGc0PQgBsrDFWG0tpl0gvbGoqaWmq7HT7ZUOOoNrQvbVITNx5LbPo4gJvdzoI9VA7B3Kz7KPtUtvuKKu3BviQsxVbuAcIXS48lMRVRuf/Z5zpgqrOyZ+V+1xZLnE2xBwiFull9s5XNVbiX+7fBJPosMNYivA12L+MWQvk0DSyL0rTNt7HBWdiiAq6om1JaYFzAQ5bSnIXJClnUjqsgTFA2fJZF45+eesYGoSJXkbE+z/FO/v3OhrIsnE4j113JbcpiXoyobOWXv//WPy/XdQPha4YCV2z+x74CMzQcWi+xcAQAAAAASUVORK5CYII=\'); background-size: cover; display: block;"\n ></span>\n <picture>\n <source\n srcset="/static/f8a195b9434c6fa40
1db7add1ad2af562/2ff5b/service-affinity.webp 252w,\n/static/f8a195b9434c6fa40db7add1ad2af562/4d583/service-affinity.webp 504w,\n/static/f8a195b9434c6fa40db7add1ad2af562/905a7/service-affinity.webp 1008w,\n/static/f8a195b9434c6fa40db7add1ad2af562/5bb53/service-affinity.webp 1200w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/webp"\n />\n <source\n srcset="/static/f8a195b9434c6fa40db7add1ad2af562/019e0/service-affinity.png 252w,\n/static/f8a195b9434c6fa40db7add1ad2af562/0dcb2/service-affinity.png 504w,\n/static/f8a195b9434c6fa40db7add1ad2af562/832a9/service-affinity.png 1008w,\n/static/f8a195b9434c6fa40db7add1ad2af562/5ece7/service-affinity.png 1200w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/png"\n />\n <img\n class="gatsby-resp-image-image"\n src="/static/f8a195b9434c6fa40db7add1ad2af562/832a9/service-affinity.png"\n alt="Service Affinity"\n title=""\n loading="lazy"\n decoding="async"\n style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;"\n />\n </picture>\n </a>\n </span>'}}),"\n",i.createElement(t.p,null,i.createElement(t.em,null,"Fig 6: Cilium service affinity traffic is prioritized to local backend pods within each cluster, with cross-cluster spillover (dashed) triggered only when all local endpoints in Cluster 1 fail or degrade.")),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Shared Services")),"\n",i.createElement(t.p,null,"Using a Hub and Spoke topology, global services allow organizations to centralize common operational tools. Cilium Cluster Mesh provides cloud architects and platform operators with the flexibility to centralize commonly used services like shared secrets, DNS, and other global services from a hub. This prevents you from having to deploy heavy monitoring or vault instances into every cluster."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Handling Unreachable Clusters")),"\n",i.createElement(t.p,null,"Because Cilium leverages the underlying capabilities of Kubernetes, there is no need to modify any of Kubernetes' fundamental architectures. Services that are available to other clusters are kept healthy using Kubernetes' liveness and readiness probes, where services are added and removed as necessary when pods scale up and down, or they become unhealthy. If a cluster goes offline, the cluster mesh-apiserver instantly removes those endpoints from the mesh, ensuring traffic is only routed to healthy clusters."),"\n",i.createElement(t.p,null,i.createElement(t.a,{href:"https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/"},"Read About Setting Up a ClusterMesh")),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"VII. Network Policy Across Cluster Boundaries")),"\n",i.createElement(t.p,null,"Extending connectivity across clusters introduces new security challenges. If Cluster A is compromised, you must ensure the attacker cannot freely pivot into Cluster B."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"How Identity-Based Policy Works Across Clusters")),"\n",i.createElement(t.p,null,"Because network policies are implemented at the kernel level, all traffic can be observed and monitored with Prometheus and visualized with Hubble without requiring developers to instrument their code."),"\n",i.createElement(t.p,null,"The key to seamless pod-to-pod networking is Cilium's implementation of identity-based networking that identifies which pods and services can communicate using labels instead of IP addresses to enforce access controls. When traffic leaves one cluster, the security identity (represented as a numeric ID) is embedded in the network packet. The receiving cluster evaluates this identity against its own local network policies before allowing the packet to reach the destination pod."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Writing Cross-Cluster Policies")),"\n",i.createElement(t.p,null,"Writing a cross-cluster policy is identical to writing a local CiliumNetworkPolicy. Because identities are synchronized, you can restrict traffic based on cluster names. For example, using the ",i.createElement(t.strong,null,i.createElement(t.em,null,"io.cilium.k8s.policy.
1cluster"))," label, you can write a policy stating that the frontend pod in cluster-1 is only allowed to talk to the backend pod in cluster-2, effectively micro-segmenting your mesh."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Default-Deny Across Cluster Boundaries")),"\n",i.createElement(t.p,null,"The best practice in Kubernetes security is the Default-Deny posture. By creating a baseline policy that denies all ingress and egress traffic, you force developers to explicitly define what cross-cluster communication is permitted. Cilium honors this posture seamlessly; if a global service does not have an explicit network policy allowing the cross-cluster identity, the eBPF datapath will drop the packets at the source node."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"FQDN Policy in Multi-Cluster")),"\n",i.createElement(t.p,null,"Cilium also supports DNS-based (FQDN) policies across clusters. If a pod in a remote cluster needs to reach an external API (like api.stripe.com), you can enforce egress security at the DNS level, ensuring that even within a vast multi-cluster mesh, workloads can only communicate with approved external domains."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Limitations")),"\n",i.createElement(t.p,null,"It is important to note that standard ClusterMesh deployments require non-overlapping Pod CIDRs across all clusters. While Isovalent Enterprise for Cilium offers advanced NAT capabilities for overlapping IPs, using standard open source Cilium with overlapping subnets can severely complicate identity propagation and direct pod routing."),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"VIII. Multi-Cluster Observability with Hubble")),"\n",i.createElement(t.p,null,"Maintaining visibility in a multi-cluster environment is crucial for troubleshooting and security purposes. When traffic traverses multiple infrastru
1cture boundaries, blind spots are unacceptable."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Hubble")),"\n",i.createElement(t.p,null,"Hubble is built on top of Cilium and eBPF to enable deep visibility into the communication and behavior of services as well as the networking infrastructure. Because the identity-aware datapath spans the mesh, Hubble provides platform teams with a single management plane for load-balancing, observability, and security enforcement between nodes from multiple Kubernetes clusters."),"\n",i.createElement(t.span,{dangerouslySetInnerHTML:{__html:'<span\n class="gatsby-resp-image-wrapper"\n style="position: relative; display: block; margin-left: auto; margin-right: auto; max-width: 1008px; "\n >\n <a\n class="gatsby-resp-image-link"\n href="/static/9d9558a11ba9d4a14e998cfcd5a760ff/44899/hubble-ui.png"\n style="display: block"\n target="_blank"\n rel="noopener"\n >\n <span\n class="gatsby-resp-image-background-image"\n style="padding-bottom: 31.349206349206348%; position: relative; bottom: 0; left: 0; display: block;"\n ></span>\n <picture>\n <source\n srcset="/static/9d9558a11ba9d4a14e998cfcd5a760ff/2ff5b/hubble-ui.webp 252w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/4d583/hubble-ui.webp 504w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/905a7/hubble-ui.webp 1008w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/bb9f8/hubble-ui.webp 1512w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/5aae5/hubble-ui.webp 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/webp"\n />\n <source\n srcset="/static/9d9558a11ba9d4a14e998cfcd5a760ff/019e0/hubble-ui.png 252w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/0dcb2/hubble-ui.png 504w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/832a9/hubble-ui.png 1008w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/19357/hubble-ui.png 1512w,\n/static/9d9558a11ba9d4a14e998cfcd5a760ff/44899/hubble-ui.png 1999w"\n sizes="(max-width: 1008px) 100vw, 1008px"\n type="image/png"\n />\n <img\n class="gatsby-resp-image-image"\n src="/static/9d9558a11ba9d4a14e998cfcd5a760ff/832a9/hubble-ui.png"\n alt="Hubble UI"\n title=""\n loading="lazy"\n decoding="async"\n style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0;"\n />\n </picture>\n </a>\n </span>'}}),"\n",i.createElement(t.p,null,i.createElement(t.em,null,"Fig 7: Cilium Hubble UI showing cluster mesh visualization.")),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Filtering Flows by Cluster")),"\n",i.createElement(t.p,null,"Using the Hubble CLI or UI, operators do not need to guess where a packet was dropped. Because the cluster name is attached to the flow identity, an engineer can instantly filter network telemetry to show only cross-cluster traffic (e.g., traffic originating in cluster-aws and destined for cluster-onprem)."),"\n",i.createElement(t.h2,null,i.createElement(t.strong,null,"Cross-Cluster Dependency Mapping")),"\n",i.createElement(t.p,null,"Through the Hubble UI, security and platform teams can view a real-time, graphical dependency map. If a global service spans three clusters, Hubble visually maps the traffic flows between them, indicating protocol types, bandwidth usage, and highlighting dropped packets in red. This allows SREs to instantly pinpoint if a multi-cluster outage is due to a crashed pod, a misconfigured network policy, or a cloud provider network partition."),"\n",i.createElement(t.h1,null,i.createElement(t.strong,null,"IX. Summary")),"\n",i.createElement(t.p,null,"Multi-cluster Kubernetes is no longer an edge case; it is a necessity for enterprise-grade resilience and scale. Organizations now require the ability to control and observe multi-cluster architectures that can seamlessly discover services, load balance across zones, perform cross-cloud disaster recovery, and deliver low-latency services globally."),"\n",i.createElement(t.p,null,"Although Kubernetes makes it simple to scale distributed a
1pplications on a single cluster, its native networking model introduces significant operational complexity and performance overhead when attempting to connect workloads across multiple clusters. Historically, bridging these environments meant relying on heavy proxies, API gateways, and external load balancers."),"\n",i.createElement(t.p,null,"By leveraging eBPF-native solutions like Cilium, organizations are overcoming these networking bottlenecks. Through features like ClusterMesh, Cilium provides the high-performance, identity-aware infrastructure required to treat multiple clusters as a single, cohesive environment. It preserves workload identity for all cross-cluster traffic, meaning that security policies and network observability tooling such as Cilium's Hubble continue to operate exactly as they do within a local cluster."),"\n",i.createElement(n,r.A.CharityMbisi))}var l=function(e){void 0===e&&(e={});const{wrapper:t}=Object.assign({},(0,a.RP)(),e.components);return t?i.createElement(t,e,i.createElement(s,e)):s(e)};var o=n(8125),c=n(5805),u=n(8838),d=n(2744);const m=e=>{const{data:{mdx:t},children:n}=e,{frontmatter:{path:a,title:r,date:s,tags:l,ogSummary:u}}=t;return i.createElement(d.A,{headerWithSearch:!0},i.createElement(o.A,{path:a,content:n,date:s,title:r,tags:l,summary:u}),i.createElement(c.A,{className:"my-10 md:my-20 lg:my-28"}))},h=e=>{var t,n;let{data:{mdx:a,site:r},location:{pathname:s}}=e;const{frontmatter:{title:l,ogImage:o,ogSummary:c,dateIso:d,tags:m,author:h}}=a,{siteUrl:p}=r.siteMetadata,g=`${c.slice(0,133)}...`,b=`${p}${s}`,f=null!=o&&null!==(t=o.childImageSharp)&&void 0!==t&&null!==(n=t.resize)&&void 0!==n&&n.src?`${p}${o.childImageSharp.resize.src}`:null,y={title:l,description:g,image:o||null,slug:s},v={"@context":"https://schema.org","@type":"BlogPosting",headline:l,description:g,url:b,datePublished:d,dateModified:d,author:h?{"@type":"Person",name:h}:{"@type":"Organization",name:"Cilium",url:p},publisher:{"@type":"Organization",name:"Cilium",url:p,logo:{"@type":"ImageObject",url:`${p}/images/social-preview.jpg`}},...f&&{image:{"@type":"ImageObject",url:f,width:1200,height:630}},...(null==m?void 0:m.length)>0&&{keywords:m.join(", ")}};return i.createElement(u.A,{data:y,type:"article",datePublished:d,jsonLd:v})};function p(e){return i.createElement(m,e,i.createElement(l,e))}},6452:function(e,t){t.A={thomasGraf:{header:"Thomas Graf",bio:'Thomas Graf is a Co-Founder of Cilium and the CTO & Co-Founder of <a href="https://isovalent.com/?utm_source=website-cilium&utm_medium=referral&utm_campaign=cilium-enterprise">Isovalent</a>, the company behind Cilium. Before that, Thomas spent 15 years as\n a kernel developer working on the <a href="https://kernel.org">Linux kernel</a> in networking, security and eventually eBPF.'},lizRice:{header:'<a href="https://twitter.com/lizrice">Liz Rice</a>',bio:'Liz is Chief Open Source Officer at <a href="https://isovalent.com/?utm_source=website-cilium&utm_medium=referral&utm_campaign=cilium-enterprise" target="_blank" rel="noopener noreferrer">Isovalent</a>, the company behind Cilium. She is also chair of the CNCF\'s Technical Oversight Committee, and the author of Container Security published by O\'Reilly.'},luanGuimaraes:{header:"Luan Guimarães",bio:"Luan is a Brazilian rock climber, amateur musician, and\n programmer and am enthusiastic about free software communities and other\n open knowledge initiatives. He has been working as a Site Reliability\n Engineer at Wildlife Studios, using and building infrastructure tools on\n top of Kubernetes in order to support millions of users around the world."},joshVanLeeuwen:{header:"Josh Van Leeuwen",bio:"Josh interned at Jetstack during the summer of 2017 before continuing to\n work part time during his final year of study at the University of Bristol.\n During this year, Josh developed a Kubernetes custom controller that\n automates the delegation of RBAC permissions based on time and event\n triggers. This work was later awarded the best Software Development Tool\n Final Year Project. Josh now works full time at Jetstack where if heâs not\n writing more Go, heâs making good food."},howardHao:{header:"Howard Hao",bio:" Howard Hao has been working as a Site Reliability Engineer for five years at\n Ect888.com since graduating from Shanghai Jiao Tong University. His team\n consists of 7 members and has been focusing on the construction of\n container orchestration platform like Kubernetes for one and a half years."},sergeyGeneralov:{header:"Sergey Generalov",bio:"Sergey is a member of the technical staff at Isovalent\n and focuses on helping Cilium users solve challenges related\n to network policies, monitoring, and connectivity troubleshooting\n b
1y building tools like Network Policy Editor, Hubble UI and more."},liWenquan:{header:"Li Wenquan",bio:"Hello everyone, I am Li Wenquan from China. You can call me David. I\n started my Docker journey from 2014 and now work as a project manager of\n enterprise container platform, which is built on Kubernetes and Mesos. I\n got to know Cilium project from Kubecon, it is so interesting and\n promising. I've learned a lot from it, such as BPF, XDP and how to replace\n kube-proxy in a elegant way and I'd love to contribute to it."},alexanderAlemayhu:{header:"Alexander Alemayhu",bio:"Alexander Alemayhu is a software engineer at Isovalent,\n the company behind Cilium. He has been working on eBPF and Linux\n kernel technologies for several years, focusing on networking and observability solutions."},DanielBorkmann:{header:"Daniel Borkmann",bio:"Daniel Borkmann is a Distinguished Software Engineer, Isovalent at Cisco"},ThomasGraf:{header:"Thomas Graf",bio:"Thomas Graf is the CTO & Co-Founder Isovalent and also the Vice President Security Cisco"},JedSalazar:{header:"Jed Salazar",bio:"Jed Salazar is a Senior Solutions Architect, Isovalent"},JedSalazarandJoeStringer:{header:"Jed Salazar and Joe Stringer",bio:"Jed Salazar is a Senior Solutions Architect at Isovalent\n and Joe Stringer is a Principal Engineer, Isovalent at Cisco"},JosephIrving:{header:"Joseph Irving",bio:"Joseph Irving is a Platform Engineer Lead at RVU (Uswitch)"},BillMulligan:{header:"Bill Mulligan",bio:"Bill Mulligan is a Cilium and eBPF Community Pollinator,\n Isovalent at Cisco and a Governing Board Member of the eBPF Foundation."},OndrejBlazek:{header:"Ondrej Blazek",bio:"Ondrej Blazek is an Infrastructure Engineer at Seznam.cz"},LeonardCohnenandMoritzEckert:{header:"Leonard Cohnen and Moritz Eckert",bio:"Leonard Cohnen and Moritz Eckert are team members at Edgeless Systems"},PolArroyo:{header:"Pol Arroyo",bio:"Pol Arroyo is a DevOps Engineer at Hetzner Cloud."},JedSalazarandMartynasPumputis:{header:"Jed Salazar and Martynas Pumputis",bio:"Jed Salazar is a Senior Solutions Architect, Isovalent and Martynas Pumputis is a Principal Software Engineer, Isovalent at Cisco"},ShedrackAkintayo:{header:"Shedrack Akintayo",bio:"Shedrack Akintayo is a Community Manager at\n Isovalent helping build the eBPF and Cilium open source communities"},AmirKheirkhahan:{header:"Amir Kheirkhahan",bio:"Amir Kheirkhahan is a DevOps Specialist at DB Schenker handling design, development,\n deployment and maintenance of wide range of devops toolchain on top of Kubernetes clusters"},PaulArah:{header:"Paul Arah",bio:"Paul Arah is a Community Builder focused on Security at Isovalent (Cisco)"},HimalKumar:{header:"Himal Kumar, Bhaskar Dutta, Arman Pashamokhtari",bio:"Himal Kumar, Bhaskar Dutta, Arman Pashamokhtari are all part of the\n CanopusAI team Real Time Network Observability, powered by eBPF and Agentic AI"},DoniaChaiehloudj:{header:"Donia Chaiehloudj",bio:"Donia Chaiehloudj is a Senior Software Engineer and Community Oriented at Isovalent.\n She has been working on Cilium and eBPF technologies, focusing on networking and security solutions."},KatieMeinders:{header:"Katie Meinders",bio:"Katie Meinders is a Community Builder at Isovalent where\n she helps grow the Cilium and eBPF communities through storytelling,\n social media, showcasing user success, and building connections across the open source ecosystem."},PeaceSandy:{header:"Peace Sandy",bio:"Peace Sandy is an LFX mentee who contributed to improving Cilium SEO, AEO, and\n AIO during her mentorship period."},NehaAggarwal:{header:"Neha Aggarwal",bio:"Neha Aggarwal is a Principal Engineer at Microsoft."},CharityMbisi:{header:"Charity Mbisi",bio:"Charity Mbisi is an LFX mentee who contributed to improving Cilium's SEO, AEO, and AIO during his mentorship period.\n Professionally, Charity Mbisi is a Software Engineer consulting in the Fin-tech and banking industry, specializing in building cloud native computing solutions and optimized service delivery."},andreMartinsAndFerozSalam:{header:"André Martins and Feroz Salam",bio:"André Martins is a Cilium maintainer and Software Engineer, Isovalent at Cisco.\n Feroz Salam is a member of the Cilium Security Team and a Security Engineer, Isovalent at Cisco."},ChristianHernandez:{header:"Christian Hernandez",bio:"Christian is a well rounded technologist with experience in infrastru
1cture engineering, systems administration, enterprise architecture, tech support, advocacy, and product management. Passionate about OpenSource and containerizing the world one application at a time. He is currently a maintainer of the Argo Project and OpenGitops. Currently, he works as a Technical Marketing Engineer and Tech Lead at Cisco. He focuses on GitOps practices, DevOps, Kubernetes, Network Security, and Containers."},AkilaInduranga:{header:"Akila Induranga",bio:'Akila is a Senior Software Engineer at WSO2, and a maintainer of <a href="https://openchoreo.dev/" target="_blank" rel="noopener noreferrer">OpenChoreo</a>, an open-source internal developer platform for Kubernetes and a CNCF sandbox project.\n He works on the platform\'s observability and networking layers, including the Cilium-based networking module that brings identity-based policy and Hubble observability to OpenChoreo cells.'}}}}]); 2//# sourceMappingURL=component---src-templates-blog-post-jsx-content-file-path-src-posts-2026-06-13-multi-cluster-kubernetes-explained-index-md-8a8954c3c225999c673e.js.map
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.