
Pod Startup Forensics: The Problem
Why slow Kubernetes pod startups undermine autoscaling, CI/CD, and incident response, and why Events and kubelet telemetry cannot identify the delayed phase.
Series · 7 posts
A 5-part series diagnosing what actually makes Kubernetes pod startup slow, going past kubectl events and kubelet SLI metrics to trace which pod, which phase, and why.

Why slow Kubernetes pod startups undermine autoscaling, CI/CD, and incident response, and why Events and kubelet telemetry cannot identify the delayed phase.

Why existing eBPF tools, continuous profilers, and APM platforms can't provide a durable pod-startup timeline that joins lifecycle records to kernel evidence.

A design for retaining pod-startup evidence after deletion by putting Kubernetes lifecycle records and eBPF syscall observations on the same time axis.

How the CLI resolves pod owners and phases, the eBPF tracer captures syscall evidence, and the exporter joins both into a verified startup timeline.

How the profiler retains pod-startup evidence after deletion, verified by reconstructing a deleted three-pod Tekton PipelineRun with `--timeline`.

Correlating socket syscalls and kubelet probe attempts into the merged timeline, then fixing a real cgroup-attribution bug that left most of those events unresolved.

Closing the series: what six parts proved, the two scaling questions still untested, and the remaining exec-probe and production-kernel boundaries.