Gitea Actions Rust builds appeared extremely slow and a Gitea runner pod was evicted. Investigation showed this was not primarily caused by runner CPU throttling: both Gitea runner deployments have no CPU limits and runner.capacity: 1, and live BuildKit/Rust builds were able to consume multiple cores. The immediate operational fault was node ephemeral-storage pressure on the single Kubernetes node.
drg-k8s.auth.home.lan.ephemeral-storage; available space was about 38 GiB with kubelet threshold about 40 GiB./dev/sda2 252 GiB total, 184 GiB used, 56 GiB available..autocoder/worktrees was 106 GiB, mostly stale AutoCoder issue worktrees.workspace-cleanup CronJob manifest was not deployed and is too broad as written because it can remove repository directories under /workspace/repos, not only stale worktrees./home/ax_julian/temp/rust-build-disk-cleanup-20260509./home/ax_julian/temp/rust-build-disk-cleanup-20260509/pre-cleanup-audit.log.issue-* worktree directories under /opt/local-path-provisioner/.../autocoder-workspace-pvc/.autocoder/worktrees using low-priority ionice/nice deletion.gitea-act-runner-2-79b6746994-qg2cp; the replacement runner pod was already running./home/ax_julian/temp/rust-build-disk-cleanup-20260509/post-cleanup-verification.log.#2237 (Add targeted stale worktree cleanup to prevent Kubernetes disk pressure)./dev/sda2 252 GiB total, 105 GiB used, 135 GiB available..autocoder/worktrees after cleanup: 22 GiB.DiskPressure: False.Running with both containers ready.Do not increase Gitea runner concurrency or pod CPU limits as the first fix. The runners were not CPU-limited by Kubernetes, and extra concurrent Rust builds on this single node can make individual builds slower. The durable fix is to control AutoCoder workspace growth and preserve host disk headroom.
Recommended follow-up: