Automatic merge from submit-queue
Allow customisation of the nginx proxy_buffer_size directive via ConfigMap
I'm opening a new PR with the same changes as #1693 because I pushed the latter with an email address that can't be used to sign the CLA. Description from the previous PR:
When using nginx as a proxy we can run into the following error:
```
upstream sent too big header while reading response header from upstream
```
In order to fix this, we need to be able to configure the proxy_buffer_size nginx directive to increase its value. This PR updates the nginx-ingress-controller to allow that.
Automatic merge from submit-queue
[nginx-ingress-controller]: Adapt nginx hash sizes to the number of ingress
This change allows the tuning of 2 important NGINX variables:
- server_names_hash_max_size
- server_names_hash_bucket_size
The default values should be enough for most of the users but after +300 Ingress rules or long hostnames as FQDN NGINX requires tuning of this values or it will not start.
The introduced change allows the self-tuning using the Ingress information
Using `--v=3` it's possible to see the changes:
```
...
I0822 21:42:10.517778 1 template.go:84] adjusting ServerNameHashMaxSize variable from 4096 to 16384
...
```
fixes#1487
Automatic merge from submit-queue
ingress: use POD_NAMESPACE as a namespace in cli parameters
When you deploy ingress not into `default` namespace, ingress RC fails with the `no service with name default/default-http-backend found: services "default-http-backend" not found` error message.
This fix uses `POD_NAMESPACE` which we already pass into the pod ENV.
Automatic merge from submit-queue
Use existing uid if one is found
Without this if we create some ingresses we will get eg: a forwarding rule like "foo-uid". Now if we restart
the ingress controller, and while it's down delete the configmap where it stores its uid, it will come back, see an existing ingress, but wrongly record the uid as "empty string". This will cause the ingress to ignore the old forwarding rule, backends etc.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.kubernetes.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.kubernetes.io/reviews/kubernetes/contrib/1363)
<!-- Reviewable:end -->
Automatic merge from submit-queue
Don't clobber backends.
If a parallel ingress controller updates the backend service with another instance group, don't clobber it, just make sure the instance group you put in is there.
Automatic merge from submit-queue
Correctly handle ingress.class in GCE controller
This bug would only get activated when a user has both `ingess.class=gce` and `ingress.class=nginx` ingresses active in the same GCE/GKE cluster, and would manifest as a set of cloud resources created wastefully for the `ingress.class=nginx` ingress as well.
We were previously only ignoring ingress.class (documented here: https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc) when the ingress was created/deleted/modified. There's a chance another ingress with the correct class results in us entering the `sync` routine and listing all ingresses. The listing routine was not smart enough to ignore `ingress.class=nginx`, so we ended up creating resources for the nginx ingress anyway.
The second commit fixes some of the nginx examples to include a `readiness` probe that is == liveness probe.
Minhan or Girish, whichever one has spare cycles first.
