Kubernetes DaemonSet Spec Structure

Kubernetes DaemonSet Spec Structure is the schema and internal organization of the spec field on an apps/v1 DaemonSet object, defining how scheduling constraints, update behavior, and the Pod template are expressed together to describe a workload meant to run once per eligible node. Compared to a Deployment's spec, a DaemonSet's spec is notably smaller: it has no replicas field, since the desired Pod count is derived entirely from cluster node membership rather than declared as a number, and its update-related fields are specifically tailored to rolling changes across an entire, topology-driven fleet of Pods rather than a fixed-size replica set.

Understanding the DaemonSet spec structure means understanding which fields exist specifically because a DaemonSet's Pod placement is tied to nodes, as opposed to the fields it shares in common with every other Pod-template-based controller.

Top-Level Fields

apiVersion and kind

DaemonSets are defined under apps/v1 with kind: DaemonSet. Earlier API versions (extensions/v1beta1, apps/v1beta2) have been removed in favor of the stable apps/v1 group.

metadata

Standard object metadata: name, namespace, labels, annotations. As with Deployments, labels here identify the DaemonSet object itself, distinct from the labels applied inside template.metadata to its Pods.

The spec Block

selector

A required field specifying matchLabels and/or matchExpressions that must match the labels in template.metadata.labels. Unlike Deployments, this selector is immutable after creation — a DaemonSet's selector cannot be changed once set, since altering it would change which Pods the controller considers its own.

spec:
  selector:
    matchLabels:
      app: codartium-node-agent

updateStrategy

Controls how existing Pods are replaced when the template changes:

• type: RollingUpdate (default), with rollingUpdate.maxUnavailable bounding how many node Pods may be simultaneously absent during a rollout, and rollingUpdate.maxSurge (available in more recent versions) permitting a temporary extra Pod on a node before the old one is removed.
• type: OnDelete, which disables automatic propagation entirely; updated Pods are only created once an operator manually deletes the existing Pod for a given node.

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1

minReadySeconds

The minimum number of seconds a newly created Pod must be ready without any of its containers crashing before it is considered available, used by the rolling update process to pace how quickly it proceeds to the next node.

revisionHistoryLimit

Bounds how many old ControllerRevision objects (used to support rollback) are retained for the DaemonSet, analogous to the same field on Deployments and StatefulSets.

template

A full PodTemplateSpec, structurally identical to what a Deployment or StatefulSet uses — its own metadata and spec describing containers, volumes, resources, nodeSelector, affinity, and tolerations.

Fields Notably Absent

No replicas

There is no spec.replicas field on a DaemonSet at all; the schema simply does not define one, since Pod count is implicitly one per eligible node rather than a chosen number.

No Native Scaling Commands

Because there is no replica count, commands like kubectl scale have no meaningful effect on a DaemonSet; the only way to change its effective Pod count is to change which nodes match its scheduling constraints, or to change the set of nodes in the cluster itself.

Full Structural Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-spec-example
  labels:
    app: codartium-spec-example
spec:
  selector:
    matchLabels:
      app: codartium-spec-example
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  minReadySeconds: 10
  revisionHistoryLimit: 5
  template:
    metadata:
      labels:
        app: codartium-spec-example
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      tolerations:
        - operator: "Exists"
          effect: "NoSchedule"
      containers:
        - name: agent
          image: codartium/node-agent:latest
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"
            limits:
              cpu: "100m"
              memory: "128Mi"

kubectl explain daemonset.spec
kubectl get daemonset codartium-spec-example -o yaml