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

161–170 of 178 posts

Re: Kubernetes Ingress Nginx is retiring

#161

Post by pronik »

kardianos wrote: post #25

Traefik has an Nginx compatibility for annotations as well to make it easy to switch.

Nginx annotations is not something we want to keep though and there is rarely such a thing as a seamless drop-in replacement. Every change needs to be intensively tested and nobody in their right mind would replace an ingress controller by another one in-place on any cluster size. The correct way will be to offer a new ingress class and nudge the cluster users to migrate to that one, one app at a time, which means you could as well migrate to something completely different, depending on size and effort. Traefik tries very hard to be an option in Kubernetes space, with some promising concepts, but supporting random annotations is not it.

Re: Kubernetes Ingress Nginx is retiring

#162

Post by conor- »

steve1977 wrote: post #145
mlrtime wrote: post #125

Earlier quoted context omitted.

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

But with a containerized app image you can reduce the blast radius of the poorly maintained app compared to running it bare metal on a host with other services. Also you can still maintain base images to patch/try to reduce vulnerability surfaces

Re: Kubernetes Ingress Nginx is retiring

#163

Post by zzyzxd »

3ln00b wrote: post #19

How do you people even keep up with this? I'm going back to cybersecurity after trying DevOps for a year, it's not for me. I miss my sysadmin days, things were simple back then and worked. Maybe I'm just getting old and my cognitive abilities are declining. It seems to me that the current tech scene doesn't reward simple.

If your infrastructure can justify the complexity of Kubernetes, keeping up with Kubernetes native software is extremely easy comparing to anything else I have dealt with. I had some horror story managing nginx instances on 3 servers with ansible. To me that's much harder than working with ingress controllers in Kubernetes.

Replacing an ingress controller in Kubernetes is also a well documented practice, with minimum or even zero downtime if you want to.

Generally, if your engineering team can reasonably keep things simple, it's good. However, business needs to grow and infrastructure needs to scale out. Sometimes trying too hard to be simple is, in my experience, how things become unmanageably complex.

I find well-engineered complexity to be much more pleasant to work with.

Re: Kubernetes Ingress Nginx is retiring

#164

Post by KaiserPro »

szszrk wrote: post #113
3ln00b wrote: post #19

How do you people even keep up with this? I'm going back to cybersecurity after trying DevOps for a year, it's not for me. I miss my sysadmin days, things were simple back then and worked. Maybe I'm just getting old and my cognitive abilities are declining. It seems to me that the current tech scene doesn't reward simple.

It's a much less of a deal than it seems. Yeah, it is a popular project that has been around for a while, but this is just another day at work. Things evolve, there are migration paths no matter if you want to stay with ingresses or move on... Kubernetes is promoting Gateway API for a while now. It's in GA for 2 years already (while Ingress was in GA quite late, 2020/K8s 1.19?). Sun-setting ingress-nginx was not exac…

> this is just another day at work.

But the point is this, it worked, it does work and will, if given developer time continue to work.

I now need to schedual in time to test the changes, then adjust the metrics and alerting that we have.

For no gain.

It just feels like kuberenetes is carbon fibre programming.

Re: Kubernetes Ingress Nginx is retiring

#165

Post by fragmede »

jabl wrote: post #91
dangus wrote: post #53

Earlier quoted context omitted.

Even after the bash script era, I don’t think the configuration management landscape gets enough discredit for how bad it is. I never felt like it stopped feeling hacked together and unreliable. E.g., Chef Software, especially after its acquisition, is just a dumpster fire of weird anti-patterns and seemingly incomplete, buggy implementations. Ansible is more of the gold standard but I actually moved to Chef to gain…

I have to say I hate ansible too (and puppet and cfengine that I have previously used). But it's unclear to me how containers fix the problems ansible solves. So instead of an ansible playbook/role that installs, say, nginx from the distro package repository, and then pushes some specific configuration, I have a dockerfile that does the same thing? Woohoo?

You use docker to create a thing on your laptop that you know is good and works, then you send the Dockerfile file in to the system and that thing is a static blob of bits. Ansible/puppet/chef/cfengine modify a live thing from one state to another. Sure, you can use qcow vm disk images and vm snapshots to achieve the same thing, but it’s a lot more cumbersome and feels slow and yuckier, and no one packaged it up into a neat little tool that got popular (which is to say, Vagrant is awesome but slow, so docker won out).

Re: Kubernetes Ingress Nginx is retiring

#166

Post by KaiserPro »

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…

> Kubernetes is incredibly reliable compared to traditional infrastructure.

The fuck it is.

> It eliminates a ton of the configuration management

Have you used k8s recently? to get it secure and sane is a lot of work. Even if you buy in sensible defaults, its a huge amount of work to get a safe, low blast radius deployment pipeline working reliably

