What’s new in Portworx Enterprise 3.7.2

More Pools, Better Locality, Bringing Efficiency and Resilience to Kubernetes with Kube Datastore Dynamic Pools

Version 1.0

Authors: Aditya Dani, Anshuman Ratnani

Kubernetes has become the platform for more than stateless cloud-native applications. Organizations are also bringing enterprise databases, business-critical services, AI workloads, and virtual machines onto Kubernetes, often in their own data centers, where predictable performance, efficient infrastructure utilization, and strong data protection are non-negotiable. And they need storage that can scale with those workloads

Cloud Native Apps were designed around a shared-nothing model. Applications used replicas across worker nodes to achieve availability and resilience. That model works well when each node owns its storage. But when Kubernetes persistent volumes (PVs) are backed by a shared SAN, replicating the same data across multiple worker nodes can create unnecessary work: additional write I/O, east-west network traffic, storage consumption, and latency.

Portworx addresses this with the General Availability (GA) launch of Kube Datastore (KDS) on supported SAN arrays, building on their native capabilities for fast failover and efficient storage use, available with Portworx Enterprise 3.7.2. By introducing KDS and support for dynamic pools, Portworx now provides a familiar VMFS-style datastore experience for Kubernetes environments while combining two complementary forms of resilience:

• Portworx Enterprise provides application-level high availability, workload mobility, and Kubernetes-aware placement.
• Everpure FlashArray provides shared-storage resiliency, data protection, data reduction, and fault tolerance.

The result is a more efficient architecture for running Kubernetes workloads on-premises, especially large persistent volumes and virtual machines managed by KubeVirt or OpenShift Virtualization when backed by a SAN array.

Portworx Enterprise 3.7.2 release advances that goal in four connected ways: more pools per node, better initial placement, a path back to co-location of app and volume attachment after disruption, and pool-level recovery that avoids copying data across worker nodes to rebuild replicas.

Why Kubernetes needs a datastore model for shared storage

VMware administrators settled this question a long time ago. Nobody gives each VM its own LUN. You present a handful of large LUNs, format them as VMFS datastores, and carve hundreds of VMDKs out of them. That virtualization layer keeps the whole stack manageable: the array tracks tens of volumes instead of thousands, hosts stay well inside their device and path limits, and creating a disk is a datastore operation rather than an array round trip.

Kubernetes skipped that layer. 

On the other spectrum, traditional Kubernetes storage commonly uses a shared-nothing approach. A persistent volume is replicated across multiple worker nodes so the application can continue operating when a node fails. For a workload with a replication factor greater than one, every write may need to cross the cluster network and be persisted in multiple locations. That approach can result in approximately 2–3x storage overhead and 3–5x network I/O amplification, depending on the replication factor. The same data is protected twice: once by the application or storage layer in Kubernetes and again by the shared array underneath it.The alternative, mapping every persistent volume to its own array volume, brings back LUN-per-VM sprawl at container scale.

This becomes increasingly expensive as workloads grow. A virtual machine may consume hundreds of gigabytes or more, while a single worker node may host tens of terabytes of persistent data. Replicating that data across the cluster can consume capacity and network bandwidth that customers would rather use for applications.

Kube Datastore puts the missing layer back. It groups storage pools backed by the same shared storage backend into a logical datastore. . Applications still consume standard Kubernetes persistent volumes, but Portworx can manage those volumes as a pool-level unit and use the resiliency of the shared backend instead of creating redundant copies across worker nodes.

How KDS Dynamic Pools work

A Dynamic Pool is a Portworx storage pool created from a shared storage backend, such as Everpure FlashArray. Multiple pools backed by the same array form a Kube Datastore.

Dynamic pools hold volumes with a replication factor of one. Instead of keeping an additional copy of the same data on another worker node, Portworx maintains availability by moving the pool.  If a node is taken down for maintenance or becomes unavailable, the affected pool can be detached from the source node and reattached to a healthy destination node. The volumes in that pool move together.

