Sources
Configuring the source of manifests for a Component
Explore the templating language, and how to control the lifecycle of dependent objects. Learn about tuning the reconciliation on operator level, component level, and on the level of individual resources.
A component is a coherent set of Kubernetes resources. The Component resource (reconciled by Component Operator) ties together a source containing manifests with instructions on how to apply the described Kubernetes objects to the cluster. It is the central abstraction in component-operator: you declare what to deploy (via the source), how to parameterize it (via values), and how to manage the lifecycle of the resulting objects.
A dependent object is a specific Kubernetes resource (e.g., a Deployment, Service, ConfigMap) that results from rendering the component’s manifests. Dependent objects are owned and managed by the component throughout their lifecycle: created when the component is applied, updated or deleted when the manifests change, and deleted when the component is removed.
A source defines how component-operator retrieves the manifests. A source can be:
Blueprint), without requiring an external repository.See Sources for details.
A manifest is a (potentially templated) YAML document specifying a Kubernetes resource. Manifests are the raw input from which dependent objects are derived. They may contain Go template expressions, Helm-style function calls, or kustomize overlays that are evaluated during the rendering step.
Generation (or rendering) is the process of producing the final set of Kubernetes manifests from the source files. During this step, template expressions are evaluated, values are substituted, kustomize overlays are applied, and the result is a concrete list of Kubernetes objects ready to be applied to the cluster.
Configuring the source of manifests for a Component
How manifests are structured, templated, and rendered
How component-operator detects and handles drift
How component-operator determines whether a dependent object is ready
Controlling where dependent objects are deployed
Controlling how dependent objects are applied and deleted
Overview of annotations that can be set with dependent resources
What happens when a Component is deleted
Tuning reconciliation timing
How component-operator tracks ownership and handles pre-existing objects
Controlling how individual dependent objects are reconciled
Deploying dependent objects as a specific service account or to a remote cluster
Configuring reconciliation timeouts and source revision stickiness
Declaring ordering constraints between Component objects
Streaming component events to the Flux notification controller