Reloader vs Init Containers#
In Kubernetes, applications often rely on configuration stored in ConfigMaps and Secrets.
When those resources change, running pods do not automatically reload the updated values. Platform teams therefore need a strategy to ensure applications pick up configuration changes.
Two approaches sometimes discussed are:
- Using init containers to prepare configuration
- Using a controller such as Reloader to restart workloads when configuration changes
While both can be involved in configuration management, they solve different problems in the pod lifecycle.
The Configuration Reload Problem#
In Kubernetes, updating a ConfigMap or Secret does not automatically restart pods.
Example:
ConfigMap updated
↓
Pods continue running
↓
Application still uses old configuration
This happens because Kubernetes only triggers a rollout when the Pod specification changes, not when referenced resources change.
What Init Containers Are#
Init containers are special containers that run before the main application container starts.
Their purpose is to prepare the environment required for the application to run.
Typical tasks performed by init containers include:
- generating configuration files
- downloading dependencies
- preparing directories or volumes
- validating prerequisites
Example workflow:
Pod starts
↓
Init container runs
↓
Configuration prepared
↓
Application container starts
Init containers run once per pod startup.
Advantages of Init Containers#
Init containers can be useful in several configuration-related scenarios.
Pre-processing Configuration#
Init containers can generate configuration files before the application starts.
For example, they can combine multiple sources of configuration into a single file.
Environment Preparation#
They allow applications to start with all required configuration already in place.
Simple Startup Logic#
Init containers are a built-in Kubernetes feature and do not require additional controllers.
Limitations of Init Containers for Configuration Updates#
Init containers run only during pod startup.
Because of this, they cannot react to configuration changes that occur after the pod is already running.
Example:
Pod starts
↓
Init container prepares configuration
↓
Application runs
↓
ConfigMap updated later
↓
Init container does NOT run again
↓
Application keeps old configuration
This means init containers alone cannot ensure applications reload configuration updates.
Additional mechanisms are still required to restart pods when configuration changes.
How Reloader Works#
Reloader is a Kubernetes controller that watches for changes in:
- ConfigMaps
- Secrets
When those resources change, Reloader automatically triggers a rolling restart of workloads that reference them.
Typical workflow:
ConfigMap or Secret updated
↓
Reloader detects change
↓
Deployment patched
↓
Kubernetes rolling restart triggered
This ensures applications restart and load the updated configuration.
Key Differences#
| Aspect | Reloader | Init Containers |
|---|---|---|
| Purpose | Restart workloads when configuration changes | Prepare environment before pod startup |
| Lifecycle | Reacts during runtime | Runs only during pod initialization |
| Automation | Automatic restart on config change | No reaction to later changes |
| Operational scope | Cluster-level controller | Pod-level container |
Init containers focus on startup preparation, while Reloader handles runtime configuration updates.
When Init Containers Make Sense#
Init containers are appropriate when:
- configuration must be generated before application startup
- files need to be prepared in shared volumes
- initialization logic must run before the application begins
They are commonly used for setup and bootstrapping tasks.
When Reloader Is a Better Fit#
Reloader is more appropriate when:
- configuration changes after applications are already running
- Secrets or ConfigMaps are updated dynamically
- automated rolling restarts are required
- platform teams want a consistent solution across workloads
These scenarios are common in modern Kubernetes environments.
Summary#
Init containers and Reloader serve different roles in Kubernetes.
Init containers prepare the application environment before a pod starts.
Reloader ensures applications restart when configuration changes during runtime.
Both can coexist in the same platform, but they solve different stages of the application lifecycle.
FAQ#
Do init containers rerun when a ConfigMap changes?#
No. Init containers only run when a pod starts. They do not rerun when configuration changes later.
Can init containers restart pods when configuration changes?#
No. Init containers cannot trigger restarts automatically.
Can init containers and Reloader be used together?#
Yes. Init containers can prepare configuration during startup, while Reloader ensures applications restart if configuration changes later.