Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- >>zero-downtime
the site is down for me.
by dwa3592 - >P.S Nginx would do too, I just felt like getting haproxy up this time :)
I think this line summarizes better than anything. Perfect example of how move fast and break things begins gloriously at first then inevitably, the breaking you thought you were doing hasn't even started and you find out what that part means.
I've always been the one saying "this is going to be a problem in a couple months" then I get shot down for "being negative." Then in a couple of of months when it fails I start getting aggression thrown at me "oh i know you want to say I told you so" and such even though I've never said such a thing when something fails. No. I would just like you to hear out my thoughts even when they may not be what you want to hear. We are all working towards the same goal.
by citizenpaul - > There's a mass delusion in the industry that you need Kubernetes to run a serious production service. You don't. At StatusDude, we serve thousands of monitoring checks per minute, run multi-region workers, and deploy multiple times a day
This is pretty small scale, Kubernetes comes in when you've got a larger workload.
by variety8675 - In theory. I read so many times now where people report they use it and don't really need it, and I've seen it myself now too. Still very anecdotal, but it seems somethings thereby _def
- While I agree with you I'm not sure the rest of the world does.
Over the past decade, I'm seeing k8s used everywhere for everything, companies setting up clusters to run literally one simple app with couple of hundred requests per hour.
by canto - The whole reasoning behind this is flawed.
“We don’t know how to scale Traefik so we went with haproxy”
Well doh. Haproxy is designed for this. You can make haproxy serve copious amount of traffic on a single arm core and a little bit of ram. Imagine what you can do with a few replicas on your large clusters.
This has nothing to do with the choice of CI/CD or docker versus kubernetes.
by k_roy - Isn't that exactly what kamal-proxy is for?by aliyome
- Are you monitoring resource utilization per container? Do notifications get sent out when container(s) become unhealthy? How are you handling secrets?
These are things I'm trying to figure out at work using Podman. Would love to hear about any experience in these areas.
by limaho - docker-rollout also works well: https://github.com/wowu/docker-rollout
The readme covers connection draining with Traefik which should solve one of the issues the author mentions
by tallytarik - > thousands of monitoring checks per minute
That isn’t a lot. You could easily run that from one host. The reason people reach for Kubernetes (and similar) is because they need to scale past that single host dependency.
by hnlmorg - ..and HA
- The reason most people reach for Kubernetes is because it's cool. The entire infra the vast majority of Kubernetes users have could run on a single bare metal machine with a second one for redundancy.
To be fair: using Kubernetes anyways builds the skill just in case you become one of the 0.1% who actually need it down the line.
by chmod775 - > The reason people reach for Kubernetes (and similar) is because they need to scale past that single host dependency.
I have some stuff on single-node k3s. Because it's standard so I don't have to care.
by tbrownaw - You could, but they don't, meaning their argument is still sound (whether they _could_ use a single host is besides the point, they're not doing that).by ghusto
- 100%. And a shared mental model. I love how I can scale up all my services the same way, across clouds.
It's great.
by nullpoint420 - Mandatory mention: https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
But yeah, pretty cool DNS resolving features in HAProxy, that's nifty
by maxboone - I‘ve built this anti-k8s stance pre-LLMs, and just realized that, actually, agents should be pretty helpful in dealing with it? Is avoiding kubernetes still advisable for projects that will likely never use its full complexity, given how easy it is to maintain now?by manmal
- I remember a time where HN was quite critical to the complexity of k8s. After reading top comments, I can see the tide has shifted.by brumar
- This or there's a lot of fresh blood ;-)by canto
- I used to be critical of almost everyone who used it. Now that I've been learning the ecosystem for a couple years, I'm not as angry about it, and it doesn't affect me as much personally.
I still think almost all of my complaints were valid: - not just container orchestration, more like a whole AWS solution (its own routing)
- has single-points of failure that would be avoided if you just used aws
- unnecessary complexity for almost all use cases
- ecosystem easily allows you to 2x-8x that complexity (helm+argocd+istio+carpenter+dozens more=hundreds of new failure modes)
- fundamentally moves many teams to a "I don't understand why my service is crashing, so let's just bring up more nodes every time rather than ever learning to debug it" mentality.
- All the feature teams that are supposed to "own their own kubernetes implementation for their own services" never do.
Of course a lot of that frustration is more at working at a place with a poorly-operated SOA where it takes a half-dozen services to send an email to a client or send a text or something silly. It sure is a waste of runway to obsess over a SOA when you aren't profitable yet.
But at this point it's sort of a sunk cost because it's become the industry standard. And AI can help with 90% of the complexity, which is it's own yellow-flag, but here we are.
by zug_zug - CTOs have found reasons to standardize on k8s and it's not just for technical reasons. This was recently discussed last week:
https://notnotp.com/notes/what-job-interviews-taught-me-abou...
by bizzletk - I was surprised that there was no mention of two things:
1. Retrying a non-idempotent request on a failure type that does indicate that no action was taken is not necessarily safe.
2. It’s possible and actually fairly common to design a backend that can do a clean shutdown: it stops accepting new requests, completes old requests, then exits. I sincerely hope that Docker’s tooling is good enough for a service to unregister itself before it actually stops accepting requests, but I’m not actually very familiar with using Docker to manage HTTP routing. (I use a home grown tool that is far simpler.)
by amluto - It's actually fun to see this. Running systems in a lot of different ways are just interesting. I do however get kinda sad at the hate at k8s because it's really good at what it does.
I've seen so many projects bending over backwards to avoid k8s and pay large cloud bills to avoid it at all costs. (ECS and app services are hopelessly expensive and bothersome)
K8s is really good, pretty easy to maintain, but a bit hard to understand. Mostly because distributed, zero down time systems are a bit hard to get by nature. But if you have someone that wants to take it on I've managed k8s clusters, solo, without incident, while doing lots of other stuff too (working with larger teams now though). Not to mention there's a lot of competence out there that can take over if I'd move on. Most of the deep complexity comes with more advance use cases, that wont show up for smaller deployments.
That said, no h8 towards going your own way! If your a solo developer (or small team) for a smallish project, don't feel the absolute need. If you get to the point you need it you should be earning enough to start paying someone to help ya get your app to a distributed system like k8s.
I think it's good to invest the time in understanding k8s though as a professional. Even if you won't directly run it it teaches you a lot about how to think about distributed, zero downtime systems. And what requirements that puts on an app.
by Jumziey - I see stuff like Azure Container Applications like an easy introduction to the world of k8s. Sane defaults, looks managed but you can still get familiar with all the important concepts, and sooner or later you can move to a proper Kubernetes setup while having mastered the ideas behind it. If needed, of course.by soco
- Balanced takes like this are the only reason I still come back to HN. A shot at K3S in my homelab is in my backlog but young kids have set me back. If you have any material that touches on what you said above I'd appreciate a link. So much crap out there which is just Hello World blogspam.by 000ooo000