Running and managing microservices applications in containers at scale across a cluster of machines is a challenging task. Kubernetes helps you meet the challenge by giving you a powerful solution for container orchestration. It includes several important features, such as fault tolerance, autoscaling, rolling updates, storage, service discovery, and load balancing.
In this blog post we explain how to use NGINX Open Source or NGINX Plus with Ingress, the built‑in Kubernetes load‑balancing framework for HTTP traffic. Ingress enables you to configure rules that control the routing of external traffic to the services in your Kubernetes cluster. You can choose any load balancer that provides an Ingress controller, which is software you deploy in your cluster to integrate Kubernetes and the load balancer. Here we show you how to configure load balancing for a microservices application with Ingress and the Ingress controllers we provide for NGINX Plus and NGINX.
[Editor – The previously separate controllers for NGINX and NGINX Plus have been merged into a single Ingress controller for both.]
In this blog post we examine only HTTP load balancing for Kubernetes with Ingress. To learn more about other load‑balancing options, see Load Balancing Kubernetes Services with NGINX Plus on our blog.
Note: Complete instructions for the procedures discussed in this blog post are available at our GitHub repository. This post doesn’t go through every necessary step, but instead provides links to those instructions.
Before we deploy the sample application and configure load balancing for it, we must choose a load balancer and deploy the corresponding Ingress controller.
An Ingress controller is software that integrates a particular load balancer with Kubernetes. We have developed an Ingress controller for both NGINX Open Source and NGINX Plus, now available on our GitHub repository. There are also other implementations created by third parties; to learn more, visit the Ingress Controllers page at the GitHub repository for Kubernetes.
For complete instructions on deploying the NGINX or NGINX Plus Ingress controller in your cluster, see our GitHub repository.
Our sample application is a typical microservices web application that consists of multiple services, each deployed separately. The application, called cafe, lets you order either tea via the tea service or coffee via the coffee service. You indicate your drink preference with the URI of your HTTP request: URIs ending with /tea get you tea and URIs ending with /coffee get you coffee. Connections to the application must be secured with SSL/TLS.
The diagram below conceptually depicts the application, with the NGINX Plus load balancer playing the important role of routing client requests to the appropriate service as well as securing client connections with SSL/TLS.
To deploy the application in your cluster, follow the instructions on our GitHub repository.
Our cafe app requires the load balancer to provide two functions:
To configure load balancing with Ingress, you define rules in an Ingress resource. The rules specify how to route external traffic to the services in your cluster.
In the resource you can define multiple virtual servers, each for a different domain name. A virtual server usually corresponds to a single microservices application deployed in the cluster. For each server, you can:
You can find a more detailed explanation of Ingress, with examples, on the Ingress documentation page.
Here is the Ingress resource (cafe‑ingress.yaml) for the cafe app:
Examining it line by line, we see:
In lines 6–9 we set up SSL/TLS termination:
In lines 13–21 we define two path‑based rules:
For complete instructions on deploying the Ingress and Secret resources in the cluster, see our GitHub repository.
Once we deploy the NGINX Plus Ingress controller, our application, the Ingress resource, and the Secret resource, we can test the app.
When we make a tea request with the /tea URI, in the browser we see a page generated by the tea service.
We hope you’re not too disappointed that the tea and coffee services don’t actually give you drinks, but rather information about the containers they’re running in and the details of your request. Those include the container hostname and IP address, the request URI, and the client IP address. Each time we refresh the page we get a response from a different container.
We can also connect to the NGINX Plus live activity monitoring dashboard and see real‑time load balancing metrics from NGINX Plus and each container of our application.
Ingress provides basic HTTP load‑balancing functionality. However, it is often the case that the load‑balancing requirements for your applications are more complex and thus not supported by Ingress. To address some of those requirements, we have added a number of extensions to the Ingress controller. This way you can still take an advantage of using Kubernetes resources to configure load balancing (as opposed to having to configure the load balancer directly) but leveraging the ability to utilize advanced load‑balancing features.
For a complete list of the available extensions, see our GitHub repository.
In addition, we provide a mechanism to customize NGINX configuration by means of Kubernetes resources, via Config Maps resources or Annotations. For example, you can customize values of the proxy_connect_timeout
or proxy_read_timeout
directives.
When your load‑balancing requirements go beyond those supported by Ingress and our extensions, we suggest a different approach to deploying and configuring NGINX Plus that doesn’t use the Ingress controller. Read Load Balancing Kubernetes Services with NGINX Plus on our blog to find out more.
With NGINX Plus, the Ingress controller provides the following benefits in addition to those you get with NGINX:
Kubernetes provides built‑in HTTP load balancing to route external traffic to the services in the cluster with Ingress. NGINX and NGINX Plus integrate with Kubernetes load balancing, fully supporting Ingress features and also providing extensions to support extended load‑balancing requirements.
To try out NGINX Plus and the Ingress controller, start your free 30-day trial today or contact us to discuss your use cases.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."