W E K A
4.3
4.3
  • WEKA v4.3 documentation
    • Documentation revision history
  • WEKA System Overview
    • WEKA Data Platform introduction
      • WEKA system functionality features
      • Converged WEKA system deployment
      • Optimize redundancy in WEKA deployments
    • SSD capacity management
    • Filesystems, object stores, and filesystem groups
    • WEKA networking
    • Data lifecycle management
    • WEKA client and mount modes
    • WEKA containers architecture overview
    • Glossary
  • Planning and Installation
    • Prerequisites and compatibility
    • WEKA cluster installation on bare metal servers
      • Plan the WEKA system hardware requirements
      • Obtain the WEKA installation packages
      • Install the WEKA cluster using the WMS with WSA
      • Install the WEKA cluster using the WSA
      • Manually install OS and WEKA on servers
      • Manually prepare the system for WEKA configuration
        • Broadcom adapter setup for WEKA system
        • Enable the SR-IOV
      • Configure the WEKA cluster using the WEKA Configurator
      • Manually configure the WEKA cluster using the resource generator
      • Perform post-configuration procedures
      • Add clients to an on-premises WEKA cluster
    • WEKA Cloud Deployment Manager Web (CDM Web) User Guide
    • WEKA Cloud Deployment Manager Local (CDM Local) User Guide
    • WEKA installation on AWS
      • WEKA installation on AWS using Terraform
        • Terraform-AWS-WEKA module description
        • Deployment on AWS using Terraform
        • Required services and supported regions
        • Supported EC2 instance types using Terraform
        • WEKA cluster auto-scaling in AWS
        • Detailed deployment tutorial: WEKA on AWS using Terraform
      • WEKA installation on AWS using the Cloud Formation
        • Self-service portal
        • CloudFormation template generator
        • Deployment types
        • AWS Outposts deployment
        • Supported EC2 instance types using Cloud Formation
        • Add clients to a WEKA cluster on AWS
        • Auto scaling group
        • Troubleshooting
      • Install SMB on AWS
    • WEKA installation on Azure
    • WEKA installation on GCP
      • WEKA project description
      • GCP-WEKA deployment Terraform package description
      • Deployment on GCP using Terraform
      • Required services and supported regions
      • Supported machine types and storage
      • Auto-scale instances in GCP
      • Add clients to a WEKA cluster on GCP
      • Troubleshooting
      • Detailed deployment tutorial: WEKA on GCP using Terraform
      • Google Kubernetes Engine and WEKA over POSIX deployment
  • Getting Started with WEKA
    • Manage the system using the WEKA GUI
    • Manage the system using the WEKA CLI
      • WEKA CLI hierarchy
      • CLI reference guide
    • Run first IOs with WEKA filesystem
    • Getting started with WEKA REST API
    • WEKA REST API and equivalent CLI commands
  • Performance
    • WEKA performance tests
      • Test environment details
  • WEKA Filesystems & Object Stores
    • Manage object stores
      • Manage object stores using the GUI
      • Manage object stores using the CLI
    • Manage filesystem groups
      • Manage filesystem groups using the GUI
      • Manage filesystem groups using the CLI
    • Manage filesystems
      • Manage filesystems using the GUI
      • Manage filesystems using the CLI
    • Attach or detach object store buckets
      • Attach or detach object store bucket using the GUI
      • Attach or detach object store buckets using the CLI
    • Advanced data lifecycle management
      • Advanced time-based policies for data storage location
      • Data management in tiered filesystems
      • Transition between tiered and SSD-only filesystems
      • Manual fetch and release of data
    • Mount filesystems
      • Mount filesystems from Single Client to Multiple Clusters (SCMC)
    • Snapshots
      • Manage snapshots using the GUI
      • Manage snapshots using the CLI
    • Snap-To-Object
      • Manage Snap-To-Object using the GUI
      • Manage Snap-To-Object using the CLI
    • Quota management
      • Manage quotas using the GUI
      • Manage quotas using the CLI
  • Additional Protocols
    • Additional protocol containers
    • Manage the NFS protocol
      • Supported NFS client mount parameters
      • Manage NFS networking using the GUI
      • Manage NFS networking using the CLI
    • Manage the S3 protocol
      • S3 cluster management
        • Manage the S3 service using the GUI
        • Manage the S3 service using the CLI
      • S3 buckets management
        • Manage S3 buckets using the GUI
        • Manage S3 buckets using the CLI
      • S3 users and authentication
        • Manage S3 users and authentication using the CLI
        • Manage S3 service accounts using the CLI
      • S3 rules information lifecycle management (ILM)
        • Manage S3 lifecycle rules using the GUI
        • Manage S3 lifecycle rules using the CLI
      • Audit S3 APIs
        • Configure audit webhook using the GUI
        • Configure audit webhook using the CLI
        • Example: How to use Splunk to audit S3
      • S3 supported APIs and limitations
      • S3 examples using boto3
      • Access S3 using AWS CLI
    • Manage the SMB protocol
      • Manage SMB using the GUI
      • Manage SMB using the CLI
  • Operation Guide
    • Alerts
      • Manage alerts using the GUI
      • Manage alerts using the CLI
      • List of alerts and corrective actions
    • Events
      • Manage events using the GUI
      • Manage events using the CLI
      • List of events
    • Statistics
      • Manage statistics using the GUI
      • Manage statistics using the CLI
      • List of statistics
    • Insights
    • System congestion
    • Security management
      • Obtain authentication tokens
      • KMS management
        • Manage KMS using the GUI
        • Manage KMS using the CLI
      • TLS certificate management
        • Manage the TLS certificate using the GUI
        • Manage the TLS certificate using the CLI
      • CA certificate management
        • Manage the CA certificate using the GUI
        • Manage the CA certificate using the CLI
      • Account lockout threshold policy management
        • Manage the account lockout threshold policy using GUI
        • Manage the account lockout threshold policy using CLI
      • Manage the login banner
        • Manage the login banner using the GUI
        • Manage the login banner using the CLI
      • Manage Cross-Origin Resource Sharing
    • User management
      • Manage users using the GUI
      • Manage users using the CLI
    • Organizations management
      • Manage organizations using the GUI
      • Manage organizations using the CLI
      • Mount authentication for organization filesystems
    • Expand and shrink cluster resources
      • Add a backend server
      • Expand specific resources of a container
      • Shrink a cluster
    • Background tasks
      • Set up a Data Services container for background tasks
      • Manage background tasks using the GUI
      • Manage background tasks using the CLI
    • Upgrade WEKA versions
  • Licensing
    • License overview
    • Classic license
  • Monitor the WEKA Cluster
    • Deploy monitoring tools using the WEKA Management Station (WMS)
    • WEKA Home - The WEKA support cloud
      • Local WEKA Home overview
      • Deploy Local WEKA Home v3.0 or higher
      • Deploy Local WEKA Home v2.x
      • Explore cluster insights and statistics
      • Manage alerts and integrations
      • Enforce security and compliance
      • Optimize support and data management
    • Set up the WEKAmon external monitoring
    • Set up the SnapTool external snapshots manager
  • Support
    • Get support for your WEKA system
    • Diagnostics management
      • Traces management
        • Manage traces using the GUI
        • Manage traces using the CLI
      • Protocols debug level management
        • Manage protocols debug level using the GUI
        • Manage protocols debug level using the CLI
      • Diagnostics data management
  • Best Practice Guides
    • WEKA and Slurm integration
      • Avoid conflicting CPU allocations
    • Storage expansion best practice
  • WEKApod
    • WEKApod Data Platform Appliance overview
    • WEKApod servers overview
    • Rack installation
    • WEKApod initial system setup and configuration
    • WEKApod support process
  • Appendices
    • WEKA CSI Plugin
      • Deployment
      • Storage class configurations
      • Tailor your storage class configuration with mount options
      • Dynamic and static provisioning
      • Launch an application using WEKA as the POD's storage
      • Add SELinux support
      • NFS transport failback
      • Upgrade legacy persistent volumes for capacity enforcement
      • Troubleshooting
    • Convert cluster to multi-container backend
    • Create a client image
    • Update WMS and WSA
    • BIOS tool
