Examples

Creation¶

Create a ConfigBundle with the desired configuration:

apiVersion: training.k8s.operators.dev/v1
kind: ConfigBundle
metadata:
  name: example
spec:
  message: "Hello, Kubernetes!"
  immutable: false

Apply it to the cluster:

kubectl apply -f configbundle.yaml

The operator creates the corresponding ConfigMap.

Verify both resources:

kubectl get configbundle example
kubectl get configmap

The created ConfigMap contains the configured message:

data:
  message: "Hello, Kubernetes!"

Updates¶

A mutable ConfigBundle can be updated by changing its spec.

For example, change the message:

apiVersion: training.k8s.operators.dev/v1
kind: ConfigBundle
metadata:
  name: example
spec:
  message: "Updated message"
  immutable: false

Apply the updated resource:

kubectl apply -f configbundle.yaml

The operator updates the managed ConfigMap to reflect the new desired configuration.

data:
  message: "Updated message"

The operator also updates ConfigBundle.status using the resulting ConfigMap.

Verify both resources:

kubectl get configbundle example
kubectl get configmap

Immutability¶

A ConfigBundle can make its managed ConfigMap immutable by setting spec.immutable to true.

apiVersion: training.k8s.operators.dev/v1
kind: ConfigBundle
metadata:
  name: example
spec:
  message: "Immutable configuration"
  immutable: true

After applying the resource:

kubectl apply -f configbundle.yaml

the managed ConfigMap is created with:

immutable: true

Once the previous ConfigBundle.spec.immutable value is true, subsequent updates to the spec are reverted to the previous values.

For example, changing:

spec:
  message: "Changed message"
  immutable: true

does not change the existing configuration.

Instead, the operator restores the previous spec values on the ConfigBundle.

ConfigMap Recovery¶

The operator continuously watches the managed ConfigMap.

If the ConfigMap is deleted while its ConfigBundle still exists, the operator detects that the managed resource is missing and recreates it from the current ConfigBundle.spec.

Find the corresponding ConfigMap and delete it, after a little bit of time check its existence again.

Drift Recovery¶

The operator also detects changes made directly to the managed ConfigMap.

For example, manually modify the message:

kubectl patch configmap example \
  --type merge \
  -p '{"data":{"message":"Manually modified"}}'

The actual ConfigMap now differs from the desired configuration defined by the ConfigBundle.

The operator's watch loop detects this difference and replaces the ConfigMap with the desired state.

After the next integrity check, the managed ConfigMap contains the original desired message again.

Metadata Synchronization¶

Changes to metadata.labels and metadata.annotations on the ConfigBundle are propagated to the managed ConfigMap.

For example, add a label:

apiVersion: training.k8s.operators.dev/v1
kind: ConfigBundle
metadata:
  name: example
  labels:
    environment: production
spec:
  message: "Hello, Kubernetes!"
  immutable: false

Apply the change:

kubectl apply -f configbundle.yaml

The operator updates the corresponding label on the managed ConfigMap.

The same behavior applies to annotations:

metadata:
  name: example-yblkjs
  annotations:
    example.com/owner: platform

The operator handles adding, changing, and removing labels and annotations.

The metadata of the managed ConfigMap is therefore kept synchronized with the corresponding metadata changes on the ConfigBundle.