LINBIT® will exhibit at the KubeCon and CloudNativeCon North America 2026 conference. The conference takes place November 9-12, at the Salt Palace Convention Center, Salt Lake City, Utah.
As Kubernetes continues to evolve, so does the LINBIT team’s development of LINSTOR® in Kubernetes and the upstream CNCF Piraeus Datastore project. 2026 has brought new features to LINSTOR in Kubernetes, alongside component maintenance and modernization, such as a jump to using the DRBD® 9.3 branch for data replication, and improvements to existing features.
This article serves as a roundup of LINBIT development work in 2026 for LINSTOR in Kubernetes. KubeCon attendees can use it as a way to start conversations with the LINBIT team at the conference booth. People new to, or curious about, LINSTOR in Kubernetes can use this article as a primer or jumping-off point to explore aspects of the software through the linked blog articles or other resources.
The state of LINSTOR in Kubernetes
The LINBIT team’s LINSTOR in Kubernetes development work focuses on three areas: Kubernetes and Container Storage Interface (CSI) integration, the open source upstream Piraeus project, and the LINSTOR Operator. Piraeus Datastore is a CNCF Sandbox project, accepted in 2021. Its components include the Kubernetes Operator, the LINSTOR CSI driver, and the High Availability (HA) Controller that speeds failover of stateful workloads. LINSTOR provisions and manages volumes on request from the CSI driver and sets up replication with DRBD. The HA Controller uses LINSTOR and DRBD Reactor to make the LINSTOR controller service highly available, so that the LINSTOR control plane stays available in the case of a node-level failure.
Operator and platform certification
The LINSTOR Operator v2 drives life cycle management of the LinstorCluster and related Custom Resource Definitions (CRDs). It also makes it possible to deploy LINSTOR in Kubernetes by entering only two commands. Now at version 2, the LINSTOR Operator is mature software that is also a Red Hat certified offering available through the OperatorHub in the OpenShift Container Platform. LINSTOR also lists Red Hat-certified OpenShift Virtualization infrastructure features in its Red Hat Ecosystem Catalog listing, next to CSI.
You can read more about the Red Hat certifications for LINSTOR and its Operator in the “LINSTOR in OpenShift: A Red Hat Certified OperatorHub Offering” and “LINSTOR is Red Hat Certified for OpenShift Virtualization” articles on the LINBIT blog.
Tiered storage with quality of service limits
One of the new features the LINBIT development team, led by Moritz Tanner, added to LINSTOR in Kubernetes in 2026 was per-volume I/O QoS enforcement in Kubernetes. Enforcement happens through the nri-volume-qos NRI plugin, which you deploy separately from its own Helm chart. The feature also requires LINSTOR Operator 2.11.0 and later, and the CSI driver 1.11.3 and later. This feature allows administrators to specify read and write bandwidth and IOPS limits as StorageClass parameters, and every volume created from that StorageClass inherits those limits. Service providers can use QoS limits to offer tiered storage to customers on mixed storage media. Using the feature can also prevent “noisy neighbor” VMs from affecting other VMs on shared storage.
You can read more about QoS enforcement in LINSTOR in Kubernetes in the LINBIT blog article, “Applying Per-Volume I/O Quality of Service Limits with LINSTOR in Kubernetes”.
Consistency groups for persistent volumes
The LINSTOR Operator 2.11.0 release also added consistency groups to the LINSTOR CSI driver. When you label several PersistentVolumeClaims (PVCs) with linstor.csi.linbit.com/consistency-group, the CSI driver places them as separate volumes of a single LINSTOR resource, rather than as independent resources. This makes it so application writes to multiple volumes maintain transactional consistency with one another. Consistency groups enforce sequential write ordering across multiple volumes, so that an individual volume cannot persist writes faster or slower than another volume in the consistency group. A database that keeps its data and write-ahead log on different volumes is an example use case for this feature.
Virtualization in Kubernetes
Interest in running virtual machines in Kubernetes has increased as organizations look for alternatives to their existing virtualization platforms. Much of this shift follows VMware licensing changes after the Broadcom acquisition. Kubernetes-native virtualization with KubeVirt is an alternative way to consolidate VMs and containers on a single control plane. This alternative can appeal to organizations already running Kubernetes.
The LINBIT team wrote about using LINSTOR in Kubernetes as a way to support KubeVirt VMs as early as 2020, although the technical origins began a couple of years earlier. 1 Since then, the LINBIT development team has worked in Piraeus and LINSTOR in Kubernetes to enhance and harden its support for this use case. The LINSTOR Operator 2.10.0 release in 2025 introduced native NFS-based RWX support.
The LINBIT development team added a maxConcurrentEvacuations setting in LINSTOR Operator 2.11.0, released in August 2026. By using this setting, an administrator can limit how many Satellites evacuate at the same time during node drains or removals. Setting an appropriate limit reduces the chance of mass simultaneous VM migrations overwhelming a cluster during maintenance.
If you are interested in exploring using LINSTOR to support virtualization in Kubernetes, the LINBIT blog article, “Using LINSTOR in Kubernetes to Create & Manage Persistent Storage for KubeVirt VMs” is an introduction to the topic.
A real-world LINSTOR with Kubernetes deployment
WEDOS Internet a.s., the largest hosting provider in the Czech Republic, is one of many LINBIT customers running LINSTOR with Kubernetes. It uses LINSTOR with Kubernetes and OpenNebula to back its virtual private server hosting. LINSTOR uses thin-provisioned LVM logical volumes and DRBD to mirror each volume for high availability. WEDOS has grown its deployment to a LINSTOR cluster of more than 500 nodes. You can read about this deployment in the LINBIT case study, “High Availability with LINSTOR and DRBD”.
Emerging workloads and testing LINSTOR in Kubernetes
Not falling under the category of “development work” but still notable in 2026, was the LINBIT team’s work to explore different use cases and architectures with LINSTOR and Kubernetes. If you are interested in AI and LLM workloads in Kubernetes, LINBIT Solutions Architect, Matt Kereczman, wrote an article about running a local LLM in Kubernetes with vLLM and LINSTOR. Kereczman also wrote the article, “Integrating External LINSTOR Clusters With Kubernetes by Using the LINSTOR CSI Driver” that describes how an administrator can use LINSTOR with Kubernetes in a disaggregated architecture.
Object storage was another area that the LINBIT team explored in 2026. The article “Disaster Recovery With RustFS and LINSTOR in Kubernetes” shows how you can ship snapshots of a LINSTOR-backed PVC to RustFS, an S3-compatible object store written in Rust. The example workload is a CloudNativePG PostgreSQL cluster, and the instructions cover both shipping a snapshot to the remote object store and restoring the database from it.
For new users, the LINBIT blog article “Using minikube to Get Started With LINSTOR in Kubernetes”, published at the start of 2026, describes how you can evaluate LINSTOR in Kubernetes by using minikube. The instructions in the article can get you up and running from nothing to something in about 20-30 minutes.
Piraeus and the community
Piraeus Datastore is the upstream open source project that LINSTOR in Kubernetes is built from. It uses the same architecture and the same custom resource definitions, and it has been a CNCF Sandbox project since 2021. Development happens in public, in the piraeus-operator repository on GitHub, under the Apache 2.0 license. That repository has the v2 line of the Operator, which supports Kubernetes v1.30 and later. You can install the Operator with the Helm chart in the repository, or by applying the released manifest with kubectl apply. The LINSTOR CSI driver, the HA Controller, and the nri-volume-qos plugin that enforces the QoS limits live in their own repositories under the same GitHub organization. Project documentation is available at the Piraeus website.
The Piraeus Datastore project takes issue reports and pull requests through GitHub. If you run or evaluate Piraeus Datastore, the LINBIT team is interested in hearing about your deployment, either through GitHub or at the KubeCon booth.
Data protection and disaster recovery in Kubernetes
Data protection and disaster recovery are subjects that this roundup has not covered yet, but they are a critical component of any enterprise Kubernetes deployment. LINSTOR provisions storage through a CSI driver and supports CSI volume snapshots, so Kubernetes-native backup tools work against LINSTOR-backed volumes. The LINBIT blog has instructions for working with two of these backup tools, Velero and CloudCasa.
Meet the LINBIT team at KubeCon
You can find the LINBIT booth at the Salt Palace Convention Center, November 10-12. LINBIT engineers and solutions architects will be there to talk about high availability, disaster recovery, and software-defined storage, in Kubernetes and on the other platforms that LINBIT software integrates with. Bring an architecture diagram, a recovery time objective that your current storage layer cannot meet, or a question about anything in this article. If you cannot attend the conference, you can contact LINBIT to arrange a conversation with the team.