Powered by GitBook
On this page
  • API-based communication model
  • Prerequisites
  • Configure secret data
  • Connect K8s worker nodes to multiple WEKA clusters
  • Configure directory-backed StorageClass
  • Configure snapshot-backed StorageClass
  • Configure filesystem-backed StorageClass
  1. Appendices
  2. WEKA CSI Plugin

Storage class configurations

PreviousDeploymentNextTailor your storage class configuration with mount options

Last updated 7 months ago

The Weka CSI Plugin supports the following persistent volume types:

  • Dynamic: Persistent Volume Claim (PVC).

  • Static: Persistent Volume (PV).

The Weka CSI Plugin communicates with the WEKA cluster using REST API, leveraging this integration to provide extended capabilities, such as strictly enforcing volume capacity usage through integration with filesystem directory quota functionality. For details, see .

Starting from CSI Plugin v2.0, three StorageClass configurations are available:

  • Directory-backed StorageClass

  • Snapshot-backed StorageClass

  • Filesystem-backed StorageClass

API-based communication model

In the API-based model, the API endpoint addresses and authentication credentials must be provided to the WEKA CSI Plugin to establish a REST API connection with the WEKA cluster and perform configuration tasks.

The information is stored securely in , referred to by the Storage Class.

Adhere to the following:

  • The configuration described in this section applies to WEKA CSI Plugin version 0.8.4 and higher. To get all features, WEKA CSI Plugin version 2.0 is required.

  • Directory quota integration requires WEKA cluster version 3.13.0 and higher.

  • Snapshot quota integration requires WEKA cluster version 4.2 and higher.

  • Authenticated mounts for filesystems set with auth-required=true, and filesystems in the non-root organization, require WEKA cluster version 3.14.0 and higher.

