Authors: Siva Kumar Perumalla, Apoorva Kamath.

Exploring NetScaler Ingress Controller's Multi-Cluster Solutions

In today's cloud-native environments, Kubernetes adoption has become integral to enterprises, particularly with multi-cluster deployments. These deployments offer disaster recovery, autoscaling, and identity management benefits. Efficiently managing ingress traffic across clusters is crucial, and NetScaler Ingress Controller (NSIC) provides robust multi-cluster solutions. NSIC leverages different NetScaler form factors (CPX, BLX, VPX, MPX) to manage traffic into Kubernetes clusters. Using NetScaler, organizations can ensure high availability, resilience, and optimal performance across their Kubernetes clusters, even when independently managed by different teams.

NetScaler Ingress Controller (NSIC) provides advanced solutions for Kubernetes resources, including ingress, service, and various custom resource definitions. In this blog, we explore different multi-cluster solutions and their appropriate use cases. We categorize the multi-cluster load balancing offerings into three types: MultiCluster Ingress Solution, Single Site Multi Cluster Ingress, Multi Site Multi Cluster Ingress, and using shared NetScaler resources.

Multicluster Ingress Solution

The Multicluster Ingress Solution uses a single NetScaler to manage ingress traffic for applications deployed across Kubernetes clusters, allowing them to share the same VIP address. This solution is ideal for hosting different applications on a single domain and IP, simplifying DNS management and improving resource utilization.

When to Use:

• Unified Domain Management: When you want to host multiple applications on the same domain. 
• Ingress resource Sharing:  A single entry point (shared virtual IP address) for accessing applications distributed across multiple Kubernetes clusters.
• Application Segmentation: Ideal for scenarios where different applications are hosted across multiple clusters but need to appear under a unified domain structure.
• IP Allocation: Distributing IP addresses from a pool and using the same IP for all clusters that share the Ingress Resource.

Topology Diagram:

In the above diagram, we depict the traffic distribution across different Kubernetes clusters and applications using a single VIP (vip-1).  

Example Use Case:

A service provider hosting multiple SaaS applications can use this solution to manage all applications under a single domain (e.g., app.example.com), with different paths (e.g., app.example.com /service1, app.example.com /service2) directed to different Kubernetes clusters. Developers have a choice to deploy their services ( app.example.com /service1 and app.example.com /service2) in any Kubernetes clusters of Multi Cluster Ingress deployment. 

For further information, refer to the Multi Cluster Ingress documentation: 

Single Site Multi Cluster Global Server Load Balancing (GSLB)

Single Site GSLB involves using a single NetScaler to manage ADNS service and ingress resources for multiple Kubernetes clusters within the same site. This approach simplifies management by consolidating traffic routing through a single NetScaler while still enabling efficient traffic distribution across Kubernetes clusters using ADNS service. For more information refer to the global server load balancing document and ADNS service document. 

When to Use:

• Centralized Management: Ideal for organizations that prefer a single point of control for multiple clusters in the same data center.
• Resource Optimization: Reduces the overhead of managing multiple ADCs while still benefiting from GSLB features like load balancing and failover within a single site.
• Consistency: Ensures consistent policy application and traffic management across all clusters under a single ADC.

Topology Diagram:

In the above diagram step-1, 2 refers to controller pods (NSIC & GSLB controllers respectively) provisioning NetScaler Entities. In step-3, when the user accesses appUrl based on the application availability the response will be sent to the client. In step-4, 5; users can directly access the application using the respective cluster ingress front-end IP. Each Ingress will have its own front-end IP, which is resolved by ADNS service.

Example Use Case:

An enterprise with multiple Kubernetes clusters in a data center, serving primarily regional customer base, can employ Single-Site GSLB to effectively manage ingress traffic, ensuring high availability and optimized resource utilization.

For further information, refer to the NetScaler GSLB controller for single site documentation. 

Multi Site Multi Cluster GSLB

Multicluster with Global Server Load Balancing (GSLB) uses multiple NetScalers across different sites, each paired with its respective Kubernetes clusters. This setup leverages GSLB to distribute traffic across these regions based on proximity, availability, performance and other load balancing algorithms.

When to Use:

• Global Reach: When your application needs to serve a geographically distributed user base, ensuring low latency and high availability.
• Disaster Recovery: Provides robust failover capabilities, redirecting traffic to healthy clusters in case of a site failure.
• Load Balancing: Balances traffic loads effectively across clusters, preventing any single cluster from becoming a bottleneck.

Topology:

In the above diagram step-1, 2 refers to controller pods (NSIC & GSLB controllers respectively) provisioning NetScaler Entities. In step-3, when the user accesses appUrl, based on the application availability the response will be sent to the client. In step-4, 5; users can directly access the application using the respective cluster ingress front-end IP. Each ingress will have its own front-end IP, which is resolved by the ADNS service.

Example Use Case:

A multinational corporation with data centers in different continents can use this setup to route users to the nearest cluster, improving response times and ensuring business continuity in case of a regional outage.

For further information, refer to the GSLB overview and deployment topologies documentation. 

Conclusion

NetScaler Ingress Controller in tandem with NetScaler GSLB Controller offers versatile multi- cluster solutions designed to meet varying organizational needs. Here's a quick recap to help you decide:

• Multi Cluster Ingress Solution: Ideal for a unified VIP address sharing across multiple local Kubernetes clusters. Centralized management of ingress rules and traffic distribution across multiple local Kubernetes clusters.
• Single-Site GSLB:  Single-Site GSLB can be used to provide advanced domain management capabilities along with centralized control and granular routing across Kubernetes clusters.
• Multi Cluster with GSLB: Best for geographically distributed deployments requiring high availability and disaster recovery. Routing traffic to the most appropriate cluster based on factors such as proximity, latency, and load.

By selecting the right multi-cluster solution, you can enhance the performance, resilience, and manageability of your Kubernetes environments, ensuring your applications deliver the best possible user experience.

Note: This blog is part of a multi-part series. In upcoming posts, we will explore each of these topics in greater detail, providing deeper insights and practical guidance on implementing NetScaler Ingress Controller's multi-cluster solutions. Stay tuned!