Kustomize Components: Reusable Overlays
A Component is a reusable bundle of resources and patches that overlays opt into via the components field.
Components solve optional, cross-cutting features (add monitoring, enable TLS) that you want to mix into several overlays without copy-pasting patches.
What it does
A Component is a directory whose kustomization.yaml uses apiVersion kustomize.config.k8s.io/v1alpha1 and kind Component. Unlike a base, a component is applied in sequence after the resources accumulate, so its patches can modify resources the overlay already pulled in. Overlays include it via the components field.
Common usage
# components/monitoring/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
patches:
- path: add-sidecar.yaml
# overlays/prod/kustomization.yaml
resources:
- ../../base
components:
- ../../components/monitoringComponent vs base
| Aspect | Component |
|---|---|
| kind | Component (not Kustomization) |
| apiVersion | kustomize.config.k8s.io/v1alpha1 |
| referenced by | components field, not resources |
| order | Applied after resources, can patch them |
| use case | Optional, composable features |
In CI
Components let one base feed many overlays that each enable different optional features, cutting duplicated patches. They are still v1alpha1, so pin your kustomize version and confirm the build is stable before relying on them in production pipelines.
Common errors in CI
"kind: should be Component" appears if a directory listed under components has kind Kustomization, or vice versa under resources. "json: unknown field \"components\"" means a kustomize too old to support components; upgrade the runner. A component patch that targets a resource the overlay did not include fails with "no matches for Id".