The legacy communication model is deprecated and will be removed in the next release. If you are using the legacy communication model, replacing it with the API-based one is recommended.

Prerequisites

  • To provision any persistent volume type, a Storage Class must exist in Kubernetes deployment that matches the secret name and namespace in the WEKA cluster configuration.

  • For directory-backed and snapshot-backed storage class configurations, a filesystem must be pre-created on the WEKA cluster to create PVCs.

  • For the filesystem-backed StorageClass configuration, the filesystem name is generated automatically based on the PVC name, but the filesystem group name must be declared in the Storage Class configuration.

Configure secret data

  1. Create a secret data file (see the following example).

Example: csi-wekafs-api-secret.yaml file
csi-wekafs/examples/dynamic_api/csi-wekafs-api-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: csi-wekafs-api-secret
  namespace: csi-wekafs
type: Opaque
data:
  # A username to connect to the cluster API (base64-encoded)
  username: YWRtaW4=
  # A password to connect to the cluster API (base64-encoded)
  password: YWRtaW4=
  # An organization to connect to (default Root, base64-encoded)
  organization: Um9vdA==
  # A comma-separated list of cluster management endpoints. Format: <IP:port> (base64-encoded)
  # It is recommended to configure at least 2 management endpoints (cluster backend nodes), or a load-balancer if used
  # e.g. 172.31.15.113:14000,172.31.12.91:14000
  endpoints: MTcyLjMxLjQxLjU0OjE0MDAwLDE3Mi4zMS40Ny4xNTI6MTQwMDAsMTcyLjMxLjM4LjI1MDoxNDAwMCwxNzIuMzEuNDcuMTU1OjE0MDAwLDE3Mi4zMS4zMy45MToxNDAwMCwxNzIuMzEuMzguMTU1OjE0MDAwCg==
  # protocol to use for API connection (may be either http or https, base64-encoded)
  scheme: aHR0cA==
  # for multiple clusters setup, set a specific container name (base64-encoded)
  localContainerName: ""
  1. Apply the secret data and validate it is created successfully.

Apply the yaml file
# apply the secret .yaml file
$ kubectl apply -f csi-wekafs-api-secret.yaml

# Check the secret was successfully created
$ kubectl get secret csi-wekafs-api-secret -n csi-wekafs
NAME                    TYPE     DATA   AGE
csi-wekafs-api-secret   Opaque   5      7m

To provision CSI volumes on filesystems residing in non-root organizations or filesystems, set with auth-required=true. A CSI Plugin of version 0.8.4 and higher and WEKA cluster version 3.14 and higher are required.

Secret data parameters

All values in the secret data file must be in base64-encoded format.

Key
Description
Comments

username

The user name for API access to the WEKA cluster.

To run the CSI Plugin in a non-default organization, OrgAdmin permission is required. In other cases, ClusterAdmin permission is required.

password

The user password for API access to the Weka cluster.

organization

The WEKA organization name for the user. For a single organization, use Root.

You can use multiple secrets to access multiple organizations, which are specified in different storage classes.

scheme

