Replicating Kubernetes workloads with VAST Data 5.5 & CSI 2.6.6

Replicate Kubernetes workloads with VAST Data 5.5 and CSI 2.6.6: protected paths, Global Snapshot Clones, and practical DR for OpenShift and cloud-native apps.

A Practical Kubernetes Disaster-Recovery

.

Kubernetes makes it easy to schedule applications, but it does not make a stateful application recoverable across storage sites by itself. A PersistentVolumeClaim (PVC) tells Kubernetes where an application should mount storage; it does not define how the data reaches a second VAST cluster, how a remote copy becomes writable, or how a workload switches to that copy during an outage.

Starting with VAST CSI Driver 2.6.6 (General Availability, August 2026), VAST Block CSI supports asynchronous replication of Block volumes between VAST clusters, including failover to a secondary peer. Data from one source cluster can be replicated to multiple destination clusters.

.

VAST CSI Replication Operator closes that gap for VAST Block deployments. The extensions controller ships with the VAST Block CSI Helm chart and turns a Kubernetes declaration into the VAST protection policy, protected path, replication stream, CSI-addons resources, destination PV/PVC pairs, and—when enabled—pod remapping needed for a controlled role change.

This guide explains the model and then walks through a two-site VAST Block deployment. It aligns with the published Replicating Block Volumes with VAST CSI Replication Operator documentation and the VAST CSI Driver 2.6.6 release notes, reviewed on August 5, 2026.

Scope: This is asynchronous, active/standby replication: one site is primary at a time. Your recovery point objective (RPO) is bounded by the protection-policy cadence, not by Kubernetes. Test the procedure on non-production data before using it for a production runbook.

What Kubernetes replication needs to solve

A useful disaster-recovery workflow has to coordinate four things:

.

Without an operator, each layer is a separate integration task. An administrator must pre-create array-side objects, create or update CSI-addons resources, provision matching destination claims, and coordinate workload changes. The VAST CSI Replication Operator owns those integration points from a VastStorageClassReplication (VSCR) or VastVolumeReplication (VVR) resource.

Using the information in those CRDs, the operator can:

.

Choose the right replication scope: VSCR, VVR, or subsystem

The published Block replication guide supports three related patterns:

.

Decision	VSCR	VVR
Scope	All PVCs on a StorageClass (optionally a volume group)	One named PVC (volumeName)
Destination PVC timing	Waits at least one replication cycle before creating destination PVCs	Creates the destination PVC without that additional wait
Typical fit	Application group or common tier	One-off workload or independent SLA

.

This guide uses a VSCR because it is the clearest pattern for a Block application with several claims.

The VAST Block model

Figure 2. The controller connects Kubernetes declarations to VAST replication objects.

The Block StorageClasses are the bridge between Kubernetes and the two VAST clusters. Each site has its own:

.

For two sites, create one replication peer relationship. For three sites, create one peer relationship for every pair in the mesh. The VSCR topology is undirected: two sites need one entry; three sites need three; in general, n sites need n(n-1)/2 entries. Native Replication uses a dedicated VAST replication VIP pool; it is distinct from the protocol VIP pool that serves workload I/O.

For Block, the StorageClass subsystem parameter identifies the Block subsystem. The native-replication data plane is path-based on the BLOCK view: every volume under the protected view path is replicated as part of that protection domain, rather than being independently replicated by the array. The admission webhook injects these labels when a matching PVC is created:

.

Those labels allow the volume-group replication selectors to locate the intended claims without developers hand-authoring replication labels.

Requirements

VAST cluster

.

These preconfiguration steps are performed with the VAST Web UI, CLI, or REST API, as described in the VAST Cluster Administrator’s Guide.

Kubernetes

.

Application and operational assumptions

.

Upgrade to VAST CSI Driver 2.6.6

Block CSI replication requires CSI Driver 2.6.6 or later. If you are already on a Helm-based deployment from 2.2.1 or later:

.

