kubectl "apply -k" vs standalone kustomize build mismatch in CI

kubectl embeds its own vendored kustomize, which often lags the standalone kustomize binary. A kustomization that builds standalone can fail under kubectl apply -k (or vice versa) because features and flags differ between the two versions.

What this error means

kubectl apply -k reports an unknown field or unsupported flag that kustomize build accepts, or the rendered output differs, causing an apply failure only in CI.

error: json: unknown field "helmCharts"
error: unknown flag: --enable-helm

Common causes

kubectl vendored kustomize lags the standalone binary

A newer kustomization feature is not yet in the kustomize version baked into the runner kubectl, so apply -k rejects it.

Flag support differs between the two paths

Some kustomize flags are exposed differently or not at all through kubectl, so a working standalone command fails via apply -k.

How to fix it

Build with standalone kustomize, then apply

1. Render with the standalone kustomize binary you control the version of.
2. Pipe the output to kubectl apply -f -.
3. This decouples rendering from the kubectl vendored version.

kustomize build --enable-helm overlays/prod | kubectl apply -f -

Pin a matching kustomize version

Install a known kustomize version in CI so rendering behavior is reproducible regardless of the runner kubectl.

- uses: imranismail/setup-kustomize@v2
  with:
    kustomize-version: '5.4.3'

How to prevent it

• Render with standalone kustomize and pipe to kubectl apply -f -.
• Pin the kustomize version in CI for reproducibility.
• Do not assume kubectl -k matches your local kustomize version.

Related guides