This architecture separates two responsibilities in a deliberate way:

• Portworx handles application-level availability, volume placement, pool mobility, failover coordination, and workload movement.
• The shared storage backend handles data durability, data reduction, erasure coding, and underlying storage resiliency.

Because the data does not need to be rebuilt across worker nodes during a pool move, Dynamic Pools can avoid the replication-driven write and network I/O amplification associated with a shared-nothing design. Customers can use the shared array’s data protection without paying for multiple copies of the same data in the Kubernetes cluster.

Static and dynamic pools can coexist in the same cluster. Dynamic pools are intended for eligible repl-1 workloads that benefit from fast pool-level failover. Static pools remain available for workloads that require replication-based availability, such as volumes with higher replication factors or volume types that are not eligible for dynamic-pool failover (e.g. SharedV4, volumes with journal profiles, etc.).

Familiar Datastore benefits for Kubernetes workloads

Dynamic Pools bring several datastore characteristics familiar to virtualization administrators into a Kubernetes-native operating model:

• A logical datastore abstraction for persistent volumes and VM disks.
• A datastore abstraction that groups Kubernetes persistent volumes over shared array storage, reducing unnecessary per-volume array-management overhead.
• Pool-level mobility without copying the data between worker nodes.
• Storage migration and rebalancing capabilities that are aware of Kubernetes placement and workload state.
• A consistent storage platform for containers and virtual machines running side by side.

This is not an attempt to turn Kubernetes into a traditional hypervisor. Instead, KDS aligns the storage architecture with the needs of enterprise workloads running on Kubernetes. Kubernetes continues to provide declarative orchestration, while Portworx supplies storage intelligence that understands persistent volumes, virtual machines, nodes, pools, and application placement.

Compute-aware placement: put the workload next to its data

Storage locality is most valuable when it is established before the workload starts. PXE 3.7.2 uses Kubernetes WaitForFirstConsumer binding to improve that initial placement decision.

When a VM or pod is scheduled, Kubernetes selects a node based on CPU, memory, affinity, tolerations, selectors, and other scheduling constraints. The selected node is recorded on the PVC. Portworx reads that placement hint and prefers to create the volume on a pool on the same node, subject to capacity and administrative placement policies.

This creates an important alignment between compute and storage:

• Kubernetes chooses where the workload should run.
• Portworx uses that decision to place the persistent volume nearby.
• The application starts with compute and storage colocated whenever the cluster has the required capacity and policy compatibility.

The result is less east-west traffic during normal I/O, lower dependence on remote storage paths, and a better foundation for predictable application performance. The same placement applies to Rapid VM Migration from VMware (Migration Toolkit for Virtualization with FlashArray XCOPY), so migrated VMs, including powered-off ones, start with their disks co-located on the destination node.

Compute-aware placement is intentionally best-effort. Hard capacity limits, volume placement strategies, affinity rules, and other Kubernetes policies take precedence. The goal is not to override the scheduler; it is to give storage placement the context it needs to support the scheduler’s decision.

Co-location that can recover after disruption

For KubeVirt and OpenShift Virtualization workloads, colocation means that the VM and the persistent volumes serving it are on the same node whenever resources and scheduling constraints allow.

A VM and pool failover in an event of node outage  always puts availability first. A pool may land on a node where its VMs are not running, and for a while those VMs reach their disks over the network. PXE 3.7.2 does not leave the cluster that way. 

Once VMs settle after a node outage, Portworx keeps related pools always together, and Stork live-migrates each VM back to the node that holds its data, without a restart and within its CPU, memory and affinity rules. When the cluster changes more, for example when nodes are added or VMs move off legacy pools, an administrator can run the PX Descheduler on demand to plan a better layout that maximizes colocation of application and volume and reduces any east-west traffic.

This matters operationally. A failure should not leave the cluster permanently fragmented, with storage on one node and VMs on another. KDS Dynamic Pools and Stork work together to restore an efficient state after the immediate recovery action is complete.

