I’ve lost count of how many times I’ve updated a ConfigMap and then wondered why my application wasn’t picking up the changes.

The fix was always the same: manually restart the deployment.

kubectl rollout restart deployment/my-app

This gets old fast.

The Problem

Kubernetes doesn’t automatically restart pods when their ConfigMaps or Secrets change. Your deployment keeps running with the old configuration until you manually trigger a rollout.

This creates a few issues:

  • Forgotten restarts after config changes
  • Inconsistent state between what’s in the ConfigMap and what’s running
  • Manual intervention in what should be an automated workflow

Enter Reloader

Reloader is a Kubernetes controller from Stakater that watches for changes in ConfigMaps and Secrets. When it detects a change, it automatically triggers a rolling restart of any deployments that reference them.

It’s one of those tools that does exactly one thing, and does it well.

How I’m Running It

I deployed Reloader via Flux with a HelmRelease:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: reloader
  namespace: kube-system
spec:
  interval: 30m
  chart:
    spec:
      chart: reloader
      version: "1.x"
      sourceRef:
        kind: HelmRepository
        name: stakater
        namespace: flux-system
  values:
    reloader:
      watchGlobally: true

The watchGlobally: true setting means it monitors all namespaces—you don’t need to deploy it per-namespace.

Enabling Auto-Reload

Reloader doesn’t reload everything by default. You opt-in per deployment with an annotation:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  annotations:
    reloader.stakater.com/auto: "true"
spec:
  # ...

That’s it. Now when any ConfigMap or Secret referenced by this deployment changes, Reloader triggers a rolling restart.

More Granular Control

If you only want to reload on specific resource changes:

# Only reload when a specific ConfigMap changes
annotations:
  configmap.reloader.stakater.com/reload: "my-configmap"

# Only reload when a specific Secret changes
annotations:
  secret.reloader.stakater.com/reload: "my-secret"

# Multiple resources
annotations:
  configmap.reloader.stakater.com/reload: "config-1,config-2"

This is useful when a deployment references multiple ConfigMaps but you only care about reloading for certain ones.

GitOps Consideration

One thing to be aware of: by default, Reloader modifies your pod template to trigger the rollout. This can cause drift in GitOps setups because the running state differs from what’s in git.

The fix is to use the restart strategy:

annotations:
  reloader.stakater.com/auto: "true"
  reloader.stakater.com/rollout-strategy: "restart"

With the restart strategy, Reloader uses kubectl rollout restart instead of modifying annotations. This keeps your manifests clean and GitOps-friendly.

Resource Usage

Reloader is lightweight. The defaults are:

resources:
  requests:
    cpu: 10m
    memory: 128Mi
  limits:
    memory: 512Mi

I’ve been running it for a few weeks and it barely registers in my monitoring.

When to Use This

Reloader shines for:

  • Development environments where you’re iterating on configs frequently
  • GitOps workflows where config changes should automatically propagate
  • Any deployment that reads configuration at startup and doesn’t hot-reload

It’s not necessary for applications that watch their config files and hot-reload automatically. But most applications don’t do that.

The Bottom Line

Reloader removes a manual step from my workflow. I update a ConfigMap, push to git, Flux applies it, and Reloader restarts the affected deployments. No more “did I remember to restart that?” moments.

Small tools like this compound. Each one removes a bit of friction, and over time your cluster becomes more self-managing.

Links: