</code></pre></div><ul><li>Use Helm to install the additional instance of the ingress controller</li><li>Ensure you have Helm working (refer to the <ahref=https://helm.sh/docs/>Helm documentation</a>)</li><li>We have to assume that you have the helm repo for the ingress-nginx controller already added to your Helm config. But, if you have not added the helm repo then you can do this to add the repo to your helm config;</li></ul><divclass=highlight><pre><span></span><code>helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
</code></pre></div><ul><li>Make sure you have updated the helm repo data;</li></ul><divclass=highlight><pre><span></span><code>helm repo update
</code></pre></div><ul><li>Now, install an additional instance of the ingress-nginx controller like this:</li></ul><divclass=highlight><pre><span></span><code>helm install ingress-nginx-2 ingress-nginx/ingress-nginx \
</code></pre></div><p>If you need to install yet another instance, then repeat the procedure to create a new namespace, change the values such as names & namespaces (for example from "-2" to "-3"), or anything else that meets your needs.</p><p>Note that <code>controller.ingressClassResource.name</code> and <code>controller.ingressClass</code> have to be set correctly. The first is to create the IngressClass object and the other is to modify the deployment of the actual ingress controller pod.</p><h3id=i-cant-use-multiple-namespaces-what-should-i-do>I can't use multiple namespaces, what should I do?<aclass=headerlinkhref=#i-cant-use-multiple-namespaces-what-should-i-dotitle="Permanent link"> ¶</a></h3><p>If you need to install all instances in the same namespace, then you need to specify a different <strong>election id</strong>, like this:</p><divclass=highlight><pre><span></span><code>helm install ingress-nginx-2 ingress-nginx/ingress-nginx \
</code></pre></div><h2id=retaining-client-ipaddress>Retaining Client IPAddress<aclass=headerlinkhref=#retaining-client-ipaddresstitle="Permanent link"> ¶</a></h2><p>Question - How to obtain the real-client-ipaddress ?</p><p>The goto solution for retaining the real-client IPaddress is to enable PROXY protocol.</p><p>Enabling PROXY protocol has to be done on both, the Ingress NGINX controller, as well as the L4 load balancer, in front of the controller.</p><p>The real-client IP address is lost by default, when traffic is forwarded over the network. But enabling PROXY protocol ensures that the connection details are retained and hence the real-client IP address doesn't get lost.</p><p>Enabling proxy-protocol on the controller is documented <ahref=https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-proxy-protocol>here</a> .</p><p>For enabling proxy-protocol on the LoadBalancer, please refer to the documentation of your infrastructure provider because that is where the LB is provisioned.</p><p>Some more info available <ahref=https://kubernetes.github.io/ingress-nginx/user-guide/miscellaneous/#source-ip-address>here</a></p><p>Some more info on proxy-protocol is <ahref=https://kubernetes.github.io/ingress-nginx/user-guide/miscellaneous/#proxy-protocol>here</a></p><h3id=client-ipaddress-on-single-node-cluster>client-ipaddress on single-node cluster<aclass=headerlinkhref=#client-ipaddress-on-single-node-clustertitle="Permanent link"> ¶</a></h3><p>Single node clusters are created for dev & test uses with tools like "kind" or "minikube". A trick to simulate a real use network with these clusters (kind or minikube) is to install Metallb and configure the ipaddress of the kind container or the minikube vm/container, as the starting and ending of the pool for Metallb in L2 mode. Then the host ip becomes a real client ipaddress, for curl requests sent from the host.</p><p>After installing ingress-nginx controller on a kind or a minikube cluster with helm, you can configure it for real-client-ip with a simple change to the service that ingress-nginx controller creates. The service object of --type LoadBalancer has a field service.spec.externalTrafficPolicy. If you set the value of this field to "Local" then the real-ipaddress of a client is visible to the controller.</p><divclass=highlight><pre><span></span><code>% kubectl explain service.spec.externalTrafficPolicy
KIND: Service
VERSION: v1
FIELD: externalTrafficPolicy <string>
DESCRIPTION:
externalTrafficPolicy describes how nodes distribute service traffic they
receive on one of the Service's "externally-facing" addresses (NodePorts,
ExternalIPs, and LoadBalancer IPs). If set to "Local", the proxy will
configure the service in a way that assumes that external load balancers
will take care of balancing the service traffic between nodes, and so each
node will deliver traffic only to the node-local endpoints of the service,
without masquerading the client source IP. (Traffic mistakenly sent to a
node with no endpoints will be dropped.) The default value, "Cluster", uses
the standard behavior of routing to all endpoints evenly (possibly modified
by topology and other features). Note that traffic sent to an External IP or
LoadBalancer IP from within the cluster will always get "Cluster" semantics,
but clients sending to a NodePort from within the cluster may need to take
traffic policy into account when picking a node.
Possible enum values:
- `"Cluster"` routes traffic to all endpoints.
- `"Local"` preserves the source IP of the traffic by routing only to
endpoints on the same node as the traffic was received on (dropping the
traffic if there are no local endpoints).
</code></pre></div><h3id=client-ipaddress-l7>client-ipaddress L7<aclass=headerlinkhref=#client-ipaddress-l7title="Permanent link"> ¶</a></h3><p>The solution is to get the real client IPaddress from the <ahref=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For>"X-Forward-For" HTTP header</a></p><p>Example : If your application pod behind Ingress NGINX controller, uses the NGINX webserver and the reverseproxy inside it, then you can do the following to preserve the remote client IP.</p><ul><li><p>First you need to make sure that the X-Forwarded-For header reaches the backend pod. This is done by using a Ingress NGINX conftroller ConfigMap key. Its documented <ahref=https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-forwarded-headers>here</a></p></li><li><p>Next, edit <code>nginx.conf</code> file inside your app pod, to contain the directives shown below:</p></li></ul><divclass=highlight><pre><span></span><code>set_real_ip_from 0.0.0.0/0; # Trust all IPs (use your VPC CIDR block in production)
real_ip_header X-Forwarded-For;
real_ip_recursive on;
log_format main '$remote_addr - $remote_user [$time_local] "$request"'
</code></pre></div><h2id=kubernetes-v122-migration>Kubernetes v1.22 Migration<aclass=headerlinkhref=#kubernetes-v122-migrationtitle="Permanent link"> ¶</a></h2><p>If you are using Ingress objects in your cluster (running Kubernetes older than version 1.22), and you plan to upgrade your Kubernetes version to K8S 1.22 or above, then please read <ahref=../user-guide/k8s-122-migration/>the migration guide here</a>.</p><h2id=validation-of-path>Validation Of <strong><code>path</code></strong><aclass=headerlinkhref=#validation-of-pathtitle="Permanent link"> ¶</a></h2><ul><li><p>For improving security and also following desired standards on Kubernetes API spec, the next release, scheduled for v1.8.0, will include a new & optional feature of validating the value for the key <code>ingress.spec.rules.http.paths.path</code>.</p></li><li><p>This behavior will be disabled by default on the 1.8.0 release and enabled by default on the next breaking change release, set for 2.0.0.</p></li><li><p>When "<code>ingress.spec.rules.http.pathType=Exact</code>" or "<code>pathType=Prefix</code>", this validation will limit the characters accepted on the field "<code>ingress.spec.rules.http.paths.path</code>", to "<code>alphanumeric characters</code>", and "<code>/</code>", "<code>_</code>", "<code>-</code>". Also, in this case, the path should start with "<code>/</code>".</p></li><li><p>When the ingress resource path contains other characters (like on rewrite configurations), the pathType value should be "<code>ImplementationSpecific</code>".</p></li><li><p>API Spec on pathType is documented <ahref=https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types>here</a></p></li><li><p>When this option is enabled, the validation will happen on the Admission Webhook. So if any new ingress object contains characters other than alphanumeric characters, and, "<code>/</code>", "<code>_</code>", "<code>-</code>", in the <code>path</code> field, but is not using <code>pathType</code> value as <code>ImplementationSpecific</code>, then the ingress object will be denied admission.</p></li><li><p>The cluster admin should establish validation rules using mechanisms like "<code>Open Policy Agent</code>", to validate that only authorized users can use ImplementationSpecific pathType and that only the authorized characters can be used. <ahref=https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#strict-validate-path-type>The configmap value is here</a></p></li><li><p>A complete example of an Openpolicyagent gatekeeper rule is available <ahref=https://kubernetes.github.io/ingress-nginx/examples/openpolicyagent/>here</a></p></li><li><p>If you have any issues or concerns, please do one of the following:</p></li><li>Open a GitHub issue</li><li>Comment in our Dev Slack Channel</li><li>Open a thread in our Google Group <ahref=mailto:ingress-nginx-dev@kubernetes.io>ingress-nginx-dev@kubernetes.io</a></li></ul><h2id=why-is-chunking-not-working-since-controller-v110>Why is chunking not working since controller v1.10 ?<aclass=headerlinkhref=#why-is-chunking-not-working-since-controller-v110title="Permanent link"> ¶</a></h2><ul><li><p>If your code is setting the HTTP header <code>"Transfer-Encoding: chunked"</code> and the controller log messages show an error about duplicate header, it is because of this change <ahref=http://hg.nginx.org/nginx/rev/2bf7792c262e>http://hg.nginx.org/nginx/rev/2bf7792c262e</a></p></li><li><p>More details are available in this issue <ahref=https://github.com/kubernetes/ingress-nginx/issues/11162>https://github.com/kubernetes/ingress-nginx/issues/11162</a></p></li></ul></article></div></div></main><footerclass=md-footer><divclass="md-footer-meta md-typeset"><divclass="md-footer-meta__inner md-grid"><divclass=md-copyright> Made with <ahref=https://squidfunk.github.io/mkdoc
