<p>What you have installed, the <code>ingress controller</code>, is only one part of the story. The other part is an <code>ingress</code>: in an <code>ingress</code> you define what pods/services should receive traffic of what domain and request path. The <code>ingress controller</code> picks this information up, and dynamically reconfigures the underlying proxy, in your case nginx. You can find examples of ingresses in the official documentation: <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/#types-of-ingress" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/ingress/#types-of-ingress</a></p>

CC BY-SA 3.0
2017-11-26T16:38:06.693Z
2017-11-26T16:38:06.693Z
slintes
<p>Ingress controllers allow you to not manually wire stuff up, that's the whole point.</p>

<p>If you'd rather do it manually You could have an nginx array (either inside Kubernetes our outside of it) and just point to the ip/port of the services that expose your microservices. If you use an nginx array external to Kubernetes you'd have to use the externalIP service type. If you run the Nginx array on Kubernetes you could store your "manual proxy config" in a configmap so that all your nginx proxies get the same config.</p>

<p>I would definetely advise to not do this tho. Ingress controllers are built to simplify traffic routing, and as your complexity grows you will definetely want to take advantage of them. A good labeling scheme is absolutely paramount in Kubernetes, and that goes for ingresses aswell. </p>

CC BY-SA 3.0
2017-11-26T10:43:20.733Z
2017-11-26T10:43:20.733Z
Trondh
<p>I'm running on a simple KVM host and have poor man's load balancing with round robin DNS to and nginx ingress based on <a href="https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress" rel="nofollow noreferrer">this chart</a> which is <a href="https://kubeapps.com/charts/stable/nginx-ingress" rel="nofollow noreferrer">documented here</a> </p>

<p>So to direct traffic to backend pods it seems from those docs that all you  would need to do is apply appropriate labels and magic will ensue. </p>

<p>It's a bit too magical for me and I'd rather just edit the nginx config and put reverse proxy entries in for the service urls for my microservices.</p>

<p>What's the typical way of doing this? </p>

CC BY-SA 3.0
2017-11-24T20:45:02.007Z
It should work just configuring `controller.service.externalIPs` array on `values.yaml` Could you share your `values.xml` file? Sorry, but I can't comment on your question.
Gabriel Miretti aka gmiretti
CC BY-SA 3.0
2017-12-06T12:43:11.977Z
Yes indeed, I hadn't realised it was so simple to use in the end!
barrymac
<kubernetes><containers><microservices><load-balance>
In kubernetes, using an nginx ingress controller what is recommended way of adding back end services?
barrymac
# In kubernetes, using an nginx ingress controller what is recommended way of adding back end services?

(Asked by: username_0 on 2017-11-23)

I'm running on a simple KVM host and have poor man's load balancing with round robin DNS to and nginx ingress based on [this chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress) which is [documented here](https://kubeapps.com/charts/stable/nginx-ingress)

So to direct traffic to backend pods it seems from those docs that all you would need to do is apply appropriate labels and magic will ensue.

It's a bit too magical for me and I'd rather just edit the nginx config and put reverse proxy entries in for the service urls for my microservices.

What's the typical way of doing this?

**Tags:** kubernetes, containers, microservices, load-balance

> **Comments:**
> **username_1**: It should work just configuring `controller.service.externalIPs` array on `values.yaml` Could you share your `values.xml` file? Sorry, but I can't comment on your question.  
> **username_0**: Yes indeed, I hadn't realised it was so simple to use in the end!  

---

## 2 answers

### Answer by username_2 on 2017-11-26. Score: 2 | Accepted answer

What you have installed, the `ingress controller`, is only one part of the story. The other part is an `ingress`: in an `ingress` you define what pods/services should receive traffic of what domain and request path. The `ingress controller` picks this information up, and dynamically reconfigures the underlying proxy, in your case nginx. You can find examples of ingresses in the official documentation: <https://kubernetes.io/docs/concepts/services-networking/ingress/#types-of-ingress>


---

### Answer by username_3 on 2017-11-26. Score: 2

Ingress controllers allow you to not manually wire stuff up, that's the whole point.

If you'd rather do it manually You could have an nginx array (either inside Kubernetes our outside of it) and just point to the ip/port of the services that expose your microservices. If you use an nginx array external to Kubernetes you'd have to use the externalIP service type. If you run the Nginx array on Kubernetes you could store your "manual proxy config" in a configmap so that all your nginx proxies get the same config.

I would definetely advise to not do this tho. Ingress controllers are built to simplify traffic routing, and as your complexity grows you will definetely want to take advantage of them. A good labeling scheme is absolutely paramount in Kubernetes, and that goes for ingresses aswell.


---

