Skip to content

4.2. DaemonSets

Overview

The DaemonSets page manages every DaemonSet held on the MCM control plane in one place. A DaemonSet is the workload that guarantees a pod runs on every node of a cluster (or on particular nodes).

What it is for:

  • Managing multi-cluster DaemonSets together
  • Monitoring the node scheduling state per cluster
  • Creating, changing, and deleting DaemonSets
  • Managing pod placement by node selector
  • Checking the PropagationPolicy and OverridePolicy

Where DaemonSets are used:

  • Log collection agents (fluentd, filebeat, and so on)
  • Monitoring agents (node-exporter, datadog-agent, and so on)
  • Storage daemons (ceph, glusterd, and so on)
  • Network plugins (calico, flannel, and so on)

How the Screen Is Laid Out

The DaemonSets page shows the DaemonSet list as a table.

The DaemonSets main screen

The Elements at the Top of the Page

ElementDescription
Namespace filterShows only the DaemonSets of a particular namespace
Refresh buttonRefreshes the DaemonSet list
Create buttonOpens the dialog for creating a new DaemonSet
Search boxSearches by DaemonSet name

Table Columns

ColumnDescriptionSortable
NameThe DaemonSet name
NamespaceThe namespace the DaemonSet belongs to
StatusReady pods / desired pods
PodsShows current / desired / ready
Node SelectorThe node selection condition ("-" when there is none)
ImageThe container image name
AgeThe time since the DaemonSet was created
ActionsThe edit and delete buttons-

How Status Is Shown

The Status column is shown as ready / desired:

  • 13/13: pods are Ready on all 13 nodes
  • 10/13: only 10 of 13 are Ready

Pod Information

The Pods column shows the DaemonSet's pods in detail:

  • Current: the number of pods currently scheduled
  • Desired: the number of pods that should be scheduled
  • Ready: the number of pods that are Ready

DaemonSet Detail

Clicking a DaemonSet row opens the detail panel.

DaemonSet detail

The Detail Panel Header

ElementDescription
DaemonSet nameThe name of the chosen DaemonSet
NamespaceThe namespace the DaemonSet belongs to
Sync StatusThe N/N node-ready figure

The Action Buttons

ButtonWhat it does
RefreshRefreshes the DaemonSet information
EditOpens the YAML edit mode
DeleteDeletes the DaemonSet

Note: a DaemonSet runs one pod per node, so unlike a Deployment it has no scale button.

The Tabs

The Overview Tab

Shows the DaemonSet's basic information, node scheduling state, and update strategy.

Basic information:

ItemDescription
NameThe DaemonSet name
NamespaceThe namespace the DaemonSet belongs to
StatusN/N ready
AgeThe time since creation
CreatedWhen the DaemonSet was created

Node scheduling:

The node scheduling section shows the DaemonSet's central state:

ItemDescription
Node ready stateN / N nodes ready (with a progress bar)
Desired ScheduledThe number of nodes that should be scheduled
Current ScheduledThe number of nodes currently scheduled
Number ReadyThe number of pods that are Ready
Number AvailableThe number of pods that are Available
Updated ScheduledThe number of pods updated to the latest version

Pod state:

The pod state section shows the DaemonSet's pods visually:

  • Running: pods working normally
  • Pending: pods waiting to be scheduled
  • Failed: pods that failed

Update strategy:

ItemDescription
Update StrategyRollingUpdate or OnDelete
Max UnavailableThe number of pods that may be down at once during an update

Container images:

Shows the list of container images defined on the DaemonSet:

  • The image name and tag
  • A copy button

The Multi-Cluster Policies Tab

Shows the multi-cluster policies that apply to the DaemonSet.

The multi-cluster policies tab

PropagationPolicy:

ColumnDescription
NameThe PropagationPolicy name
NamespaceThe namespace the policy belongs to
ScopeNamespace-scoped policies / cluster-scoped policies
Target ClustersThe list of target clusters

OverridePolicy:

Shown where there are per-cluster custom settings. Where there are none, the message "No related override policies found" is shown.

The Labels Tab

Shows the list of Kubernetes labels applied to the DaemonSet.

The Annotations Tab

Shows the list of annotations applied to the DaemonSet.

The Pods Tab

Shows the list of pods running for that DaemonSet.

