Boost Serverless Pod Creation Speed on Kubernetes: Practical Optimizations

Background

Serverless computing runs on top of Kubernetes, which provides the underlying container orchestration. While the model abstracts away servers, the elasticity of the platform depends heavily on how quickly pods can be created and upgraded.

Pod Creation Workflow

When a pod creation request arrives, the scheduler selects a node, then the node pulls the required container image, which involves downloading the image layers and decompressing them before the container can start. Two common business scenarios trigger pod creation:

Initial application deployment – scheduling followed by pod creation on a selected node.

Application upgrade – repeated creation of new pods and deletion of old ones.

Both scenarios suffer from high latency when image pull and decompression dominate the total time.

Identified Bottlenecks

Measurements on two images (golang:1.10 ~248 MB and Hadoop namenode ~506 MB) showed that image decompression can account for up to 77 % of the total pull time, while download and decompression each contribute roughly 40 %–60 % for larger images.

Optimization Techniques

1. Image Pre‑warming

Pre‑pull images on nodes before scheduling so that the pod creation path no longer includes the pull step. This can be done globally on all nodes or lazily after the scheduler selects a target node.

2. Faster Decompression

Replace the single‑threaded gzip/gunzip with the multithreaded pigz/unpigz pair. Containerd from version 1.2 supports unpigz, allowing parallel decompression on multi‑core nodes.

Adjust Docker daemon concurrency parameters --max-concurrent-downloads and --max-concurrent-uploads (default 3 and 5) to match the cluster’s bandwidth.

3. Non‑Compressed Images

When the internal network is fast, the compression step can be omitted. By disabling gzip during docker push, the subsequent docker pull skips decompression, reducing total pull time by roughly 30 %–50 % in tests.

4. P2P Image Distribution (DragonFly)

In large clusters, the central image registry becomes a bottleneck. A peer‑to‑peer system such as CNCF’s DragonFly introduces three components:

ClusterManager – a super‑node acting as tracker, scheduler, and cache.

Dfget – client on each node that also serves cached layers to peers.

Dfdaemon – transparent proxy for Docker daemon requests, routing them through Dfget.

This design spreads download traffic across all nodes, leveraging internal bandwidth.

5. On‑Demand Image Loading (stargz)

Typical .tar.gz images must be fully downloaded before any file can be read. The stargz format adds an index, enabling HTTP range requests to fetch only the needed files during container start‑up.

Implementing a remote snapshotter in containerd that understands stargz allows containers to start after pulling just the required layers.

In‑Place Upgrade

For image‑only upgrades, Kubernetes patching can replace the container image without recreating the pod. Combining this with readinessGates and the OpenKruise CloneSet controller enables zero‑downtime upgrades.

Conclusion

By analyzing the pod creation pipeline and applying targeted optimizations—image pre‑warming, multithreaded decompression, optional compression, P2P distribution, on‑demand loading, and in‑place upgrades—teams can significantly reduce latency, improve elasticity, and meet the performance expectations of serverless workloads on Kubernetes.