Part 6 · Applications

Storage, state and recovery

Prerequisites: 02-objects, 04-eks-model

06 / Ask for storage, then mount it

A Pod references a PVC, which requests a StorageClass and CSI driver to provision a volume. The resulting PV binds to the PVC and is mounted.

Scroll the diagram sideways for readable labels.

Dynamic provisioning is shown conceptually. Binding may be delayed until scheduling. Fargate has different storage support; persistent storage is not a backup. [S06] [S21] [S29]

A disk can pin a Pod to a zone

An EBS volume in AZ A cannot simply attach to a replacement Pod in AZ B. Data recovery must be planned separately.

Scroll the diagram sideways for readable labels.

Simplified single-volume failure example. EBS attachment topology is not cross-zone database replication. EFS is a shared filesystem option with different semantics. [S39] [S29] [S13]

Learning objective and mechanism verified

A PVC asks for storage; a PV represents allocated storage; a StorageClass describes provisioning policy. A CSI integration connects Kubernetes to the storage system. Pods mount claims. Reclaim policy controls what happens when a claim is released; Pod replacement is a different event from deleting a claim.

[S06]

EKS choices verified

Use EBS integration for supported block-volume workloads and EFS integration when shared filesystem semantics fit. EBS is zonal; align scheduling with volume topology. Auto Mode uses the ebs.csi.eks.amazonaws.com provisioner, distinct from the standard EBS CSI provisioner. Fargate cannot mount EBS and supports EFS static rather than dynamic provisioning.

[S21] [S29] [S39]

Worked example and decision synthesis

In the insurance scenario, keep transaction state in a managed PostgreSQL service and documents in object storage rather than inside disposable API containers. This proposed boundary reduces the database-operator scope of the EKS platform team, but database networking, credentials, migrations, recovery and cost remain explicit responsibilities.

[S25] [S06]

Common pitfall synthesis

A persistent volume is not proof that a database can survive losing a zone. Likewise, copying Kubernetes manifests does not restore transaction data. Define which system owns database backups, document versions and workload configuration, then restore them together in a compatible sequence.

[S06] [S21]

Further improvement synthesis

Specify an acceptable recovery point (RPO: tolerated data loss) and recovery time (RTO: tolerated outage). Rehearse an isolated restore and validate business records, not just that a Pod becomes Running. These are proposed acceptance criteria, not measured outcomes.

[S06] [S22]
Keep this: Persistence, replication and backup solve different failure cases.
Check yourself: Is a Pod rescheduled to another AZ enough to recover an EBS-backed database?

Not by itself. The volume’s zone, data replication or restore strategy, database consistency and available capacity must all be considered.

Sources & further reading

  1. [S06] Persistent volumes

    Kubernetes · documentation · accessed 2026-10-10 · Living documentation; target-cluster compatibility must be checked · Not stated in retrieved page

    Supports: PVC, PV, provisioning and reclaim lifecycle

    Read the linked primary source for implementation details and current constraints.

  2. [S13] Topology spread constraints

    Kubernetes · documentation · accessed 2026-10-10 · Living documentation; target-cluster compatibility must be checked · Not stated in retrieved page

    Supports: Zone and host distribution, strict scheduling constraints

    Read the linked primary source for implementation details and current constraints.

  3. [S21] EBS CSI integration

    AWS · documentation · accessed 2026-10-10 · Living documentation; target-cluster compatibility must be checked · Not stated in retrieved page

    Supports: EBS support limits and different Auto Mode provisioner

    Read the linked primary source for implementation details and current constraints.

  4. [S22] Cluster upgrade best practices

    AWS · documentation · accessed 2026-10-10 · Living documentation; target-cluster compatibility must be checked · Not stated in retrieved page

    Supports: Compatibility, removed APIs, node upgrades and add-on coordination

    Read the linked primary source for implementation details and current constraints.

  5. [S25] Crossuite migration to EKS

    AWS / Crossuite · customer case study · accessed 2026-10-10 · Living documentation; target-cluster compatibility must be checked · Not stated in retrieved page

    Supports: HPA, Karpenter, ALB, RDS PostgreSQL, CloudWatch and reported outcomes

    Read the linked primary source for implementation details and current constraints.

  6. [S29] EFS CSI integration

    AWS · documentation · accessed 2026-10-10 · Living documentation; target-cluster compatibility must be checked · Not stated in retrieved page

    Supports: Shared filesystem integration and Fargate static provisioning constraint

    Read the linked primary source for implementation details and current constraints.

  7. [S39] Amazon EBS volumes

    AWS · documentation · accessed 2026-10-10 · Living documentation; target-cluster compatibility must be checked · Not stated in retrieved page

    Supports: Volumes and attached instances must be in the same Availability Zone

    Read the linked primary source for implementation details and current constraints.