What's the difference between exposing nginx as load balancer vs Ingress controller?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
When designing scalable and resilient web applications, one critical component is how you route and manage traffic to your application services. The use of a load balancer helps distribute incoming traffic across multiple servers, ensuring no single server becomes overwhelmed. Meanwhile, an Ingress controller often facilitates managing the access to internal Kubernetes services, providing a user-friendly way to handle HTTP and HTTPS requests. In this article, we dive deep into the differences between using NGINX as a standalone load balancer versus as an Ingress controller within a Kubernetes cluster.
NGINX as a Load Balancer
Overview
NGINX is a powerful and high-performance web server that can be configured to serve as a load balancer. As a load balancer, NGINX distributes incoming network or application traffic across multiple servers, ensuring resource optimization, enhanced resilience, and increased availability.
Technical Explanation
- Configuration: NGINX load balancer configuration involves setting up `upstream` blocks in the configuration file, specifying the server group you'd like to balance the load across.
- Load Balancing Algorithms: NGINX supports different algorithms for distributing traffic, such as:
- Round Robin: Distributes requests evenly across the servers.
- Least Connections: Sends requests to the server with the least number of active connections.
- IP Hash: Directs requests from the same client to the same server.
- SSL/TLS Termination: NGINX can terminate SSL/TLS connections, decrypting incoming requests before passing them to back-end services. This helps reduce the computation burden on the back-end servers.
- Health Checks: NGINX performs health checks on servers in the `upstream` block, directing traffic only to servers that are running smoothly.
Example Configuration
- Ingress Resource: In Kubernetes, the `Ingress` resource defines how services are exposed. It abstracts the routing logic, allowing developers to manage accesses using HTTP routing rules.
- Annotations and Custom Resources: NGINX Ingress controller can be customized using annotations in the Ingress resources or custom resource definitions (CRDs), offering control over behavior like path-based routing, sticky sessions, and SSL termination.
- Load Balancing: Functions similarly to a traditional NGINX load balancer but tailored to work seamlessly with Kubernetes services.
- SSL/TLS Management: Natively supports SSL/TLS configuration through Kubernetes secrets, easing the management process and allowing automatic certificate management with tools like cert-manager.
- host: example.com
- path: /foo
Related reading
- What's the difference between Terraform's kubernetes_config_map and kubernetes_config_map_v1 and kubernetes_config_map_v1_data?
- What's the maximum number of Kubernetes namespaces?
- What's the meaning of READY2/2 output by command kubectl get pod yourpod
- What's the most efficient way to determine the minimum AWS permissions necessary for a Terraform configuration?
- What's the risk of deploying debug symbols pdb file in a production environment?
- When deploying Corda nodes across the network, which JARs have to be exactly the same?
- When do I have to use TensorFlow's FileWriter.flush method?
- When do you exactly use consensus algorithm in distributed system?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.