Configuring cluster

Last published : Jun 12, 2026
Complete the following steps for each cluster.
Note: Ensure that you add a Kubernetes node only to a single InfoScale cluster.
  1. 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; fornodeName : \<Name of the first node\>, enternodeName : Primarynode. InfoScale on Kubernetes is a keyless deployment.

1.  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 renamingcr.yamland maintaining a custom resource for each cluster. The renamedcr.yamlis used to add more nodes to that InfoScale cluster.

1.  Run the following command on the master node.``kubectl create -f /infoscale-yamls-v9.1.0/kubernetes/cr.yaml``1.  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 -```txt
NAMESPACE   NAME                VERSION   CLUSTERID   STATE   AGE
.
.
\<Namespace\> <Name of the
             InfoScale cluster> 9.1.0  \<Cluster ID\> Running 25h
.
.

```txt
1.  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```txt
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
```txt

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](../../administering-infoscale-on-containers/adding-nodes-to-an-existing-cluster.md).

See [Removing nodes from an existing cluster](../../administering-infoscale-on-containers/removing-nodes-from-an-existing-cluster.md).