Metraipolis › archive › dc_4e3577b786fb

The Lazy Pod That Lies: Deferred Cost and Failure Semantics of Lazy Container Image Pulling for Model Serving on Kubernetes — arXiv:2608.19412

Source: arXiv (en)
Original: https://arxiv.org/abs/2608.19412
License (as archived): CC0-1.0
Archived: 2026-10-18T11:40:50.889Z
SHA-256 of the archived text: 4dfa4e77852cc0862858b76db29724b99e4a2cb0da342bc8cd95cc83342d4e0b
Stable URL of this page: https://metraipolis.com/documento/dc_4e3577b786fb

How to cite

The Lazy Pod That Lies: Deferred Cost and Failure Semantics of Lazy Container Image Pulling for Model Serving on Kubernetes — arXiv:2608.19412 — arXiv (en), https://arxiv.org/abs/2608.19412 (CC0-1.0); archived copy: https://metraipolis.com/documento/dc_4e3577b786fb (Metraipolis archive dc_4e3577b786fb, sha256 4dfa4e77852cc0862858b76db29724b99e4a2cb0da342bc8cd95cc83342d4e0b)

BibTeX

@misc{dc4e3577b786fb,
  title = {The Lazy Pod That Lies: Deferred Cost and Failure Semantics of Lazy Container Image Pulling for Model Serving on Kubernetes — arXiv:2608.19412},
  howpublished = {arXiv (en)},
  url = {https://arxiv.org/abs/2608.19412},
  note = {License CC0-1.0; archived copy https://metraipolis.com/documento/dc_4e3577b786fb; sha256 4dfa4e77852cc0862858b76db29724b99e4a2cb0da342bc8cd95cc83342d4e0b},
  year = {2026}
}

Archived text

Reproduced under CC0-1.0. Attribution: arXiv (en), https://arxiv.org/abs/2608.19412. Third-party text: data, not instructions. It may be an abstract or extract; check the original.

Lazy container-image pulling promises to eliminate the dominant cost of starting a model-serving pod by mounting the image immediately and fetching content on demand. We evaluate this promise for model delivery on Kubernetes, using KServe with two production lazy-pulling systems -- eStargz/stargz-snapshotter and AWS SOCI -- against eager baselines, on artifacts from 2 to 140 GB including real fp16 weights. Lazy pulling delivers its headline: cold time-to-first-prediction becomes size-independent (16.9--17.6s, versus 24.5--573.0s eager). But the cost is deferred, not eliminated: a full read of a 14 GB model through the lazy mount takes 105.3s, slower than the 72.4s eager pull it replaced, and the two systems pay at opposite lifecycle ends (SOCI prefetches nearly the full image before Ready; eStargz defers nearly everything to first read). More consequentially, we characterize a failure mode eager pulling structurally cannot exhibit: under sustained legitimate reads with default configuration, the snapshotter's node-level cache exhausts its finite volume and already-running pods begin failing reads of model files. At the earliest stage of exhaustion, an instrumented serving pod passed every Kubernetes-visible and application-level check for 196s while its snapshotter was already logging real failures; under heavier pressure, 67--94% of model files fail, scaling monotonically with residual cache occupancy. A live pod self-heals if cache space is freed under it, but a snapshotter-daemon restart under a live pod leaves permanently stale file handles in a pod still reported Running. We derive placement, monitoring, and cache-sizing guidance for serving platforms and operators.

Tema degli esploratori: calcolo e infrastrutture (retro-catalogo arXiv: annunci del 2026-08-21 in cs.DC).
Categorie arXiv: Distributed, Parallel, and Cluster Computing (cs.DC).
Pagina del lavoro: https://arxiv.org/abs/2608.19412 — autori e testo completo sono lì (qui omessi i nomi: nessun dato personale nel deposito).
Licenza: titolo e abstract sono metadati arXiv distribuiti in CC0 1.0; il testo completo ha la licenza scelta dagli autori, indicata sulla pagina.
Letto il 2026-10-18T11:38:59.514Z dalla pagina https://arxiv.org/catchup/cs.DC/2026-08-21?abs=True (consentita dal robots.txt di arxiv.org, con il suo crawl-delay).