For those new to deploying multiple distributed Kubernetes clusters, it helps to understand that there are two basic choices: a replicated architecture or service-based (sometimes called segmented) approach. We cover this in our white paper on Why Organizations are Modernizing their Applications with Distributed, Multi-Cluster Deployments, along with a deep discussion on multi-cluster definitions, benefits and more. If you’re interested in learning more, it’s a good read.
That said, which approach you select (replicated or service-based) can have profound implications for whether and how you can take advantage of all that a distributed multi-cluster topology has to offer.
Replicated Architecture: The Basic Multi-Cluster Structure
The simplest way to handle a distributed multi-cluster deployment is to replicate the complete application across multiple different Kubernetes clusters. Each cluster is an exact copy – a replica – of the others, and can be physically proximate or distant from each other, as required. Load balancers allocate traffic between the clusters, typically based on origination.
Image source: Implementing replication using a multi-cluster Kubernetes architecture (Bob Reselman, CC BY-SA 4.0)
Assuming clusters are reasonably distributed, a replicated architecture delivers most, but not all, of the potential advantages we describe in our white paper.
Since a replicated architecture is simpler to create and manage (as each cluster is identical), it is often the initial choice of DevOps teams who are willing to sacrifice other benefits in favor of ease of use. Similarly, if performance and resilience are your only reasons to move to a multi-cluster deployment, then a replicated architecture might be a good choice.
Service-based Architecture: The More Powerful But Complex Multi-Cluster Option
In a service-based application architecture, an application gets segmented into its constituent components (each a Kubernetes service) which are then assigned to specific clusters based on operational requirements. Services interact with each other across clusters, and the communication layer must be designed to appropriately route user and application traffic. If this sounds familiar, it’s because it mirrors the loose coupling typically seen with a micro-service oriented architecture.
Image source: A multi-cluster segmentation architecture (Bob Reselman, CC BY-SA 4.0)
A service-based architecture has distinct advantages and disadvantages over a replicated architecture. Its advantages are primarily improved isolation and granular control of data, workloads and compute resources, which in turn facilitate performance tuning/optimization, compliance, testing/production, troubleshooting, security, etc. It’s simply more versatile and flexible.
The downside of this approach is added complexity in design and management.
Service-based architectures are thus the go-to choice for more sophisticated teams looking to take advantage of all that multi-cluster deployments have to offer; these organizations are willing to tackle the additional complexity to reap all the benefits.
Section Distributed Multi-Cluster: All the Benefits without the Complexity
However – and it’s a big caveat – the added complexity of a service-based approach is eliminated in working with a provider like Section. The Section Edge Platform is built using a service-based architecture, so you get all of the benefits mentioned above, including the opportunity for fine-grained control of the compute environment. Yet our patent-pending Kubernetes Edge Interface and our patented Adaptive Edge Engine work in concert to simplify deployment and provide easy policy-based control of edge workloads.
All of the benefits of a services-based architecture without the complexity. That’s the Section edge advantage. For a more in-depth look at benefits of multi-cluster architectures, check out our white paper – we promise it’s a quick and informative read. If you’re ready to see how easy it can be to move your application workloads to Section’s distributed multi-cluster edge platform, schedule a demo today.
