What is the NGINX Ingress Controller?
In Kubernetes, Ingress is a collection of rules that allow inbound connections to reach the cluster services. It is a way to route external traffic to the services running in your cluster. Ingress is useful when you want to expose multiple services to the Internet and need a way to control the traffic to those services. It is also useful when you want to use a single external IP address to access multiple services in your cluster.
To use Ingress in your cluster, you need to have an Ingress controller running. An Ingress controller is a piece of software that implements the Ingress rules and routes the traffic to the appropriate backend service.
The NGINX Ingress Controller is a software component that runs inside a Kubernetes cluster and manages traffic coming into the cluster. It acts as a reverse proxy, routing traffic from external clients to the appropriate service within the cluster based on the Ingress rules configured in the cluster.
How does the NGINX Ingress Controller work?
To use the NGINX Ingress Controller in a Kubernetes cluster, you need to deploy the NGINX Ingress Controller as a deployment in your cluster. You also need to create Ingress resources in your cluster to define the rules for routing traffic to the services.
The NGINX Ingress Controller runs as a pod within a Kubernetes cluster. It watches for changes to the Ingress resources in the cluster and updates its configuration accordingly.
When a client sends a request to the NGINX Ingress Controller, it looks up the Ingress rules configured in the cluster to determine which service to route the request to. The NGINX Ingress Controller then forwards the request to the appropriate service and returns the response to the client.
Configuring and extending the Ingress Controller
The NGINX Ingress Controller can be configured using annotations in the Ingress resources, which allows you to customize the behavior of the controller. For example, you can use annotations to set the protocol (e.g., HTTP or HTTPS), the hostname, and other parameters for the Ingress rules.
The NGINX Ingress Controller can also be extended using custom NGINX configuration templates, which allows you to add custom logic and functionality to the controller. This makes it easy to tailor the behavior of the NGINX Ingress Controller to your specific needs.
The control loop and cache
The control loop is the main loop of the NGINX Ingress Controller that runs continuously and looks for changes. When a change is detected, the control loop updates the configuration of the NGINX Ingress Controller to reflect the new Ingress rules.
The cache is a data structure that stores the Ingress rules from the Ingress resources in the cluster. The NGINX Ingress Controller uses the cache to quickly look up the Ingress rules for incoming traffic, which helps to improve the performance of the controller.
NGINX Ingress Controller vs. NGINX Kubernetes Gateway
An evolution of the traditional Kubernetes Ingress Controller, the NGINX Kubernetes Gateway solves the challenge of allowing multiple teams to manage Kubernetes infrastructure in a modern customer environment. It also simplifies deployment and management by providing many features without implementing a CRD.
NGINX Kubernetes Gateway uses NGINX technology as the data plane to manage traffic with high performance, improved security and visibility. This solution maps three key gateway API resources—Gateway, GatewayClass, and Routes—using role-based access control (RBAC) to map resources to the relevant roles—Infrastructure Provider, Cluster Operator, and Application Developer.
By comparison, the NGINX Ingress Controller uses the Ingress API specification to provide core functionality, and extends it with custom annotations, NGINX Ingress resources, and CRDs. The NGINX Kubernetes Gateway follows the Gateway API specification to simplify implementation—it is better suited for service network configuration.
The NGINX Kubernetes Gateway does not replace the NGINX Ingress Controller. Instead, it is a new technology based on an alpha version of Gateway API, designed for evaluation purposes only—not for production use. The NGINX Ingress Controller is a stable and mature technology used by many NGINX customers in production. You can use custom annotations and CRDs to tailor it to your specific use case.
NGINX does not expect the NGINX Kubernetes Gateway to be a full replacement for the NGINX Ingress Controller in the near future. According to announcements made by the company, the transition will probably take years. In the meantime, the NGINX Ingress Controller will likely play a major role in managing north-south network traffic across many use cases, including security, traffic limiting, load balancing, and traffic splitting.
NGINX Ingress Controller best practices
Specify the right number of controller pods and set resource limits
Specifying the right number of controller pods helps to ensure that the controller can handle the incoming traffic and maintain good performance. If you specify too few controller pods, the controller may not be able to handle the incoming traffic and may become overloaded, which can lead to performance issues and possibly even downtime. Too many controller pods, and you may be wasting resources and increasing the complexity of your deployment unnecessarily.
Configuring the right resource limits is important for ensuring that the NGINX Ingress Controller is able to run effectively and efficiently in your Kubernetes cluster. To configure resource limits for the NGINX Ingress Controller, you can use the resources field in the deployment configuration. For example, you might specify limits for the CPU and memory usage of the controller pods like this:
Configure auto scaling with HPA
While the NGINX Ingress Controller can usually handle spikes in traffic, configuring the Horizontal Pod Autoscaler (HPA) can help ensure the controller is able to handle incoming traffic effectively and maintain good performance.
To configure the HPA for the NGINX Ingress Controller, you need to create an HPA resource in your cluster. The HPA resource should specify the deployment to be scaled (i.e., the NGINX Ingress Controller), the minimum and maximum number of pods, and the target CPU or memory usage. For example:
Use the Controller to distribute non-HTTP requests
The NGINX Ingress Controller can serve as a proxy for distributing non-HTTP requests in Kubernetes clusters. This can be useful when you want to expose non-HTTP services to the Internet or to other parts of your network, because HTTP is the default connection.
To use the NGINX Ingress Controller as a proxy for non-HTTP requests, you need to configure the Ingress resources in your cluster to specify the protocol and port for the non-HTTP service. For example, you can use the nginx.ingress.kubernetes.io/ssl-passthrough annotation to specify that the NGINX Ingress Controller should pass through SSL/TLS traffic to the backend service:
Rate limiting
Rate limiting is a technique that is used to control the rate at which a service or system processes requests or transmits data. It can be useful for protecting against DoS (Denial of Service) attacks, mitigating the impact of traffic spikes, and ensuring that the service or system is able to operate effectively and efficiently.
The NGINX Ingress Controller supports rate limiting for connections and transmission rates using the nginx.ingress.kubernetes.io/limit-conn and nginx.ingress.kubernetes.io/limit-rate annotations, respectively. These annotations allow you to specify the maximum number of connections and the maximum transmission rate that the NGINX Ingress Controller should allow for a given Ingress rule.
For example:
Ingress Controller management with Solo Gloo Gateway
The Solo Gloo Gateway is a powerful ingress controller that natively integrates with Kubernetes, and can be managed using GitOps operational models. Not only have Envoy-based Gloo Gateway proven to be a more scalable ingress controller, but it also seamlessly integrates with the control plane and data plane of Gloo Mesh. This enables companies that are just getting started with Kubernetes to have both a powerful ingress controller and API Gateway today, but are future-proofed for expanding their Kubernetes environments in the future, when service mesh is needed for scalability, security and observability.
