NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing

NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing

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 the open source NGINX software 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 are have recently introduced for NGINX Plus and NGINX.

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.

Ingress Controllers for NGINX and NGINX Plus

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 Ingress controllers for both open source NGINX and NGINX Plus, now available on our GitHub repository. Other implementations also exist; to learn more, visit the Ingress Controllers page at the GitHub repository for Kubernetes.

For complete instructions on deploying the NGINX Plus Ingress controller in your cluster, see our GitHub repository.

The Sample Microservices Application

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.

Configuring Kubernetes Load Balancing via Ingress

Our cafe app requires the load balancer to provide two functions:

• Routing based on the request URI (also called path‑based routing)
• SSL/TLS termination

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:

• Specify multiple path‑based rules. Traffic is sent to different services in an application based on the request URI.
• Set up SSL/TLS termination by referencing an SSL/TLS certificate and key.

You can find a more detailed explanation of Ingress, with examples, on the Ingress documentation page.

Here is the Ingress resource for the cafe app (cafe‑ingress.yaml):

 1. apiVersion: extensions/v1beta1

 2. kind: Ingress

 3. metadata:

 4.  name: cafe-ingress

 5. spec:

 6.  tls:

 7.  - hosts:

 8.    - cafe.example.com

 9.    secretName: cafe-secret

10.  rules:

11.  - host: cafe.example.com

12.    http:

13.      paths:

14.      - path: /tea

15.        backend:

16.          serviceName: tea-svc

17.          servicePort: 80

18.      - path: /coffee

19.        backend:

20.          serviceName: coffee-svc

21.          servicePort: 80

Examining it line by line, we see:

• In line 4 we name the resource cafe‑ingress.

• In lines 6–9 we set up SSL/TLS termination:

  • In line 9 we reference a Secret resource by its name cafe‑secret. This resource contains the SSL/TLS certificate and key and it must be deployed prior to the Ingress resource.
  • In line 8 we apply the certifcate and key to our cafe.example.com virtual server.
• In line 11 we define a virtual server with domain name cafe.example.com.

• In lines 13–21 we define two path‑based rules:

  • The rule defined in lines 14–17 instructs the load balancer to distribute the requests with the /tea URI among the containers of the tea service, which is deployed with the name tea‑svc in the cluster.
  • The rule defined in lines 18–21 instructs the load balancer to distribute the requests with the /coffee URI among the containers of the coffee service, which is deployed with the name coffee‑svc in the cluster.
  • Both rules instruct the load balancer to distribute the requests to port 80 of the corresponding service.

For complete instructions on deploying the Ingress and Secret resources in the cluster, see the GitHub repository.

Testing the Application

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 andcoffee 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 Controller Extensions

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 couple 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.

Currently, we provide the following extensions to our Ingress controllers:

• WebSocket, which allows you to load balance WebSocket applications
• Session Persistence (NGINX Plus only), which guarantees that requests from a given client are always passed to the same backend container

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 what Ingress and our extensions support, 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.

Benefits of the NGINX Plus Controller

The NGINX Plus controller provides the following benefits in addition to those provided by the NGINX controller:

• Stability in a highly dynamic environment – Every time there is a change to the number of pods of services being exposed via Ingress, the Ingress controller needs to update the NGINX or NGINX Plus configuration to reflect the changes. With open source NGINX, you must change the configuration file manually and reload the configuration. With NGINX Plus, you can use the on‑the‑fly reconfiguration API to update the configuration without reloading the configuration file. This prevents the potential increased memory usage and overall system overloading that can occur when configuration reloads are very frequent.
• Real‑time statistics – NGINX Plus provides advanced real‑time statistics, which you can access either through an API or on the built‑in dashboard. This can give you insights into how NGINX Plus and your applications are performing.
• Session persistence – When you enable session persistence, NGINX Plus makes sure that all the requests from the same client are always passed to the same backend container using the sticky cookie method.
• Support – The NGINX, Inc. Professional Services team can provide assistance with the NGINX and NGINX Plus Ingress controller.

Summary

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 for a live demo.

The post NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing appeared first on NGINX.

Source: NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing