Provision storage for container workloads

Portworx Fusion Controller provides Fusion-backed persistent storage for Kubernetes workloads.

To use Fusion-backed storage, create a standard Kubernetes workload that references a Fusion-backed StorageClass. The Fusion webhook detects the StorageClass, creates a corresponding FusionWorkload custom resource (CR), and provisions the required volumes on the appropriate FlashArray through the Fusion Coordinator. You do not create or manage FusionWorkload resources directly.

The Fusion Controller uses the Fusion preset associated with the StorageClass to apply storage policies such as quality of service (QoS), placement, and replication.

note

• You do not need to create volumes manually, manage pure.json, or configure FlashArray systems. Fusion provisions and manages storage through Fusion-backed StorageClass resources.
• Fusion-backed StorageClass resources are cluster-scoped and can be referenced by workloads in any namespace. Create and manage Fusion presets using the Fusion console.

Prerequisites

Before you begin:

• Enable the Portworx Fusion Controller. For more information, see Enable Portworx Fusion Controller.
• Create a Fusion preset. For more information, see Create a Fusion Preset.
• Ensure that the namespace does not have the fusion.purestorage.com/webhook: disabled label.

Limitations

Before provisioning Fusion-backed storage for Kubernetes workloads, review the following limitations:

• Portworx Fusion Controller does not convert existing non-Fusion workloads into Fusion workloads.
• All volumes attached to a VM must use the same StorageClass.

Required permissions

The fusion-operator ServiceAccount has the cluster permissions required to manage Fusion workloads. Users who create container workloads require the following permissions:

Resource	Permissions
persistentvolumeclaims	create, get, list, delete
deployments, statefulsets	create, get, list, update, patch, delete
storageclasses	get, list

Users do not require permissions for FusionWorkload resources. The Fusion webhook creates and manages these resources. Use RBAC to control which users can create and manage workloads in each namespace.

Create a StatefulSet

A StatefulSet creates one PVC for each replica by using the volumeClaimTemplates field. Reference a Fusion-backed StorageClass to provision one Fusion volume for each replica.

The following example creates a StatefulSet in which each replica requests a 50 GiB volume:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: fusion-statefulset
  namespace: portworx
spec:
  serviceName: fusion-statefulset
  replicas: 3
  selector:
    matchLabels:
      app: fusion-statefulset
  template:
    metadata:
      labels:
        app: fusion-statefulset
    spec:
      containers:
        - name: app
          image: nginx
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        storageClassName: fleet-testing-gold-tier
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 50Gi

Replace fleet-testing-gold-tier with the StorageClass generated from your Fusion preset.

note

• Use the ReadWriteOnce (RWO) access mode for per-replica volumes.
• Kubernetes creates one PVC for each replica, for example, data-fusion-statefulset-0.

Create a Deployment

Unlike a StatefulSet, a Deployment does not create PVCs automatically. Create the PVC before creating the Deployment, and then reference the PVC from the workload.

The following example uses a shared ReadWriteMany (RWX) PVC across the Deployment replicas.

1. Create a PVC that references a Fusion-backed StorageClass:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: fusion-app-data
     namespace: portworx
   spec:
     storageClassName: fleet-testing-gold-tier
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 50Gi

   Replace fleet-testing-gold-tier with the StorageClass generated from your Fusion preset.

   note

   The PVC remains in the Pending state until you create the Deployment.

2. Create the Deployment that references the PVC:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: fusion-deployment
     namespace: portworx
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: fusion-deployment
     template:
       metadata:
         labels:
           app: fusion-deployment
       spec:
         containers:
           - name: app
             image: nginx
             volumeMounts:
               - name: data
                 mountPath: /data
         volumes:
           - name: data
             persistentVolumeClaim:
               claimName: fusion-app-data

note

Scaling a Deployment does not provision additional volumes. Create additional PVCs manually, or use a shared RWX PVC.

Verify the workload

When a workload references a Fusion-backed StorageClass, the Fusion webhook creates a FusionWorkload resource. Fusion creates one FusionWorkload CR for each StatefulSet or Deployment that uses a Fusion-backed StorageClass.

Fusion names the resources as follows:

• sts-<statefulset-name> for a StatefulSet
• dep-<deployment-name> for a Deployment
• vm-<vm-name> for a VirtualMachine
• ns-<namespace-name> for a namespace

note

Fusion truncates generated FusionWorkload resource names to 63 characters.

To list the Fusion workloads, run:

kubectl get workload -n <namespace>

To view the details of a workload, run:

kubectl describe workload <workload-name> -n <namespace>

The workload details include the following fields:

Field	Description
status.status	Lifecycle state of the workload, such as creating, ready, destroying, or destroyed.
status.statusDetails	Details about the current operation or lifecycle state.
status.id	Unique identifier of the Fusion workload.
status.placement.arrayName	Name of the FlashArray selected for the workload.
status.volumes	List of provisioned volumes, including the volume ID, serial number, provisioned size, and associated PVC.

Fusion also records Kubernetes events throughout the workload lifecycle. Typical events include:

Event	Description
Creating	Workload provisioning has started.
Ready	Workload provisioning completed successfully.
Destroying	Workload deletion has started.
Destroyed	Workload deletion completed successfully.
VolumeRetained	The volume was retained because the StorageClass reclaim policy is set to Retain.
DestroyFailed	Workload deletion failed.
VolumeDestroyFailed	Volume deletion failed.

Scale a workload

StatefulSet

Fusion provisions additional storage when you scale up a StatefulSet.

When you scale up a StatefulSet, Kubernetes creates a new PVC for each additional replica. The Fusion webhook detects the new PVC, updates the corresponding FusionWorkload, and Fusion provisions a new FlashArray volume.

When you scale down a StatefulSet, Kubernetes deletes the pods but retains the PVCs and their underlying FlashArray volumes. The retained volumes remain available if you scale the StatefulSet back up.

note

Delete unused PVCs manually to reclaim storage after scaling down.

Deployment

Fusion does not provision additional storage when you scale a Deployment. Create additional PVCs as required, or use a shared RWX PVC.

Delete a workload

Delete the parent StatefulSet or Deployment workload and its PVCs. The Fusion Controller deletes the corresponding FusionWorkload resource.

The StorageClass reclaim policy determines how Fusion handles the underlying FlashArray volumes:

• Delete: Fusion deletes the FlashArray volumes. Deleted volumes remain recoverable for the configured recovery window, which is 24 hours by default, before they are permanently removed.
• Retain: Fusion preserves the FlashArray volumes. Delete retained volumes manually when they are no longer needed.

If Fusion cannot delete a workload or volume, it records a DestroyFailed or VolumeDestroyFailed event.