I also feel like we as an industry should steer towards a state of &quot;doneness&quot; for OSS solutions. As long as it works, it&#x27;s fine to keep using technologies that are only sparsely maintained.

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.

It&#x27;s exactly why taking a trip through the ops&#x2F;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.

Mhm! And Google just sit there laughing at everyone. Mission accomplished

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 reliability. They are far faster to pull and start than deploying to VMs, which end up needing some kind of annoying deployment pipeline involving building images or having some kind of complex and failure-prone deployment system.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)And who is really working for a company that has a small deployment? I’d say that most medium-sized tech companies can easily justify the complexity of running a kubernetes cluster.Networking can be complex with Kubernetes, but it’s only as complex as your service architecture.These days there are more solutions than ever that remove a lot of the management burden but leave you with all the benefits of having a cluster, e.g., Talos Linux.

&gt; It seems to me that the current tech scene doesn&#x27;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. &quot;Here&#x27;s how we&#x27;re using AI to right size our pods! Never mind the actual costs and reliability compared to traditional infrastructure, we only ever need to talk about the happy path&#x2F;best case scenarios.&quot;

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&#x27;re in. I&#x27;d recommend either Puppet, Ansible (with AWX) and&#x2F;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 if you&#x27;re not provisioning bare-metal worker nodes, then don&#x27;t bother with Kubernetes.The problem is that Kubernetes provides orchestration which is missing, or at least limited, in the VM and bare-metal world, so I can understand reaching for Kubernetes, because it is providing a relatively uniform interface for your infrastructure. It just comes at the cost of additional complexity.Generally speaking I think people need to be more comfortable with build packages for their operating system of choice and install applications that way. Then it&#x27;s mostly configuration that needs to be pushed and that simplifies things somewhat.

I think you underestimate what can be done with actual code because the devops industry seems entirely code averse and seem to prefer a &quot;infrastructure as data&quot; paradigm instead and not even using good well tested&#x2F;understood formats like sql databases or even object storage but seems to lean towards more fragile formats like yaml.yes the possix shell is not a good language which is why thinks like perl, python and even php or C got widely used but there is a intermediate layer with tools like fabric(<a href="https:&#x2F;&#x2F;www.fabfile.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.fabfile.org&#x2F;</a>) solving a lot of the problems with the fully homegrown without locking you into the &quot;Infrastructure as(manually edited) Data&quot; paradigm that only really works for problems of big scale and low complexity which is exactly the opposite of what you see in many enterprise environments.

&gt; Otherwise, there will be far easier solutions at lower scale.Which solutions do you have in mind?- VPS with software installed on the host- VPS(s) with Docker (or similar) running containers built on-host- Server(s) with Docker Swarm running containers in a registry- Something Kubernetes like k3s?In a way there&#x27;s two problems to solve for small organisations (often 1 server per app, but up to say 3): the server, monitoring it and keeping it up to date, and the app(s) running on each server and deploying and updating them. The app side has more solutions, so I&#x27;d rather focus on the server side here.Like the sibling commenter I strongly dislike the configuration management landscape (with particular dislike of Ansible and maintaining it - my takeaway is never use 3rd party playbooks, always write your own). As often for me these servers are set up, run for a bit and then a new one is set up and the app redeployed to that (easier than an OS upgrade in production) I&#x27;ve gone back to a bash provisioning script, slightly templated config files and copying them into place. It sucks, but not as much as debugging Ansible has.

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 a little more capability. But now I hate both of them.When I just threw this all in the trash in my HomeLab and went to containerization it was a major breath of fresh air and resulted in getting a lot of time back.For organizations, of the best parts about Kubernetes is that it’s so agnostic so that you can drop in replacements with a level of ease that is just about unheard of in the Ops world.If you are a small shop you can just start with something simpler and more manageable like k3s or Talos Linux and basically get all the benefits without the full blown k8s management burden.Would it be simpler to use plain Docker, Docker Swarm, Portainer, something like that? Yeah, but the amount of effort saved versus your ability to adapt in the future seems to favor just choosing Kubernetes as a default option.

&gt; things were simple back thenIf you were working in the orgs targeted by k8s, I think it was generally more of a mess. Think about managing a park of 100~200 servers with home made bash scripts and crappy monitoring tools and a modicum of dashboards.Now, k8s has engulfed a lot more than the primary target, but smaller shops go for it because they&#x27;r also hoping to hit it big someday I guess. Otherwise, there will be far easier solutions at lower scale.

i prefer current era where i never have to ssh to debug a node. if a node is misbehaving or even needs a patch i destroy it. one command, works every time.

&gt; &#x2F;r&#x2F;kubernetes had this announcement up about five mins after it dropped at Kubecon. It&#x27;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 deployment. It&#x27;s what cloud providers offer out of the box as a major selling point to draw in customers.But then I browsed through the Gateway API docs, and it is a world of difference. It turns a hard problem that requires so many tutorials and products to help anyone get something running into a trivially solvable problem. The improvements on their security model is undoubtedly better and alone clearly justifies getting rid of ingress.Change might be inconvenient, but you need change to get rid of pain points.

&#x2F;r&#x2F;kubernetes had this announcement up about five mins after it dropped at Kubecon. It&#x27;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 your question, I use HN, &#x2F;r&#x2F;devops and &#x2F;r&#x2F;kubernetes to stay current. I&#x27;m also working on a weekly blog series wherein I&#x27;ll be doing an overview and quick start guide for every CNCF project in their portfolio. There&#x27;s hundreds (thousands?) of projects in the collection, so it will keep me busy until I retire, probably :)

Cybersecurity is easier? Isn&#x27;t it all about constantly updating and patching obsolete vulnerable stuff - most annoying part of ops?

DevOps teams are always running slightly behind and rarely getting ahead of technical debt because they are treated as cost centers by the business (perpetually understaffed) and as “last minute complicated requests that sound simple enough” and “oops our requirements changed” dumping grounds for engineering teams.Plus, the ops side has a lot of challenges that can really be a different beast compared to the application side. The breadth of knowledge needed for the job is staggering and yet you also need depth in terms of knowing how operating systems and networks work.

I like devops. It means you get to get ahead of all the issues that you could potentially find in cybersecurity. Sure it&#x27;s complicated, but at least you&#x27;ll never be bored. I think the hardest part is that you always feel like you don&#x27;t have enough time to do everything you need to.

In my experience, many teams keep up with this by spending a lot of time keeping up with this and less time developing the actual product. Which, you probably guessed it, results in products much shittier than what we had 10 or 20 years ago.But hey, it keeps a lot of people busy, which means it also keeps a lot of managers and consultants and trainers busy.

But the Gateway API has only been generally available for two years now. And the last time I checked, most managed K8S solutions recommend the Ingress API while Gateway support is still experimental.

&gt; doesn’t change that muchYet they are retiring a core Ingress that has been around for almost as long as Kubernetes has.

The Ingress API has been on ice for like 5 years. The core Kubernetes API doesn&#x27;t change that much, at least these days. There&#x27;s an infinite number of (questionable) add-ons you can deploy in your cluster, and I think that&#x27;s mostly where folks get stuck in the mud.

ingress-nginx is older than 5-7 years tough. In that time frame you would’ve needed to update your Linux system, which gets hairy most often as well.
The sad thing is just that the replacement is just not there and gateway api has a lot of drawbacks that might get fixed in the next release (working with cert manager)

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

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&#x27;t Nomad or docker swarm.

1) ingress still works but is on the path to deprecation. It&#x27;s a super popular API, so this process will take a lot of time. That&#x27;s why service meshes have been moving to Gateway API. Retiring ingress-nginx, the most popular ingress controller, is a very loud warning shot.2) see (1).

It doesn&#x27;t but Kubernetes team was kind of like &quot;Hey, while you are switching, maybe switch away from Ingress API?&quot;

Reading few blogs and forums about it today - people talking about switching to Gateway API (from &quot;legacy&quot; Ingress).And I do not understand it:1. Ingress still works, it&#x27;s not deprecated.2. There a lot of controllers, which supports both: Gateway API and Ingress (for example Traefik)So, how Ingress Nginx retiring related &#x2F; affects switch to Gateway API?

&gt; InGate development never progressed far enough to create a mature replacement; it will also be retired

To be fair, this is not the first time we&#x27;e heard about this, <a href="https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;ingress-nginx&#x2F;issues&#x2F;13002" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;ingress-nginx&#x2F;issues&#x2F;13002</a> exists since March. However I also thought that the timeline to a complete project halt would be much longer considering the prevalence of the nginx ingress controller. Might also mean that InGate is dead, since it&#x27;s not mentioned in this post and doesn&#x27;t seem to be close to any kind of stable release.

