Propagate Labels and Annotations

Starting with Kannika Armory version 0.13.0, you can propagate labels and annotations from Kannika custom resources to the child resources they create. This feature works with all Kannika resources that have child resources.

The example below demonstrates this feature on a Backup resource, but the same approach applies to all Kannika custom resources.

apiVersion: kannika.io/v1alpha
kind: Backup
metadata:
  name: kafka-backup
  annotations:
    # Custom annotations to propagate
    prometheus.io/scrape: "true"
    prometheus.io/port: "9000"
    prometheus.io/path: "/metrics"
    # Control which annotations to propagate
    io.kannika/propagate-annotations: "prometheus.io/scrape, prometheus.io/port, prometheus.io/path"
    # Control which labels to propagate
    io.kannika/propagate-labels: "environment, team"
  labels:
    # Custom labels to propagate
    environment: production
    team: platform
spec:
  source: my-eventhub
  sink: my-storage

The specified labels and annotations from the metadata section will be propagated to all pods created by Kannika. This ensures consistent metadata across resources, useful for filtering, monitoring, and resource management:

kubectl get pods -l environment=production,team=platform

NAME                           READY   STATUS    RESTARTS   AGE
kafka-backup-worker-0          1/1     Running   0          2m30s
kafka-backup-worker-1          1/1     Running   0          2m28s

Wildcard Propagation

You can use * as a wildcard to propagate all labels or annotations:

apiVersion: kannika.io/v1alpha
kind: Backup
metadata:
  name: kafka-backup
  annotations:
    # Propagate all annotations and labels
    io.kannika/propagate-annotations: "*"
    io.kannika/propagate-labels: "*"
    prometheus.io/scrape: "true"
    prometheus.io/port: "9000"
    prometheus.io/path: "/metrics"
  labels:
    environment: production
    team: platform
spec:
  source: my-eventhub
  sink: my-storage

Specification-Based Propagation

In addition to metadata propagation, you can define labels and annotations directly in the resource specification. These are always propagated without needing control annotations:

apiVersion: kannika.io/v1alpha
kind: Restore
metadata:
  name: kafka-restore
spec:
  source: my-storage
  sink: my-eventhub
  labels:
    app: kannika-restore
    component: data-recovery
  annotations:
    monitoring: enabled

All labels and annotations defined in spec.labels and spec.annotations are automatically applied to child pods.

Override Behavior

When the same label or annotation key exists in both metadata and spec, the spec value takes precedence:

apiVersion: kannika.io/v1alpha
kind: Backup
metadata:
  name: kafka-backup
  labels:
    environment: staging
  annotations:
    io.kannika/propagate-labels: "*"
spec:
  source: my-eventhub
  sink: my-storage
  labels:
    environment: production  # This overrides the metadata value

In this example, pods will have environment: production.

Reserved Labels and Annotations

To prevent conflicts with Kubernetes and Kannika internals, certain labels and annotations are not propagated from metadata:

• Labels and annotations matching io.kannika/*
• Labels and annotations matching kubectl.kubernetes.io/*
• The controller-revision-hash label (managed by Kubernetes StatefulSet controller)
• The pod-template-hash label (managed by Kubernetes Deployment controller)

This list is non-exhaustive and may change in future versions.

These restrictions only apply to metadata propagation. Labels and annotations defined in spec.labels and spec.annotations are always propagated, even if they use reserved prefixes.