Introduction
backedblock.io is block storage for Kubernetes that keeps its capacity in object storage. A volume's blocks live in S3; its working set is served from a write-back cache on local disks; pods attach over NVMe-oF/TCP and see an ordinary block device.
Most workloads never need all of a disk at once. A database's working set — the pages it reads and rewrites — is a fraction of the volume it sits on, and the rest is data that was written once and is asked for rarely, if ever. Provisioned block storage prices both the same: every gigabyte costs the fast tier's rate, whether it is hot or has not been touched in months.
Splitting the two is where the saving is. Serve the working set from a device built for latency — EBS — and keep the bulk in object storage, where the same gigabyte costs a fraction as much. Do that split well enough and the capacity is priced like S3 while the I/O a workload actually issues is served at block-device speed.
Doing that by hand is not an option for most software, though. Databases, queues and filesystems are written against a block device, not an object store; they expect a disk. So backedblock.io does the tiering underneath and exposes the result through the block API: capacity in the bucket, the working set on fast local disks, and a device that behaves like any other. There is nothing to port and no compatibility layer to work around — a volume is used the way an EBS volume is used.
Why you would use it
Object storage economics, with the latency of a standard block device. Capacity comes from the bucket and is thin-provisioned, so you pay for the bytes actually written rather than for the size declared, and the local disks only have to hold the working set. That working set is what a pod's reads and writes land on, so the latency it sees is a local disk's. And it stays an ordinary block device throughout: filesystems, databases and raw devices work as they do on any other volume, with nothing in the application aware of where the blocks end up.
What does backedblock.io do?
It is a CSI driver in front of a storage cluster that runs the data path. Each
volume is presented as an NVMe-oF/TCP target, its writes are absorbed into a
write-back cache on local disk, and the durable copy of every block is kept in
an S3 bucket as a 1 MiB object. A pod gets /dev/nvmeXnY and a filesystem on
top of it — no S3 API, no object-storage semantics leaking into the
application.
Next
Installing is two steps, in order:
- Deploy the storage cluster — Terraform on AWS, one pool or a fleet.
- Install the driver and provision a volume — Helm, a PVC, a pod.