Older upgrade paths (2.2.0, 2.1.x, 2.0.x, 1.0.x) follow the published Steps to Upgrade VAST CSI Driver guide: some require removing the old chart, redeploying 2.6.x, and optionally migrating PVs or creating View-per-Volume views for existing PVCs. Chart packages and assets are published under the helm-vastcsi-2.6.6 (and related Block / operator) tags on the vast-csi GitHub releases page.

Step 1: Configure Block StorageClasses and enable the Replication Operator

Add the extensions controller to the Block CSI Helm chart configuration, then deploy or upgrade the chart.

storageClassDefaults:
  vipPool: vippool-1
storageClasses:
  vastdata-block:
    secretName: vast-mgmt-a
subsystem: source
    volumeGroup: “/k8s”
vastdata-block2:
    secretName: vast-mgmt-b
subsystem: destination
    volumeGroup: “/k8s-repl”
extensions:
enabled: true
webhook:
    disablePvcLabelsWebhook: false
    filterConfig:
      storageClassNameRegex: “^vastdata-.*”
replication:
    pvcNameFormat: “{pvc_name}-repl-{endpoint}”
    pvNameFormat: “{pv_name}-repl-{endpoint}”
  applyExistingPvcs: true
image:
  vastExtensionController:
repository: vastdataorg/csi
tag: v2.6.6-extensions

applyExistingPvcs: true is important if PVCs existed before the webhook was enabled. On each primary-StorageClass change, the controller can backfill the storage-class label (and the subsystem label for Block StorageClasses) for existing PVCs whose backing VAST object is known in the relevant VolumeMapping.

Note on the extension controller image: the chart defaults vastExtensionController.tag to {{ .Values.image.csiVastPlugin.tag }}-extensions, so it normally tracks the driver tag automatically with an -extensions suffix appended. If you pin it explicitly, as shown above, keep that suffix — a bare v2.6.6 tag is the main CSI plugin image, not the extensions controller image, and will not run the replication controller.

Destination PVC and PV names default to {pvc_name}-repl-{endpoint} and {pv_name}-repl-{endpoint} (for example, myapp-data-repl-16-0-0-2). You can change the format with placeholders such as {pvc_name}, {pvc_name_suf:<N>}, {endpoint}, {sc_name}, and the corresponding PV / prefix variants documented in the administrator’s guide.

To restrict a VSCR to a volume group rather than every claim on the StorageClass, set volume_group (or the chart-equivalent volumeGroup) on the source StorageClass.

Apply the chart and make sure the extensions controller is running:

helm upgrade –install csi charts/vastblock/ -f values.yaml
kubectl get pods -n vast-csi

Step 2: Declare the protection topology with a VSCR

The VSCR expresses the intended state. It names the primary StorageClass, the two-site topology, a snapshot/retention policy, and the synchronization behavior.

apiVersion: vastdata.com/v1alpha1
kind: VastStorageClassReplication
metadata:
name: app-replication
namespace: default
spec:
  primaryStorageClass: vastdata-block
  protectionTopology:
– source: vastdata-block
destination: vastdata-block2
# peerName: cluster-a-cluster-b-peer # optional when one peer is discoverable
  protectionPolicyTemplate:
params:
– every: 15m
        keepLocal: 2d
        keepRemote: 7d
  failoverType: gracefulFailover
  syncIntervalSeconds: 900
  syncPVCPV: true
  syncVastObjects: true
  pvcRemap: true
  destVolReclaimPolicy: Retain

For one source and two destinations (A -> B and A -> C), include the full undirected mesh so failover can resynchronize every pair—for example A-B, A-C, and B-C.

Key fields:

.

For a single named volume, use a VastVolumeReplication with the same fields plus volumeName.

Apply and watch the resource:

kubectl apply -f app-replication.yaml
kubectl get vscr -w
kubectl get volumegroupreplicationclass
kubectl get volumegroupreplication
kubectl get events –sort-by=‘.lastTimestamp‘ | tail -20

A healthy VSCR converges to syncStatus: Completed. After the source PVCs are created, replication proceeds on the schedule defined in the CRD.

Step 3: Verify both Kubernetes and VAST state

The status fields are a quick health check:

Field	What it means
syncStatus	Completed, InProgress, Unreachable, Error, Invalid, Deleting, or Failed (a permanent infrastructure error that requires user intervention)
currentPrimaryStorageClass	The StorageClasscurrently treated as primary
ppathName	The VAST ProtectedPath created by the controller
ppathDirMapping	Maps every StorageClass in the constellation to its predicted ProtectedPath source directory
lastFailoverType	The most recent failover type (graceful or ungraceful) that was applied

.

On the VAST primary, verify:

.

On Kubernetes, verify that the primary volume-group replication object has replicationState: primary and the destination has replicationState: secondary.

The operator also ships a vcsi CLI (GitHub release v1.0) for day-2 operations:

vcsi list
vcsi status —vscr app-replication

Step 4: Create application PVCs

PVCs remain ordinary Kubernetes resources. A developer selects the primary StorageClass; the webhook and controller handle the replication plumbing.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myapp-data
namespace: default
spec:
  accessModes:
– ReadWriteOnce
resources:
requests:
storage: 10Gi
  storageClassName: vastdata-block

Apply the claim, then inspect labels and destination objects:

kubectl apply -f myapp-data.yaml
kubectl get pvc –show-labels
kubectl get pv

With a VSCR, destination mirror creation waits until the VAST backend object is available after at least one replication cycle. Do not infer that replication failed simply because the destination PVC is not present the moment the source claim is created.

Step 5: Deploy and validate the workload

Mount the primary PVC as usual. For a first test, use a disposable workload that writes an identifiable record:

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: default
spec:
replicas: 1
selector:
    matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
– name: writer
image: busybox
command:
– sh
– -c
– while true; do date >> /data/log.txt; sleep 5; done
          volumeMounts:
– name: data
              mountPath: /data
volumes:
– name: data
          persistentVolumeClaim:
            claimName: myapp-data

Check the initial primary before proceeding:

vcsi list
vcsi status —vscr app-replication

Step 6: Perform a failover

Figure 3. A failover changes the primary and can remap workloads to mirror claims.

Choose graceful failover for planned maintenance: the controller completes a final replication step before it switches roles. Choose ungraceful failover for an outage in which the old primary cannot be assumed reachable. Details of each manner are covered in the VAST Cluster Administrator’s Guide.

Use the CLI for an explicit operational command:

vcsi failover —vscr app-replication \
–primary vastdata-block2 \
–manner graceful

Or update the VSCR declaratively (edit primaryStorageClass, then apply):

kubectl patch vscr app-replication –type=merge \
–p ‘{“spec“:{“primaryStorageClass”:”vastdata-block2″,”failoverType”:”gracefulFailover”}}‘

Watch the transition:

kubectl get vscr app-replication -w
kubectl get volumegroupreplication
kubectl get pods -n default -w

Expected result:

.

Failback is another role change after the original site is healthy and replication is re-established in the new direction. Treat it as a tested operation, not as an automatic reversal.

Step 7: Trigger an immediate resync when needed

You can request on-demand synchronization in either of two equivalent ways.

Declarative, one-shot flag on the CRD:

kubectl patch vscr app-replication –type=merge \
–p ‘{“spec“:{“resync“:true}}’

The controller resets spec.resync to false after triggering the operation.

Or use the CLI:

vcsi sync —vscr app-replication

To remove a replication configuration when you are finished with a lab or cleanup:

vcsi delete —vscr app-replication

destVolReclaimPolicy then determines whether destination volumes are retained or deleted.

Operational guardrails

.

A concise runbook

.

Further reading

• Replicating Block Volumes with VAST CSI Replication Operator

• VAST CSI Driver 2.6.6 Release Notes

• Steps to Upgrade VAST CSI Driver

• vast-csi GitHub releases (helm-vastcsi-2.6.6 and vcsi CLI)