Component Operator

Seamless Integration with FluxCD Sources

Existing FluxCD HelmRelease or Kustomization resources can be seamlessly replaced by components. The Component Operator automatically detects if the referenced source is a Helm Chart or not, and applies the corresponding rendering logic.

Example: Component Using Flux Sources

apiVersion: core.cs.sap.com/v1alpha1
kind: Component
metadata:
  name: app
spec:
  sourceRef:
    fluxHelmChart:
      name: app
    # gitRepository:
    #   name: app

The Component Operator intelligently determines the source type and applies the appropriate rendering strategy, whether it's Helm templating for charts or standard YAML processing for Kustomizations.

One big advantage is that one and the same resource type (Component) can be used with all types of sources (Helm Chart or Kustomization). This makes it much easier to declare dependencies between components.

FluxCD Integration

Component Operator seamlessly integrates with FluxCD to enable GitOps workflows. It can be seen as a third Flux deployer (besides kustomize-controller and helm-controller), and can be used in parallel or instead of the default Flux deployers. Define your components declaratively, let Flux do the source management, and let Component Operator handle the synchronization with the Kubernetes cluster.

Example: FluxCD Component Deployment

Use the regular Flux source types GitRepository, HelmChart, OCIRepository and Bucket.

# Using a Flux GitRepository

apiVersion: core.cs.sap.com/v1alpha1
kind: Component
metadata:
  name: my-app
  namespace: default
spec:
  sourceRef:
    fluxGitRepository:
      name: app
  values:
    replicas: 3
    image:
      tag: latest

# Using a Flux HelmChart

apiVersion: core.cs.sap.com/v1alpha1
kind: Component
metadata:
  name: my-app
  namespace: default
spec:
  sourceRef:
    fluxHelmChart:
      name: app
  values:
    replicas: 3
    image:
      tag: latest

In-Cluster Blueprints

Alternatively, use our in-cluster Blueprints feature to define reusable component templates directly in your cluster.

# Blueprint definition

apiVersion: core.cs.sap.com/v1alpha1
kind: Blueprint
metadata: 
  name: webapp
spec:
  files:
    resources.yaml: |
      # here come the templated resource manifests

# Consuming component

apiVersion: core.cs.sap.com/v1alpha1
kind: Component
metadata:
  name: webapp
spec:
  sourceRef:
    blueprint:
      name: webapp
    values:
      replicas: 3
      service:
        type: LoadBalancer

Apply and Delete Waves

Dependent objects can be annotated to apply or delete them in waves. This allows you to control the order in which resources are created or removed, ensuring proper dependencies are respected.

Example: Configuring Apply and Delete Order

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  annotations:
    component-operator.cs.sap.com/apply-order: "1"
    component-operator.cs.sap.com/delete-order: "2"

Improved Status Detection

For some objects, the default status (readiness) detection is not sufficient. In these cases, the status detection can be tweaked using annotations to specify custom conditions and checks.

Example: Custom Status Hints

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: destination
  annotations:
    component-operator.cs.sap.com/status-hint: hasObservedGeneration,hasReadyCondition,conditions=Succeeded

Smart Handling of Custom Resource Definitions

The Component Operator intelligently handles components containing Custom Resource Definitions. The deletion of such components is automatically postponed as long as foreign instances of the contained Custom Resource Types exist in the cluster. This keeps the operator being part of the component alive, and gives the owners of these Custom Resource Objects the chance to clean up consistently.

Dependencies Between Components

As with FluxCD Kustomization or HelmRelease, dependencies between components can be defined. However other than in FluxCD, dependencies are not only honored upon applying objects, but also during deletion, in reverse order. This ensures proper cleanup sequences and maintains system consistency.

Helm Chart Templating

Sources which are Helm Charts use the usual Golang-based Helm template syntax. This provides the full power of Helm templating with all standard functions and capabilities.

Enhanced Templating for Kustomizations and Plain Manifests

Alternatively, sources can be Kustomizations or just plain YAML manifests (which is actually a special case of a Kustomization). Unlike FluxCD, these Kustomizations or plain manifests can use Golang templating as well.

The syntax is similar to Helm but more powerful. In particular, enhanced reflexivity functions are provided, such as:

• localLookup - Look up resources in the local component context
• lookupWithKubeConfig - Look up resources with custom kubeconfig
• lookupList - Retrieve lists of resources
• And many more advanced reflexivity functions...

These enhanced functions enable powerful cross-resource references and dynamic manifest generation based on the actual state of your cluster.