nginx/nginx-ingress-operator

https://www.repostatus.org/badges/latest/active.svg](https://www.repostatus.org/#active) !https://badgen.net/badge/support/commercial/green?icon=awesome

NGINX Ingress Operator

The NGINX Ingress Operator is a Kubernetes/OpenShift component which deploys and manages one or more https://github.com/nginx/kubernetes-ingress which in turn handle Ingress traffic for applications running in a cluster.

Learn more about operators in the https://kubernetes.io/docs/concepts/extend-kubernetes/operator/.

To install a specific version of the NGINX Ingress Controller with the operator, a specific version of the NGINX Ingress Operator is required.

Up until version 0.5.1, this Operator was Go based. Version 1.0.0 marks an incompatible upgrade as this release switched the Operator to being Helm-based, built from the NGINX Ingress Controller Helm chart. The configuration for the Helm chart can be seen in the NGINX Ingress Controller documentation.

The following table shows the relation between the versions of the two projects:

Note: The NGINX Ingress Operator works only for NGINX Ingress Controller versions after 1.7.0.

Getting Started

1. Install the NGINX Ingress Operator. See docs.
   NOTE: To use TransportServers as part of your NGINX Ingress Controller configuration, a GlobalConfiguration resource must be created before starting the Operator - see the notes

2. Creating the default-server-secret.yaml is optional and it is recommended that users provide their own certificate. An example yaml for this can be found in the https://github.com/nginx/nginx-ingress-helm-operator/blob/main/examples/default-server-secret.yaml

3. (If using OpenShift) Create the scc resource on the cluster by applying the scc.yaml file found in the resources folder of this repo:

   shell
   kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-ingress-helm-operator/main/resources/scc.yaml
   

4. Deploy a new NGINX Ingress Controller using the NginxIngress Custom Resource:

   • Use the name of the default server secret created above for controller.defaultTLS.secret field (needs to be in the form namespace/name)
   • If using NGINX Plus:
     • Set the controller.nginxPlus to true
     • Set the controller.image.repository and controller.image.tag to the appropriate values
     • Set the controller.serviceAccount.imagePullSecretName if applicable
   • For full configuration details see the Helm documentation here.

Notes: Multiple NIC Deployments

• Please see the NGINX Ingress Controller documentation for general information on running multiple NGINX Ingress Controllers in your cluster.
• To run multiple NIC instances deployed by the NGINX Ingress Operator in your cluster in the same namespace, rbac.create should be set to false, and the ServiceAccount and ClusterRole***ding need to be created independently of the deployments. Please note that controller.serviceAccount.imagePullSecretName will also be ignored in this configuration, and will need to be configured as part of the independent ServiceAccount creation.
• The ClusterRole***ding needs to configured to ***d to the nginx-ingress-operator-nginx-ingress-admin ClusterRole.
• See RBAC example spec for an example ServiceAccount and ClusterRole***ding manifest.
• To run multiple NIC instances deployed by the NGINX Ingress Operator in your cluster in any namespace but sharing an IngressClass, controller.ingressClass.name should be set to an e***y string and the IngressClass resource needs to be created independently of the deployments.Please note that controller.ingressClass.setAsDefaultIngress will also be ignored in this configuration, and will need to be configured as part of the independent IngressClass creation.
• See IngressClass example spec for an example IngressClass manifest.

Upgrades

See upgrade docs

NGINX Ingress Operator Releases

We publish NGINX Ingress Operator releases on GitHub. See our https://github.com/nginx/nginx-ingress-helm-operator/releases.

The latest stable release is https://github.com/nginx/nginx-ingress-helm-operator/releases/tag/v3.6.2. For production use, we recommend that you choose the latest stable release.

Development

It is possible to run the operator in your local machine. This is useful for testing or during development.

Run Operator locally

1. Have access to a Kubernetes/OpenShift cluster.

2. Apply the IC CRD:

   shell
    make install
   

3. Run make run.

The operator will run in your local machine but will be communicating with the cluster.

Contributing

If you'd like to contribute to the project, please read our Contributing guide.