Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thank you. So there is a DNAT to get to the Ingress Controller but from there at least it's direct routing to the service endpoint(s)? Does that mean the Virtual IP given to the Service is basically bypassed when using Ingress Controller?

TLS termination at the Ingress Controller and by default unencrypted from there to the service endpoint?

I found this useful: http://blog.wercker.com/troubleshooting-ingress-kubernetes

Interesting discussion here: https://github.com/kubernetes/ingress/issues/257

It seems like a lot of overhead before even starting to process a request!



> TLS termination at the Ingress Controller and by default unencrypted from there to the service endpoint?

We are doing TLS termination at the ELB (we're running on AWS).

> Interesting discussion here: https://github.com/kubernetes/ingress/issues/257

Great, thanks!

Regarding ways of updating of the NGINX upstreams without requiring a reload, I was just made aware of modules like ngx_dynamic_upstream[1]. I'm sure there are other ways to address this in a less disruptive way than reloading everything, so this is probably something that could be improved in the future.

[1] https://github.com/cubicdaiya/ngx_dynamic_upstream


May I ask how you are automating the ELB/TLS configuration and how that ties into the Ingress controller? Do you somehow specify which ELB it should use? We're in a similar situation.


You can annotate any Service of type LoadBalancer in order to configure various aspects[1] of the associated ELB, including which ACM-managed certificate you want to attach to each listener port.

[1] https://github.com/kubernetes/kubernetes/blob/master/pkg/clo...


Thanks a lot, this will save us quite some time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: