"Ingress NGINX has always struggled with insufficient or barely-sufficient maintainership"
They can ask Linux Foundation for money, they have plenty.
Kubernetes Ingress Nginx is retiring
131–140 of 178 posts
Re: Kubernetes Ingress Nginx is retiring
#132We have been building an ingress Nginx compatibility layer in Traefik that supports the most used ingress Nginx annotations. You should definitely give it a try as it makes Traefik a drop-in replacement to ingress Nginx, without touching your existing ingress resources.
Your feedback will be super useful to make it better
https://traefik.io/blog/transition-from-ingress-nginx-to-tra...
Re: Kubernetes Ingress Nginx is retiring
#133Earlier quoted context omitted.
The problem is that some Kubernetes features would have a positive impact on development velocity in theory, however in my experience (25 years of ops and devops), the cost of keeping up often eats up those benefits and often results in a net-negative. This is not always a problem of Kubernetes itself though, but of teams always chasing after the latest shiny thing.
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)
Re: Kubernetes Ingress Nginx is retiring
#134How 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.
I once installed some kubernetes based software by following the instructions and watching many unicode/ascii-art animations on the commandline. I've also learned that the 8 in k8s stands for 8 letters: 'ubernete'. I've decided that D4s is not for me.
Re: Kubernetes Ingress Nginx is retiring
#135Earlier quoted context omitted.
The problem is that some Kubernetes features would have a positive impact on development velocity in theory, however in my experience (25 years of ops and devops), the cost of keeping up often eats up those benefits and often results in a net-negative. This is not always a problem of Kubernetes itself though, but of teams always chasing after the latest shiny thing.
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…
> 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 get far with a standard CI/CD pipeline and "old school" deployments
But of course I will never voice my opinion in my current company to avoid the "boomer" comments behind my back. I want to stay employable and am happy to waste company resources to pad my resume. If the CTO doesn't care about reducing complexity and costs, why should I?
Re: Kubernetes Ingress Nginx is retiring
#136How 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.
Things weren't simpler. The complexity was simply not visible because different teams/department were all doing a small part of what now a single team is doing with Kubernetes. Yes, for that single team it is more complex. But now it's 1 team that does it all, instead of 5 separate teams responsible for development, storage, networking, disaster recovery, etc.
Kubernetes is a gift.
Re: Kubernetes Ingress Nginx is retiring
#137Earlier 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)
Too opened ended of a question, but in 'old days' it would be a ticket for a new vm, then back and forth between dev and infra to setup the host, deploy the application etc...
Re: Kubernetes Ingress Nginx is retiring
#138In my Docker Swarm clusters I just use a regular Apache2 image in front of everything, since mod_md is good enough for Let's Encrypt and it doesn't have the issue with "nginx: [emerg] host not found in upstream" that Nginx did when some containers are not available and are restarting (and none of that "nginx: [emerg] "proxy_redirect default" cannot be used with "proxy_pass" directive with variables" stuff either).
From the cases where I've used Kubernetes, the Nginx based ingress controller was pretty okay. I wonder why we never got Ingress Controllers for Kubernetes that are made with something like Apache2 under the hood, given how many people out there use it and how the implementation details tend to be useful to know anyways. Looking at the names in the new list of Gateway https://gateway-api.sigs.k8s.io/implementations/ in very much seems it's once more a case of NIH, although it's nice that LiteSpeed and Traefik and HAProxy are there.
Re: Kubernetes Ingress Nginx is retiring
#139Earlier 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…
> 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.
Re: Kubernetes Ingress Nginx is retiring
#140Earlier 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…
> You can manage and reason about ~2000+ servers without Kubernetes, even with a relatively small team, say about 100 - 150 Oh wow, so uh... I'm managing around 1000 nodes over 6 clusters, alone. There's others able to handle things when I'm not around or on leave and meticulously updated docs for them to do so but in general am the only one touching our infra. I also do dev work the other half of the week for our co…
This sounds super familiar.
At one job I was the only IT person and we had ~250 plain boring VMs on some bare metal Linux/KVM hosts. No config management. No Kubernetes. I fixed that quickly. There was one other guy capable of taking a look at most of it.
I was also doing the software builds and client releases, client support, writing the documentation for the software, and fixing that software.
I suspect we would have had no problem scaling up with some better tooling. Imagine a team of 150? When people tell me things like that, it sounds more like the solution isn't much of a solution at all.