> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shiftlabs.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# DaemonSets

> Manage Kubernetes DaemonSets that run pods on every node

DaemonSets ensure that a copy of a pod runs on all (or selected) nodes in the cluster. They are ideal for cluster-wide services like log collectors, monitoring agents, and storage daemons.

## Key Concepts

<CardGroup cols={2}>
  <Card title="DaemonSet" icon="circle-nodes">
    A controller that ensures pods run on all matching nodes automatically.
  </Card>

  <Card title="Node Selector" icon="filter">
    Labels that restrict which nodes run the DaemonSet pods.
  </Card>

  <Card title="Tolerations" icon="shield-check">
    Allow DaemonSet pods to run on tainted nodes (e.g., master nodes).
  </Card>

  <Card title="Rolling Update" icon="rotate">
    Gradual update of pods across nodes while maintaining availability.
  </Card>
</CardGroup>

## Required Permissions

| Action            | Permission                                     |
| ----------------- | ---------------------------------------------- |
| View daemonsets   | `iam:project:infrastructure:kubernetes:read`   |
| Restart daemonset | `iam:project:infrastructure:kubernetes:write`  |
| Create daemonset  | `iam:project:infrastructure:kubernetes:write`  |
| Edit daemonset    | `iam:project:infrastructure:kubernetes:write`  |
| Delete daemonset  | `iam:project:infrastructure:kubernetes:delete` |

## DaemonSet Status Values

| Status           | Description                                    |
| ---------------- | ---------------------------------------------- |
| **Running**      | All desired nodes have ready pods              |
| **Updating**     | Rolling update in progress                     |
| **NotReady**     | Some pods are not ready yet                    |
| **Misscheduled** | Pods running on nodes that shouldn't have them |
| **NoNodes**      | No nodes match the DaemonSet's node selector   |
| **Unknown**      | Status cannot be determined                    |

## DaemonSet Metrics

| Metric           | Description                                     |
| ---------------- | ----------------------------------------------- |
| **Desired**      | Number of nodes that should run the pod         |
| **Current**      | Number of nodes running at least one pod        |
| **Ready**        | Number of nodes with ready pods (ready/desired) |
| **Available**    | Number of nodes with available pods             |
| **Misscheduled** | Pods running where they shouldn't               |
| **Updated**      | Nodes running the latest pod template           |

## How to View DaemonSets

<Steps>
  <Step title="Select Cluster">
    Choose a cluster from the cluster dropdown.
  </Step>

  <Step title="Select Namespace">
    Choose a namespace or select "all" to view DaemonSets across all namespaces.
  </Step>

  <Step title="Filter and Search">
    Use the search box to find DaemonSets by name, or filter by status.
  </Step>
</Steps>

## How to View DaemonSet Details

<Steps>
  <Step title="Find the DaemonSet">
    Locate the DaemonSet in the list.
  </Step>

  <Step title="Click DaemonSet Name">
    Click on the DaemonSet name to open the detail drawer.
  </Step>

  <Step title="Review Details">
    View DaemonSet information including:

    * Pod distribution across nodes
    * Container specifications
    * Update strategy configuration
    * Node selector and tolerations
    * Labels and annotations
  </Step>
</Steps>

## How to Restart a DaemonSet

Restart triggers a rolling restart of pods on all nodes.

<Steps>
  <Step title="Find the DaemonSet">
    Locate the DaemonSet in the list.
  </Step>

  <Step title="Open Actions Menu">
    Click the actions menu (three dots) on the DaemonSet row.
  </Step>

  <Step title="Click Restart">
    Select **Restart** from the menu.
  </Step>

  <Step title="Monitor">
    Watch the status change to Updating as pods are replaced on each node.
  </Step>
</Steps>

<Info>
  Restart performs a rolling update by adding a `kubectl.kubernetes.io/restartedAt` annotation. Pods are updated one node at a time by default.
</Info>

## How to Create a DaemonSet

<Steps>
  <Step title="Click Create DaemonSet">
    Click the **Create DaemonSet** button in the page header.
  </Step>

  <Step title="Write YAML">
    Enter the DaemonSet manifest in YAML format. A template is provided.
  </Step>

  <Step title="Select Namespace">
    Choose the target namespace for the DaemonSet.
  </Step>

  <Step title="Create">
    Click **Create** to apply the manifest.
  </Step>
</Steps>

<Tip>
  Common DaemonSet use cases include log collectors (Fluentd, Filebeat), monitoring agents (Prometheus Node Exporter, Datadog), and storage plugins (CSI drivers).
</Tip>

## How to Edit a DaemonSet

<Steps>
  <Step title="Open Actions Menu">
    Click the actions menu on the DaemonSet row.
  </Step>

  <Step title="Click Edit YAML">
    Select **Edit YAML** to open the editor.
  </Step>

  <Step title="Modify Spec">
    Edit the DaemonSet specification. Common changes:

    * Container image (triggers rolling update)
    * Resource requests/limits
    * Environment variables
    * Node selector or tolerations
  </Step>

  <Step title="Save">
    Click **Update** to apply changes.
  </Step>
