Usage

About writing manifests and controlling reconciliation of dependent resources

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.

Glossary

Component

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.

Dependent Object

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.

Source

A source defines how component-operator retrieves the manifests. A source can be:

  • A Flux GitRepository, OCIRepository, Bucket, or HelmChart — externally managed artifact sources provided by the Flux source controller.
  • A Blueprint — an in-cluster source type where manifests are stored directly inside a Kubernetes custom resource (Blueprint), without requiring an external repository.

See Sources for details.

Manifest

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 / Rendering

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.


Sources

Configuring the source of manifests for a Component

Manifests

How manifests are structured, templated, and rendered

Drift Detection

How component-operator detects and handles drift

Status Detection

How component-operator determines whether a dependent object is ready

Target Namespace and Name

Controlling where dependent objects are deployed

Dependents Lifecycle

Controlling how dependent objects are applied and deleted

Dependents Annotations

Overview of annotations that can be set with dependent resources

Component Deletion

What happens when a Component is deleted

Intervals and Timing

Tuning reconciliation timing

Ownership and Adoption

How component-operator tracks ownership and handles pre-existing objects

Reconcile Modes

Controlling how individual dependent objects are reconciled

Impersonation and Remote Clusters

Deploying dependent objects as a specific service account or to a remote cluster

Timeout and Stickiness

Configuring reconciliation timeouts and source revision stickiness

Dependencies

Declaring ordering constraints between Component objects

Notifications

Streaming component events to the Flux notification controller