It only became fashionable to call k8s crappy because it effectively won the orchestration wars. In reality it's quite good, and it changed the game for everyone. The hype for it went overboard a good bit so some swing back is justified. It's too complex for many use cases. The API surface isn't perfect but it's rather consistent and well defined, the project's codebase is mostly a good example of style at this size. Really I think the authors of k8s should be proud of what they built.
I think the complexity is the main source of people thinking it's "crappy". It certainly my main issue. E.g. I've built orchestrators from scratch smaller than some k8s configs I've worked on. However they were special purpose - they worked well for the specific type of loads, and for that they were suitable because their tiny size meant they were easy to tweak, but they'd have been totally inappropriate as a general-purpose alternative to k8s.
And so even though I don't like it much, I think it's fine to default to k8s for people (including at my current day job), and the default will always get a lot of crap because the default choice will get pressure to include all kinds of functionality that makes it more complicated in order to support all of the very diverse workloads that don't - and likely never will - justify a custom solution.
Comments
It only became fashionable to call k8s crappy because it effectively won the orchestration wars. In reality it's quite good, and it changed the game for everyone. The hype for it went overboard a good bit so some swing back is justified. It's too complex for many use cases. The API surface isn't perfect but it's rather consistent and well defined, the project's codebase is mostly a good example of style at this size. Really I think the authors of k8s should be proud of what they built.
I think the complexity is the main source of people thinking it's "crappy". It certainly my main issue. E.g. I've built orchestrators from scratch smaller than some k8s configs I've worked on. However they were special purpose - they worked well for the specific type of loads, and for that they were suitable because their tiny size meant they were easy to tweak, but they'd have been totally inappropriate as a general-purpose alternative to k8s.
And so even though I don't like it much, I think it's fine to default to k8s for people (including at my current day job), and the default will always get a lot of crap because the default choice will get pressure to include all kinds of functionality that makes it more complicated in order to support all of the very diverse workloads that don't - and likely never will - justify a custom solution.