NGINX Controller Tech Specs

Guidelines and recommendations for configuring NGINX Controller.

Overview

This guide lists the technical recommendations for NGINX Controller v3 and NGINX Controller Agent. Review this guide before installing or updating NGINX Controller or NGINX Controller Agent.

Supported Distributions

NGINX Controller, the NGINX Controller Agent, and the NGINX Controller Application Security Add-on support the following distributions and architectures:

Distribution Version Architecture(s) NGINX Controller
(Control Plane)
Controller Agent
(Data Plane)
App Security Add-on
(Data Plane)
Notes
Amazon Linux 2 x86_64 Not supported v3.0+ Not supported
Amazon Linux 2017.09+ x86_64 Not supported v3.0+ Not supported
CentOS 6.5+ x86_64 Not supported v3.0+ Not supported • CentOS 6.5 and later versions in the CentOS 6 family are partially supported.
• This distribution does not support AVRD.
CentOS 7.4+ x86_64 v3.0+ v3.0+ v3.12+ • CentOS 7.4 and later versions in the CentOS 7 family are supported.
Debian 8 x86_64 Not supported v3.0+ Not supported • This distribution does not support AVRD.
Debian 9 x86_64 v3.0+ v3.0+ v3.12+
Debian 10 x86_64 Not supported v3.17+ v3.17+ Important: Support for Debian 10 is included as a technical preview. Functionality has been verified; however, more testing is needed before we finalize this feature. Look for updates in future releases. See the NGINX Plus Admin Guide for requirements for Debian 10.
Red Hat Enterprise Linux 6.5+ x86_64 Not supported v3.0+ Not supported • RHEL 6.5 and later versions in the RHEL 6 family are partially supported.
Red Hat Enterprise Linux 7.4+ x86_64 v3.5+ v3.5+ v3.12+ • RHEL 7.4 and later versions in the RHEL 7 family are supported.
RHEL 8 is not supported at this time.
• SELinux may interfere with NGINX Controller installation and operation. If you do enable SELinux, it must use permissive mode. Use of enforcing mode is not supported.
Ubuntu 18.04 LTS x86_64 v3.0+ v3.0+ v3.13+
Ubuntu 20.04 LTS x86_64 Not supported v3.12+ v3.16.1+
Note:
The NGINX Controller App Security Add-on is only available for use with the NGINX Controller Application Delivery Module.

Analytics, Visibility, and Reporting Daemon (AVRD)

NGINX Controller v3.1 and later use an Analytics, Visibility, and Reporting daemon (AVRD) to aggregate and report app-centric metrics, which you can use to track and check the health of your apps. To learn more about these metrics, see the NGINX Metrics Catalog topic.

 


Storage Requirements

The following table shows the minimum storage requirements we recommend for NGINX Controller. Your final storage requirements may differ depending on your environment, configuration, and the number of instances, apps, and APIs you’re managing. Production deployments, for example, will require more storage than trial deployments. Contact your NGINX Controller sales associate if you have questions about sizing for your particular environment.

We recommend using a local volume for the analytics and config databases for trial deployments, for simplicity’s sake so you can get started using NGINX Controller right away. For production environments, we recommend using an external volume for the databases for resiliency.

Resource Path(s) Minimum Storage
NGINX Controller /opt/nginx-controller 80 GB
Analytics database /opt/nginx-controller/clickhouse_data • 50 GB
• 150 GB if App Security is enabled
Config database /opt/nginx-controller/postgres_data 10 GB
Logs • /var/log/nginx-controller
• /var/log/journal
• /var/log/pods
• /var/lib/docker/containers
• /var/lib/kubelet
• /var/lib/kubernetes
15 GB cumulative

 


Supported Deployment Environments

You can deploy NGINX Controller v3 into the following environments:

  • Bare metal
  • Public cloud: Amazon Web Services, Google Cloud Platform, Microsoft Azure
  • Virtual Machine

 


NGINX Plus Instances

NGINX Controller, using the Controller Agent, can monitor and manage up to 100 NGINX Plus instances. When using Controller App Security, NGINX Controller can monitor and manage up to 30 NGINX Plus instances with NGINX App Protect installed.

NGINX Controller supports the following NGINX Plus versions:

NGINX Plus NGINX Controller
R24 v3.17+
R23 v3.12+
R22 v3.5+
R21 v3.3+
R20 v3.0+
R19 v3.0+

 


NGINX App Protect Compatibility Matrix

The App Security add-on for the NGINX Controller Application Delivery module is compatible with the versions of NGINX Plus and NGINX App Protect shown in the table below.

See Also:
Refer to Using NGINX App Protect with NGINX Controller for installation instructions and additional information.
NGINX Controller version NGINX App Protect version(s) NGINX Plus version(s)
v3.17+ v3.2 R24
v3.16+ v3.1, v3.0, v2.3
v2.1.1
R23
R22
v3.15+ v3.0, v2.3
v2.1.1
R23
R22
v3.14+ v3.0, v2.3
v2.1.1
R23
R22
v3.13+ v2.3
v2.1.1
R23
R22
v3.12+ v2.1.1 R22

 


