Environment variables exist on just about EVERY runtime, changed without requiring a pipeline run.

However, subprocess is interesting but I've never run into subprocess that is not sharing a config. Where I worked, if you have subprocess that can't see those configs, you create a new service.

If your point is that existing managers support setting environment variables but not creating config files, then sure. But that isn't a fundamental truth, it's just working with the tools you have.

It just seems far easier to have your kube config inject the env variables from your kube file and that way you don't have to worry during deployment how to add that file and you don't check it into the source. This applies to basically any way you deploy your app, especially containerised ones. Unless you're running your app in an EC2 machine where you can go in and easily edit the file (not that you can't do it in a container), it just seems like extra steps. I've found the happy medium to be sourcing default configs from a file that can all be overridden through env variables

But there's no fundamental reason for that to be the case. You could imagine a very nearby parallel universe where Kubernetes config files don't let you set environment variables, but do let you inject files. In this universe, you can see other deployment approaches that make config files easier (Puppet and suchlike). And if you're building something from scratch, you can make the choice.