Optimize Container start time with OCI Storage

Containerized applications are transforming the way we build, deploy, and scale software. However, as environments grow, managing large numbers of container images across multiple nodes and users can become increasingly challenging. This is where the concept of additional image stores comes into play—providing a powerful solution for sharing and accessing container images from a centralized, read-only repository.

Additional image stores allow container runtimes like containerd to access container images from one or more read-only, pre-populated locations on shared storage. Instead of pulling images repeatedly from a remote registry, nodes can mount these shared directories—such as an OCI File Storage (FSS) or Lustre volume—and instantly reuse existing image layers. This approach reduces network overhead, speeds up container startup times, and improves efficiency across large, multi-node environments where many containers share the same base images.

In this blog, we’ll showcase the improvements in image pull and container start up times that were observed during testing Additional Image Stores feature in OCI using Oracle Cloud Infrastructure (OCI) shared storage offerings such as File Storage and Lustre.

By leveraging these services as a shared network resource, you can store thousands of container images in a centralized location and make them accessible across your entire infrastructure. This approach not only saves storage space by eliminating redundant image pulls but also simplifies image management and accelerates container startup times.

OCI Deployment Topology

In order to illustrate the performance gains in container pull and start times , the following setup was used 

• Virtual Cloud Network (VCN) includes two main subnets:
  • Public Subnet: Contains a Bastion Virtual Machine (VM) that provides secure external access for administrative purposes.
  • Private Subnet: Hosts multiple VMs which act as container hosts, responsible for running containerized applications.
     
• File System of type OCI File Storage Service
   
• File System of type OCI Lustre

Image Pull Flow

• When a required Docker image is not available locally, the container host VM performs a “Cold Pull” from the remote Docker Hub registry over the Internet via the NAT Gateway. This ensures up-to-date images can be fetched when needed.
   
• For subsequent accesses, the image can be served as a “Warm Pull” directly from the local shared file storage, significantly improving speed and efficiency. This process is routed through a Service Gateway, which securely connects compute resources with Oracle Cloud services without traversing the public Internet.

• This setup avoids repeated external downloads by caching frequently-used images, enabling faster container startup and reducing Internet data transfer costs.

FSS and Lustre Performance Results

Note: The performance measurements shown here are illustrative, based on one-time test runs in a specific OCI setup.

They are presented to demonstrate the general performance improvement trend — the larger the container image, the greater the observed benefit from shared storage.These are not formal benchmarks, averages, or guaranteed performance indicators.Actual results may vary depending on workload, image size, network conditions, and configuration.We recommend users run their own tests in their specific environments to evaluate expected performance gains.

Observations

Using Additional Image Stores (FSS) and OCI File Storage with Lustre can significantly improve container image pull and run times in cloud environments, especially for large images and frequent warm cache scenarios.

​

Performance Highlights

For Alpine (7.7 MB), FSS reduced cold pull time from 1.8s to 1.7s and cold run time from 2.8s to 2.19s, resulting in an 11% speed-up on warm runs.

For Debian (80 MB), FSS pulled images up to 60% faster in warm cache, decreasing cold pull time from 3.85s to 1.53s, and cold run time from 4.34s to 2.51s (42% speed-up on warm runs).

With Python 3.12 (1.3 GB), FSS improved warm pull speeds by 89% and warm run speeds by 84x% (cold pull: 24.03s, warm pull: 2.51s; cold run: 30.78s, warm run: 4.82s).

Lustre Results

• Lustre also shows major speed improvements. For Alpine, cold pull was 1.9s (vs. 1.8s FSS), but warm pull was even faster at 1.4s for a 25x speed-up. Run times improved similarly, with warm runs up to 40x faster than cold.
•   Larger images benefit most: For Python 3.12 (1.3 GB), Lustre’s cold pull was 28.99s and warm pull just 2.29s (92% faster); cold run was 31.34s, warm run 4.29s (85% speed-up).

Key Takeaways

• Both FSS and Lustre drastically reduce container image fetch and execution times on repeat accesses.
• Larger images see the biggest speed-ups on warm cache.
• OCI Lustre offers even faster warm pulls for large images than FSS, making it ideal for high-performance workloads.

Conclusion

In summary, leveraging Additional image stores with OCI File Storage delivers substantial performance improvements for containerized workloads. By centralizing and sharing images from a read-only OCI File Storage mount, you eliminate redundant downloads

Experience faster performance and greater flexibility—try OCI File Storage and Lustre today for your cloud workloads. Both solutions deliver impressive speed-up for image pulls and container start times, making them ideal for large scale shared storage needs. Unlock the power of efficient, scalable file storage and see the difference for yourself

You can easily create a file system from the OCI Cloud Console, Terraform, CLI or APIs. For more detailed technical information, consult the File Storage with Lustre documentation and OCI File Storage Service or reach out to OCI to discuss your file systems and performance requirements.