Supported Browsers

NGINX Controller works best with the newest and the last prior version of these browsers with JavaScript, cookies, and SSL enabled:

Important:

You may need to turn off any ad blockers while using the NGINX Controller user interface.

In some cases, the NGINX Controller user interface may not display analytics or security events if an ad blocker is enabled. Refer to the AskF5 KB article K48603454 to learn more about this issue and how to resolve it.

 


Hardware Specifications

The following minimum hardware specifications are required for each node running NGINX Controller:

  • RAM: 8 GB RAM
  • CPU: 8-Core CPU @ 2.40 GHz or similar
  • Disk space: 155–255 GB free disk space. 255 GB of free space is recommended if NGINX Controller App Security is enabled. See the Storage Requirements section for a categorized list of the storage requirements.

The NGINX Controller Agent consumes as little memory and CPU as possible. CPU usage should be under 10%, and RSS memory consumption should be just a few dozen MBs. If you notice the NGINX Controller Agent consuming resources at a higher rate, you should contact NGINX Support for assistance.

 


NGINX Controller Database Requirements

When installing NGINX Controller, you can choose the type of volume to use for the analytics and config databases. The types of volumes that are supported are:

We recommend using a local volume for the analytics and config databases for trial deployments, for simplicity’s sake so you can get started using NGINX Controller right away. For production environments, we recommend using an external volume for the databases for resiliency.

 

Local Storage

When using local storage for the analytics and/or config database, we recommend the following specs:

  • 100 IOPS
  • 155–255 GB free disk space. 255 GB of free space is recommended if NGINX Controller App Security is enabled. See the Storage Requirements section for a categorized list of the storage requirements.
Tip:
To conserve IO and/or disk space, you can use a separate disk for the local storage directory /opt/nginx-controller/clickhouse_data.

 

NFS

To use NFS for external storage for the analytics and/or config database, consider the following:

  • Make certain that the NFS version used by the server is supported by the client system where you’re installing NGINX Controller.
  • If you’re using NFS v4 file locking or Network Lock Manager (NLM) on the NFS server, make sure that the client system that’s running your NGINX Controller has access to the mount point.
  • Install the nfs-common (on Ubuntu/Debian) or nfs-utils (on CentOS/RedHat) package on all hosts on which NGINX Controller will be installed.
  • The no_root_squash option must be set for the mount point on the NFS server. If this is not allowed, the owner of the path used for the analytics database must be set to 101:101 and owner of the path for config database must be set to 70:70.
  • The config database should support a throughput of 2 MiB/s or greater.

 

AWS EBS

Important:
If you plan to run NGINX Controller on AWS EC2 instances, we recommend using NFS shares for the external volumes. Using EBS shares for multi-node clusters is not recommended because of the EBS Availability Zone limitations; for example, the requirement to have EC2 instances and EBS volumes in the same Availability Zone.

If you are installing NGINX Controller on AWS EC2 instances and plan to use EBS volumes for the analytics and/or config database, consider the following:

You will need add an IAM role like that shown below.

  • IAM Role for Single-Node Installation

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "autoscaling:DescribeAutoScalingGroups",
            "autoscaling:DescribeLaunchConfigurations",
            "autoscaling:DescribeTags",
            "ec2:DescribeInstances",
            "ec2:DescribeRegions",
            "ec2:DescribeRouteTables",
            "ec2:DescribeSecurityGroups",
            "ec2:DescribeSubnets",
            "ec2:DescribeVolumes",
            "ec2:CreateSecurityGroup",
            "ec2:CreateTags",
            "ec2:CreateVolume",
            "ec2:ModifyInstanceAttribute",
            "ec2:ModifyVolume",
            "ec2:AttachVolume",
            "ec2:AuthorizeSecurityGroupIngress",
            "ec2:CreateRoute",
            "ec2:DeleteRoute",
            "ec2:DeleteSecurityGroup",
            "ec2:DeleteVolume",
            "ec2:DetachVolume",
            "ec2:RevokeSecurityGroupIngress",
            "ec2:DescribeVpcs",
            "iam:CreateServiceLinkedRole",
            "kms:DescribeKey"
          ],
          "Resource": [
            "*"
          ]
        }
      ]
    }
    
  • IAM Role for Multi-Node Installation

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "autoscaling:DescribeAutoScalingGroups",
            "autoscaling:DescribeLaunchConfigurations",
            "autoscaling:DescribeTags",
            "ec2:DescribeInstances",
            "ec2:DescribeRegions",
            "ec2:DescribeRouteTables",
            "ec2:DescribeSecurityGroups",
            "ec2:DescribeSubnets",
            "ec2:DescribeVolumes",
            "ec2:CreateSecurityGroup",
            "ec2:CreateTags",
            "ec2:CreateVolume",
            "ec2:ModifyInstanceAttribute",
            "ec2:ModifyVolume",
            "ec2:AttachVolume",
            "ec2:AuthorizeSecurityGroupIngress",
            "ec2:CreateRoute",
            "ec2:DeleteRoute",
            "ec2:DeleteSecurityGroup",
            "ec2:DeleteVolume",
            "ec2:DetachVolume",
            "ec2:RevokeSecurityGroupIngress",
            "ec2:DescribeVpcs",
            "elasticloadbalancing:AddTags",
            "elasticloadbalancing:AttachLoadBalancerToSubnets",
            "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
            "elasticloadbalancing:CreateLoadBalancer",
            "elasticloadbalancing:CreateLoadBalancerPolicy",
            "elasticloadbalancing:CreateLoadBalancerListeners",
            "elasticloadbalancing:ConfigureHealthCheck",
            "elasticloadbalancing:DeleteLoadBalancer",
            "elasticloadbalancing:DeleteLoadBalancerListeners",
            "elasticloadbalancing:DescribeLoadBalancers",
            "elasticloadbalancing:DescribeLoadBalancerAttributes",
            "elasticloadbalancing:DetachLoadBalancerFromSubnets",
            "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
            "elasticloadbalancing:ModifyLoadBalancerAttributes",
            "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
            "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
            "elasticloadbalancing:AddTags",
            "elasticloadbalancing:CreateListener",
            "elasticloadbalancing:CreateTargetGroup",
            "elasticloadbalancing:DeleteListener",
            "elasticloadbalancing:DeleteTargetGroup",
            "elasticloadbalancing:DescribeListeners",
            "elasticloadbalancing:DescribeLoadBalancerPolicies",
            "elasticloadbalancing:DescribeTargetGroups",
            "elasticloadbalancing:DescribeTargetHealth",
            "elasticloadbalancing:ModifyListener",
            "elasticloadbalancing:ModifyTargetGroup",
            "elasticloadbalancing:RegisterTargets",
            "elasticloadbalancing:DeregisterTargets",
            "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
            "iam:CreateServiceLinkedRole",
            "kms:DescribeKey"
          ],
          "Resource": [
            "*"
          ]
        }
      ]
    }
    

 


