This document discusses multi-cluster load balancing strategies in Kubernetes. It describes DNS-based global server load balancing (GSLB), service mesh-based load balancing using Linkerd or Istio, and CNI-based load balancing. GSLB is ideal for load balancing external traffic across clusters in different regions with no single point of failure. Service meshes excel at load balancing within and across clusters, offering control over traffic but potential vendor lock-in. CNI-based approaches leverage the container network interface for pod-to-pod communication across clusters but have overlay networking overhead. The best strategy depends on requirements around external vs internal traffic, statefulness, and need for pod-level connectivity.

1. Multi-Cluster Load Balancing in Kubernetes:
Strategies and Considerations
Tamil Vanan
Tech Lead, Arcesium

2. Self Introduction
● I'm Tamil Vanan, with over 11 years of
experience in networking, automation,
development, and cloud-native technologies.
● My current role is as a Tech Lead at Arcesium.
● I have a keen interest in exploring and solving
cloud-native use cases.
● In my spare time, I enjoy playing badminton.
● You can reach out to me(@tamilhce) on
Twitter/Linkedin

3. Introduction
● What is Multi cluster Load balancing in Kubernetes?
● Use cases
● Importance of effective multi-cluster load balancing

4. Key Networking Constructs
1. Pods-to-pods communication without the need for proxies or
translations using IP addresses.
1. The service abstraction, which groups pods under a common
access policy, creating a virtual IP for transparently proxying
client requests to the pods.
1. Exposing services to the external world using Ingress, Gateway,
or services of type LoadBalancer.

5. Enabling External Access for Your Kubernetes
Application
How to make your application accessible outside the
kubernetes cluster
● Service of Type LB
● Ingress
● Gateway
Service Based Routing

6. Ingress Routing

7. Gateway Routing

8. Multi-Cluster Load Balancing Strategies
● GSLB (DNS-based Global Server Load Balancing)
● Service Mesh-based Multi-Cluster Load Balancing
● CNI-based Multi-Cluster Load Balancing

9. GSLB (DNS-based Global Server Load Balancing)
● Load balancing is based on timeproof
DNS protocol which is perfect for
global scope and extremely reliable
● No dedicated management cluster and
no single point of failure
● Reference: K8gb

10. GSLB (DNS-based Global Server Load Balancing)
● Pros
○ External Client Traffic
■ Ideal for applications with significant external traffic
○ Geographic Distribution
■ directing traffic to the nearest cluster or region based on the client’s location
■ minimizing latency
○ No Dependency
■ It doesn’t have any dependency on the vendor specific CNI, service mesh. Ingress
controller
■ Works with any existing clusters
● Cons
○ enabling fine-grained control over traffic patterns(traffic splitting, circuit breaking, retries, and
fault tolerance) is not applicable
○ DNS TTL

11. Service Mesh-based Multi-Cluster Load Balancing
● Service Mesh excels provides load balancing
services across multiple clusters, offering
precise control over traffic routing, load
balancing, and service discovery.
● References: Linkerd, Istio

12. Service Mesh-based Multi-Cluster Load Balancing
● Pros
○ East-West Traffic Handling
■ It’s perfect for east-west traffic, managing communication within and across clusters.
○ Advanced Traffic Management
■ Service Mesh offers advanced traffic management capabilities like traffic splitting, circuit breaking,
retries, and fault tolerance, enabling fine-grained control over traffic patterns
● Cons
○ Vendor Lock-in
■ Implies being tied to a specific service mesh provider, limiting flexibility
○ Scalability Challenges
■ As the number of clusters increases, inter-cluster service becomes more complex and has limitations
on scaling.
○ Increased Complexity and Overhead
■ Introduces additional complexity and overhead for routing external traffic.

13. CNI-based Multi-Cluster Load Balancing
● Multi-cluster load balancing based on CNI
leverages the underlying CNI for load distribution.
● Pod-to-Pod Communication
● Service Discovery

14. CNI-based Multi-Cluster Load Balancing
Requirements
● Ensure each Kubernetes worker node has a unique IP address and IP connectivity between all
worker nodes
● Achieve this through VPN tunneling for cross-region clusters or direct physical network connections
for clusters within the same region/DC.
● Assign unique PodCIDR ranges to all clusters.

15. CNI-based Multi-Cluster Load Balancing
Pros
● Ensure each Kubernetes worker node has a unique IP address and IP connectivity between all worker nodes
● Achieve this through VPN tunneling for cross-region clusters or direct physical network connections for clusters
within the same region/DC.
● Assign unique PodCIDR ranges to all clusters.
Cons
● Vendor Lock-in
○ Involves dependency on a particular CNI provider
● Adds extra overhead and cost implications: overlay networking via VPN, potentially resulting in added expenses and
latency

16. Selecting the Right Multi-Cluster Load Balancing
Strategy
● Why do you require multi-cluster load balancing?
● is it solely for achieving application high availability and disaster recovery?
● Is your application stateless?
● Does your application need service-to-service communications across clusters? why?
● Are you primarily dealing with HTTP-based applications, or do you also support UDP/TCP-based
services?
● Does your use case necessitate pod-to-pod service connectivity across clusters?

17. Conclusion
In summary, choosing the right multi-cluster load balancing strategy depends on
your specific requirements:
● DNS-based GSLB - For load balancing external traffic across clusters
spanning multiple regions.
● Service Mesh-based multi-cluster load balancing - When scaling services
across clusters and facilitating east-west communication.
● If your needs revolve around direct pod-to-pod communication across
clusters, opt for the CNI-based approach.

18. Q&A
● References
○ https://linkerd.io/2.14/features/multicluster
○ https://istio.io/latest/docs/setup/install/multicluster
○ https://cilium.io/blog/2019/03/12/clustermesh
○ https://github.com/k8gb-io/k8gb
● Contact: @tamilhce

19. Thank You !