Open bgrant0607 opened 2 years ago
This came up in the slack channel: https://kubernetes.slack.com/archives/C0155NSPJSZ/p1651968001107699
/cc @yuwenma
I was working on KRM support in SopsSecretGenerator and found that it's not possible because the plugin reads external files (like .env
files) to generate the Secrets.
Without support for non-KRM files, all K8s resources that use local files will not be supported by KRM functions.
We need this for ConfigMap generation: #3119
Some updates: we did POC about passing non-KRM files through functions input/output.
Demo1: https://drive.google.com/file/d/1BMYH3HcTzUcnSTk0iO0oO_O4O_RiUhF7/view Demo2: https://drive.google.com/file/d/1yvrWxDQJRGqCdzvvT0zmR-Cr6nUR3nMc/view The graph below explains the high level workflow, more context can be found in the CUJ and Strawman doc
This came up in the slack channel: https://kubernetes.slack.com/archives/C0155NSPJSZ/p1651968001107699
There are cases where users would like non-KRM files to be available to functions.
Examples that have come up include:
I'm sure there are more.
I imagine we could do this with KRM wrappers and SDK library functions to unwrap/wrap the files, so they could be included in the ResourceList.
Where we can identify common file types, it would be useful to give them dedicated KRM types rather than generic File kinds.
I'd be open to more radical changes to the ResourceList, but that would require a KEP to kustomize (https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli).
Speaking of which, with kustomize moving towards KRM functions, how is it planning to deal with this? Mounting filesystems and/or pulling files over the network is maybe necessary in some cases (e.g., helm charts), but seems suboptimal for common cases.