Supported PostgreSQL Versions

NGINX Controller supports the following versions of PostgreSQL:

  • PostgreSQL 12.x – works with NGINX Controller 3.9 and later.
  • PostgreSQL 9.5 – works with NGINX Controller 3.0 and later.

For a system monitoring 100 NGINX Plus instances, we recommend at least 32 GB of database storage. Database storage requirements can vary, depending on the number of NGINX Plus instances, components, published API specs, and the churn rate for configuration changes. For monitor-only implementations, the database storage needs are small; for API Management (APIM) and/or App Delivery Controller (ADC) implementations in production, the storage needs are greater.

Important:
If you use PostgreSQL 12, we recommend disabling Just-in-Time (JIT) compilation to improve NGINX Controller’s performance. To disable JIT, edit the postgresql.conf file and set jit=off.

 


Firewall/IP Settings

Configure NGINX Controller with the following firewall settings:

Port Used by Used for
432 TCP NGINX Controller database Incoming connections to the NGINX Controller database from the NGINX Controller host
443 TCP • NGINX Controller
• NGINX Controller licensing
• Incoming connections to NGINX Controller from a browser; for example, from an internal network and NGINX Plus instances
• Incoming and outgoing connections used to used to validate the entitlements for your NGINX Controller license
8443 TCP NGINX Controller Incoming connections from NGINX Plus instances
8883 TCP NGINX Controller licensing Incoming and outgoing connections used to validate the entitlements for your NGINX Controller license
Note:
Port 8883 TCP needs to be opened only if you’re running NGINX Controller v3.15 or earlier.

If you have a firewall running on the NGINX Controller host, enable NAT (masquerade) and open the following ports. These ports are used for internal traffic only and don’t need to be open to the outside:

Port Used by Used for
2379 TCP
2380 TCP
6443 TCP
NGINX Controller Incoming requests to the Kubernetes control plane; used for the Kubernetes API server and etcd
10250 TCP NGINX Controller Incoming requests to the Kubernetes worker node; used for the Kubelet API
10251 TCP NGINX Controller Incoming requests to the Kubernetes kube-scheduler; used for the pod scheduling
10252 TCP NGINX Controller Incoming requests to the Kubernetes kube-controller-manager; used for regulating the state of the system
8472 UDP NGINX Controller Used for pod-to-pod communication in multi-node resilient clusters

For more information about these ports, see the Kubernetes guide Installing kubeadm .

 


Supported Python Versions

NGINX Controller and the NGINX Controller Agent versions 3.6 and earlier require Python 2.6 or 2.7. Python is not needed for NGINX Controller or the NGINX Controller Agent versions 3.7 and later.

 


Open-Source Licenses

The list of open-source packages and their licenses used by NGINX Controller can be found in the downloaded file that is part of the NGINX Controller package. On your NGINX Controller host, see controller-installer/files/license-controller.md.

In addition, see the AskF5 KB article Third-party software for NGINX Controller controller-datacollection-components for third-party software packages that may be used by or distributed with controller-datacollection-components. This information is not included in the license-controller.md that’s mentioned above.


This documentation applies to the following versions of NGINX Controller Documentation: 3.0, 3.1, 3.2, 3.3, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.12, 3.13, 3.14, 3.15, 3.16.1, 3.17 and 3.18.