Container-native storage separates an application’s replaceable containers from the data that must remain available. On OpenShift, that means understanding both Kubernetes storage objects and the supported storage service behind them.
Older Red Hat Container-Native Storage deployments used Gluster-based technology. Red Hat’s Gluster Storage lifecycle policy lists December 31, 2024 as that product’s end of life. Treat an older deployment as a migration-planning task, with its exact versions and dependencies recorded, rather than assuming a current storage product is an in-place replacement.
Know what the application requests
A persistent volume (PV) represents storage available to a cluster; a persistent volume claim (PVC) requests storage for a workload. The volume’s lifecycle is separate from an individual pod’s lifecycle. That separation enables persistence, but does not itself guarantee redundancy, backup, or access after every failure. See the Kubernetes persistent-volume documentation for binding and lifecycle behavior.
A StorageClass describes a class of storage and its provisioning parameters. Check its provisioner, binding behavior, expansion support, and reclaim policy. A dynamically provisioned volume may use a Delete reclaim policy: deleting the associated claim can lead to deletion of the backing storage. Confirm the actual policy before any cleanup or migration operation.
Access modes are easy to misread. ReadWriteOnce normally limits read-write mounting to one node; multiple pods on that node can still use the volume. ReadWriteOncePod addresses single-pod access with supported CSI storage. Neither mode is a replacement for a database’s own concurrency and consistency controls.
Match storage semantics to the application
On a small screen, scroll the table sideways to read all columns.
| Interface | Typical fit | Questions that change the decision |
|---|---|---|
| Block storage | An application or filesystem needs a block device, often for a database. | What attachment, filesystem, latency, recovery, and writer rules does the application require? |
| Shared file storage | Several workers need a shared directory tree. | Are locking, permissions, metadata performance, and required access modes supported? |
| Object storage | The application stores objects through an API, such as media or backups. | Does the application support the API and required consistency, versioning, and lifecycle behavior? |
Object storage is not automatically a mounted filesystem, and a shared filesystem does not automatically make a database safe to run with multiple writers. Start from the application’s documented storage requirements, then confirm the platform’s supported configuration.
Red Hat’s OpenShift Data Foundation architecture guide describes internal and external deployment approaches. In broad terms, storage services can run within the OpenShift environment or be supplied by an external storage cluster. This linked edition explains the architecture; use the documentation and compatibility information for the release you actually deploy.
Compare who operates the storage, resource overhead, failure boundaries, connectivity, expansion, and support coverage. “Inside the cluster” can simplify some management while coupling other responsibilities. “External” adds a service boundary that still needs coordinated monitoring, upgrades, and incident response.
Test failure domains and restore behavior
A replica count is meaningful only with placement and failure assumptions. Copies on the same host, rack, power source, or dependent service may fail together. Plan capacity for normal use, growth, recovery work, and the required failure scenario; do not treat nominal raw capacity as usable application capacity.
A snapshot captures a storage point in time under the capabilities of the driver and storage system. Kubernetes volume snapshots use snapshot resources and supporting CSI components. Their existence does not establish that a database was captured consistently or that the copy survives loss of the original storage service.
Define what you need to restore: volume contents, database state, configuration, secrets, object metadata, and the application’s relationship to those records. Use application-aware backup or quiescing where required. Keep recovery copies with appropriate independence, access controls, and retention, then test restoring into a clean environment.
State the acceptable data-loss interval and recovery time in business terms. Measure how long a usable application takes to return, including credentials, DNS or routing changes, validation, and user acceptance. A successful volume restore is only one part of that result.
Build a migration plan from an inventory
Record the source OpenShift and storage versions, storage classes, provisioners, PVCs, access modes, capacities, actual usage, snapshots, encryption and key handling, and application owners. Include cluster services that use the old storage. An overlooked registry, logging component, or supporting database can delay retirement of the source platform.
Choose a supported target and a transfer method appropriate to the data. Depending on the application and available support, that might involve application-level backup and restore, an approved migration tool, or a controlled file/object transfer. Do not assume that copying storage objects or editing a PVC’s class moves the existing data.
Rehearse with representative data. Check ownership, permissions, file counts where meaningful, checksums, object metadata, and application-level consistency. Establish a final synchronization or write-freeze procedure so that new source writes are not lost. Define the moment at which the target becomes authoritative and what happens if validation fails after that point.
Download the storage migration readiness worksheet (plain text). It covers the inventory, support confirmation, consistency plan, rehearsal, cutover, rollback, and retirement evidence.
Fictional readiness example: shared uploads
A service has several pods that share uploaded documents, plus a separate database storing document references. The team first confirms the application’s shared-file requirements and inventories both stores. Copying only the uploaded files would leave the migration incomplete; the database references must describe the same accepted set of documents.
During rehearsal, the team restores files and database data into an isolated target, checks representative downloads and permissions, and measures the complete recovery time. For cutover, it plans how to stop or capture new writes and how to reconcile them before switching traffic. It retains the source under controlled access until the acceptance and rollback conditions are resolved.
The example illustrates the questions a plan must answer. It is not a vendor-supported migration recipe. Confirm the exact source/target combination and application procedure with the responsible support teams before changing a live cluster.