The URL scheme that is used for communicating with the Weka cluster API.

http or https can be used. The user must ensure that the Weka cluster was configured to use the same connection scheme.

endpoints

Comma-separated list of endpoints consisting of IP address and port. For example,

172.31.15.113:14000,172.31.12.91:14000

For redundancy, specify the management IP addresses of at least 2 backend servers.

localContainerName

WEKA client container name for the client connected to the relevant WEKA cluster. Only required when connecting a K8s worker node to multiple WEKA clusters. For a single cluster, do not set this parameter.

All local container names relevant to a specific WEKA cluster must be the same across all k8s worker nodes.

Connect K8s worker nodes to multiple WEKA clusters

A single K8s worker node can be connected to multiple WEKA clusters (maximum 7 clusters) simultaneously.

Procedure

  1. For each k8s worker node, create a number of WEKA client containers according to the number of clusters you want to connect to. The WEKA client container name must be according to the WEKA cluster that is connected to. For example, to connect to 7 WEKA clusters, it is required to create 7 WEKA client containers named client 1, client 2, and so on.

  2. Create secret data files for each WEKA cluster. In the localContainerName set the relevant client container name. For example, for client 1 set the name of the client container connected to cluster 1.

  3. Configure storage classes using the relevant secret data file.

Filesystem names used for k8s (defined in the storage classes) must be unique across all clusters.

Related topic

Mount filesystems from Single Client to Multiple Clusters (SCMC)

Configure directory-backed StorageClass

  1. Create a directory-backed storage class yaml file (see the following example).

Example: storageclass-wekafs-dir-api.yaml
csi-wekafs/examples/dynamic_api/storageclass-wekafs-dir-api.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-wekafs-dir-api
provisioner: csi.weka.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  volumeType: dir/v1
  filesystemName: default
  capacityEnforcement: HARD
  # optional parameters setting UID, GID and permissions on volume
  # UID of the volume owner, default 0 (root)
  #ownerUid: "1000"
  # GID of the volume owner, default 0 (root)
  #ownerGid: "1000"
  # permissions in Unix octal format, default "0750"
  #permissions: "0775"
  # name of the secret that stores API credentials for a cluster
  # change the name of secret to match secret of a particular cluster (if you have several Weka clusters)
  csi.storage.k8s.io/provisioner-secret-name: &secretName csi-wekafs-api-secret
  # change the name of the namespace in which the cluster API credentials
  csi.storage.k8s.io/provisioner-secret-namespace: &secretNamespace csi-wekafs
  # do not change anything below this line, or set to same parameters as above
  csi.storage.k8s.io/controller-publish-secret-name: *secretName
  csi.storage.k8s.io/controller-publish-secret-namespace: *secretNamespace
  csi.storage.k8s.io/controller-expand-secret-name: *secretName
  csi.storage.k8s.io/controller-expand-secret-namespace: *secretNamespace
  csi.storage.k8s.io/node-stage-secret-name: *secretName
  csi.storage.k8s.io/node-stage-secret-namespace: *secretNamespace
  csi.storage.k8s.io/node-publish-secret-name: *secretName
  csi.storage.k8s.io/node-publish-secret-namespace: *secretNamespace

  1. Apply the directory-backed storage class and validate it is created successfully.

Apply the yaml file
# apply the storageclass .yaml file
$ kubectl apply -f storageclass-wekafs-dir-api.yaml
storageclass.storage.k8s.io/storageclass-wekafs-dir-api created

# check the storageclass resource has been created successfully 
$ kubectl get sc
NAME                           PROVISIONER         RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
storageclass-wekafs-dir-api    csi.weka.io         Delete          Immediate           true                   75s

Adhere to the following:

  • You can define multiple storage classes different filesystem groups for filesystem backups.

  • You can use the same secret for multiple storage classes, as long as the credentials are valid to access the filesystem.

  • You can use several secret data files for different organizations on the same WEKA cluster, or for different WEKA clusters spanning across the same Kubernetes cluster.

Directory-backed StorageClass parameters

Parameter
Description

filesystemName

The name of the WEKA filesystem to create directories as Kubernetes volumes.

The filesystem must exist on the WEKA cluster.

The filesystem may not be defined as authenticated.

capacityEnforcement

Possible values: HARD or SOFT.

  • HARD: Strictly enforce quota and deny any write operation to the persistent volume consumer until space is freed.

  • SOFT: Do not strictly enforce the quota. If the quota is reached, create an alert on the WEKA cluster.

