2 ms·
If you're implementing a distributed system that needs to manage many custom resources (of whatever kind, not Kubernetes-specific), implementing a Kubernetes co
by antonvs 2y ago
If you're implementing a distributed system that needs to manage many custom resources (of whatever kind, not Kubernetes-specific), implementing a Kubernetes controller for it can save a great deal of development time and give you a better system in the end, with standard built-in observability, manageability, deployment automation, and a whole lot else.
It's certainly true that some use of Kubernetes is overkill. But if you actually need what it offers, it can be a game-changer. That's a big reason why it caught on so fast in big enterprises.
Don't fall into the trap of thinking that because you don't understand the need for something, that the need doesn't exist.
- nijave 2y agoI'm always surprised when people say Kubernetes is overkill in the context of distributed systems. You'll end up running all the same stuff yourself but have to manage the integration yourself as well (traffic/L7, config, storage, app instances, network/L1-4)
- antonvs 2y agoRight, the key is "distributed systems". The overkill tends to come in when someone decides to use Kubernetes to run e.g. a single web application and database - which is not particularly "distributed" on the back end - or something that they could run with say Docker Compose on a single machine. A chart of effort vs. complexity would show this nicely. Kubernetes involves a baseline level of effort that's higher than simpler alternatives, which is the "overkill" part of the chart. But once complexity reaches a certain level, the effort involved in alternatives grows higher and faster. > (traffic/L7, config, storage, app instances, network/L1-4) Cloud and PaaS providers can do a lot of this for you though. Of course some of the PaaS providers are built on Kubernetes, but the point is they're the ones expending that effort for you.