Kubernetes DaemonSet Configuration Management

Kubernetes DaemonSet Configuration Management is the practice of supplying and updating the runtime configuration a daemon container needs — connection endpoints, feature flags, per-cluster or per-environment settings — without baking that configuration into the container image itself, using the same ConfigMap and Secret mechanisms available to any Pod, but applied with attention to the fact that a configuration change here affects every node the DaemonSet covers simultaneously. Because daemon workloads are typically foundational infrastructure rather than frequently redeployed application code, configuration changes are often more common than image changes for a DaemonSet over its operational lifetime, making configuration management as significant a concern as the template design itself.

The central challenge specific to DaemonSets is that a configuration update, once applied, needs to reach every running instance of the daemon across the cluster — and how quickly and safely that propagation happens depends heavily on which mechanism is used to deliver the configuration.

Delivering Configuration

ConfigMap and Secret Volume Mounts

Mounting a ConfigMap or Secret as a volume is the most common approach, and Kubernetes automatically updates the mounted files on each node when the underlying object changes (subject to the kubelet's periodic sync interval, typically within a minute), without requiring the Pod itself to be recreated.

volumes:
  - name: agent-config
    configMap:
      name: codartium-log-agent-config
volumeMounts:
  - name: agent-config
    mountPath: /etc/codartium/config
    readOnly: true

Environment Variables from ConfigMap/Secret

Environment variables sourced via configMapKeyRef or secretKeyRef are, by contrast, fixed at container start time — updating the underlying ConfigMap or Secret does not update already-running containers' environment variables, requiring a Pod restart (triggered via a rolling update or manual deletion) to pick up the change.

env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: codartium-log-agent-config
        key: log-level

Choosing between volume-mounted and environment-variable configuration for a daemon is, in large part, a choice about whether the daemon needs to pick up changes live (favoring volumes, if the application supports hot-reloading) or whether a controlled rollout via Pod replacement is acceptable or even preferred (favoring environment variables).

Propagating Configuration Changes Cluster-Wide

Forcing a Rollout on ConfigMap Change

Because a plain ConfigMap update does not, by itself, trigger a DaemonSet rollout, teams needing every daemon instance to restart and pick up a new configuration reliably often embed a hash of the ConfigMap's content into a Pod template annotation, which changes the template's hash and triggers a normal rolling update purely as a side effect.

template:
  metadata:
    annotations:
      codartium.io/config-hash: "{{ .Values.configHash }}"

This pattern — common in Helm charts via a checksum/config annotation convention — converts an otherwise silent configuration update into an explicit, trackable rollout that benefits from the same maxUnavailable and readiness-gating protections as any other template change.

Per-Node Configuration Variance

Some daemons need slightly different configuration on different classes of nodes (a different buffer size for high-throughput nodes, a different log verbosity for a debugging subset). Since a single DaemonSet applies one uniform template, this is typically handled either by running multiple DaemonSets scoped via nodeSelector to different node classes, each with its own ConfigMap, or by having the daemon itself read node labels via the downward API and adjust its own behavior internally rather than relying on Kubernetes to differentiate the configuration per node.

Secrets Handling for Daemons

Avoiding Broad Secret Distribution

Because a Secret mounted into a DaemonSet is distributed to every node the daemon covers, credentials granted to a daemon (an API token for a log aggregation backend, a TLS certificate) should be scoped to the minimum privilege that specific daemon actually needs — a compromised node running that daemon exposes whatever secret material was mounted there, and a broadly privileged credential multiplies that exposure across every covered node.

Rotation Considerations

Secret rotation for daemon-mounted credentials benefits from the same volume-mount propagation behavior as ConfigMaps (updated automatically on each node without a Pod restart, within the kubelet's sync interval), which is often preferable to environment-variable-based secrets specifically because it allows rotation without needing to trigger a full daemon rollout across the cluster.

Example

apiVersion: v1
kind: ConfigMap
metadata:
  name: codartium-log-agent-config
data:
  log-level: "info"
  flush-interval: "5s"
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-log-agent
spec:
  selector:
    matchLabels:
      app: codartium-log-agent
  template:
    metadata:
      labels:
        app: codartium-log-agent
      annotations:
        codartium.io/config-hash: "a1b2c3d4"
    spec:
      containers:
        - name: log-agent
          image: codartium/log-agent:latest
          volumeMounts:
            - name: agent-config
              mountPath: /etc/codartium/config
              readOnly: true
      volumes:
        - name: agent-config
          configMap:
            name: codartium-log-agent-config