Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Painless NGINX Ingress

danielfm.me

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Painless NGINX Ingress

#21

Post by endorphone »

philipcristiano wrote: post #8
fulafel wrote: post #7

Why 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?

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.

Re: Painless NGINX Ingress

#22

Post by zaroth »

Am I correct in assuming that there is the Kube Service IP routing happening via iptables DNAT to get the request into the Kube running the Ingress Controller, and then the Ingress Controller is on top of that routing traffic to another Service IP which also has to go through the iptables DNAT?

Re: Painless NGINX Ingress

#23

Post by zaroth »

ultimoo wrote: post #19

Great read! >> "Let me start by saying that if you are not alerting on accept queue overflows, well, you should." Does anyone know how to effectively keep a tab on this on a docker container running nginx open source? I have an external log/metrics monitoring server that could alert on this, but I'm asking more on the lines of how to get this information to the monitoring server.

It sounded like there's a config directive to have Ingress Controller push all its metrics into Prometheus?

Re: Painless NGINX Ingress

#24

Post by foxylion »

ultimoo wrote: post #19

Great read! >> "Let me start by saying that if you are not alerting on accept queue overflows, well, you should." Does anyone know how to effectively keep a tab on this on a docker container running nginx open source? I have an external log/metrics monitoring server that could alert on this, but I'm asking more on the lines of how to get this information to the monitoring server.

In this case (ingress controller) this is done with a Prometheus metric exporter. So all the metrics are available in Prometheus.

https://github.com/hnlq715/nginx-vts-exporter

Re: Painless NGINX Ingress

#25

Post by danielmartins »

zaroth wrote: post #22

Am I correct in assuming that there is the Kube Service IP routing happening via iptables DNAT to get the request into the Kube running the Ingress Controller, and then the Ingress Controller is on top of that routing traffic to another Service IP which also has to go through the iptables DNAT?

No. By default, the NGINX ingress controller routes traffic directly to pod IPs (the Service endpoints):

https://github.com/kubernetes/ingress/tree/master/controller...

Re: Painless NGINX Ingress

#26

Post by zaroth »

danielmartins wrote: post #25
zaroth wrote: post #22

Am I correct in assuming that there is the Kube Service IP routing happening via iptables DNAT to get the request into the Kube running the Ingress Controller, and then the Ingress Controller is on top of that routing traffic to another Service IP which also has to go through the iptables DNAT?

No. By default, the NGINX ingress controller routes traffic directly to pod IPs (the Service endpoints): https://github.com/kubernetes/ingress/tree/master/controller...

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!

Re: Painless NGINX Ingress

#27

Post by danielmartins »

zaroth wrote: post #26
danielmartins wrote: post #25

Earlier quoted context omitted.

No. By default, the NGINX ingress controller routes traffic directly to pod IPs (the Service endpoints): https://github.com/kubernetes/ingress/tree/master/controller...

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 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

Re: Painless NGINX Ingress

#28

Post by Thaxll »

"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.

Re: Painless NGINX Ingress

#29

Post by danielmartins »

Thaxll wrote: post #28

"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 personally don't know anyone who runs production servers of any kind on top of unmodified Linux distros.

Re: Painless NGINX Ingress

#30

Post by manigandham »

Thaxll wrote: post #28

"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.

> high load web servers

Really? The distributions might work for the average site but high-load always requires tuning from the defaults on even the latest distros.

Post reply on HN