How to fix DaemonSet pod not ready, readiness probe failing in Kubernetes

KubernetesINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 144 views

DaemonSet pods fail readiness checks due to liveness/readiness probe misconfiguration, application startup delays, or resource constraints. Fix by adjusting probe parameters, increasing initialDelaySeconds, or fixing the underlying application issue.

Quick fix

Fixes DAEMONSET_NOT_READY

# Get DaemonSet YAML:
kubectl get daemonset -n <namespace> <name> -o yaml

# Look for readinessProbe and livenessProbe:
kubectl get daemonset -n <namespace> <name> -o yaml | grep -A 10 "readinessProbe\|livenessProbe"

# Check exact probe settings:
# - initialDelaySeconds
# - timeoutSeconds
# - periodSeconds
# - failureThreshold
  1. Check probe configuration
  2. Check pod logs for readiness probe failures
  3. Increase initialDelaySeconds
  4. Increase timeoutSeconds and failureThreshold
kubernetes — error
# Get DaemonSet YAML:
kubectl get daemonset -n <namespace> <name> -o yaml
# Look for readinessProbe and livenessProbe:
kubectl get daemonset -n <namespace> <name> -o yaml | grep -A 10 "readinessProbe\|livenessProbe"
# Check exact probe settings:
# - initialDelaySeconds
# - timeoutSeconds
# - periodSeconds
# - failureThreshold
DaemonSet pod not ready, readiness probe failing

What this error means

