Adding an SMB-based persistent storage

In Kubernetes deployments, workloads such as microservices or stateful services often need to share files or preserve data beyond the lifecycle of a pod. This could be for storing configuration files, sharing assets, or keeping logs accessible across multiple services. A shared network file system solves this need.

For environments using Windows File Server, the SMB (Server Message Block) protocol offers a reliable way to share files across systems on a network. Integrating SMB-based shared storage with Kubernetes allows multiple pods—running on different nodes—to access the same files, enabling:

Shared configuration and assets across workloads
Centralized storage for logs, reports, or generated artifacts
Cross-platform interoperability with Windows systems

To connect a Kubernetes Cluster to SMB storage, the SMB CSI (Container Storage Interface) Driver is used. This driver allows Kubernetes to treat SMB shares as Persistent Volumes (PVs)—storage resources that exist independently of pods. The pods request access to these volumes through PersistentVolumeClaims (PVCs). When a pod using such a PVC starts, Kubernetes automatically mounts the SMB share, giving the pod seamless read/write access to the files stored there.

This document describes the process of configuring SMB-based shared storage in a Kubernetes Cluster using the SMB CSI Driver.

Implementation steps

	The provided example YAML files can be applied without modification (other than updating username and password). For multiple environments (dev, qa, prod), use different StorageClasses, PVs, PVCs, volumeHandles, secret, and namespaces.

Add and update the SMB Helm Repo by running the following two commands in the same order:

Code

helm repo add smb https://raw.githubusercontent.com/kubernetes-csi/csi-driver-smb/master/charts

Code

Helm repo update

Install the SMB CSI Driver in the Kubernetes Cluster by running the install command as shown in the following example:

Code

helm install smb-csi smb/smb-csi-driver -n kube-system

	• smb-csi – Helm release name for this installation. • smb/smb-csi-driver – Name of the chart from the Helm repo. • kube-system – Namespace where the CSI driver must be installed.

Create a storageClass, for example, smb-storageClass.yaml, using the following definition:

Code

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: smb-static-dev
provisioner: smb.csi.k8s.io
parameters: {}
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - vers=3.0
reclaimPolicy: Retain
volumeBindingMode: Immediate

	Change smb-static-dev (storageClass name) to a unique name per environment (For example, smb-static-qa).

Create a Secret for SMB Credentials, for example, smb-secret.yaml, using the following definition:

Code

apiVersion: v1
kind: Secret
metadata:
  name: smbcreds-dev
  namespace: adeptia-dev   # Change to your target namespace
type: Opaque
data:
  username:< YWRlcHRpYQ==>   # base64 for 'adeptia' 
  password: <YWRlcHRpYQ== >  # base64 for 'adeptia'

	• Change the name and namespace for the secret to match your environment. Ensure that they are unique across the cluster. • Encode your SMB username and password in Base64, and replace the placeholder values in the secret.

Create a Persistent Volume (PV), for example, smb-pv.yaml, to access the Windows File Server SMB shares using the following definition.

Code

apiVersion: v1
kind: PersistentVolume
metadata:
  name: smb-static-pv-dev
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  storageClassName: smb-static-dev
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: smb.csi.k8s.io
    volumeHandle: unique-smb-handle-dev # MUST BE UNIQUE
    volumeAttributes:
      source: "//hostname/AdeptiaShare"
      mountOptions: '["vers=3.0","uid=1000","gid=2000","dir_mode=0777","file_mode=0777"]'
    nodeStageSecretRef:
      name: smbcreds-dev
      namespace: adeptia-dev

• Change smb-static-pv-dev (PV name) and unique-smb-handle-dev (volumeHandle name) to unique names per environment.
• storageClassName must match the name, for example, smb-static-dev, defined for the storageClass you created.
• csi > volumeAtrributes > source must point to your SMB server path, for example, //hostname/AdeptiaShare.
• csi > nodeStageSecretRef > name must match the name, for example, smbcreds-dev, defined for the secret you created.
• csi > nodeStageSecretRef > namespace should match the namespace where the secret is created (for example, adeptia-dev).

Create a Persistent Volume Claim (PVC), for example, smb-pvc.yaml.

Code

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: smb-static-pvc
  namespace: adeptia-dev
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: smb-static-dev
  resources:
    requests:
      storage: 10Gi
  volumeName: smb-static-pv-dev

	• Change smb-static-pvc (PVC name) to a unique name per environment. • namespace should match the namespace, for example, adeptia-dev, where the secret is created. • storageClassName must match the name, for example, smb-static-dev, defined for the storageClass you created.

Apply PV and PVC configurations by running the following two commands:

Code

kubectl apply -f smb-pv.yaml
kubectl apply -f smb-pvc.yaml

Open the Adeptia Automate application's global values.yaml file and configure the variables in the section additionalvolumeMounts as indicated below:

Code

additionalVolumeMounts:
   - name: smb-volume-dev
     mountPath: /mnt/AdeptiaShare
additionalVolumes:
   - name: smb-volume-dev
     persistentVolumeClaim:
     claimName: smb-static-pvc-dev

	• Change smb-volume-dev (Volume Mount name) to a unique name per environment (for example, smb-volume-qa). • Replace /mnt/AdeptiaShare with the actual path of the SMB share. • claimName must match the name of the PVC you created, for example, smb-static-pvc-dev.

Run the install or upgrade command as shown below to bring the changes into effect:

• If you are performing a fresh installation of Adeptia Automate along with the configurations described in this document, run the install command.
• If Adeptia Automate is already deployed and you only need to configure SMB-based persistent storage, run the upgrade command. Before running the upgrade, make sure that all other configurations in the global values.yaml file are identical to those used during the initial deployment of the application.

Install:

Code

helm install <Name of the release> adeptia-connect/adeptia-connect --version <The version of Adeptia Automate that you want to deploy> -f <Path of the values.yaml file> -n <Namespace where you want to deploy the application>

Upgrade:

Code

helm upgrade -i <Name of the release> adeptia-connect/adeptia-connect --version <version of the application, for example, 4.6.0> -f <Complete path of the global values.yaml> -n <Namespace>

Implementation steps ​

Implementation steps