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