Hacker News Reader

Comment by Spivak | Hacker News Reader

I cannot understand why people in this thread are saying people who want state are holding it wrong. If you are saying that k8s falls down on state — literally the only hard problem — then why are you bothering take on the complexity of k8s? What are you running on k8s that is stateless and can’t be served by ec2 instances in auto scaling groups? State management is the killer feature for k8s; it manages all the complexity and presents you a fiction where stateful apps can be written like they’re actually stateless.

View on HN

People are definitely sleeping on k8s' capability in managing stateful workloads. We run various datastores on it all the time, and it's quite reliable for a lot of use cases (largely because the underlying cloud block stores it's orchestrating are incredibly robust).

That said there are warts that should be removed, but that's not surprising.

The vast majority of developers don't understand what "stateless" means, since if you want to get technical is no such thing as a stateless system.

You might have drained requests off of a pod, but it still has a "state", it still has things cached in memory, it might still have connections open to some outside entity (Database, whatever), and the developer, not K8s, is responsible for catching those signals, cleaning up things in memory, gracefully terminating connections, handing off in-flight workloads to another pod, etc. Even in the upper echelons of the tech I see a very small minority of developers actually aware of all the things that can make stateless workloads stateful. Which is OK for something where the stakes are low, but if you're a DBA or a Systems oriented person you'll see people make these (very wrong) assumptions all the time and recoil in horror.

And that's why the title DBA is going the way of the dodo; state in this instance does not include cache and connections, because those are theoretically idempotent.

Theoretically is not actually, and a ton of the assumptions in k8s break down when you look at them super closely, but they break down when things have gone wrong. If your cache is properly designed it doesn't matter if it's a little stale; you're not using it for things where correct and up to date is the most important thing. Connections, too; it shouldn't matter if your connection pool needs to spin up another connection, because if any of the conditions exist that the connection fails (or takes too long and stalls requests for any appreciable time), you already should have been paged and be on the way to resolving the incident.

Reply on news.ycombinator.com