IMHO if you need a tool like this, you are normally better off building it yourself in-house. You will inevitably end up fighting all of the leaky abstractions something like this does not support for your use cases.
This a hundred times. Do yourself a favour and use Dhall/Cue/Jsonnet to develop some abstractions that fit your workload and environment. There is not much value proposition in a tool like this if you can use a slightly lower-level, more generic tool (like a configuration-centric programming language, which is an actually full-fledged programming language) to accomplish the same goal in a more flexible and more powerful fashion, that leaves you space for evolution and unforeseen structure changes.
The idea of tools mandating what 'environments' are is absurd, as it's pretty much always different for everyone (and that's good!).
I've been enjoying using Tanka [1], which is a command-line tool from the Grafana team to manage k8s configurations, which you define using jsonnet. Complete flexibility, with minimal boilerplate possible by using the older (unmaintained unfortunately) ksonnet library [2] or the upcoming jsonnet-libs/k8s(-alpha) (which we're using in production) [3], or roll your own, abstracting to whatever level you find best.
I've been using kubecfg [1] with kube.libsonnet [2]. I don't like Tanka as it imposes a given directory structure on me via scaffolding - which is a big no-no for the way I organize projects (I value very unopinionated tools in this regard). I also couldn't get into the ksonnet style of mixins/arguments, as it takes away the ease of overriding underlying Kubernetes structures.
I strongly disagree. One of the primary* values of Kubernetes is that it commoditizes ops. Most companies are not special. Most applications are not special.
You probably need some APIs, a database or two, domain names and TLS certificates, and maybe a caching layer and object storage. There's zero reason why an abstraction layer can't be flexible enough to handle the overwhelming majority of line-of-business apps out there.
If you're going to be home-rolling your own janky custom deploy solution, you might as well save yourselves the headaches and not bother using Kubernetes either.
* - I might argue the only real value for most non-Google-scale organisations.
The idea of tools mandating what 'environments' are is absurd, as it's pretty much always different for everyone (and that's good!).