ownerUid

Effective User ID of the owner user for the provisioned CSI volume. Might be required for application deployments running under non-root accounts. Defaults to 0 CSI plugin v2.0 adds fsgroup features so this is optional.

ownerGid

Effective Group ID of the owner user for the provisioned CSI volume. Might be required for application deployments running under non-root accounts. Defaults to 0 CSI plugin v2.0 adds fsgroup features so this is optional.

permissions

Unix permissions for the provisioned volume root directory in octal format. It must be set in quotes. Defaults to 0775

csi.storage.k8s.io/provisioner-secret-name

Name of the K8s secret. For example, csi-wekafs-api-secret.

It is recommended to use a trust anchor definition to avoid mistakes because the same value (&secretName) must be specified in the additional parameters according to the CSI specifications. Format: see Example: storageclass-wekafs-dir-api.yaml above (the additional parameters appear at the end of the example).

csi.storage.k8s.io/provisioner-secret-namespace

The namespace the secret is located in.

The secret may reside in the CSI plugin namespace or a different one.

It is recommended to use a trust anchor definition to avoid mistakes because the same value (&secretNamespace) must be specified in the additional parameters according to the CSI specifications. Format: see Example: storageclass-wekafs-dir-api.yaml above (the additional parameters appear at the end of the example).

Configure snapshot-backed StorageClass

  1. Create a snapshot-backed StorageClass yaml file (see the following example).

Example: storageclass-wekafs-snap-api.yaml
csi-wekafs/examples/dynamic_snapshot/storageclass-wekafs-snap-api.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-wekafs-snap-api
provisioner: csi.weka.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  volumeType: weka/v2  # this line can be ommitted completely

  # name of an EMPTY filesystem to provision volumes on
  filesystemName: default

  # name of the secret that stores API credentials for a cluster
  # change the name of secret to match secret of a particular cluster (if you have several Weka clusters)
  csi.storage.k8s.io/provisioner-secret-name: &secretName csi-wekafs-api-secret
  # change the name of the namespace in which the cluster API credentials
  csi.storage.k8s.io/provisioner-secret-namespace: &secretNamespace csi-wekafs
  # do not change anything below this line, or set to same parameters as above
  csi.storage.k8s.io/controller-publish-secret-name: *secretName
  csi.storage.k8s.io/controller-publish-secret-namespace: *secretNamespace
  csi.storage.k8s.io/controller-expand-secret-name: *secretName
  csi.storage.k8s.io/controller-expand-secret-namespace: *secretNamespace
  csi.storage.k8s.io/node-stage-secret-name: *secretName
  csi.storage.k8s.io/node-stage-secret-namespace: *secretNamespace
  csi.storage.k8s.io/node-publish-secret-name: *secretName
  csi.storage.k8s.io/node-publish-secret-namespace: *secretNamespace
  1. Apply the snapshot-backed StorageClass and validate it is created successfully.

Apply the yaml file
# apply the storageclass.yaml file
$ kubectl apply -f storageclass-wekafs-snap-api.yaml
storageclass.storage.k8s.io/storageclass-wekafs-snap-api created

# check the storageclass resource has been created successfully 
$ kubectl get sc
NAME                           PROVISIONER         RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
storageclass-wekafs-snap-api   csi.weka.io         Delete          Immediate           true                   75s

Adhere to the following:

  • You can define multiple storage classes with different filesystems.

  • You can use the same secret for multiple storage classes, as long as the credentials are valid to access the filesystem.

  • You can use several secret data files for different organizations on the same WEKA cluster, or for different WEKA clusters spanning across the same Kubernetes cluster.

snapshot-backed StorageClass parameters

Parameter
Description

volumeType

The CSI Plugin volume type.

For snapshot-backed StorageClass configurations, use weka/v2.

filesystemName

The name of the WEKA filesystem to create snapshots as Kubernetes volumes.

The filesystem must exist on the WEKA cluster and be empty.

csi.storage.k8s.io/provisioner-secret-name

Name of the K8s secret. For example, csi-wekafs-api-secret.

It is recommended to use a trust anchor definition to avoid mistakes because the same value must be specified in the additional parameters according to the CSI specifications. Format: see Example: storageclass-wekafs-snap-api.yaml above (the additional parameters appear at the end of the example).

