The CSI Plugin 1.1 for Unity is now available

Back in November 2019, we released the first version of the Kubernetes CSI plugin for the Unity array, you can read all about it here: https://volumes.blog/2019/11/22/the-csi-plugin-1-0-for-unity-is-now-available/

Now, we have just released the 1.1 version which includes the following updates:

The Plugin capabilities for this version that are supported are:

Persistent volume (PV) capabilities:
Create
List
Delete
Mount
Unmount
Supports mounting volume as file system.
Supports snapshot creation.
Supports creation of a volume from a snapshot.
Supports static volumes and dynamic volumes.
Supports Bare Metal machine type.
Supports Virtual Machine type.
Supports SINGLE_NODE_WRITER access mode.
Supports CentOS 7.6 as host operating system.
Supports Red Hat Enterprise Linux 7.6 as host operating system.
Supports Kubernetes version 1.14.
Supports Unity OE 5.0 l Supports FC Protocol.
Supports iSCSI Protocol.

Note: Volume Snapshots is an Alpha feature in Kubernetes. It is recommended for use only in short-lived testing clusters, as features in the Alpha stage have an increased risk of bugs and a lack of long-term support. See Kubernetes documentation at https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-stages for more information about feature stages.

Installation

Full details are in the Installation Guide and here is a summary of pre-requisites for the driver.
• Upstream Kubernetes 1.14.x, with specific feature gates enabled
• Docker daemon running and configured with MountFlags=shared on all k8s masters/nodes
• Helm and Tiller installed on k8s masters. (https://helm.sh/docs/using_helm/#quickstart)
• Make sure that the FC WWN (initiators) from the Kubernetes nodes are not part of any existing Hosts on the array(s) if FC protocol is to be used
• Make sure that all the nodes in the Kubernetes cluster have network connectivity zoned with the Unity Array in case of FC
• Make sure that the iSCSI IQN (initiators) from the Kubernetes nodes are not part of any existing Hosts on the array(s) if iSCSI protocol is to be used
• Make sure iscsi-initiator-utils is installed and iscsiadm works on all nodes in order to make use of iSCSI protocol
• Make sure device-mapper-multipath package is installed on all nodes and /etc/multipath.conf is present

Full details are in the Installation Guide.
1. Clone the repository from the URL – github.com/dell/csi-unity
2. Create myvalues.yaml file from the values.yaml file and edit some parameters for
installation. These include
– The Unity URL
– Username/Password to access Unisphere
– StoragePool ID
– Docker image for driver

3. Run the “install.unity” shell script
4. Installation works on helm 2 as well as helm 3

Upgrade Steps

Clone/Update the repository from the URL – github.com/dell/csi-unity
2. myvalues.yaml file from the values.yaml file can be the same as the one used for csi-unity v1.0
3. Uninstall v1.0 of the driver using “uninstall.unity” shell script
4. Optionally the user can upgrade the helm from v2 to v3 only after uninstalling the v1.0 driver
5. Install v1.1 using “install.unity” shell script

A correct installation should display
text similar to that below:
• 4 containers running in the controller pod
• 2 containers running in each node pod
• Storage classes unity and unity-iscsi
created
NAME READY STATUS RESTARTS AGE
unity-controller-0 4/4 Running 0 20s
unity-node-r5kdt 2/2 Running 0 20s
unity-node-tq5tj 2/2 Running 0 20s
…
StorageClasses:
NAME PROVISIONER AGE
unity (default) csi-unity.dellemc.com 21s
unity-iscsi csi-unity.dellemc.com 21s

About Custom Storage Class

StorageClass provides a means for passing parameters to Node/Controller
• Protocol defines the transfer protocol to be used for volume provisioning. This can be “FC” or “iSCSI” and if this parameter is not specified, the default value would be FC

Troubleshooting
Here are some installation failures that might be encountered and how to mitigate them.
• Warning about feature gates: Double check that you have applied all the features
to the indicated processes. Restart the kubelet when remediated.
• “kubectl describe pods unity-controller-0 –n unity” indicates the driver
image could not be loaded. You may need to put an insecure-registries entry in /etc/docker/daemon.json or login to the docker registry.
• “kubectl logs unity-controller-0 –n unity” logs shows the driver cannot authenticate (check your secret’s username and password).
• “kubectl logs unity-controller-0 –n unity” logs shows the driver failed to connect to the Unity because it couldn’t verify the certificates, then check the
unity-certs secret and ensure it is not empty or it has the valid certificates. Set unityInsecure: “true” for insecure connection.

Pod stuck at container creating state for over 1 minute and pod description says
“Unable to find device after multiple discovery attempts: rpc error: code =
NotFound desc = Check for disk path /dev/disk/by-id/wwn-
0xxxxxxxxxxxxxxxxxxxxxx not found readlink /dev/disk/by-id/wwn-
0xxxxxxxxxxxxxxxxxxxxxx: no such file or directory”
– Troubleshooting steps: Check if zoning is done right for FC channel OR if at least 1 iSCSI target is
up on the array
– If the problem still persists, execute /usr/bin/rescan-scsi-bus.sh -a -r. The script cleans up any stale
devices present on the node. Install sg3_utils package if the script is not present on the node.