Piraeus gives Kubernetes a replicated block storage layer without a storage vendor

A glue project between Kubernetes and LINSTOR

Piraeus is described as a high performance, highly-available, simple, secure and cloud agnostic storage solution for Kubernetes, and the README is unusually candid about what it is. Piraeus Datastore is mainly a glue project that connects LINSTOR and DRBD to Kubernetes. That sentence tells you where the complexity lives. The upstream project says the same thing: nearly every component of Piraeus was created by others and made freely available to the public. The repository itself is correspondingly thin. The top-level entries are the README, a LICENSE, GOVERNANCE.md and MAINTAINERS.md, a CODE_OF_CONDUCT.md and CONTRIBUTING.md, an ADOPTERS.md, a dockerfiles directory, an artwork directory and a legacy directory. There is no source tree of consequence, because the source lives in the component repositories. The primary language is recorded as Shell, which is consistent with a repository that mostly holds manifests, scripts and documentation. The licence is Apache 2.0 and Piraeus is a CNCF Sandbox Project, which is the least mature of the CNCF maturity levels.

The five components and what each one does

The project list in the README names five pieces, and they divide into two controllers, one driver and two upstream storage components. The Kubernetes Operator creates, configures and maintains all components of Piraeus, and it lives in the piraeus-operator repository. The CSI Driver provisions persistent volumes and volume snapshots on the storage cluster maintained by Piraeus, and it lives in the linstor-csi repository. The High Availability Controller speeds up the failover process of stateful workloads, in piraeus-ha-controller. The Volume Affinity Controller keeps Kubernetes persistent volumes reported affinity in sync with the cluster, in linstor-affinity-controller. And the container images are for the open source components Piraeus is built on: DRBD as the underlying storage replication mechanism between cluster nodes, and LINSTOR, which creates and manages volumes on request of the CSI driver, sets up replication using DRBD and prepares the backing storage devices. Both LINSTOR and DRBD come from LINBIT, with documentation provided by LINBIT.

Installing it, in three commands

The README says installing Piraeus can be as easy as applying the operator manifest, waiting for the operator pod to become ready, and then applying a cluster custom resource.

$ kubectl apply --server-side -f "https://github.com/piraeusdatastore/piraeus-operator/releases/latest/download/manifest.yaml"
namespace/piraeus-datastore configured
...

The next command waits for the controller manager to report Ready in the piraeus-datastore namespace.

$ kubectl wait pod --for=condition=Ready -n piraeus-datastore -l app.kubernetes.io/component=piraeus-operator
pod/piraeus-operator-controller-manager-dd898f48c-bhbtv condition met

Then you create the storage cluster itself as a custom resource.

$ kubectl apply -f - <<EOF
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
  name: linstorcluster
spec: {}
EOF

The spec is empty in the example, which is worth pausing on. The operator fills in the rest, and the README directs you to the Piraeus Operator docs for the detailed instructions on getting started. The operator repository also contains a basic Helm chart, under the v2 branch at charts/piraeus, for anyone who would rather install through Helm than by applying a raw manifest.

What the high availability and affinity controllers add

Two of the five components exist because Kubernetes and a block storage layer disagree about how state should move, and the README describes each in one line. The High Availability Controller speeds up the failover process of stateful workloads, which matters because the default Kubernetes behaviour is to wait for a pod's termination grace period before starting a replacement, and on a replicated block device you would rather have the volume attach to a surviving node quickly. The Volume Affinity Controller keeps Kubernetes persistent volumes reported affinity in sync with the cluster, which is the piece that stops a volume being scheduled onto a node that does not hold the data. The CSI Driver then provisions the persistent volumes and volume snapshots on the storage cluster that the operator maintains. Taken together, the components mean Piraeus is not just storage: it is the reconciliation layer that makes block replication behave the way a Kubernetes scheduler expects.

Where Piraeus is the wrong choice

Three limits. The first is that you are adopting a stack, not a product. Because Piraeus is mainly a glue project, the behaviour, the failure modes and the upgrade path live in LINSTOR and DRBD, and DRBD in particular is kernel-level replication, which means node reboots, kernel versions and network partitions all become your problem in a way they are not with a CSI driver talking to an appliance or a cloud API. The second is the maturity level. A CNCF Sandbox Project is explicitly earlier in the lifecycle than an incubating or graduated one, and the repository has no GitHub releases, so the operator manifest is fetched from a releases/latest URL and the version pinning story is thin. The third is fit. If your workload can live on object storage, or you are content with a managed block store and the per-volume cost, Piraeus buys you vendor independence at the price of operating replication yourself. It is the right answer for a platform team that wants to run storage on its own hardware with its own retention and replication policy, and the wrong answer for a small team that would rather spend its time on the application.

Community, governance and where the real support lives

The README routes support in a way that reflects the glue nature of the project. The active channel for Piraeus is a Slack workspace, and contributing is open, with CONTRIBUTING.md in the repository. But because Piraeus Datastore connects LINSTOR and DRBD to Kubernetes, communication channels for LINSTOR and DRBD are also relevant for people interested in the project, and those are the LINBIT community forums, the DRBD related mailing lists and the LINBIT community meetings. The presence of GOVERNANCE.md and MAINTAINERS.md in the repository is the marker of a CNCF project with a defined process rather than a single vendor's repository, which is also a signal about who owns the roadmap. The homepage is piraeus.io, and the operator documentation lives at piraeus.io/docs. If you are evaluating this, the practical point is that most of your questions will be about LINSTOR and DRBD rather than about Piraeus itself, and the README is honest about that.

Editorial conclusion

Adopt Piraeus if you run Kubernetes and need replicated persistent volumes without committing to a storage vendor's appliance or licence, and if you are willing to own the kernel-level replication underneath. Skip it if your storage needs are simple, because object storage or a managed block store will be less to run. Before you install, read the operator docs, and plan for the fact that Piraeus itself is thin and the real complexity sits in LINSTOR and DRBD.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. piraeusdatastore/piraeus on GitHub
4. Project website
5. README