This repository contains the source code and build methods to build a Kubernetes CSI driver that helps provision VMware Cloud Director Named Independent Disks as a storage solution for Kubernetes Applications. This uses VMware Cloud Director API for functionality and hence needs an appropriate VMware Cloud Director Installation. This CSI driver will help enable common scenarios with persistent volumes and stateful-sets using VMware Cloud Director Shareable Named Disks.
The version of the VMware Cloud Director API and Installation that are compatible for a given CSI container image are provided in the following compatibility matrix:
| CSI Version | CSE Version | VMware Cloud Director API | VMware Cloud Director Installation | Notes | Kubernetes Versions | docs |
|---|---|---|---|---|---|---|
| main | 4.2.0+ | 37.2+ | 10.4.2+ |
|
CSI main docs |
|
| 1.5.0 | 4.2.0+ | 36.0+ | 10.3.3.4+ |
|
|
CSI main docs |
| 1.4.1 | 4.1.0 | 36.0+ | 10.3.3.4+ |
|
|
CSI 1.4.z docs |
| 1.4.0 | 4.1.0 | 36.0+ | 10.3.3.4+ |
|
|
CSI 1.4.z docs |
| 1.3.2 | 4.0.z | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
|
|
CSI 1.3.z docs |
| 1.3.1 | 4.0.0 | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
|
|
CSI 1.3.z docs |
| 1.3.0 | 4.0.0 | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
|
|
CSI 1.3.z docs |
| 1.2.1 | 3.1.x | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
|
|
CSI 1.2.x docs |
| 1.2.0 | 3.1.x | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
|
|
CSI 1.2.x docs |
| 1.1.1 | 3.1.x | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
|
|
CSI 1.1.x docs |
| 1.1.0 | 3.1.x | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
|
|
CSI 1.1.x docs |
| 1.0.0 | 3.1.x | 36.0+ | 10.3.1+ (10.3.1 needs hot-patch to prevent VCD cell crashes in multi-cell environments) |
First cut with support for Named Independent Disks |
|
CSI 1.0.0 docs |
This extension is intended to be installed into a Kubernetes cluster installed with VMware Cloud Director as a Cloud Provider, by a user that has the rights as described in the sections below.
cloud-director-named-disk-csi-driver is distributed as a container image hosted at Distribution Harbor as projects.registry.vmware.com/vmware-cloud-director/cloud-director-named-disk-csi-driver:<CSI version>
This driver is in a GA state and will be supported in production.
Note: This driver is not impacted by the Apache Log4j open source component vulnerability.
| Feature | Support Scope |
|---|---|
| Storage Type |
|
| Provisioning |
|
| Access Modes |
|
| Volume |
|
| VolumeMode |
|
| Volume Expansion Support |
|
| Topology |
|
- VCD: VMware Cloud Director
- ClusterAdminRole: This is the role that has enough rights to create and administer a Kubernetes Cluster in VCD. This role can be created by cloning the vApp Author Role and then adding the following rights (details on adding the rights below can be found in the CSE docs):
- Full Control: VMWARE:CAPVCDCLUSTER
- Edit: VMWARE:CAPVCDCLUSTER
- View: VMWARE:CAPVCDCLUSTER
- ClusterAdminUser: For CSI functionality, there needs to be a set of additional rights added to the
ClusterAdminRoleas described in the "Additional Rights for CSI" section below. The Kubernetes Cluster needs to be created by a user belonging to this enhancedClusterAdminRole. For convenience, let us term this user as theClusterAdminUser.
In this section, we assume that the Kubernetes cluster is created using the Container Service Extension 4.0. However, that is not a mandatory requirement.
The ClusterAdminUser should have view access to the vApp containing the Kubernetes cluster. Since the ClusterAdminUser itself creates the cluster, it will have this access by default.
This ClusterAdminUser needs to be created from a ClusterAdminRole with the following additional rights:
- Access Control =>
- User => Manage user's own API TOKEN
- Organization VDC => Create a Shared Disk
Execute the following command to log HTTP requests to VCD and HTTP responses from VCD -
kubectl set env -n kube-system StatefulSet/csi-vcd-controllerplugin -c vcd-csi-plugin GOVCD_LOG_ON_SCREEN=true -oyaml
kubectl set env -n kube-system DaemonSet/csi-vcd-nodeplugin -c vcd-csi-plugin GOVCD_LOG_ON_SCREEN=true -oyamlOnce the above command is executed, CSI containers will start logging the HTTP requests and HTTP responses made via go-vcloud-director SDK.
The container logs can be obtained using the command kubectl logs -n kube-system <CSI pod name>
To stop logging the HTTP requests and responses from VCD, the following command can be executed -
kubectl set env -n kube-system Deployment/csi-vcd-controllerplugin -c vcd-csi-plugin GOVCD_LOG_ON_SCREEN-
kubectl set env -n kube-system DaemonSet/csi-vcd-nodeplugin -c vcd-csi-plugin GOVCD_LOG_ON_SCREEN-NOTE: Please make sure to collect the logs before and after enabling the wire log. The above commands update the CSI controller Deployment and CSI node-plugin DaemonSet, which creates a new CSI pods. The logs present in the old pods will be lost.
To perform an upgrade of the Container Storage Interface (CSI) from versions v1.2.0, v1.2.1, v1.3.0, v1.3.1, and v1.3.2, it is recommended to follow the following steps:
- Remove the current StatefulSet:
kubectl delete statefulset -n kube-system csi-vcd-controllerplugin- Apply the CSI 1.4 Controller CRS:
kubectl apply -f https://github.com/vmware/cloud-director-named-disk-csi-driver/blob/1.4.z/manifests/csi-controller-crs.yamlNOTE:
- These steps ensure a successful upgrade of CSI to the latest version (v1.4.0) and guarantee that the new CSI Deployment is properly installed within the Kubernetes environment.
- it is recommended not to manually delete any Persistent Volumes (PVs) or Persistent Volume Claims (PVCs) associated with a StatefulSet.
Please see CONTRIBUTING.md for instructions on how to contribute.