Break the Chains of Storage Ops with Portworx Autopilot

In Modern Virtualization platforms, data is the most valuable asset and storage growth is the day-2 problem that never stops. OpenShift and Kubernetes made stateless operations feel effortless. Scaling is routine, rollouts are repeatable, and the platform behaves predictably. But with stateful workloads, data keeps growing, and eventually storage runs out.

Persistent data rarely fails loudly, it creeps up. A database volume nears capacity, a VM disk expands unexpectedly, and the “fix” turns into a ticket and an approval. Suddenly, your self-healing platform is blocked by a manual step. Portworx Autopilot by Pure Storage was built to break this loop by turning PVC growth into policy.

What is Portworx Autopilot?

Portworx Autopilot is a rule-based automation engine for OpenShift/Kubernetes storage operations. It evaluates storage and cluster metrics from your monitoring source and executes the action automatically when conditions are met, eliminating ticket-driven intervention.
Autopilot’s most common and high-impact capability –

• Autoated PVC resizing for Container workloads and ModernVirt VM disks.
• Expand the storage pool in the Portworx cluster until they reach a certain capacity.
• Rebalance of storage pools when they begin to run out of space and to help manage capacity and performance drift over time.

Autopilot architecture Overview

Portworx Autopilot integrates tightly with OpenShift/Kubernetes and is deployed alongside the Portworx storage layer. At a high level, it consists of –

• Autopilot controller: Runs as a pod in the cluster and evaluates Autopilot rules, then executes the corresponding actions.
• Metrics provider: Prometheus feeds Autopilot the storage and cluster metrics it uses to determine when a rule should trigger.
• CRDs: Custom resources that let you define automation policies (such as AutopilotRule) and view their status on the targeted objects.
• StorageCluster integration: Autopilot is enabled and configured through the Portworx StorageCluster, including settings like the metrics endpoint and operational options.
• AutopilotRule CR: AutopilotRule is the Kubernetes-native policy object that drives Autopilot. It lets teams define data-driven automation for storage operations—such as resizing volumes or expanding pools—based on measurable conditions in the environment.

AutopilotRule for PVC resize for containers and KubeVirt VM disks

ModernVirt gives you one big operational advantage, you don’t need separate container and VM storage operations. If the workload consumes a PersistentVolumeClaim (PVC), whether it’s mounted by a Pod or attached as a KubeVirt VM disk, the same automation policy applies.The policy is defined as an AutopilotRule.

A PVC resize AutopilotRule typically includes:

• PVC selector: Choose which PVCs to manage (label-based)
• Namespace Selector: Matches labels on the namespaces the rule should monitor.
• Metric Conditions: Metric expressions (e.g., volume usage). All conditions must be satisfied (AND logic) for actions to trigger.
• PVC resize actions: Perform once the metric conditions are met.

For PVC growth, the key action is: openstorage.io.action.volume/resize

Guardrails matter most –

• scalepercentage: how much to grow
• maxsize: a hard cap to prevent runaway growth
• actionsCoolDownPeriod: Defines the duration in seconds for which autopilot will not re-trigger any actions once they have been executed.

apiVersion: autopilot.libopenstorage.org/v1alpha1
kind: AutopilotRule
metadata:
  name: auto-resize-critical-pvcs
spec:
 ##### selector filters the objects affected by this rule given labels
  selector:
    matchLabels:
      app: application-1
  ##### namespaceSelector selects the namespaces of the objects affected by this rule
  namespaceSelector:
    matchLabels:
      database: database-1
  ##### conditions are the symptoms to evaluate. All conditions are AND'ed
  conditions:
    # volume usage should be less than 50%
    expressions:
    - key: "100 * (px_volume_fs_usage_bytes / px_volume_capacity_bytes)"
      operator: Gt
      values: ["50"]
  ##### action to perform when condition is true
  actions:
  - name: openstorage.io.action.volume/resize
    params:
      scalepercentage: "50"
      maxsize: "200Gi"

Example: grow PVCs by 50% up to 200Gi when usage exceeds 50%

Autopilot in Containers vs VMs –

Containers: Autopilot detects the threshold breach, triggers the resize action, and you can clearly show the before/after PVC size along with the rule status / events that indicate an action was executed.

PVC and disk size of the container before the AutopilotRule event

AutopilotRule State Transitions (Triggered → ActiveActionsTaken)

PVC and disk size increased post the AutopilotRule action

VMs: Autopilot resizes the VM disk PVC the same way as the container, but the VM admin still owns the last step—expanding the partition/filesystem inside the guest OS (for example, growpart + resize2fs or xfs_growfs) so the VM can use the newly available space.

PVC and VM disk size (/dev/sdb) of the VM before the AutopilotRule event

AutopilotRule State Transitions (Triggered → ActiveActionsTaken)

PVC and disk size (/dev/sdb) increased post the AutopilotRule action

See the autopilot live in action—watch the full demo here:

Summary

PVC resize shouldn’t be a ticket queue item. Portworx Autopilot turns PVC growth into a Kubernetes-native/Openshift policy-driven behavior, based on metrics and guardrails and applies it consistently across container workloads and KubeVirt VM disks through the shared abstraction of PVCs. On the business side, Portworx positions this approach as a way to reduce overprovisioning and manual effort by growing storage on demand.If you need a human in the loop, Autopilot supports approval-gated enforcement. When enabled, triggered actions wait for an operator to approve or decline before execution.