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

Kubernetes Ingress Nginx is retiring

kubernetes.dev

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Kubernetes Ingress Nginx is retiring

#141

Post by KronisLV »

wg0 wrote: post #69

Kubernetes is never maturing. It keeps moving. An installation just a year ago would have things that would require significant planning to upgrade. What is missing is an open source orchestrator that has a feature freeze and isn't Nomad or docker swarm.

> What is missing is an open source orchestrator that has a feature freeze and isn't Nomad or docker swarm.

Running Docker Swarm in production, can't really complain, at least for scales where you need a few steps up from a single node with Docker Compose, but not to the point where you'd need triple digits of nodes. I reckon that's most of the companies out there. The Compose specification is really simple and your ingress can be whatever web server you prefer configured as a reverse proxy.

Re: Kubernetes Ingress Nginx is retiring

#142

Post by throw_away_341 »

mlrtime wrote: post #139
throw_away_341 wrote: post #135

Earlier quoted context omitted.

> If a company sets this up correctly developers can create tooling incredibly fast I find that it has its place in companies with lots of micro services. But I think that because it is made "easy" it encourages unnecessary fragmentation and one ends up with a distributed monolith. In my opinion, unless you actually have separate products or a large engineering team, a monolith is the way to go. And in that case you…

In my example it was a simple CRUD app, no microservice. It could just as easy been ran by scping the entire dev dir to a vm and ensuring a port is open. But I wouldn't get many of the things I described above and I don't need to monitor it at all. Also a release is just a PR merge + helm upgrade.

You had PR merge and automatic release before Kubernetes too, and it's not that hard to configure.

If one has a small project where a few seconds of downtime is acceptable, you can just setup a simple Github action triggered on commit/merge. It can scp the file to the server and run "sysctl restart" automatically. I have used this approach for small side projects (even with external paying users)

And if you need a "no downtime" release, a proper CI/CD pipeline can handle a blue/green switch. I don't think you would spend much more time setting that up, than Kubernetes from scratch unless you have extensive experience with Kubernetes.

Re: Kubernetes Ingress Nginx is retiring

#143

Post by hoherd »

toredash wrote: post #75
solatic wrote: post #24

Earlier quoted context omitted.

It's exactly why taking a trip through the ops/infra side is so important for people - you learn why LTS-style engineering is so important. You learn to pick technologies that are stable, reliable, well-supported by a large-enough people who are conservative in their approach, for anything foundational, because the alternative is migration pain again and again.

I often find myself trying to tell people that KISS is a good thing. If something is somewhat complex it will be really complex after a few years and a few rotations of personnel.

Another great one is PLOS, the Principal of Least Astonishment. Stable and reliable software and systems should avoid astonishing surprises.

https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Re: Kubernetes Ingress Nginx is retiring

#144

Post by j0057 »

steeleduncan wrote: post #116
j0057 wrote: post #109

Earlier quoted context omitted.

Docker is not for production. Nomad at scale in practice needs a lot of load-bearing Bash scripts around it: for managing certs, for external DNS, you need Consul for service discovery, Vault for secrets. At that point, is Nomad still simple? If you're going to take on all of the essential complexity of deploying software at scale, just do it right and use Kubernetes. Source: running thousands of containers in produc…

> you need Consul for service discovery Kubernetes uses etcd for service discovery. It isn't that Nomad does things differently or less simply, it is just that they are more explicit about it. The real difference is that Kubernetes has a wide array of cloud hosts that hide the complexity from users, whereas Nomad can realistically be self hosted

I'm not saying that Kubernetes isn't complex, I'm saying it's a fallacy to claim that the Hashicorp stack in any way manages to be less complex in practice. All of these moving parts are unavoidable if you want to run software at scale, Kubernetes is just way better engineered than the Hashicorp stack, if only for not depending on dockerd.

Re: Kubernetes Ingress Nginx is retiring

#145

Post by steve1977 »

mlrtime wrote: post #125
mrweasel wrote: post #74

Earlier quoted context omitted.

You can manage and reason about ~2000+ servers without Kubernetes, even with a relatively small team, say about 100 - 150, depending on what kind of business you're in. I'd recommend either Puppet, Ansible (with AWX) and/or Ubuntu Landscape (assuming that your in the Ubuntu ecosystem). Kubernetes is for rather special case environments. I am coming around to the idea of using Kubernetes more, but I still think that i…

