NGINX also has their own ingress controller (in addition to the kubernetes community version): https://github.com/nginxinc/kubernetes-ingress
Painless NGINX Ingress
31–40 of 51 posts
Re: Painless NGINX Ingress
#32Why does everyone use reverse proxies? It seems complex and inefficient. Why not serve xhr's and other dynamic content from the app server(s) and static content from a static webserver?
That's a simplistic scenario and does not apply at all here. Kubernetes is a container orchestration platform that can run thousands of containers over thousands of compute nodes and directing traffic to them will require some sort of routing/proxy system.
Re: Painless NGINX Ingress
#33Earlier quoted context omitted.
What would you use to provide a single endpoint to multiple instances of an app server?
What about just exposing the multiple instances of app server, and have the frontend code select one for load balancing or failover purpouses? There could be a load balancing config read by the client, or you can have static rules in the frontend js, like choosing shard number based on a hash from the client ip address. Round-robin DNS might also work or complement this.
So you're answer to not using a reverse proxy is to fake your own via client-side logic? It's far better to have a tested, reliable, dynamic, and scalable solution right next to the actual app servers instead.
Almost everything on the internet is behind layers of proxies, it's not a bad thing and isn't much cause for concern.
Re: Painless NGINX Ingress
#34"Most Linux distributions do not provide an optimal configuration for running high load web servers out-of-the-box; double-check the values for each kernel param via sysctl -a." This is not true, if you run Debian / CentOS7 / Ubuntu, out of the box the settings are good. The thing you don't want to do is start to modify the network stack by reading random blogs.
> This is not true, if you run Debian / CentOS7 / Ubuntu, out of the box the settings are good. The thing you don't want to do is start to modify the network stack by reading random blogs. I agree these are good defaults, but they are not meant to work well for all kinds of workloads. And yes, if things are working for you they way they are, that's okay; there's no need to change anything. On the other hand, I person…
Sounds interesting! Do you have urls for more information about this? Would love to read good posts about that! My production servers have been running with standard parameters at every company so far. I feel I might be missing out!
Re: Painless NGINX Ingress
#35Earlier quoted context omitted.
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-kuberne…
> 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 ther…
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.
Re: Painless NGINX Ingress
#36Earlier quoted context omitted.
> 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 ther…
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...
Re: Painless NGINX Ingress
#37Earlier quoted context omitted.
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.
Re: Painless NGINX Ingress
#38Earlier quoted context omitted.
What about just exposing the multiple instances of app server, and have the frontend code select one for load balancing or failover purpouses? There could be a load balancing config read by the client, or you can have static rules in the frontend js, like choosing shard number based on a hash from the client ip address. Round-robin DNS might also work or complement this.
So you're answer to not using a reverse proxy is to fake your own via client-side logic? It's far better to have a tested, reliable, dynamic, and scalable solution right next to the actual app servers instead. Almost everything on the internet is behind layers of proxies, it's not a bad thing and isn't much cause for concern.
I think your viewpoint might be somewhat inflexible if routing logic in the client & server looks like "faking a reverse proxy" to you. That's where the rest of the logic is, after all, and when designing systems we generally prefer to have the logic in fewer places.
It's a proven design rule (the end-to-end principle) to prefer the smarts at the edges of your system, and the problems stemming from the reverse proxy described in the article, in my book, counts as further evidence for this idea.
Re: Painless NGINX Ingress
#39Cool read. I don't use Kubernetes but I learned a few things from this blog post that are applicable to my ECS environment. The NGINX config part is tricky and it didn't come to mind that many programs will try to be smart about machine resources and it won't work in the container world as expected. This was a good reminder. OP didn't mention what Linux distro he's using and what are all of the OS-level configs he ch…
> OP didn't mention what Linux distro he's using and what are all of the OS-level configs he changed in the end of the day. I'm using Container Linux, and yes, I did a few modifications, but I intentionally left them out of the blog post as someone would be tempted to use them as-is. I'll share more details in that regard if more people seem interested.
I'd be interested to hear more.
Re: Painless NGINX Ingress
#40Earlier quoted context omitted.
What would you use to provide a single endpoint to multiple instances of an app server?
There are scenarios where your app servers might be varied as well -- I've leveraged reverse proxies in front of a PHP application that had parts in .NET and parts in Go, for instance. Technologies/competencies change as projects evolve, and being able to effortlessly reorganized and reroute is so profoundly powerful.
Sure, I'm symphatetic to this kind of "in the trenches" application of reverse proxies - just not doing it by default.