Kustomize helmCharts and --enable-helm
The helmCharts field renders a Helm chart and folds its output into the Kustomize build, but only with --enable-helm.
When you want Kustomize overlays on top of a third-party Helm chart, helmCharts inflates the chart and lets you patch the result, gated behind an explicit flag.
What it does
helmCharts declares charts to render with the Helm template engine during the build. Kustomize shells out to helm to inflate each chart with the given values, then treats the output as resources you can patch and transform. Because it runs an external binary, it requires the --enable-helm flag.
Common usage
# kustomization.yaml
helmCharts:
- name: nginx
repo: https://charts.bitnami.com/bitnami
version: 15.0.0
releaseName: web
valuesInline:
replicaCount: 3
# build (flag is required)
kustomize build --enable-helm .Fields
| Field | What it does |
|---|---|
| name | Chart name |
| repo | Chart repository URL |
| version | Chart version to render |
| releaseName | Helm release name passed to the template |
| valuesFile / valuesInline | Values file or inline overrides |
| namespace | Namespace passed to helm template |
In CI
helm must be on PATH and --enable-helm passed, or the build refuses to inflate. kubectl apply -k also needs --enable-helm forwarded; many CI jobs render with a standalone kustomize build --enable-helm into an artifact and apply that, since kubectl support for the flag has lagged. Pin both kustomize and helm versions for reproducible output.
Common errors in CI
"must specify --enable-helm" means the flag is missing. "exec: \"helm\": executable file not found in $PATH" means the helm binary is not installed on the runner. "Error: chart ... not found" means the repo or version is wrong, or the repo needs adding first. Network failures pulling the chart hit offline runners; cache or vendor the chart.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes