How to fix DaemonSet rollout stuck, pod not rolling to new template in Kubernetes

KubernetesADVANCEDHIGHUpdated Dec 6, 2025· 175 views

DaemonSet rolling updates get stuck when new pods can't be scheduled, are crashing, or old pods won't terminate. Fix by debugging pod failures, freeing node resources, fixing the new template, or manually rolling out the update.

Quick fix

Fixes DAEMONSET_ROLLOUT_STUCK

# Check rollout status:
kubectl rollout status daemonset -n <namespace> <name>

# Get full DaemonSet details:
kubectl describe daemonset -n <namespace> <name> | tail -30

# Check which nodes are updated:
kubectl get pods -n <namespace> -l <label> -o wide | grep <daemonset>

# Look for status conditions
kubectl get daemonset -n <namespace> <name> -o yaml | grep -A 10 status:
  1. Check DaemonSet rollout status
  2. Check new pod template for errors
  3. Debug failing pods
  4. Check node resources
kubernetes — error
# Check rollout status:
kubectl rollout status daemonset -n <namespace> <name>
# Get full DaemonSet details:
kubectl describe daemonset -n <namespace> <name> | tail -30
# Check which nodes are updated:
kubectl get pods -n <namespace> -l <label> -o wide | grep <daemonset>
# Look for status conditions
kubectl get daemonset -n <namespace> <name> -o yaml | grep -A 10 status:
DaemonSet rollout stuck, pod not rolling to new template

What this error means

DaemonSet rolling updates update one pod per node at a time (respecting maxUnavailable). When an update gets stuck, it means: 1. The DaemonSet controller is trying to create a pod with the new template 2. The pod either can't be created, stays unready, or crashes 3. The controller won't proceed to the next node until the current pod is healthy Unlike deployments where you can leave failed pods, DaemonSets must maintain pod presence on each node, so a single broken pod blocks the entire rollout.

Typical symptoms

  • kubectl rollout status shows 'waiting for' but never progresses
  • Some nodes have old pods, others have new pods
  • New pods stay in Pending or CrashLoopBackOff
  • Update hasn't progressed for hours
  • kubectl describe daemonset shows old version in DesiredTemplate
  • Only 1-2 nodes updated, then it stops
  • Events show 'pod failed to be scheduled'

