A CustomRun connects Tekton to disposable macOS VMs, but choosing that integration means owning results, retries and cleanup after Tekton stops waiting, with runner integrations offering another…
A fresh, pre-booted macOS VM cuts startup from 26s to 4.7s, including a similar saving through Tekton, at the cost of one VM slot and about 10 GiB of combined VM process RSS.
A macOS build can run twice after an agent restart, and Tekton can time out before its VM is deleted. Recovery needs durable results, one retry owner and independent cleanup.
A host journal tracks macOS build outcomes separately from VM deletion, with seven pipeline runs covering success, failure, cancellation and environment rejection before cloning.
Source and artifacts move between Tekton and a macOS VM through an OCI registry, with digest checks that caught an empty archive copied from a successful compilation.
A Tekton CustomRun delegates builds to a macOS VM, with the controller tracking build results and waiting for confirmed VM deletion on normal completion.
A private EKS cluster drives macOS builds on a local Mac without inbound access, using an outbound SSM tunnel and disposable VMs.
A Go controller switches an approved Kubernetes webhook to Ignore after repeated failures and restores its policy after recovery. Admission continues, but requests still pay the webhook timeout.
A mutating webhook gives a Tekton build step and Docker-in-Docker sidecar one Pod-level resource budget, then verifies the limits in node cgroups.
An out-of-tree kube-scheduler plugin that reserves node capacity across a Tekton PipelineRun's full lifetime, closing a gap none of Tekton's own coschedule modes cover on their own.
Closing the series: what six parts proved, the two scaling questions still untested, and the remaining exec-probe and production-kernel boundaries.
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.
How the profiler retains pod-startup evidence after deletion, verified by reconstructing a deleted three-pod Tekton PipelineRun with `--timeline`.
Implementing and validating node-local disk-I/O prioritization for Kubernetes Pods with cgroup v2 io.weight.
How the CLI resolves pod owners and phases, the eBPF tracer captures syscall evidence, and the exporter joins both into a verified startup timeline.
A design for retaining pod-startup evidence after deletion by putting Kubernetes lifecycle records and eBPF syscall observations on the same time axis.
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 Tekton dind sidecar borrows the step container's cgroup as dockerd's --cgroup-parent, placing the containers it creates under the step's memory limit.
Why slow Kubernetes pod startups undermine autoscaling, CI/CD, and incident response, and why Events and kubelet telemetry cannot identify the delayed phase.