Persistent Storage on OKE

Containers are designed to be ephemeral, but plenty of workloads need data that survives a pod restart. Databases, message queues, content stores and anything that keeps state need persistent storage, and getting that right on OKE means understanding how Kubernetes storage abstractions map onto OCI storage services. Teams that skip this end up with data on ephemeral pod disks that vanishes when a pod moves, which is a painful lesson. This article explains how persistent storage works on OKE and how to use it well.

It is part of our OKE and containers series and pairs with the deeper treatment in OKE for stateful workloads.

The problem persistent storage solves

A pod's own filesystem is ephemeral. When the pod is rescheduled to another node, restarted or replaced during a deployment, anything written to that filesystem is gone. For stateless applications that is fine and even desirable. For anything that holds data, you need storage that exists independently of any single pod, so the data survives the pod and can be reattached wherever the pod runs next. That is what persistent storage provides.

The two OCI storage services behind OKE

OKE persistent storage is backed by two OCI services, and the choice between them depends on how the data is accessed.

Block volumes behave like fast disks attached to a single pod, which is what most databases and single writer workloads want. File storage provides a shared file system that many pods can mount at once, which suits shared content and workloads where several pods read and write the same data. Choosing the wrong one, for example trying to share a block volume across many pods, leads to confusion, so match the service to the access pattern.

How Kubernetes connects to OCI storage

The bridge between Kubernetes and OCI storage is the container storage interface, a standard that lets Kubernetes provision and attach storage from any compliant provider. OKE ships with drivers for both block and file storage, so when a workload asks for persistent storage, Kubernetes provisions it from OCI automatically. You rarely touch the underlying OCI volumes directly. Instead you work through Kubernetes abstractions, which keeps your manifests portable and declarative.

Persistent volume claims and storage classes

Two Kubernetes objects do the work. A storage class describes a kind of storage, for example block volumes with a particular performance tier, and acts as a template. A persistent volume claim is a workload's request for storage of a given class and size. When a claim is made, Kubernetes uses the storage class to provision a matching volume from OCI and binds it to the claim. The workload mounts the claim and uses it like a normal filesystem. This indirection is what lets you change the underlying storage without changing the workload, and it is the everyday interface you will work with.

Running stateful workloads

Persistent storage is necessary for stateful workloads but not sufficient. Stateful applications also need stable identities and ordered, predictable startup, which Kubernetes provides through stateful sets, an object designed for exactly this. A stateful set gives each pod a stable name and its own persistent volume, so a database replica keeps its identity and its data across restarts. Running databases and similar workloads on Kubernetes is genuinely harder than running stateless services, and whether to do it at all is a real decision, explored in OKE for stateful workloads.

Data protection and durability

Persistent does not mean backed up. A persistent volume survives a pod, but it does not protect you against accidental deletion, corruption or the loss of an availability domain. You still need backups of the data and a plan for recovery, using OCI volume backups and, for important data, cross region copies. Designing the data protection around your stateful workloads is part of resilience, and it connects to the disaster recovery thinking covered elsewhere in our journal. Treating the persistent volume as the whole story is a common and dangerous shortcut.

A storage framework

Cost considerations

Storage is a real line on the OKE bill, and it is easy to leave it inflated. Over provisioned volumes, orphaned volumes left behind when workloads are deleted, and storage tiers higher than the workload needs all add cost quietly. Reclaiming orphaned volumes and right sizing storage tiers are straightforward savings, covered alongside compute in OKE cost optimization. Storage that nobody is using still appears on the invoice every month.

Bringing it together

Persistent storage on OKE comes down to choosing between block and file storage based on access pattern, working through persistent volume claims and storage classes rather than raw volumes, using stateful sets for workloads that need identity and state, and remembering that persistent is not the same as backed up. Get those right and stateful workloads run on OKE with their data safe across pod restarts and node moves. Continue with OKE for stateful workloads and OKE cost optimization.

The OCI storage solution and the OKE solution practices design persistent storage for stateful workloads on a fixed project fee.