Common causes

  1. New pod template has a bug (image doesn't exist, wrong config)
  2. Node resource exhaustion preventing new pod creation
  3. Broken container image in new template
  4. Readiness probe failing for new pods
  5. Insufficient node resources (CPU, memory, disk)
  6. minReadySeconds set too high, old pods terminating slowly
  7. maxUnavailable=0 blocking new pod scheduling

How to fix "DaemonSet rollout stuck, pod not rolling to new template"

1Check DaemonSet rollout status

Get detailed rollout information:

bash
# Check rollout status:
kubectl rollout status daemonset -n <namespace> <name>

# Get full DaemonSet details:
kubectl describe daemonset -n <namespace> <name> | tail -30

# Check which nodes are updated:
kubectl get pods -n <namespace> -l <label> -o wide | grep <daemonset>

# Look for status conditions
kubectl get daemonset -n <namespace> <name> -o yaml | grep -A 10 status:
2Check new pod template for errors

Verify the new template is correct:

bash
# Get current DaemonSet definition:
kubectl get daemonset -n <namespace> <name> -o yaml > current.yaml

# Check image:
cat current.yaml | grep image:

# Check if image exists and is accessible:
kubectl run -it --rm debug --image=<new-image> -- echo "Image works"

# Check pod spec for obvious errors:
kubectl get daemonset -n <namespace> <name> -o json | jq .spec.template.spec
3Debug failing pods

Examine why new pods are failing:

bash
# Find a new pod that's stuck:
kubectl get pods -n <namespace> -l <label> -o wide

# Check pod status:
kubectl describe pod -n <namespace> <new-pod-name>

# Check logs:
kubectl logs -n <namespace> <new-pod-name> --all-containers=true

# If pod is crashing:
kubectl logs -n <namespace> <new-pod-name> --previous

# Check events for specific errors:
kubectl describe pod -n <namespace> <new-pod-name> | grep -A 20 Events:

The error message will show the exact problem.

4Check node resources

Verify nodes have capacity for new pods:

bash
# Check all node resource status:
kubectl top nodes

# Detailed view of a specific node:
kubectl describe node <node-name>

# Check for resource pressure conditions:
kubectl get nodes -o json | jq '.items[] | {name:.metadata.name, conditions:.status.conditions[]}'

# If node is under pressure, free resources:
# - Drain and evict non-critical pods
# - Increase node size
# - Use cluster autoscaler to add nodes
5Fix broken image or template

If the new template has errors, fix and redeploy:

bash
# Option 1: Rollback to previous version
kubectl rollout undo daemonset -n <namespace> <name>

# Option 2: Fix template and update
kubectl set image daemonset/<name> <container>=<new-image> -n <namespace>

# Option 3: Edit YAML directly
kubectl edit daemonset -n <namespace> <name>
# Fix the image or config, save and exit

# Verify the fix works:
kubectl rollout status daemonset -n <namespace> <name>

After the fix, rollout should proceed.

6Adjust maxUnavailable if needed

If maxUnavailable=0, allow temporary unavailability:

bash
kubectl edit daemonset -n <namespace> <name>

Update updateStrategy:

yaml
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1  # Allow 1 pod unavailable per node during update

This lets the old pod terminate before the new one must be ready.

7Manually force update on stuck node

If one node is stuck, manually update it:

bash
# Find the stuck node:
kubectl get pods -n <namespace> -o wide | grep <old-image>

# Delete the old pod (forces DaemonSet to recreate it):
kubectl delete pod -n <namespace> <old-pod-name>

# Watch the new pod creation:
kubectl get pods -n <namespace> -w

# Wait for it to be Ready, then continue:
kubectl rollout status daemonset -n <namespace> <name>

The DaemonSet controller will schedule a new pod with the new template.

8Verify rollout completion

Confirm all nodes are updated:

bash
# Check rollout is complete:
kubectl rollout status daemonset -n <namespace> <name>

# Verify all pods have new image:
kubectl get pods -n <namespace> -l <label> -o wide --sort-by=.spec.containers[0].image

# Check DaemonSet metrics:
kubectl get daemonset -n <namespace> <name>
# Desired, Current, Ready should all match

# All pods should show the new image in 'IMAGE' column

If complete, rollout succeeded.

Advanced notes

### UpdateStrategy Options

Two strategies exist for DaemonSet updates:
- RollingUpdate: Gradual replacement (default)
- OnDelete: Only update when pod is manually deleted

yaml
updateStrategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1

### minReadySeconds Impact

yaml
minReadySeconds: 300  # Pod must be Ready for 5 minutes before proceeding

High values slow updates. Typical values:
- 0: No wait (default)
- 10: Ensure pod is stable
- 30-60: For stateful DaemonSets

### Common Template Mistakes

1. Wrong image registry: Image pull fails
2. Missing environment variables: App won't start
3. Port changes: Readiness probe fails
4. Security context: Permission denied errors
5. ResourceLimits too low: OOMKilled or CPU throttled

### Rollback vs Forward Fix

If rollout is stuck:
- Rollback: kubectl rollout undo daemonset <name>
- Forward fix: Update template and reapply

Rollback is faster if the old version works. Forward fix if the old version is also broken.

### Monitoring Rollout Progress

bash
# Watch updates as they happen:
kubectl get daemonset -n <namespace> -w

# Track pod updates per node:
watch kubectl get pods -n <namespace> -o wide | grep <daemonset>

# Use events to see what's happening:
kubectl get events -n <namespace> --sort-by='.lastTimestamp' | tail -20

### Performance Tuning

For faster rollouts on large clusters:

yaml
updateStrategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 5  # Update 5 nodes in parallel
minReadySeconds: 10    # Reduced from 30

Balance speed against stability—too aggressive can cause cascading failures.

Frequently asked questions

What does "DAEMONSET_ROLLOUT_STUCK" mean?
DaemonSet rolling updates update one pod per node at a time (respecting maxUnavailable). When an update gets stuck, it means: 1. The DaemonSet controller is trying to create a pod with the new template 2.
How do I fix "DAEMONSET_ROLLOUT_STUCK"?
DaemonSet rolling updates get stuck when new pods can't be scheduled, are crashing, or old pods won't terminate. Fix by debugging pod failures, freeing node resources, fixing the new template, or manually rolling out the update.
What causes "DAEMONSET_ROLLOUT_STUCK"?
New pod template has a bug (image doesn't exist, wrong config) Node resource exhaustion preventing new pod creation Broken container image in new template
Is the "DAEMONSET_ROLLOUT_STUCK" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading