61–70 of 81 posts
so op just recreated with sticks and tape a very basic feature what k8s does out of the box, and nobody else would be able to support his creation, because its handrolled adhoc with sparse documentation. sounds like ghetto engineering
so op just recreated with sticks and tape a very basic feature what k8s does out of the box, and nobody else would be able to support his creation, because its handrolled adhoc with sparse documentation. sounds like ghetto engineering
[flagged]
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.)
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 har…
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.
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.
This or there's a lot of fresh blood ;-)
The reason my position has changed is because:
1. The tooling has gotten better for setting up and managing K8.
2. In two of the last 3 jobs where we opted for a simplified alternative to k8, we came to regret that decision within a couple of years of that decision being made. If you’re core architecture is changing on a timescale of months (not years) then you picked the wrong foundations to build from.
That all said, I still think there is a pragmatic decision that needs to be made. And if I were in the author of this articles position I probably wouldn’t have picked k8s for this task either, despite what I said above. But, and as I said in my comment dismissing this article, they are dealing with low traffic and none of the problems that lend themselves to the benefits of k8. So my criticism of this article is that it’s misleading because their problem is easy but they’re writing as if they’re having to deal With problems of scale when they’re actually not.
Earlier quoted context omitted.
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.
Okay, I'll bite. What if your workload genuinely doesn't fit on one machine? Like load balancing or clustering 20+ nodes for LLM inference?
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.
https://notnotp.com/notes/what-job-interviews-taught-me-abou...
It's exhausting reading about this stuff because there is inevitably a barrage of comments about "you don't need kubernetes, you can run your app out of a single vm you dumb trend chaser" in this style. Like, sorry, no, not to a point. Yes, if you have a small app without a lot of scale, and it doesn't need to be uber reliable and have very little if almost 0 downtime, okay, sure. Most use cases are like that! This i…
Because plenty of people share your POV and kinda - a little bit - behave like there was no life before k8s, I will try to address your points. >What happens if a container in the VM goes down or the app inside of it crashes, how do you recover? Docker will restart container automatically. You don't have to do anything. Docker-compose will restart after VM restart. You don't have to do anything. If a VM goes down - I…
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 har…
> 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.
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.