# kubectl apply -k: Usage, Options & Common CI Errors

> kubectl apply -k builds and applies a kustomize overlay in one step. Overlay selection in CI, the accumulation errors, and previewing with kustomize build.

Source: https://latchkey.dev/learn/command-reference/kubectl-apply-k  
Updated: 2026-06-25

Render a kustomize overlay and apply it in a single command.

kubectl apply -k builds a kustomize directory (base plus overlay) and applies the result, the standard way to deploy environment-specific config without templating. In CI you point -k at the right overlay per environment.

## What it does

kubectl apply -k DIR runs the embedded kustomize build on DIR's kustomization.yaml - merging the base, applying patches, image tags, name prefixes, and common labels - then applies the rendered manifests. It is equivalent to kustomize build DIR | kubectl apply -f -.

## Common usage

```Terminal
kubectl apply -k overlays/prod
kubectl apply -k overlays/staging --server-side
kustomize build overlays/prod | kubectl diff -f -    # preview the change
kubectl kustomize overlays/prod                       # render without applying
```

## Common errors in CI

"error: accumulating resources ... no such file or directory" means a path in resources: is wrong or the referenced base moved - kustomize paths are relative to the kustomization.yaml. "must build at directory: not a valid directory" means you pointed -k at a file, not the folder containing kustomization.yaml. A subtle one: kubectl's built-in kustomize can lag the standalone kustomize binary, so a newer field (e.g. a transformer) may parse with kustomize build but error under apply -k - pin the kubectl version or pipe the standalone binary instead.

## 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.

```Terminal
# 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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl apply -k: Usage, Options & Common CI Errors?

kubectl apply -k builds a kustomize directory (base plus overlay) and applies the result, the standard way to deploy environment-specific config without templating. In CI you point -k at the right overlay per environment.

### What it does?

kubectl apply -k DIR runs the embedded kustomize build on DIR's kustomization.yaml - merging the base, applying patches, image tags, name prefixes, and common labels - then applies the rendered manifests. It is equivalent to kustomize build DIR | kubectl apply -f -.

### Common errors in CI?

"error: accumulating resources ... no such file or directory" means a path in resources: is wrong or the referenced base moved - kustomize paths are relative to the kustomization.yaml. "must build at directory: not a valid directory" means you pointed -k at a file, not the folder containing kustomization.yaml.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt