Persistent data must outlive the Pod that uses it
Kubernetes makes applications replaceable by design. Stateful services therefore need a storage lifecycle that remains predictable through rescheduling, node maintenance, upgrades and failures.
Kubernetes objects and the underlying storage system are separate operational layers.
Use the right lifecycle for every data set
Kubernetes separates the application request from the storage resource. That abstraction is useful only when the underlying lifecycle and failure behaviour are understood.
Ephemeral storage
Scratch data, writable container layers, logs and some temporary volumes follow the Pod or node lifecycle.
- Useful for caches and rebuildable working data
- May be lost when a node fails
- Needs requests, limits and capacity monitoring
PersistentVolume
A PV represents storage made available to the cluster. It exists independently from the lifecycle of any individual Pod.
- Can be created statically or dynamically
- Has access modes, capacity and reclaim behaviour
- Still depends on the backend and attachment method
PersistentVolumeClaim
A PVC is the workload request for capacity, access mode and a particular storage class.
- Separates developers from backend details
- Binds to a compatible PV
- Does not by itself guarantee backup or high availability
A StorageClass is only as capable as its provisioner
Pod references a PVC
The application declares storage requirements without selecting a physical disk or target.
StorageClass is selected
It defines a provisioner plus backend-specific parameters and reclaim behaviour.
PV is created or matched
A supported driver or administrator workflow presents and records the actual storage resource.
Node exposes it to the Pod
Attachment, mounting and path recovery must work wherever the workload may be scheduled.
Important: without a suitable provisioner, storage can still be statically presented and represented by pre-created PersistentVolumes. That is an operational model—not dynamic provisioning.
Different services need different access semantics
Predictable block or supported file access
- Write durability and recovery must match the database.
- Access modes and rescheduling behaviour require testing.
- Application-level replication may overlap with storage protection.
A common namespace for several Pods
- NFS can provide shared file access where supported.
- Locking, permissions and concurrent writers matter.
- Metadata performance can dominate small-file workloads.
Use S3 through the application API
- S3 is normally accessed by the application, not mounted as a PV.
- Suitable for artefacts, backups, media and data pipelines.
- Credentials and tenant separation belong in the application design.
Decide what is truly disposable
- Local ephemeral storage may be fastest for rebuildable data.
- Central logs require a separate export and retention path.
- Eviction and node-loss behaviour should be explicit.
Separate storage access from Kubernetes automation
A protocol may be suitable for a node while still requiring a separate driver, provisioner or administrator process to become a Kubernetes volume.
| Access method | Common container role | Potential advantage | Kubernetes integration to validate |
|---|---|---|---|
| NFS | Shared files and ReadWriteMany-style application designs | Familiar shared namespace across nodes | Static PV or supported external provisioner/CSI path, permissions, locking and failover remount behaviour |
| iSCSI | Persistent block volumes for stateful applications | Mature IP block access and broad host support | Qualified node initiator, multipathing, attachment workflow and supported provisioner |
| NVMe-oF | Latency-sensitive block storage where the full host stack supports it | Efficient NVMe access over TCP or RDMA | No native euroNAS Kubernetes provisioning is claimed; qualify attachment, multipathing and the chosen CSI or administrator workflow |
| Ceph-backed services | Scale-out block, file or object storage | Distributed protection and growth across failure domains | Any direct Kubernetes/Ceph integration needs its own supported driver, version matrix and operational validation |
| S3-compatible API | Application objects, repositories, backup and data pipelines | Application-level access without a mounted volume | SDK/CLI compatibility, credentials, endpoint availability and application consistency |
Do not infer a Kubernetes driver from a storage protocol
euroNAS can provide block, file and S3 services that may participate in a Kubernetes architecture. Kubernetes-native dynamic provisioning, snapshots, cloning, expansion and topology awareness depend on the exact CSI driver or provisioner selected for that environment.
Clear scope: this page does not claim a native euroNAS CSI driver, Kubernetes certification or automatic volume provisioning. Any integration layer must be selected, supported and tested independently.
Validate the complete chain
A successful mount is only the first test.
Stateful containers need more than a persistent mount
Keep nodes connected
Redundant links, multipathing and correct time-outs protect the path where the block integration supports them.
Survive a storage node fault
Automatic HA or distributed storage protection addresses a different layer from Pod rescheduling.
Coordinate state
Databases and distributed applications may need quiescing or application-native protection.
Recover earlier data
Retained, independent copies protect against deletion, corruption and wider failure boundaries.
Volume snapshots require explicit support: Kubernetes snapshot objects rely on CSI functionality and do not automatically make every backend snapshot application-consistent or independently recoverable.
Manage Ceph services through guided workflows
eEKAS can provide distributed block, file and S3 services for container platforms and other external consumers. Cluster creation, drives, pools, protection profiles, metadata placement and endpoints are managed through the graphical euroNAS interface.
Use euroNAS products at clearly defined infrastructure layers
These examples describe where storage and virtualisation can fit; they do not prescribe a particular Kubernetes distribution or CSI implementation.
Focused external storage
Block or file services for a compact environment where storage integration and complete-server recovery are handled by the surrounding architecture.
- Suitable for statically managed or independently provisioned storage
- Can be deployed as a physical or Virtual Storage Appliance
- No automatic storage-controller failover within one standalone server
Highly available external storage
Shared storage with automatic local service failover through a synchronous Mirror or dual-controller shared-storage design.
- Multipathing for supported block access
- NFS or block services according to application design
- Separate asynchronous recovery and backup controls remain necessary
Scale-out data services
Distributed block, file and S3 services that scale independently from the Kubernetes compute layer and can serve several consumer groups.
- Ceph protection across defined failure domains
- Replication or erasure coding by workload
- Any direct CSI integration must be independently qualified
Kubernetes nodes as virtual machines
eEVOS can host Kubernetes nodes as virtual machines and provide internal, external shared or Ceph-backed infrastructure according to the cluster design.
- VM high availability and live migration
- Integrated Backup & Disaster Recovery for protected VMs
- Kubernetes application protection still needs its own design
Questions to settle before the first StorageClass
Does the workload need one writer, several readers or concurrent read/write access across nodes?
Will volumes be created statically, through an external provisioner or through a qualified CSI driver?
What happens to attachment, mounting and application state when a Pod moves to another node?
Should data be deleted or retained when a PVC is removed, and who owns the cleanup process?
Which RPO and RTO apply to deletion, application corruption, node failure and site loss?
Which Kubernetes, driver, node OS, application and storage versions are tested together?
Kubernetes storage concepts
Use the current Kubernetes and integration documentation when validating the final deployment.
Persistent Volumes
Official Kubernetes explanation of volumes that outlive individual Pods and the claim-based storage model.
Open Kubernetes documentation →Storage Classes
How administrators describe storage policies, provisioners, reclaim behaviour and binding modes.
Open StorageClass documentation →Ephemeral Volumes
Official guidance for scratch, configuration and temporary storage whose lifecycle follows a Pod.
Open ephemeral storage guidance →Bring the workload and integration plan
We can review access modes, node connectivity, storage protocols, availability, recovery and scale for a business container or Kubernetes environment.