Search <book_title>...

Important Update: Cohesity Products Documentation

All Cohesity product documentation are now managed via the Cohesity Docs Portal: https://docs.cohesity.com/HomePage/Content/home.htm. Some documentation available here may not reflect the latest information or may no longer be accessible.

InfoScale™ for Kubernetes 9.1.0 - Linux

Last Published: 2026-01-07

Product(s): InfoScale & Storage Foundation (9.1)

Platform: Linux

Configuring cluster

Complete the following steps for each cluster.

Note:

Ensure that you add a Kubernetes node only to a single InfoScale cluster.

Edit clusterInfo section of the sample /infoscale-yamls-v9.1.0/kubernetes/cr.yaml for InfoScale specifications as under -

---
apiVersion: infoscale.veritas.com/v1
kind: InfoScaleCluster
metadata:
  # Please change cluster name if required
  name: infoscalecluster-dev
  namespace: infoscale-vtas
spec:
  # This denotes version of the InfoScale release
  version: 9.1.0
  # (optional) This denotes the user-provisioned ID for InfoScale
 cluster
  # The value can range from 1 to 65535
  # clusterID: <Cluster_ID>
  clusterInfo:
  # Please change worker node names according to your cluster
 configuration
  # Mention additional worker node names and corresponding node
 specific
  # parameters, as applicable.
  - nodeName: "<Hostname_of_worker_node>"
    # (optional) Specifies node IP address(es) to be used for
 InfoScale cluster.
    # If omitted, InfoScale chooses available IP address(es)
 for cluster config.
    # Please change worker IP address(es) according to your
 cluster configuration
    # ip:
    # - "<IP_Address_1>"
    # - "<IP_Address_2>"
    # (optional) Specifies a node-specific list of devices
 for InfoScale configuration.
    #
    # Only one of the following fields can be used at a time:
    # - `includeDevices`: List of devices to be explicitly 
included in InfoScale configuration.
    # - `excludeDevice`: List of devices to be excluded from
 InfoScale configuration.
    #
    # Please update the device names according to your cluster
 setup.
    # includeDevices:
    # - "<Hardware_Path_to_device_to_be_included>"
    # excludeDevice:
    # - "<Hardware_Path_to_device_to_be_excluded>"
    # (optional) Specifies node specific list of devices to be
 used for fencing purpose
    # It is sufficient to provide fencing device information
 from one node
    # (optional) Specifies node specific list of devices to be
 used for fencing purpose
    # It is sufficient to provide fencing device information
 from one node
    # Please change device names according to your cluster
 configuration
    # fencingDevice:
    # - "<Hardware_Path_to_device_to_be_used_for_fencing>"
  - nodeName: "<Hostname_of_worker_node>"
    # (optional) Specifies node IP address(es) to be used for
 InfoScale cluster.
    # If omitted, InfoScale chooses available IP address(es)
 for cluster config.
    # Please change worker IP address(es) according to your
 cluster configuration
    # ip:
    # - "<IP_Address_1>"
    # - "<IP_Address_2>"
    # (optional) Specifies node specific list of devices to be
 excluded from
    # InfoScale configuration.
    # Please change device names according to your cluster
 configuration
    # excludeDevice:
    # - "<Hardware_Path_to_device_to_be_excluded>"
  # Please change below customImageRegistry according to your
 environment
  # This is mandatory for Kubernetes and Air gapped system
 deployments
  # This is optional for OCP deployments
  # customImageRegistry: "<Custom_Registry_Address>"
  # (optional) Specifies whether SCSI-3 Persistent Reservation
 should be enabled
  # If omitted, SCSI3-PR reserveation will be disabled by default.
  # Valid values are true or false.
  # enableScsi3pr : <true/false>
  # (optional) Specifies whether Disk Group Level Encryption
 should be enabled
  # If omitted, Disk Group Level Encryption will be disabled
 by default.
  # Valid values are true or false.
  # encrypted: <true|false>
  # (optional) Specifies whether Disk Group Level Encryption
 Key should be same for all volumes in the DG
  # If omitted, different key will be created for each volume
 by default.
  # Valid values are true or false.
  # sameEncKey: <true|false>
  # (optional) Specifies whether to create Shared NonFSS Disk
 Group.
  # With this option only the full shared disks will be included
 in Disk Group
  # If omitted, FSS Disk Group will be created by default.
  # Valid values are true or false.
  # isSharedStorage: <true|false>

