Persistent Storage for Unaware Container Applications

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Container-based applications running on container orchestration systems, unaware of the orchestration system, face challenges in writing to persistent storage due to the ephemeral nature of pods and the lack of local persistent memory access.

Innovation Solution

Implementing an init container to read from non-local persistent storage, writing data to an empty directory volume, and using a manager sidecar container to monitor changes and update the persistent storage, allowing read/write operations for the application container through the directory volume.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If container-based applications are run on ephemeral pods in a container orchestration system, then application deployment flexibility and scalability are improved, but the ability to perform write operations on persistent storage is lost

Engineering Contradiction:

Improvedeployment flexibilityVSAvoidpersistent storage access

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent introduces an intermediary layer consisting of the orchestration system's storage management components and mount mechanisms. This intermediary translates the application's write operations to ephemeral pod volumes into persistent storage operations, allowing applications to interact with persistent storage without being aware of the underlying ephemeral nature of pods. The intermediary handles the complexity of storage persistence while maintaining application simplicity.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system segments the storage access functionality into separate components: the application container that performs write operations, the orchestration system that manages pod lifecycle and storage mounting, and the persistent storage layer that maintains data across pod restarts. This segmentation allows each component to operate independently with well-defined interfaces, resolving the contradiction between ephemeral pod execution and persistent storage access.

Inventive Principle:

Principle #1Segmentation

2Productivity

If pods are made ephemeral for seamless deployment across environments, then deployment speed and environmental adaptability are improved, but data persistence and state retention are worsened

Engineering Contradiction:

Improvedeployment speedVSAvoiddata persistence

Core Design Contradiction:

ProductivityVSLoss of information

Solution Approach 1:

The orchestration system performs preliminary actions by pre-configuring storage volumes and establishing mount points before pods are created or restarted. Persistent storage is prepared and made available to pods in advance, ensuring that when ephemeral pods are deployed or restarted, they can immediately access their designated persistent storage without data loss. This preliminary setup maintains both rapid deployment and data persistence.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system creates a copy mechanism where data is maintained in the persistent storage layer independently of the ephemeral pod instances. When pods are restarted or moved between environments, the persistent storage contains a copy of the data that can be immediately mounted to the new pod, ensuring data persistence while maintaining deployment flexibility and speed.

Inventive Principle:

Principle #26Copying

3Adaptability or versatility

If applications are made unaware of the orchestration system for portability, then application portability and simplicity are improved, but the ability to leverage orchestration-specific persistent storage features is lost

Engineering Contradiction:

Improveapplication portabilityVSAvoidstorage configuration

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The orchestration system provides self-service storage mounting capabilities where persistent storage volumes are automatically configured, mounted, and managed by the orchestration system itself. Applications remain unaware of the orchestration system and can use standard file I/O operations, while the orchestration system automatically handles the complex storage configuration in the background, making storage as easy to use as local filesystems.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The orchestration system implements a universal storage interface that works consistently across different deployment environments and application types. The same persistent storage mechanisms and mounting procedures work for all applications regardless of whether they are aware of the orchestration system, providing a universal solution that maintains both application portability and ease of storage configuration.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS20240370189A1Method And System For Writeable Persistent Storage For Container Based Applications Unaware of Orchestration System

Publication Date: 2024.11.07 DELL PROD LP

AI summary

Described herein are systems and methods for providing persistent storage for a container based application running on and unaware of a container orchestration system. An empty directory volume is mounted in a pod of the container orchestration system. A read to a persistent storage is performed by an init container of the pod. The persistent storage is not local to the node of the pod. Writing of the read is performed to the empty directory volume. The empty directory volume is to an application container that runs the container based application, allowing read/write operations between the empty directory volume and application container. Monitoring and providing changes is of the empty directory volume is performed to the persistent storage.