This topic describes how to deploy multiple independent NGINX ingress controllers on a cluster to provide different services for external users.
Background information

Deploy a second NGINX ingress controller
You can perform the following steps to deploy an independent NGINX ingress controller to a cluster.
Test the connectivity
The following example deploys a test application and uses the newly deployed NGINX ingress controller to provide application services for external users.
- Deploy an NGINX application.
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx spec: replicas: 1 selector: matchLabels: run: nginx template: metadata: labels: run: nginx spec: containers: - image: nginx imagePullPolicy: Always name: nginx ports: - containerPort: 80 protocol: TCP restartPolicy: Always --- apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx sessionAffinity: None type: NodePort
- Use the NGINX ingress controller to provide application services for external users.
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx annotations: # Set the value to the ingress class of the new NGINX ingress controller. kubernetes.io/ingress.class: "<YOUR_INGRESS_CLASS>" spec: rules: - host: foo.bar.com http: paths: - path: / backend: serviceName: nginx servicePort: 80
Note You must configure the kubernetes.io/ingress.class annotation.After you deploy the application, the ingress IP address is the same as the IP address of the new NGINX ingress controller.kubectl -n kube-system get svc nginx-ingress-lb
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-lb LoadBalancer 172.19.7.30 47.95.97.115 80:31429/TCP,443:32553/TCP 2d
kubectl -n <YOUR_NAMESPACE> get svc nginx-ingress-lb
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-lb LoadBalancer 172.19.6.227 39.105.252.62 80:30969/TCP,443:31325/TCP 39m
kubectl get ing
NAME HOSTS ADDRESS PORTS AGE nginx foo.bar.com 39.105.252.62 80 5m
- Access the application through the default and new NGINX ingress controllers.
# Access the application through the default NGINX ingress controller. The 404 status code is expected. curl -H "Host: foo.bar.com" http://47.95.97.115 default backend - 404 # Access the application through the new NGINX ingress controller. The NGINX welcome page is expected. curl -H "Host: foo.bar.com" http://39.105.252.62 <! DOCTYPE html> <html> <head> <title>Welcome to nginx! </title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx! </h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
The preceding tests show that application services accessed through different NGINX ingress controllers do not interfere each other. This solution applies to scenarios where some services must be available to external users, but other services only allow requests from non-Kubernetes workloads in the same VPC.