No they are going to forbid people to commit anything to the project so even security patch will be blocked.

It&#x27;s not a service shutting down though. It will still work fine for a while and it there is a critical security patch required, the community might still be able to add it.

This is required steps but the timing plan is bad. Looks like a google product closing. Let people time to move out, 6 month is not enough.

RIP, end of an era. Thank you everyone who worked on this, it was an extraordinarily useful and reliable project.

The list of supported annotations is quite short though

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

Literally the second link in the article is &quot;migrating to API Gateway&quot; and points to <a href="https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;guides&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;guides&#x2F;</a>Which has this section about migration: <a href="https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;guides&#x2F;migrating-from-ingress&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;guides&#x2F;migrating-from-ingres...</a>And this list of Gateway controllers: <a href="https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;implementations&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;implementations&#x2F;</a>

^ I second Envoy Gateway! It has support for HTTPRoute like all the others, but also TCPRoute, UDPRoute, TLSRoute, GRPCRoute backed by Envoy and they have worked great for me on EKS clusters I manage for work. The migration from Ingress API to Gateway API hasn’t been bad, as you can have both running side-by-side (just not using the same LB) and the EnvoyPatchPolicy has been great for making advanced changes for things not covered by the manifests

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

I&#x27;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.<a href="https:&#x2F;&#x2F;gateway.envoyproxy.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gateway.envoyproxy.io&#x2F;</a>

Does anyone know good resources on how to migrate and which gateway controllers are suitable replacements?Ingresses with custom nginx attributes might be tricky to migrate.

There are many Gateway implementations: <a href="https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;implementations&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gateway-api.sigs.k8s.io&#x2F;implementations&#x2F;</a>

Love haproxy but if we’re shilling projects istio is superior. Multi cluster, hbone, ambient.

It&#x27;s in beta, but HAProxy has a gateway product:<a href="https:&#x2F;&#x2F;www.haproxy.com&#x2F;blog&#x2F;announcing-haproxy-unified-gateway-beta" rel="nofollow">https:&#x2F;&#x2F;www.haproxy.com&#x2F;blog&#x2F;announcing-haproxy-unified-gate...</a>

This is terrible. Of all things k8s, ingress was the part I just did not want to have to mess with. It just worked and was stable, this gateway is completely unnecessary. And it seems to me that nginx retiring is just because people were pushing for the gateway so much that they threw in the towel. Infra is not react, people need to leave it alone.

Kubernetes behaves like a JavaScript framework. See what has been happening in React and Sevelte for past few years.Infrastructure is the underlying fabric and it needs stability and maturity.

Inadvertently we migrated to ECS just last week

I have tens of clusters to maintain. Quite an advertisement for ECS!

F5 bought nginx? Isn&#x27;t (wasn&#x27;t?) nginx a simple open source web server?

And see how confusing the naming is.ingress ngnix.
ngnix ingress.

Ingress nginx was the default ingress for pretty much the entire life of k8s. F5 bought nginx and made nginx ingress, which I&#x27;ve never met a user of.Sad to see such a core component die, but I guess now everyone has to migrate to gateways.

I don’t think this is the <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;2347&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;2347&#x2F;</a> of the ops world? People will usually use the ingress controller of their cloud provider. I’ve been using the tailscale ingresses for tailscale funnel. But the transition from ingress to gateway api is seeming to take forever so I’m just running a caddy pod with a static config until the dust settles.

Another triumph for open source: popular project probably used by many megacorps only propped up by the weekend charity of a couple unpaid suckers over the years.

The project is still active even not pushing new big features.

There are no maintainers. It was maintained by one engineer for years, he stepped down, and F5 (who bought nginx) don&#x27;t want to contribute since they have a competitor.

Why would you kill a thing that works so well, is so flexible, and does not have an equal yet?I do not understand.

I (and others) have offered to create a PR for issues opened — just point us in the right direction we asked. The maintainer always came back with “I fixed it for you”.The maintainer had plenty of people who wanted to help, but never spent the time to teach them.

Only a single maintainer for years, and it&#x27;s fallen now to best-effort.

What&#x27;s the security back-story here?

It wasn&#x27;t the most loved part of k8s, to say the least.

Great, another deprecation to address in my EKS clusters :(

Kubernetes Ingress Nginx is retiring