Announcing NGINX Ingress Controller for Kubernetes Release 1.6.0


We are happy to announce release 1.6.0 of the NGINX Ingress Controller for Kubernetes. This release builds upon the development of our supported solution for Ingress load balancing on Kubernetes platforms, including Amazon Elastic Container Service for Kubernetes (EKS), the Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift, IBM Cloud Private, Diamanti, and others.

In the 1.6.0 release, NGINX Ingress Resources – a new configuration approach introduced earlier this year – are enabled by default and ready for production use.

NGINX Ingress Resources are an alternative to the standard Kubernetes Ingress Resource. They provide a richer and safer way to define complex ingress rules, and they support additional use cases. You can use NGINX Ingress Resources at the same time as standard Ingress Resources, which gives you the freedom to define each service by using the most appropriate approach.

Release 1.6.0 also includes:

With this release, we are also pleased to share a new documentation site, available at

There, you will find the complete changelog, including bug fixes, improvements, and changes.

What Is the NGINX Ingress Controller for Kubernetes?

The NGINX Ingress Controller for Kubernetes is a daemon that runs alongside either NGINX Open Source or NGINX Plus instances within a Kubernetes environment. This daemon monitors both Ingress resources and NGINX Ingress Resources to discover requests for services that require ingress load balancing. It then automatically configures NGINX or NGINX Plus to route and load balance traffic to these services.

Multiple NGINX Ingress controller implementations are available. The official NGINX implementation is high‑performance, production‑ready, and suitable for long‑term deployment. We focus on providing stability across releases, with features that can be deployed at enterprise scale. We provide full technical support to NGINX Plus subscribers at no additional cost, and NGINX Open Source users benefit from our focus on stability and supportability.

Introducing NGINX Ingress Resources

In Release 1.5.0, we previewed a new approach to configure request routing and load-balancing. We took advantage of how the Kubernetes API can be extended using custom resources and created a set of alternative resources – NGINX Ingress Resources – with the following goals:

We’re happy to announce that in Release 1.6.0 NGINX Custom resources are enabled by default and suitable for production use.

Improvements to NGINX Ingress Resources

At the core of the NGINX Ingress Resources is the VirtualServer resource. This is used to define:

NGINX Ingress Controller can manage multiple VirtualServer resources at the same time. When it receives a request, it uses the host-level parameters to determine which VirtualServer resource handles that request.

Ingress Controller then processes the routes in the resource in order to determine the action for the request. Commonly, the action will select an upstream, and Ingress Controller will load-balance the request across the Kubernetes pods in that upstream.

For RBAC purposes, a route and upstream may be delegated to a separate VirtualServerRoute resource, located in a different Kubernetes namespace. This grants fine-grained control of upstream definitions and routing rules to other application teams in a safe and secure manner.

Routes Configuration

Routing rules are contained in a routes configuration. This configuration contains a list of path matches, and the corresponding rules to handle requests that match the path.

Patch matches can use either prefix matches or regular expressions (new in the 1.6.0 release).

The routing rules that select how a request is handled are particularly rich. Prior to the 1.6.0 release, the rule simply defined an upstream to handle the request.

New in the 1.6.0 release:

In 1.6.0, conditional match can select a Splits configuration, making it possible to create complex rules such as:

Actions Configuration

Each routing rule ultimately selects an Action configuration. This is a terminal operation that defines how the request should be handled.

Prior to the 1.6.0 release, the only supported action was to select an Upstream Group and load-balance the request to the service instances in that group:

New in the 1.6.0 release:

Upstreams Configuration

The Upstreams configuration defines one or more Upstream Groups, each identified by a name. An upstream group references the Kubernetes Service. When an upstream group is selected by the routing rules and actions, NGINX Ingress Controller will load-balance the request across the pods that are members of that service.

In the 1.6.0 release, you can select a subset of the pods of a service using labels. Additionally, for NGINX Plus, you can use a service of the type ExternalName.

Also new in the 1.6.0 release, you will find much richer control over how NGINX forwards and load-balances requests. You’ll gain more control over load balancing, keepalive and timeout settings, request retries, buffering and performance tuning, as well as support for websockets and NGINX Plus’ slow-start capability. When using the Ingress Controller with NGINX Plus, you can also configure request queuing, upstream health checks and session persistence.


In Release 1.6.0, we’ve added support for OpenTracing in the Ingress Controller, using the open source module (nginx-opentracing) created by the OpenTracing community. You can find out more in the accompanying blog post.

Other Improvements

Release 1.6.0 brings a number of additional stability, performance and security improvements. These are described in detail in the 1.6.0 Release Notes.

Of particular note is the change to run the Ingress Controller container as a non-root user.

Running containers as non-root users is a best practice. Prior to the 1.6.0 release, the Ingress Controller daemon and the NGINX master processes ran as root, while the NGINX worker processes used the unprivileged ‘nginx’ user. In Release 1.6.0, all processes inside the Ingress Controller container run as the ‘nginx’ user. The securityContext field in the pod template in the installation manifests has been updated to add the NET_BIND_SERVICE capability, so that the NGINX master process can continue to bind to privileged ports (80 and 443).

Updated Documentation

Finally, the NGINX Ingress Controller documentation has been moved from GitHub to a new location on Improving the documentation is a work in progress, and we’d welcome any feedback through the GitHub project page.

To test the NGINX Ingress Controller for Kubernetes with NGINX Plus, start your free 30-day trial of NGINX Plus today or contact us to discuss your use cases.

To try NGINX Ingress Controller with NGINX open source, you can obtain the release source code, or take a pre-built container from DockerHub.

Retrieved by Nick Shadrin from website.