Like if you want vaguely secure secrets, thats an add on. if you want decent non-stupid networking, thats an addon, Everything is split horizon DNS.

Thats before we get to state management, trying to play the pvc lottery, is not fun. which means its easier to use a clustered filesystem. Thats how fucked it is.

> there’s a lot of complexity to configuration management on traditional VMs

Not really, you need at least terraform to spin up your k8s cluster in the first place, its not that much harder to extend it to use real machines instead.

It is more expensive, unless you're binpacking with docker.

> cough…Chef

Chef can also fuck off. Although facebook use it on something like 8 million servers, somehow.

> Networking can be complex with Kubernetes

try making it use ipv6.

Look what the industry needs is a simple orchestration layer that places docker containers according to a DAG. You can have dependencies, and if you want a plugin system to allow you to paint yourself into a corner.

Have some hooks so we can trigger actions based on backlog

Leave the networking to the network, because DHCP and DNS are a solved problem.

What I'm describing is basically ECS, but without the horrid config language.

Re: Kubernetes Ingress Nginx is retiring

#167

Post by KaiserPro »

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…

> 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

THats what ld_preload is for. But real talk, if you have 2k servers and you can't package your apps to run on your OS, then you need a different platform team.

We managed 36k servers using fucking salt and perl. We were packaging nvidia drivers and all sorts. One system that everyone used still needed the athena widget set.

But the main point is, if you're using old packages, then you're gonna get hacked. You either need to kill that app, fire that developer or virtualise it and fill out the risk register, and do monthly recovery tests.

Docker allows you to pack in CVEs like no tomorrow. so sure k8s can let you do that, and given the hardly anyone properly enforces namespace isolation, so they can have a service mesh, you can still steal loads of data from a compromised container.

Re: Kubernetes Ingress Nginx is retiring

#168

Post by szszrk »

KaiserPro wrote: post #164
szszrk wrote: post #113

Earlier quoted context omitted.

It's a much less of a deal than it seems. Yeah, it is a popular project that has been around for a while, but this is just another day at work. Things evolve, there are migration paths no matter if you want to stay with ingresses or move on... Kubernetes is promoting Gateway API for a while now. It's in GA for 2 years already (while Ingress was in GA quite late, 2020/K8s 1.19?). Sun-setting ingress-nginx was not exac…

> this is just another day at work. But the point is this, it worked, it does work and will, if given developer time continue to work. I now need to schedual in time to test the changes, then adjust the metrics and alerting that we have. For no gain. It just feels like kuberenetes is carbon fibre programming.

I honestly don't get it. As a person who managed k8s in teams of 1-3 people. It's not that much effort. Things get sunset all the time.

Re: Kubernetes Ingress Nginx is retiring

#169

Post by herzzolf »

KaiserPro wrote: post #164
szszrk wrote: post #113

Earlier quoted context omitted.

It's a much less of a deal than it seems. Yeah, it is a popular project that has been around for a while, but this is just another day at work. Things evolve, there are migration paths no matter if you want to stay with ingresses or move on... Kubernetes is promoting Gateway API for a while now. It's in GA for 2 years already (while Ingress was in GA quite late, 2020/K8s 1.19?). Sun-setting ingress-nginx was not exac…

> this is just another day at work. But the point is this, it worked, it does work and will, if given developer time continue to work. I now need to schedual in time to test the changes, then adjust the metrics and alerting that we have. For no gain. It just feels like kuberenetes is carbon fibre programming.

> if given developer time continue to work.

well that's the root of the problem, no? there's no one who wants to maintain the complex lua written to make nginx cloud native. they were looking for maintainers for quite some time with no one stepping up

and I'm not surprised, their issue tracker always was full of very entitled people, so you would be doing a stressful/thankless job... for what exactly?

Re: Kubernetes Ingress Nginx is retiring

#170

Post by nunez »

locknitpicker wrote: post #64
nunez wrote: post #46

Earlier quoted context omitted.

/r/kubernetes had this announcement up about five mins after it dropped at Kubecon. It's a huge deal. So many tutorials and products used ingress-nginx for basic ingress, so them throwing in the towel (but not really) is big news. That said, (a) the Gateway API supercedes Ingress and provides much more functionality without much more complexity, and (b) NGINX and HAproxy have Gateway controllers. To generally answer…

> /r/kubernetes had this announcement up about five mins after it dropped at Kubecon. It's a huge deal. So many tutorials and products used ingress-nginx for basic ingress, so them throwing in the towel (but not really) is big news. I was one of those whose first reaction was surprise, because ingress was the most critical and hardest aspect of a kubernetes rollout to implement and get up and running on a vanilla dep…

Gateway works at Layer 4 (TCPRoute, UDPRoute). Massive improvement over Services + service mesh hackery!
Post reply on HN