Fractal Techware

Alert runbooks /

KubeletPodStartUpLatencyHigh

The kubelet on a node is taking an unusually long time to process pods, so new pods there start slowly.

   
Severity warning
Source kubelet /metrics
Key metric kubelet_pod_worker_duration_seconds_bucket

What it means

For every pod sync, a kubelet pod worker sets up volumes, the network sandbox and containers. The alert watches the slowest of those syncs per node and fires when they stay far above normal for a sustained period.

The visible effect is pods sitting in ContainerCreating or Init for a long time on that node. Rollouts slow down, autoscaling reacts late, and readiness-based traffic shifting lags.

Common causes

First checks

  1. Find the slow nodes and which operation dominates:
    topk(10, histogram_quantile(0.99, sum by (instance, operation_type, le) (rate(kubelet_pod_worker_duration_seconds_bucket{job="kubelet"}[5m]))))
    
  2. Compare end-to-end start times:
    histogram_quantile(0.99, sum by (instance, le) (rate(kubelet_pod_start_duration_seconds_bucket{job="kubelet"}[15m])))
    
  3. Check slow runtime operations such as image pulls:
    topk(5, histogram_quantile(0.99, sum by (instance, operation_type, le) (rate(kubelet_runtime_operations_duration_seconds_bucket{job="kubelet"}[15m]))))
    
  4. Look at events for a slow pod on that node:
    kubectl get pods -A --field-selector spec.nodeName=<node> | grep -v Running
    kubectl describe pod <pod> -n <namespace> | sed -n '/Events/,$p'
    

    Long gaps between Pulling and Pulled, or FailedMount and FailedCreatePodSandBox events, point to the cause.

Fixing it

Use smaller images, a pull-through registry cache or pre-pulled images. Fix the CSI driver or storage backend if mounts are slow. Free IPs or enlarge the pod subnet for CNI failures. If the runtime itself is slow, drain the node and restart containerd and the kubelet.