csi.storage.k8s.io/provisioner-secret-namespace

The namespace the secret is located in.

The secret must be located in a different namespace than the installed CSI Plugin.

It is recommended to use a trust anchor definition to avoid mistakes because the same value must be specified in the additional parameters according to the CSI specifications. Format: see Example: storageclass-wekafs-snap-api.yaml above (the additional parameters appear at the end of the example).

Configure filesystem-backed StorageClass

  1. Create a filesystem-backed StorageClass yaml file (see the following example).

Example: storageclass-wekafs-fs-api.yaml
csi-wekafs/examples/dynamic_filesystem/storageclass-wekafs-fs-api.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-wekafs-fs-api
provisioner: csi.weka.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  volumeType: weka/v2  # this line can be ommitted completely

  # name of the filesystem group to create FS in.
  filesystemGroupName: default
  # minimum size of filesystem to create (preallocate space for snapshots and derived volumes)
  initialFilesystemSizeGB: "100"

  # name of the secret that stores API credentials for a cluster
  # change the name of secret to match secret of a particular cluster (if you have several Weka clusters)
  csi.storage.k8s.io/provisioner-secret-name: &secretName csi-wekafs-api-secret
  # change the name of the namespace in which the cluster API credentials
  csi.storage.k8s.io/provisioner-secret-namespace: &secretNamespace csi-wekafs
  # do not change anything below this line, or set to same parameters as above
  csi.storage.k8s.io/controller-publish-secret-name: *secretName
  csi.storage.k8s.io/controller-publish-secret-namespace: *secretNamespace
  csi.storage.k8s.io/controller-expand-secret-name: *secretName
  csi.storage.k8s.io/controller-expand-secret-namespace: *secretNamespace
  csi.storage.k8s.io/node-stage-secret-name: *secretName
  csi.storage.k8s.io/node-stage-secret-namespace: *secretNamespace
  csi.storage.k8s.io/node-publish-secret-name: *secretName
  csi.storage.k8s.io/node-publish-secret-namespace: *secretNamespace
  1. Apply the filesystem-backed StorageClass and validate it is created successfully.

Apply the yaml file
# apply the storageclass.yaml file
$ kubectl apply -f storageclass-wekafs-fs-api.yaml
storageclass.storage.k8s.io/storageclass-wekafs-fs-api created

# check the storageclass resource has been created successfully 
$ kubectl get sc
NAME                           PROVISIONER         RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
storageclass-wekafs-fs-api     csi.weka.io         Delete          Immediate           true                   75s

Adhere to the following:

  • You can define multiple storage classes with different filesystems.

  • You can use the same secret for multiple storage classes, as long as the credentials are valid to access the filesystem.

  • You can use several secret data files for different organizations on the same WEKA cluster, or for different WEKA clusters spanning across the same Kubernetes cluster.

filesystem-backed StorageClass parameters

Parameter
Description

volumeType

The CSI Plugin volume type.

For filesystem-backed StorageClass configurations, use weka/v2.

filesystemGroupName

The name of the WEKA filesystem to create filesystems as Kubernetes volumes. The filesystem group must exist on the WEKA cluster.

initialFilesystemSizeGB

The default size to create new filesystems. Set this parameter in the following cases:

  • When the PVC requested size is smaller than the specified value.

  • For additional space required by snapshots of a volume or snapshot-backed volumes derived from this filesystem.

csi.storage.k8s.io/provisioner-secret-name

Name of the K8s secret. For example, csi-wekafs-api-secret.

It is recommended to use a trust anchor definition to avoid mistakes because the same value must be specified in the additional parameters below, according to the CSI specifications. Format: see Example: storageclass-wekafs-snap-api.yaml above (the additional parameters appear at the end of the example).

csi.storage.k8s.io/provisioner-secret-namespace

The namespace the secret is located in.

The secret must be located in a different namespace than the installed CSI Plugin.

It is recommended to use a trust anchor definition to avoid mistakes because the same value must be specified in the additional parameters according to the CSI specifications. Format: see Example: storageclass-wekafs-fs-api.yaml above (the additional parameters appear at the end of the example).

It is recommended that you create a separate user for the CSI Plugin. See .

For details, see .

Quota management
Kubernetes secret
User management
Connect k8s worker nodes to multiple WEKA clusters
k8s worker nodes connected to multiple WEKA clusters