I'm using Kustomize with FluxCD and finding that patches for environment-specific settings are getting pretty large. At what point is it simpler to keep separate configuration files instead of a shared base?
When would Flux post-build substitution from a ConfigMap make more sense than patches?
Use substitution for values that are shared across services but vary by cluster, like a domain or environment identifier. Put placeholders in the base and provide those values from an environment-specific ConfigMap through Flux post-build substitution.
Keep patches for changes to the resource itself, such as replica counts or versions. That split can make overlays much smaller when the same few values show up in lots of places.
Duplication isn't automatically worse than a shared base. If the environments have diverged enough that the patches are hard to read, separate manifests may be easier to maintain. The tradeoff is that common changes then need to be made in more than one place.
For a couple of fields, Kustomize is fine. Once patches get complicated, especially around arrays, a small Helm chart in the same repository can be easier to work with. It doesn't have to be published anywhere.
That said, Helm has its own complexity. Pick something the team can understand and use consistently rather than expecting either tool to make every configuration problem disappear.
Another option is to move some defaults into policy. Kyverno can mutate or create resources based on labels, so an overlay might only need to set a label instead of carrying a large patch. For example, a policy could supply default resource settings when none are specified.
That shifts configuration into policies rather than eliminating it, so those policies need to be understandable too.
Answers are reviewed before publication.
7m-foldcase+82:
That also works for URLs where only the cluster or environment identifier changes, rather than patching each URL separately.