Restarting workloads

Kubernetes does not restart a pod when a Secret changes. A container reads its environment once, at start, and keeps what it read.

Without the step on this page the connector does its job and your application never notices: the Secret is current, the running process is not, and everything looks fine.

Turn it on at install

helm upgrade kyvlt-connector oci://ghcr.io/bluepawlabs/charts/kyvlt-connector \
  --namespace kyvlt-operator \
  --reuse-values \
  --set reload.enabled=true

It is off by default because restarting workloads is a bigger permission than writing a Secret, and a cluster should be able to accept the projection and refuse the restarts. Enabling it lets the operator patch Deployments in the namespaces it already serves, and nothing else.

Ask for it, per workload

kubectl annotate deployment/YOUR_DEPLOYMENT \
  connectors.kyvlt.sh/reload=true

The annotation goes on the Deployment, not on the sync resource. Only the team that owns a workload knows whether it re-reads its configuration; the team that owns the projection does not.

What happens

When the Secret changes, the operator updates an annotation on the Deployment’s pod template. Changing a pod template is what a rolling update is, so Kubernetes replaces the pods as it would for any other change — gradually, respecting your readiness probes.

It does not roll for nothing

A sync that changes nothing restarts nothing. Neither does restarting or upgrading the operator: the annotation’s value is derived from the Secret itself, so a fresh operator computes the same value and writes the same bytes, which Kubernetes treats as no change.

If a workload cannot tolerate a restart

Do not annotate it. The Secret stays current either way, and you restart that workload when it suits you.