</Steps>

<Info>
  Changes to the pod template spec trigger a rolling update. Pods are replaced on each node according to the update strategy.
</Info>

## How to Delete a DaemonSet

<Steps>
  <Step title="Open Actions Menu">
    Click the actions menu on the DaemonSet row.
  </Step>

  <Step title="Click Delete">
    Select **Delete** from the menu.
  </Step>

  <Step title="Confirm">
    Confirm the deletion.
  </Step>
</Steps>

<Warning>
  Deleting a DaemonSet removes pods from all nodes. Services relying on these pods (logging, monitoring) will stop functioning.
</Warning>

## Update Strategies

DaemonSets support two update strategies:

| Strategy          | Description                                                                   |
| ----------------- | ----------------------------------------------------------------------------- |
| **RollingUpdate** | Updates pods one node at a time (default). Configurable via `maxUnavailable`. |
| **OnDelete**      | Only updates pods when they are manually deleted.                             |

**RollingUpdate parameters:**

* `maxUnavailable` - Maximum pods that can be unavailable during update (default: 1)
* `maxSurge` - Maximum extra pods that can be created during update (optional)

## Node Selection

DaemonSets use node selectors and tolerations to control pod placement:

**Node Selector:**

```yaml theme={null}
nodeSelector:
  node-type: worker
  disk: ssd
```

**Tolerations (for running on control plane nodes):**

```yaml theme={null}
tolerations:
  - key: node-role.kubernetes.io/control-plane
    operator: Exists
    effect: NoSchedule
```

## Troubleshooting

<AccordionGroup>
  <Accordion title="DaemonSet shows 0 desired pods">
    * No nodes match the node selector
    * All matching nodes are tainted and DaemonSet lacks tolerations
    * Check node labels match the DaemonSet's node selector
    * Verify tolerations for any taints on target nodes
  </Accordion>

  <Accordion title="Pods not running on some nodes">
    * Node may have taints that pods don't tolerate
    * Node may not match the node selector
    * Node may have insufficient resources
    * Check node conditions and taints
  </Accordion>

  <Accordion title="Misscheduled pods (pods where they shouldn't be)">
    * Node selector was changed after pods were scheduled
    * Manually created pods matching the selector
    * Delete misscheduled pods or update the selector
  </Accordion>

  <Accordion title="Rolling update taking too long">
    * `maxUnavailable` set too low (default is 1)
    * Pods taking long to become ready
    * Check pod events and logs for startup issues
    * Consider increasing `maxUnavailable` for faster updates
  </Accordion>

  <Accordion title="Pods keep restarting on nodes">
    * Check container logs for crash reasons
    * Verify resource limits aren't too restrictive
    * Check if readiness/liveness probes are misconfigured
    * Ensure required volumes (hostPath, ConfigMaps) exist on nodes
  </Accordion>

  <Accordion title="DaemonSet not running on new nodes">
    * New node may not match node selector
    * New node may have taints
    * Check if DaemonSet controller is healthy
    * Verify the new node is in Ready state
  </Accordion>
</AccordionGroup>

## FAQ

<AccordionGroup>
  <Accordion title="How is a DaemonSet different from a Deployment?">
    **Deployments** run a specified number of replicas scheduled across available nodes. **DaemonSets** run exactly one pod per matching node, automatically adding pods when nodes join and removing them when nodes leave.
  </Accordion>

  <Accordion title="Can I run DaemonSet pods on master/control-plane nodes?">
    Yes, by adding tolerations for control-plane taints. By default, master nodes have `node-role.kubernetes.io/control-plane:NoSchedule` taint.
  </Accordion>

  <Accordion title="How do I limit DaemonSet to specific nodes?">
    Use `nodeSelector` to match nodes with specific labels, or use `nodeAffinity` for more complex selection rules.
  </Accordion>

  <Accordion title="What happens when I add a new node?">
    The DaemonSet controller automatically schedules a pod on the new node if it matches the node selector and the pod tolerates any taints.
  </Accordion>

  <Accordion title="Can I scale a DaemonSet?">
    No. DaemonSets don't have a replica count. The number of pods is determined by the number of matching nodes. To control pod placement, modify the node selector or node labels.
  </Accordion>

  <Accordion title="What's the difference between OnDelete and RollingUpdate?">
    **RollingUpdate** automatically updates pods when the template changes. **OnDelete** only updates pods when they are manually deleted, giving you full control over update timing.
  </Accordion>

  <Accordion title="How do I update pods one node at a time?">
    Use RollingUpdate strategy with `maxUnavailable: 1` (the default). This ensures only one pod is updated at a time across the cluster.
  </Accordion>

  <Accordion title="Why doesn't my DaemonSet have pods on all nodes?">
    Check node selector matches, taint tolerations, and resource availability. Some system DaemonSets intentionally exclude certain node types.
  </Accordion>
</AccordionGroup>