>for their operating system of choice... Have you been in a company with ~2000+ servers where devs install their apps on these OSs and building packages that refuse to upgrade to the latest OS? I mean even with LTS a 20 year old company may still have 3-4 LTS OSs because that last 5% refuse to or cannot upgrade their application to work with the new OS. Sure you could VM the entire thing, but Docker + K8s removes tha…

If developers don't maintain their apps, it doesn't really matter that much how and where you deploy them. With Kubernetes, you just end up with unmaintained Docker images that potentially contain a ton of vulnerabilities.

Re: Kubernetes Ingress Nginx is retiring

#146

Post by trenchpilgrim »

steve1977 wrote: post #133
mlrtime wrote: post #123

Earlier quoted context omitted.

Also a old man from VMS/Sparc days, I'm still doing "devops" and just deployed a realtime streaming webapp tool for our team in a few days to k8s pods. It was incredibly easy and I get so much for free Automatically created for me: - Ingress, TLS, Domain name, Deployment strategy, Dev/Prod environments through helm, Single repo configuration for source code, reproducible dev/prod build+run (Docker)... If a company se…

> just deployed a realtime streaming webapp tool for our team in a few days to k8s pods. How long would you estimate that deployment would have taken with more a „classic“ approach? (e.g. deploying to a Java application server)

If you had a really good team, hours. At most companies, days to weeks. At worst, months.

With a well managed Kubernetes, around 5-15 minutes. Not a theoretical time, I have personally had thousands of devs launch that quickly on clusters I ran.

Re: Kubernetes Ingress Nginx is retiring

#147

Post by tbrownaw »

dangus wrote: post #41
gryfft wrote: post #22

Earlier quoted context omitted.

> It seems to me that the current tech scene doesn't reward simple. A deal with the devil was made. The C suite gets to tell a story that k8s practices let you suck every penny out of the compute you already paid for. Modern devs get to do constant busy work adding complexity everywhere, creating job security and opportunities to use fun new toys. "Here's how we're using AI to right size our pods! Never mind the actu…

This just seems like sensationalist nonsense spoken by someone who hasn’t done a second of Ops work. Kubernetes is incredibly reliable compared to traditional infrastructure. It eliminates a ton of the configuration management dependency hellscape and inconsistent application deployments that traditional infrastructure entails. Immutable containers provide a major benefit to development velocity and deployment reliab…

> Does Kubernetes have its downsides? Yeah, it’s complex overkill for small deployments or monolithic applications. But to be honest, there’s a lot of complexity to configuration management on traditional VMs with a lot of bad, not-so-gracefully aging tooling (cough…Chef Software)

I have a small application running under single-node k3s. It's slightly (but not hugely) easier to work with then the prior version that I had running under IIS.

Re: Kubernetes Ingress Nginx is retiring

#149

Post by immibis »

mlrtime wrote: post #126
immibis wrote: post #102

Earlier quoted context omitted.

because programmers should be able to use computers

No, they should be able to take business requirements and create performant reliable applications. They should understand CS/CE core fundamentals but they don't need to know how to admin.

You might not make it your day job but you should definitely understand the fundamentals of how your whole stack works. Everything from transistors to eyeballs.

Re: Kubernetes Ingress Nginx is retiring

#150

Post by andix »

imcritic wrote: post #14
seabombs wrote: post #6

Earlier quoted context omitted.

I've been using Envoy Gateway in my homelab and have found it to be good for my modest needs (single node k3s cluster running on an old PC). I needed to configure the underlying EnvoyProxy so that it would listen on specific IPs provided by MetalLB, and their docs were good enough to find my way through that. https://gateway.envoyproxy.io/

But envoy configs are unreadable abominations, why would you choose it? How did you even learn how to configure it? It's documentation is so confusing.

Configuring of the proxy is done by the k8s Gateway controller. Exactly like for the ingress controller. You just use standardized k8s CRDs to configure it.

The gateway/ingress controller takes the k8s resources and configures the proxy server accordingly. In some cases additional config snippets specific to the proxy (nginx, envoy, etc) are required, but it's usually just a few lines.

Which http server is used is not that important (the most common ones are all fine), it's more about how well the integration to k8s works.

Post reply on HN