Kustomize resources Field: Including Manifests
The resources field tells Kustomize which manifest files and which other Kustomization directories to pull in.
resources is the backbone of any kustomization.yaml. Each entry is either a YAML file or a path to another directory that has its own kustomization.yaml.
What it does
resources is a list of relative paths. A path to a file includes that manifest; a path to a directory includes the output of building that directory (it must contain a kustomization.yaml). Entries accumulate in order, and that order is preserved in the rendered output.
Common usage
resources:
- deployment.yaml
- service.yaml
- ../../base # another directory with its own kustomization.yaml
- ./crds/Field notes
| Form | Meaning |
|---|---|
| file.yaml | Include a single manifest file |
| ../base | Include another Kustomization directory (a base) |
| ./dir/ | Directory must contain a kustomization.yaml |
| remote URL or git ref | Include a remote base, e.g. github.com/org/repo//path?ref=v1 |
In CI
Remote resources (git URLs) fetch over the network on every build, which is slow and can fail on offline runners. Vendor them or pin a ?ref= tag, and pre-warm the kustomize cache where you can. Prefer kubectl apply -k for the directory once it builds clean.
Common errors in CI
"accumulating resources from 'x.yaml': evalsymlink failure ... no such file or directory" means a path is wrong or the file is not committed. "accumulating resources ... '../base' must resolve to a file or be in the current directory and contain a kustomization.yaml" means the referenced directory has no kustomization.yaml. Pointing resources at a bare directory without that file is the most common slip.
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