Deployment
You can deploy the WEKA CSI Plugin using the helm chart from the official WEKA ArtifactHub repository.
Prerequisites
Ensure the following prerequisites are met:
The privileged mode must be allowed on the Kubernetes cluster.
The following Kubernetes feature gates must be enabled: DevicePlugins, CSINodeInfo, CSIDriverRegistry, and ExpandCSIVolumes (all these gates are enabled by default).
A WEKA cluster is installed.
For snapshot and directory backing, a filesystem must be pre-defined on the WEKA cluster.
For filesystem backing, a filesystem group must be pre-defined on the WEKA cluster.
Your workstation has a valid connection to the Kubernetes worker nodes.
Prerequisites for using WekaFS transport
The WEKA client must be installed on the Kubernetes worker nodes. Follow these guidelines:
It is recommended to use a WEKA persistent client (a client that is part of the cluster) rather than a stateless client. See Add clients.
If the Kubernetes worker nodes are running on WEKA cluster backends (converged mode), ensure the WEKA processes are running before the
kubelet
process starts.
Prerequisites for Using NFS transport
The WEKA cluster must be installed and properly configured.
The NFS protocol must be enabled on the WEKA cluster.
An NFS interface group must be created on the WEKA cluster with at least one floating IP address. For optimal performance and load sharing, it's recommended to assign at least one IP address per protocol node in the cluster.
NFS interface group IP addresses must be accessible from the Kubernetes cluster nodes.
Guidelines for NFS Interface Groups and configuration
Setting the NFS Interface Group When defining multiple NFS interface groups on WEKA clusters, set the
pluginConfig.mountProtocol.interfaceGroupName
parameter in thevalues.yaml
file to specify the desired NFS interface group name. Failure to do so will result in the use of an arbitrary NFS interface group, which may lead to performance or networking issues.Configuring the NFS Client Group The WEKA CSI Plugin automatically creates an NFS Client group named
WekaCSIPluginClients
. During volume creation or publishing, the Kubernetes node IP address is added to this group. For larger deployments, instead of adding node IP addresses individually (which is more secure), consider defining a CIDR network range for the NFS Client group in the WEKA cluster. Use thepluginConfig.mountProtocol.nfsClientGroupName
parameter in thevalues.yaml
file to specify this group.Manual IP Address Specification In cloud or on-premises deployments where virtual IP addresses cannot be assigned to the interface group, the WEKA CSI Plugin can still be used with NFS transport. In this case, manually specify the IP addresses of the NFS protocol nodes as NFS target IP addresses (using API secret). Note that automatic failover for NFS connections will not be available, and the failure of a protocol node may disrupt NFS connections.
Installation
Install CSI Snapshot Controller and Snapshot CRDs
To enable Kubernetes-controlled snapshots, install the CSI Snapshot Controller and the CRD manifests.
On RedHat OpenShift Container Platform (OCP) those definitions might be preinstalled.
On the workstation you manage Kubernetes from, clone the CSI external-snapshotter from its GitHub repository.
Switch to the directory created by the Git clone.
Create and deploy the proper Custom Resource Definitions for the CSI external-snapshotter.
WEKAFS CSI
On your workstation, add the
csi-wekafs
repository:
Install the WEKA CSI Plugin. Run the following command:
Upgrade from any previous version to WEKA CSI Plugin v2.0
In WEKA CSI Plugin v2.0, the CSIDriver object has undergone changes. Specifically, CSIDriver objects are now immutable. Consequently, the upgrade process involves uninstalling the previous CSI version using Helm and subsequently installing the new version. It is important to note that the uninstall operation does not delete any existing secrets, StorageClasses, or PVC configurations.
If you plan to upgrade the existing WEKA CSI Plugin and enable directory quota enforcement for already existing volumes, bind the legacy volumes to a single secret. See the Bind legacy volumes to API section.
1. Prepare for the upgrade
Uninstall the existing CSI Plugin. Run the following command line:
Update the
csi-wekafs
helm repository. Run the following command line:
Download the
csi-wekafs
git repository.
2. Install the upgraded helm release
Run the following command line:
Upgrade from WEKA CSI Plugin WEKA 2.0 forward
If the WEKA CSI plugin source is v2.0 or higher, follow this workflow.
1. Update helm repo
Run the following command line:
2. Update the helm deployment
Run the following command line:
3. Elevate the OpenShift privileges
If the Kubernetes worker nodes run on RHEL and use OpenShift, elevate the OpenShift privileges for the WEKA CSI Plugin. (RHCoreOS on Kubernetes worker nodes supports NFS connections.)
To elevate the OpenShift privileges, run the following command lines:
4. Delete the CSI Plugin pods
The CSI Plugin fetches the WEKA filesystem cluster capabilities during the first login to the API endpoint and caches it throughout the login refresh token validity period to improve the efficiency and performance of the plugin.
However, the WEKA filesystem cluster upgrade might be unnoticed if performed during this time window, continuing to provision new volumes in the legacy mode.
To expedite the update of the Weka cluster capabilities, it is recommended to delete all the CSI Plugin pods to invalidate the cache. The pods are then restarted.
Run the following command lines:
Last updated