A DaemonSet pod that's Running but not Ready means: 1. Pod container is actually executing 2. Readiness or liveness probe is failing 3. kubelet marks pod as NotReady For DaemonSets, this is particularly problematic because: - Traffic doesn't get routed to the pod (if it's a service) - Dependent components think the pod is broken - Orchestration tools see the DaemonSet as unhealthy Unlike Deployments which can over-provision replicas, DaemonSets must have at least one pod per node, so NotReady pods leave gaps in coverage.

Typical symptoms

  • Pod shows 0/1 in Ready column (Running but not ready)
  • kubectl get pods shows ContainerReady=False
  • Readiness probe logs show repeated failures
  • Application is actually working but marked as not ready
  • kubectl logs show the application started successfully
  • kubectl exec into pod shows process is running
  • DaemonSet shows fewer ready replicas than desired

Common causes

  1. Readiness probe timeout too short for slow startup
  2. initialDelaySeconds too short (probe starts before app is ready)
  3. Readiness probe failure threshold too low
  4. Application not listening on probe endpoint yet
  5. Probe endpoint requires external dependencies (database, etc.)
  6. Network issues between kubelet and probe endpoint
  7. Resource constraints slowing down application startup

How to fix "DaemonSet pod not ready, readiness probe failing"

1Check probe configuration

View the current probe configuration:

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

# Look for readinessProbe and livenessProbe:
kubectl get daemonset -n <namespace> <name> -o yaml | grep -A 10 "readinessProbe\|livenessProbe"

# Check exact probe settings:
# - initialDelaySeconds
# - timeoutSeconds
# - periodSeconds
# - failureThreshold
2Check pod logs for readiness probe failures

Examine what's happening when probe fails:

bash
# Check pod logs:
kubectl logs -n <namespace> <pod-name>

# Check probe endpoint directly:
kubectl exec -n <namespace> <pod-name> -- curl -v http://localhost:8080/health

# Check application startup time:
kubectl logs -n <namespace> <pod-name> | head -20

# Look for how long app takes to be ready
3Increase initialDelaySeconds

Give the application more time to start:

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

Update the readiness probe:

yaml
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60    # Increased from 10
  timeoutSeconds: 5
  periodSeconds: 10
  failureThreshold: 3

New pods will apply these settings:

bash
# Force rollout:
kubectl rollout restart daemonset -n <namespace> <name>
4Increase timeoutSeconds and failureThreshold

Allow more time for probe endpoint to respond:

yaml
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  timeoutSeconds: 10        # Increased from 1
  periodSeconds: 10
  failureThreshold: 5       # Increased from 3

This gives the app 10 seconds to respond, and requires 5 consecutive failures before marking NotReady.

5Test the probe endpoint manually

Verify the probe endpoint works:

bash
# Get pod IP:
kubectl get pod -n <namespace> <pod-name> -o jsonpath='{.status.podIP}'

# Test endpoint from another pod:
kubectl run debug --rm -it --image=alpine -- sh
# Inside pod:
apk add curl
curl -v http://<pod-ip>:8080/health

# Or exec directly:
kubectl exec -n <namespace> <pod-name> -- curl -v http://localhost:8080/health

# Check response code - should be 200

If endpoint returns non-200, the application isn't actually ready.

6Check for resource constraints

Verify the pod has enough resources:

bash
# Check resource limits:
kubectl describe pod -n <namespace> <pod-name> | grep -A 3 "Limits\|Requests"

# Check if pod is hitting limits:
kubectl top pod -n <namespace> <pod-name>

# Check node for resource pressure:
kubectl describe node <node-name> | grep -A 5 "Allocated resources\|Conditions"

# If resources are tight, increase limits:
kubectl edit daemonset -n <namespace> <name>

Insufficient CPU/memory can slow startup significantly.

7Fix application startup issues

If the application itself is broken:

bash
# Check application logs for errors:
kubectl logs -n <namespace> <pod-name> --previous  # If pod crashed and restarted

# Common issues:
# - Missing environment variables
# - Database connection failures
# - Configuration loading errors
# - Port already in use

# Set/verify environment variables:
kubectl get daemonset -n <namespace> <name> -o yaml | grep -A 10 env:

# Check if port is already in use:
kubectl exec -n <namespace> <pod-name> -- netstat -tlnp | grep 8080

Fix the application issues, then redeploy.

8Verify probe configuration after changes

After making changes, confirm the fix:

bash
# Watch pod transitions:
kubectl get pods -n <namespace> -w | grep <pod-name>

# Check if pod becomes Ready:
kubectl get pods -n <namespace> <pod-name> -o wide

# Monitor probe results in events:
kubectl describe pod -n <namespace> <pod-name> | tail -20

# Once ready, verify all DaemonSet pods are ready:
kubectl get daemonset -n <namespace> <name>
# READY column should show N/N where N is number of nodes

Advanced notes

### Probe Types and Defaults

Kubernetes supports three probe types:
- httpGet: HTTP request (most common for web apps)
- tcpSocket: TCP connection check
- exec: Run command in container

yaml
# httpGet example:
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
    scheme: HTTP

# tcpSocket example:
readinessProbe:
  tcpSocket:
    port: 3306

# exec example:
readinessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - redis-cli ping

### Liveness vs Readiness

- Liveness: Is the container still alive? Restart if fails
- Readiness: Can the container handle traffic? Remove from service if fails

For DaemonSets (not usually in a service), readiness is less critical than for Deployments.

### Debug Configuration

For debugging, temporarily disable readiness probe:

yaml
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 999999  # Effectively disabled

This lets the pod be marked Ready while you debug the actual issue.

### Startup Probe (Kubernetes 1.18+)

For very slow-starting applications:

yaml
startupProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 30  # 30 * 10s = 5 minutes max startup
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5

Startup probe gates readiness probe—gives app time to start.

### Typical Probe Values

For different application types:
- Fast startup (1-5s): initialDelaySeconds=10, timeoutSeconds=1
- Moderate startup (10-30s): initialDelaySeconds=30, timeoutSeconds=5
- Slow startup (30-60s): initialDelaySeconds=60, timeoutSeconds=10

### Connection Refused Errors

If probe gets "connection refused":
1. Pod might not be listening yet
2. Port in probe config might be wrong
3. Application might be listening on different interface

Frequently asked questions

What does "DAEMONSET_NOT_READY" mean?
A DaemonSet pod that's Running but not Ready means: 1. Pod container is actually executing 2. Readiness or liveness probe is failing 3.
How do I fix "DAEMONSET_NOT_READY"?
DaemonSet pods fail readiness checks due to liveness/readiness probe misconfiguration, application startup delays, or resource constraints. Fix by adjusting probe parameters, increasing initialDelaySeconds, or fixing the underlying application issue.
What causes "DAEMONSET_NOT_READY"?
Readiness probe timeout too short for slow startup initialDelaySeconds too short (probe starts before app is ready) Readiness probe failure threshold too low
Is the "DAEMONSET_NOT_READY" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading