Kubernetes is popular because it solves problems at a certain scale. It's not for super small environments because you need a number of infrastructure engineers to manage it. But if you have a few hundred or thousand employees and don't want to write your own orchestration, it makes sense.

That said, it's a questionable design choice when you get to a hyperscale environment, since all the primitives are extremely opinionated and have design and scalability issues with service discovery, networking, and so on. All the controllers had to be rewritten, we had to roll our own deployment system, our own service discovery system, our own load balancing, and so on. But if you reach this level, you're probably making a lot of money and can figure out how to solve your problems.

Kubernetes is not really meant to assist apps themselves. It's a tool for organizations with multiple independent development teams which helps define a single source of truth for whats running where.

Kubernetes is a great fit for even extremely simple applications - assuming you have dozens to keep track of and dozens of developers who want to make changes to them.

> Or rather, at what point of an apps growth cycle does k8s become appropriate?

The real problem is that the point it becomes attractive to have something like Kubernetes is not too far from the point where Kubernetes becomes an overly-complex mess of disparate parts.

I'd say, not in an app's growth cycle, but when an organization wants to manage and scale platforms for itself, on which it runs apps, is when k8s becomes appropriate. In other words, k8s is a platform builder.