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

41–50 of 51 posts

Re: Painless NGINX Ingress

#41

Post by fulafel »

manigandham wrote: post #32
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?

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.

We already have routing systems for large numbers of nodes in the internet technology stack, it's not obvious to me why we another one on the HTTP layer.

Re: Painless NGINX Ingress

#42

Post by tinix »

danielmartins wrote: post #29
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 person…

> On the other hand, I personally don't know anyone who runs production servers of any kind on top of unmodified Linux distros.

You are so, so so lucky... lol. I say that as someone who has come across a desktop CentOS install on a server on multiple occasions, complete with running x-org and like 3-4 desktop environments to choose from, along with ALL of the extras. KDE office apps, Gnome's office apps, etc... HORRIBLE.

Re: Painless NGINX Ingress

#43

Post by manigandham »

fulafel wrote: post #41
manigandham wrote: post #32

Earlier quoted context omitted.

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.

We already have routing systems for large numbers of nodes in the internet technology stack, it's not obvious to me why we another one on the HTTP layer.

Many of those routing systems are proxies, and they can apply at any layer.

Re: Painless NGINX Ingress

#44

Post by toomuchtodo »

web007 wrote: post #14
odammit wrote: post #6

This is a great read. I know the single cluster for all env is something that is sort of popular but it's always made me uncomfortable for the reasons stated in the article but also for handling kube upgrades. I'd like to give upgrades a swing on a staging server ahead of time rather than go straight to prod or building out a cluster to test an upgrade on. I tend to keep my staging and prod clusters identical , even…

+100 to this. Why would any sane Op/Inf/SRE choose not to have at least account-level isolation - is it only a matter of cost due to under-utilization? I prefer to have everything 100% isolated for dev / qa / stage / prod, and have process and tooling in place to explicitly cross the streams. This comes from a history of pain with random dev-to-prod (or worse, prod-to-dev) access and dealing with "real companies" wit…

> and you can set up IAM roles and whatnot to share your API keys between accounts. That gives you at least some isolation, but still lets you GSD the same way as if you have a single account.

Do not do this. You are defeating the purpose of account level separation if you're sharing API keys between accounts. Each AWS environment should be totally segregated from the others (cross-account IAM permissions only if you must), limiting the blast radius in the event of human error or a malicious actor.

Source: Previously did devops/infra for 6 years, currently doing security

Re: Painless NGINX Ingress

#45

Post by manigandham »

fulafel wrote: post #38
manigandham wrote: post #33

Earlier quoted context omitted.

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…

> prefer the smarts at the edges of your system

That's exactly what reverse proxies do - leaving the internal apps free to just serve requests instead of worrying about the perimeter.

The problems described in this article have nothing to do with reverse proxies but rather the ingress controller and config settings.

Re: Painless NGINX Ingress

#46

Post by fulafel »

manigandham wrote: post #45
fulafel wrote: post #38

Earlier quoted context omitted.

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…

> prefer the smarts at the edges of your system That's exactly what reverse proxies do - leaving the internal apps free to just serve requests instead of worrying about the perimeter. The problems described in this article have nothing to do with reverse proxies but rather the ingress controller and config settings.

Reverse proxies making routing decisions based on request content and making server load balancing decisions is putting policy in the middle.

Re: Painless NGINX Ingress

#47

Post by fulafel »

manigandham wrote: post #43
fulafel wrote: post #41

Earlier quoted context omitted.

We already have routing systems for large numbers of nodes in the internet technology stack, it's not obvious to me why we another one on the HTTP layer.

Many of those routing systems are proxies, and they can apply at any layer.

I'm not sure I follow you. Do you mean that the routing systems at the lower networking layers can be thought of as proxies in the sense that they copy data in and copy data out? That's technically correct, but they're not conventionally called proxies.

Re: Painless NGINX Ingress

#49

Post by manigandham »

fulafel wrote: post #47
manigandham wrote: post #43

Earlier quoted context omitted.

Many of those routing systems are proxies, and they can apply at any layer.

I'm not sure I follow you. Do you mean that the routing systems at the lower networking layers can be thought of as proxies in the sense that they copy data in and copy data out? That's technically correct, but they're not conventionally called proxies.

Proxies, by definition, are intermediaries. Everything on the internet is connected by a giant network of proxies at some layer - NATs, gateways, firewalls, etc.

Kubernetes runs a cluster of machines that act like a mini internet, with many containers running many apps. These apps communicate with each other across containers and machines through a series of proxies so that apps only have to worry about a single address or service name. Kubernetes does allow for headless services which will publish all of the pod IPs under a DNS name if you want but this is usually not the common scenario.

Beyond just knowing endpoints, apps may need to worry about healthchecking, failover, load balancing, rate limiting, security, observability, routing decisions and more. It's far simpler to consolidate all this functionality rather than leaving it to every single app to implement it all over again.

An ingress controller is in charge of running a specific proxy that deals with traffic into and out of the cluster rather than within it. There are several implementations other than nginx and they all require various levels of tuning to fit the needs of the cluster, but it's an optimal solution since you might not want or have access to control traffic on the other side.

Re: Painless NGINX Ingress

#50

Post by guslees »

zaroth wrote: post #23
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?

If it's helpful at all, here's a concrete example of a k8s nginx setup that exports-to/is-monitored-by prometheus: https://github.com/bitnami/kube-manifests/blob/master/common... (Start at https://engineering.bitnami.com/articles/an-example-of-real-... if you would prefer to approach that repo top-down)
Post reply on HN