Workspace pods use Persistent Volume Claims (PVCs), which are bound to the physical Persistent Volumes (PVs) with ReadWriteOnce access mode. The way how Che server uses PVCs for workspaces is configurable and it’s called PVC strategy:

strategy details pros cons

unique

One PVC per workspace volume or user-defined PVC

Storage isolation

An undefined number of PVs is required

per-workspace

One PVC for one workspace

Easier to manage and control storage compared to unique stategy

PV count still is not known and depends on workspaces number

common (default)

One PVC for all workspaces in one kubernetes namespace

Easy to manage and control storage

If PV does not support ReadWriteMany (RWX) access mode then workspaces must be in a separate kubernetes namespaces

Or there must not be more than 1 running workspace per namespace at the same time

See how to configure namespace strategy

Unique PVC strategy

How the unique PVC strategy works

Every Che Volume of workspace gets its own PVC, which means workspace PVCs are created when a workspace starts for the first time. Workspace PVCs are deleted when a corresponding workspace is deleted.

User-defined PVCs are created with few modifications:

  • they are provisioned with generated names to guarantee that it is not conflicting with other PVCs in namespace;

  • subpaths of mount volumes that reference user-defined PVCs are prefixed with {workspace id}/{PVC name}. It is done to have the same data structure on PV on different PVC strategies(more);

Common PVC Strategy

How the common PVC strategy works

All workspaces (within one {k8s-namespace}) use the same PVC to store data in their declared volumes (projects and workspace logs by default and whatever additional volumes that a user can define.)

User-defined PVCs are ignored and volumes that reference PVCs are replaced with volume that references common PVC. The corresponding containers volume mounts are relinked to common volume and subpaths are prefixed with '{workspaceId}/{originalPVCName}' (more).

User-defined PVC name is used as Che Volume name. It means that if Machine is configured to use Che Volume with the same name as user-defined PVC has then they will use the same shared folder in common PVC.

When a workspace is deleted, a corresponding subdirectory (${ws-id}) is deleted in the PV directory.

Restrictions on using the common PVC strategy

When the common strategy is used and a workspace PVC access mode is ReadWriteOnce (RWO), only one {admin-context} node can simultaneously use the PVC. If there are several nodes, you can use the common strategy, but: - the workspace PVC access mode must be reconfigured to ReadWriteMany (RWM), so multiple nodes can use this PVC simultaneously. - the only one workspace in the same namespace may be running. See how to configure namespace strategy and running workspace count

Per workspace PVC strategy

How the per-workspace PVC strategy works

The per-workspace strategy works similarly to the common PVC strategy. The only difference is that all workspace volumes (but not all workspaces) use the same PVC to store data (projects and workspace logs by default and any additional volumes that a user can define).

How the subpaths are used in PVCs

/pv0001
  /workspaceid1
  /workspaceid2
  /workspaceidn
    /che-logs
    /projects
    /<volume1>
    /<volume2>
    /<User-defined PVC name 1 | volume 3>
    ...

Volumes can be anything that a user defines as volumes for workspace machines. The volume name is equal to the directory name in ${PV}/${ws-id}.

Configuring a per-workspace strategy using the Helm chart

The following section describes how to configure workspace PVCs strategies of a Che server using the Helm chart.

Note: it’s not recommended to reconfigure PVC strategies on an existing Che cluster with existing workspaces. After that workspaces will lost their data.

A Helm Chart is a Kubernetes extension for defining, installing, and upgrading Kubernetes applications.

When deploying Che using the Helm chart, configure the workspace PVC strategy by setting values for global.pvcStrategy. To do so, add the following option to the helm install or helm upgrade command:

$ helm install --set global.pvcStrategy=<common>

or:

$ helm upgrade --set global.pvcStrategy=<common>

Depending on the strategy used, replace the <common> option in the above example with unique or per-workspace.

Configuring a per-workspace strategy using the Operator

The following section describes how to configure workspace PVCs strategies of a Che server using the Operator.

Note: it’s not recommended to reconfigure PVC strategies on an existing Che cluster with existing workspaces. After that workspaces will lost their data.

Operators are software extensions to Kubernetes that use custom resources to manage applications and their components.

When deploying Che using the Operator, configure the intended strategy by modifying the spec.storage.pvcStrategy property of the CheCluster custom resource object YAML file. To activate changes done to CheCluster YAML file, do one of the following:

  • Create a new cluster by executing the kubectl apply command. For example:

    $ kubectl apply -f <my-cluster.yaml>

  • Update the YAML file properties of an already running cluster by executing the kubectl patch command. For example:

    $ kubectl patch checluster eclipse-che --type=json -p '[{"op": "replace", "path": "/spec/storage/pvcStrategy", "value": "common"}]'

Depending on the strategy used, replace the <common> option in the above example with unique or per-workspace.