A scheduler makes a placement decision at creation time. A descheduler is needed because clusters change after creation: 

• Nodes are added 
• VMs are migrated 
• Pools fail over 
• Maintenance drains nodes 
• New workloads consume resources 
• A placement that was optimal yesterday may no longer be optimal after one of these events.

PXE 3.7.2 introduces the placement and rebalancing workflow needed to address this lifecycle:

• Affinity groups keep related pools together during rebalance.
• Pool placement considers the current topology and available resources instead of blindly returning every pool to its original node.
• The PX Descheduler can be run on demand to rebalance pools, avoid memory hotspots, and restore a better cluster layout after an upgrade, node addition, or migration.
• Stork SchedulingOptimization can then move eligible VMs toward the nodes where their data resides.

In practical terms, the scheduler helps customers start in the right place, while the descheduler and Stork help the cluster stay in a good place.

Faster, less disruptive maintenance and failover

Dynamic Pools are designed for both planned and unplanned events. During Portworx or OpenShift upgrades, the operator can relocate eligible dynamic pools before restarting the node. The upgrade proceeds only after pool migration completes, helping avoid a storage interruption for replication-factor-one volumes.

For an unplanned node failure, Portworx can move the affected pool to a healthy node without restarting the Portworx service and without requiring a full data copy. The application continues to use its persistent volumes while the storage service restores access on the destination node.

The customer outcome is simple: faster recovery, fewer moving parts, and less cluster-wide traffic during the event that matters most.

A better architecture for on-premises Kubernetes

For customers running Kubernetes workloads on-premises, KDS Dynamic Pools provide a way to use shared SAN infrastructure without forcing Kubernetes to recreate the SAN’s data protection model at every worker node.

With PXE 3.7.2, customers can:

• Reduce duplicate writes and replication-driven network traffic.
• Use FlashArray data reduction, erasure coding, and resiliency for durable shared storage protection.
• Add application-level high availability through Portworx pool mobility and Kubernetes-aware workload placement.
• Run containers and VMs on a common storage platform.
• Improve compute and storage locality through WaitForFirstConsumer and compute-aware placement.
• Recover and converge toward colocation of app and volume placement after failures, upgrades, and other topology changes.
• Scale to higher pool, persistent-volume, and snapshot density.
• Perform planned maintenance with less disruption and without relying on a permanently idle spare storage node.

The architecture is complementary by design: the array protects the data, Portworx keeps applications available and mobile, and Kubernetes remains the control plane for workloads.

Built for production scale

PXE 3.7.2 increases the density at which customers can use KDS Dynamic Pools. The release is designed for larger enterprise clusters with more pools, persistent volumes, and snapshots per node and per pool.

The GA scale profile includes:

These limits matter because datastore benefits are only useful when they hold at production density. Higher pool density gives Portworx more placement choices, increases the likelihood that workloads and their data can remain on the same node, and provides more granular movement during maintenance or failure.

PXE 3.7.2 also adds the operational mechanisms needed to use that scale effectively: affinity-aware pool placement, serialized pool failover to a target node, compute-aware volume placement, Stork-driven workload movement, and support for local and remote FastPath on KDS pools.

Customers should use the final PXE 3.7.2 support matrix and sizing guidance for production planning, particularly when combining dynamic pools with static pools or workloads that have special volume requirements.

Get started with KDS Dynamic Pools

Kube Datastore Dynamic Pools in Portworx Enterprise 3.7.2 are designed for organizations that want the operational model of a datastore with the portability and automation of Kubernetes.

To learn whether KDS Dynamic Pools are a fit for your Kubernetes, KubeVirt, or OpenShift Virtualization environment, reach out to your Portworx representative. They can help you evaluate workload eligibility, design the right mix of dynamic and static pools, size the environment, and plan a greenfield deployment or brownfield migration.

For technical details, see the Kube Datastore concept documentation and Dynamic Pools documentation.