The Pods tab
ColumnDescription
NameThe pod name
ClusterThe cluster the pod is running on
StatusThe pod state (Running / Pending / Failed and so on)
NodeThe node the pod is scheduled on
RestartsThe pod restart count
AgeThe time since the pod was created
ActionsThe view and delete buttons

In the pod list you can see one pod distributed to each node, per cluster.

The Events Tab

Shows the Kubernetes events related to the DaemonSet.

Creating a DaemonSet

Creates a new DaemonSet on the MCM control plane.

Fields

FieldRequiredDescription
NameThe DaemonSet name
NamespaceThe namespace to deploy into
Container imageThe container image URL
Node Selector-Set this to deploy only to particular nodes
Ports-The container port settings
Environment variables-The container environment variables
Resource limits-The CPU and memory limits and requests
Volume mounts-Host paths or volume mounts

Editing the YAML

The "Edit YAML" tab lets you write the DaemonSet definition directly.

DaemonSet Operations

Editing a DaemonSet

  1. Choose the DaemonSet
  2. Press the "Edit" button in the detail panel
  3. Change the DaemonSet definition in the YAML editor
  4. Press the "Save" button

Deleting a DaemonSet

⚠️ Caution: deleting a DaemonSet deletes every pod that belongs to it. Resources deployed to member clusters are handled according to the deletion policy.

  1. Choose the DaemonSet to delete
  2. Press the "Delete" button in the detail panel
  3. Type the DaemonSet name in the confirmation dialog
  4. Press the "Delete" button

Worked Examples

Scenario 1: Deploying a Log Collection Agent Across Clusters

  1. Press the "Create" button
  2. Enter the DaemonSet details:
    • Name: fluentd-agent
    • Namespace: logging
    • Container image: fluent/fluentd:v1.14
    • Volume mount: /var/log/var/log (read-only)
  3. Press the "Create" button
  4. Create a PropagationPolicy naming the target clusters
  5. Confirm the agent is deployed to every node of each cluster

Scenario 2: Checking DaemonSet Status

  1. Click the DaemonSet you want to check in the list
  2. Check the node scheduling state on the Overview tab (the N/N figure)
  3. Check the pod distribution per cluster on the Pods tab
  4. Confirm the pod is running normally on each node
  5. Where there is a problem, find the cause on the Events tab

Scenario 3: Deploying a DaemonSet to Particular Nodes Only

  1. Press the "Create" button, or edit an existing DaemonSet
  2. Set the node selector:
    nodeSelector:
    node-type: worker
  3. Save, then confirm pods are scheduled only on the worker nodes
  4. Confirm no pod is created on the master nodes

Scenario 4: A DaemonSet Rolling Update

  1. Choose the DaemonSet and press "Edit"
  2. Change the container image version (v1.14v1.15, for example)
  3. Press "Save"
  4. Watch the update progress on the Overview tab:
    • Updated Scheduled climbs steadily
  5. Watch the pods being replaced in turn on the Pods tab

Scenario 5: Checking Pod Distribution Across Clusters

  1. Choose the DaemonSet
  2. Click the "Pods" tab
  3. Check the pod distribution per cluster:
    • Cluster A: 6 pods on 6 nodes
    • Cluster B: 7 pods on 7 nodes
  4. Confirm only one pod runs on each node
  5. Confirm a pod is scheduled automatically when a new node is added

DaemonSet against Deployment

TraitDaemonSetDeployment
Pod placementOne per nodeSpread over arbitrary nodes
ScalingAutomatic, with the node countThe replica count is set by hand
Where it is usedNode-level agentsOrdinary applications
Horizontal growthGrows by adding nodesGrows by adding replicas

Update Strategies

RollingUpdate (the default):

  • Updates the pods in turn
  • maxUnavailable: the number of pods that may be down at once (default: 1)
  • Minimises downtime

OnDelete:

  • A pod updates only when it is deleted by hand
  • Used where complete control is needed

Node Selectors and Tolerations

Node selector:

  • Deploys pods only to nodes with a particular label
  • For example node-type: gpu, disk-type: ssd

Toleration:

  • Allows pods onto nodes that carry a particular taint
  • For example, deploying DaemonSet pods to master nodes as well

PropagationPolicy and DaemonSets

When deploying a DaemonSet across clusters:

  • Name the target clusters with a PropagationPolicy
  • A pod is created on every eligible node of each cluster
  • Use an OverridePolicy where a cluster needs different settings

Next Steps