Concepts

Kubernetes does not restart your workloads when a Secret or ConfigMap they consume changes. KICK closes that gap. It watches a workload’s dependencies, detects when one changed after the last rollout, optionally asks your GitOps tool for permission, and then issues exactly one controlled restart.

How KICK turns a dependency change into a gated restart — Observation → coalesce → gate → freshness → restart

The pipeline

Every restart decision follows the same four steps. Each concept page below covers one of them in depth.

Step	What happens	Concept
1. Detect the gap	A `Secret`/`ConfigMap` changes, but the running Pod keeps its old config.	The hidden restart requirement
2. Discover deps	Find the `Secret`s and `ConfigMap`s the workload consumes via env and volumes. `imagePullSecrets` are excluded.	Dependency discovery
3. Check freshness	Compare the latest dependency change against the current rollout start. Newer dependency = stale = restart needed.	Freshness
4. Gate the restart	If a provider or windows are configured, restart only when the owner is in sync and the window is open.	GitOps gates

By default (no gitOps provider) step 4 is a no-op and KICK restarts as soon as a workload is stale.

Hidden restart requirement

Why changing a Secret or ConfigMap silently drifts your Pods.

Dependency discovery

How KICK finds the Secrets and ConfigMaps a workload consumes.

Freshness

How KICK decides a running rollout is stale and needs a restart.

GitOps gates

How native windows and a GitOps provider gate the restart.

For the same model in formal notation, see the operator model. The diagrams are editable draw.io SVGs (docs/static/images/*.drawio.svg) — open them in draw.io to edit, then save in place.

Last updated on August 21, 2026