Kubernetes DaemonSet Manifest Management

Kubernetes DaemonSet Manifest Management is the practice of authoring, organizing, and version-controlling the YAML manifests that define DaemonSet resources — along with their associated ConfigMap, Secret, ServiceAccount, and RBAC objects — in a way that reflects their role as foundational cluster infrastructure rather than ordinary application deployments. Because DaemonSets frequently underpin cluster-wide capabilities (networking, logging, security) that many other workloads implicitly depend on, manifest management practices for them tend to be more conservative and more heavily reviewed than for typical application manifests, with particular attention paid to how changes are tested before they reach every node in a cluster.

Good manifest management for DaemonSets treats each one as a small, complete package — the DaemonSet itself plus everything it depends on to function — rather than a bare Pod template manifest applied in isolation.

Manifest Composition

Bundling Supporting Resources

A production-grade DaemonSet manifest is rarely just the DaemonSet object alone; it typically travels together with its ServiceAccount, any ClusterRole/ClusterRoleBinding it needs, and any ConfigMap supplying its runtime configuration, all defined in the same directory or chart so the full set of dependencies is apparent at a glance.

manifests/log-agent/
  daemonset.yaml
  serviceaccount.yaml
  clusterrole.yaml
  clusterrolebinding.yaml
  configmap.yaml

Namespace Placement

Infrastructure DaemonSets are commonly deployed into a dedicated namespace (kube-system, or an organization-specific infrastructure namespace) rather than alongside application workloads, both to apply distinct RBAC and network policy boundaries and to make it immediately clear during a kubectl get daemonsets -A sweep which daemons are cluster infrastructure versus application-specific.

Templating Approaches

Helm for Third-Party and Fleet-Managed Daemons

Many widely used daemon workloads (CNI plugins, log collectors, monitoring agents) ship as official Helm charts, which is the most common way organizations consume them rather than hand-writing the DaemonSet manifest from scratch — manifest management here is largely about pinning chart versions deliberately and reviewing values.yaml overrides rather than authoring the underlying template.

# values.yaml (excerpt)
resources:
  requests:
    cpu: 50m
    memory: 64Mi
tolerations:
  - operator: Exists

Kustomize for In-House Daemons

For internally authored daemons, Kustomize overlays are a common way to express environment-specific differences (different nodeSelector scoping in a staging cluster with fewer node types, different resource limits in a smaller test cluster) against a shared base manifest.

Change Review Practices

Elevated Review for Privilege and Placement Changes

Because DaemonSet manifests frequently include elevated privileges (hostNetwork, privileged, broad tolerations) and cluster-wide placement, changes to these specific fields are commonly flagged for mandatory additional review in CI/CD pipelines or pull request templates, distinct from more routine changes like a resource limit adjustment or an image tag bump.

Staged Validation Before Fleet-Wide Application

kubectl apply --dry-run=server -f daemonset.yaml
kubectl diff -f daemonset.yaml

kubectl diff against the live cluster state before applying a DaemonSet manifest change is a common safeguard, surfacing exactly what will change across every covered node before the change is actually rolled out, which is particularly valuable given how widely a DaemonSet's update propagates.

Versioning and Rollback Alignment

Aligning Manifest History with Kubernetes Revision History

Because Kubernetes itself maintains ControllerRevision history for a DaemonSet's template, manifest version control (Git history) and Kubernetes-native revision history serve complementary but distinct purposes — Git history explains why a change was made, while kubectl rollout history shows exactly what was actually applied to the cluster at each point, and mature teams keep both in sync by ensuring every manifest change actually gets applied (not left as an unapplied draft) so the two histories do not drift apart.

Pinning Image Digests for Reproducibility

Given the outsized impact of a bad daemon image, manifests for particularly critical daemons sometimes pin container images by digest (codartium/log-agent@sha256:...) rather than by mutable tag, ensuring that reapplying an old manifest version during a rollback reproduces exactly the same image that was running previously, rather than whatever a floating tag happens to resolve to at that later time.

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-manifest-example
  namespace: codartium-infra
  labels:
    app.kubernetes.io/name: codartium-log-agent
    app.kubernetes.io/managed-by: helm
spec:
  selector:
    matchLabels:
      app: codartium-log-agent
  template:
    metadata:
      labels:
        app: codartium-log-agent
    spec:
      serviceAccountName: codartium-log-agent
      containers:
        - name: log-agent
          image: codartium/log-agent@sha256:abcdef1234567890
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"