I'm using Kustomize overlays with FluxCD: a shared base for common infrastructure and one overlay per environment. The overlays handle environment-specific settings such as replica counts, URLs, image tags, and subscription IDs.
Some of the patches are becoming large and complicated, to the point where maintaining separate configuration files for each environment seems simpler. How much reuse am I really gaining from the base-and-overlay approach?
I've also seen PostBuild substitution with environment-specific ConfigMaps recommended for FluxCD. When is that a better choice than Kustomize patches? At what point should I consider moving to an in-repository Helm chart or another templating approach?
5 Answers
Another approach is to keep environment-wide values in a ConfigMap and have the base reference those values consistently. Then overlays mainly contain things that genuinely differ, such as replicas or versions. For Kustomize itself, ordinary patch files are often easier to review than large inline patches, and repeated patch logic can sometimes be extracted into a reusable component.
Kustomize works well when environments are mostly the same and only need a handful of exceptions. Once every overlay has many changes, you may be repeating yourself while also having to understand several layers of patches. At that point, an in-repository Helm chart with a values file per environment can be easier to maintain, especially if the differences are mostly parameters rather than resource structure.
A good test is whether the environments are truly variants of the same application. Development, staging, and production with different images, defaults, and replica counts are a good fit for overlays. If the environments have substantially different resources or behavior, separate configurations may be clearer than trying to preserve a heavily shared base. The rendered manifests should stay easy to inspect and troubleshoot, even if that means accepting a little duplication.
A useful rule of thumb is to use PostBuild substitution for simple scalar values that vary by environment: URLs, cluster names, image tags, replica counts, IDs, and similar settings. It can remove a lot of repetitive patches. Use Kustomize patches for structural changes, such as adding a sidecar, changing volumes, or modifying list-based fields. Kustomize tends to become painful when you’re trying to manipulate arrays or substantially reshape resources.
There’s no need to treat one tool as universally correct. Kustomize is especially useful for adjusting vendor-provided manifests without maintaining a fork. Helm is usually more comfortable when you own the configuration and need lots of parameters. If you choose Helm, keep the chart structure shallow and maintainable; excessive nesting and abstraction can become harder to debug than the original overlays.
That makes sense. I’m trying to keep the shared base where it provides real value, but avoid forcing every difference through increasingly complicated patches.