This was prompted largely by a move from Docker Compose, where we used env_file quite a bit. kenv will both create the Secret/ConfigMap resource as well as inject the env lookups into an existing Kubernetes resource (deployment, replicaset, daemonset, or replication controller). This allows us to keep our environment specific configuration alongside the app and just inject at deploy time.
Thanks, and that's a good question. I see two use cases primarily:
1. Experimenting with the feel of a CLI application when designing one. This was the initial use case that started me down this path. I wanted to play with designing CLI without going through all the mess of actually coding it, especially when I wasn't sure what it should look like. It's a lot easier for me to edit a YAML file with relatively static data and see how I like the feel of it rather than updating a code base with "live" data.
2. If you have scripts/programs you want to test that call CLI commands on live services and you want to mock the output from each (especially on create, update, destroy operations). Just symlink it somewhere in your PATH before the real application.
Hope this answers your question, I'll look at adding to the README in the repo.
envsubst will really just perform variable substitution, not perform any logic or command substitution (e.g. $(hostname -f)). It's also limited, from what I've seen, in support for other bash variable actions (such as defaults). You can also write loops with output similar to other templating languages here as well.
Sure thing, I'm currently using it in docker as a lightweight way to set config files from environment variables. I'll put together a write up of how/why we are doing that and post the link in reply to this.