I have to bring up Jsonnet [1] in every one of these discussions. Jsonnet isn't the tool you want for managing a complex stack of configurable objects, but it is the tool you need. Jsonnet gets big and ungly and unweildy at a certain point, and that is also coincidentally the point where you need to have rethought your model and refactored your config, just as much as your code.
Simple yaml is just fine, even repetitive simple yaml, and you're often better off building tooling to make repetitive updates rather than condense your config. Jsonnet is for building when you've got dozens rather than handfuls of objects.
Well defined Kubernetes objects don't actually take that much configuration, don't generally need templating. Typically, my production and staging environments are precisely the same deployment definition, except image and replicas. Replicas isn't defined in the document - it's part of the working state rather than something that gets "configured" (i.e. that field is owned by an HPA, even if it's min and max values are the same)
All configuration is stored in Configmaps and secrets. Those are more likely to be templated, but still probably not. If two values are the same in production and testing (and they should be - service names are the same, with namespace defining where they point), why configure it? Use a sane default.
Simple yaml is just fine, even repetitive simple yaml, and you're often better off building tooling to make repetitive updates rather than condense your config. Jsonnet is for building when you've got dozens rather than handfuls of objects.
Well defined Kubernetes objects don't actually take that much configuration, don't generally need templating. Typically, my production and staging environments are precisely the same deployment definition, except image and replicas. Replicas isn't defined in the document - it's part of the working state rather than something that gets "configured" (i.e. that field is owned by an HPA, even if it's min and max values are the same)
All configuration is stored in Configmaps and secrets. Those are more likely to be templated, but still probably not. If two values are the same in production and testing (and they should be - service names are the same, with namespace defining where they point), why configure it? Use a sane default.
[1]https://jsonnet.org/articles/kubernetes.html