A fleet adds a new node pool image and later one DaemonSet quietly skips those nodes while remaining healthy elsewhere.
A DaemonSet appears healthy and one node family never gets the agent because the hostPath expected by the pod exists only on the older image lineage
Most nodes run the agent, yet one autoscaled family stays without it because the required host path layout differs across image generations.
Scenario
What to check first
- Identify the primary failure signal in the One Node Image Family Never Matched the Assumed Host Layout scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Compare host filesystem assumptions across node images before editing node selectors or tolerations.
Questions worth viewing together
Community-field Kubernetes problem inspired by community DaemonSet incidents where one node image family lacked the expected hostPath layout. Healthy DaemonSet rollout status can hide image-family-specific host prerequisites.
Teams often blame taints when the missing prerequisite is the hostPath itself.
DaemonSets that rely on hostPath should be validated across every node image family in use.
Similar cases seen in the field