You can add up to 16 nodes.

Note:

Do not enclose parameter values in angle brackets (<>). For example, Primarynode is the name of the first node; for nodeName : <Name of the first node> , enter nodeName : Primarynode. InfoScale on Kubernetes is a keyless deployment.

You can choose to rename cr.yaml. If you rename the file, ensure that you use that name in the next step.
Note:
Arctera recommends renaming cr.yaml and maintaining a custom resource for each cluster. The renamed cr.yaml is used to add more nodes to that InfoScale cluster.
Run the following command on the master node.
kubectl create -f /infoscale-yamls-v9.1.0/kubernetes/cr.yaml
Run the following command on the master node to know the name and namespace of the cluster.
kubectl get infoscalecluster -A
Use the namespace from the output similar to the following -
```
NAMESPACE   NAME                VERSION   CLUSTERID   STATE   AGE
.
.
<Namespace> <Name of the 
             InfoScale cluster> 9.1.0  <Cluster ID> Running 25h
.
.
```

Run the following command on the master node to verify whether the pods are created successfully.

kubectl get pods -n infoscale-vtas

An output similar to the following indicates a successful creation of nodes


NAME                                            READY   STATUS    RESTARTS      AGE

infoscale-csi-controller-7b4b7bd899-4c786       5/5     Running   0             14m

infoscale-csi-node-5rlr7                        2/2     Running   0             14m

infoscale-csi-node-fl57f                        2/2     Running   0             14m

infoscale-csi-node-srnh5                        2/2     Running   0             14m

infoscale-fencing-controller-654f549565-d56jk   1/1     Running   0             14m

infoscale-fencing-enabler-4xxx7                 1/1     Running   0             14m

infoscale-fencing-enabler-hr26f                 1/1     Running   0             14m

infoscale-fencing-enabler-qdx4v                 1/1     Running   0             14m

infoscale-licensing-operator-cfff86577-kcpnl    1/1     Running   1 (43m ago)   100m

infoscale-sds-22222-a924e23b0ed1ca1d-6t4fs      1/1     Running   0             14m

infoscale-sds-22222-a924e23b0ed1ca1d-qhqzn      1/1     Running   0             14m

infoscale-sds-22222-a924e23b0ed1ca1d-w48vz      1/1     Running   0             14m

infoscale-sds-operator-7fd45465cc-cssmm         1/1     Running   0             22m

infoscale-toolset-22222-b7c8cbf78-b9xnv         1/1     Running   0             14m

infoscale-toolset-22222-b7c8cbf78-fb8vz         1/1     Running   0             14m

infoscale-toolset-22222-b7c8cbf78-x5cjj         1/1     Running   0             14m

# kubectl get infoscalecluster -A

NAMESPACE        NAME                   VERSION   CLUSTERID   STATE     DISKGROUPS           STATUS    AGE

infoscale-vtas   infoscalecluster-dev   9.1.0     22222       Running   vrts_kube_dg-22222   Healthy   14m

InfoScale SDS pods are created in the namespace you specify in cr.yaml. Fencing and CSI pods are created in the operator namespace.

After a successful InfoScale deployment, a disk group is automatically created. You can now create Persistent Volumes/ Persistent Volume Claims (PV / PVC) by using the corresponding Storage class.

See Adding nodes to an existing cluster.

See Removing nodes from an existing cluster.