CNS-CSI 2.1 with vSphere 7.0U1 – What’s new?

In this post, we will look at what is in the new release of the vSphere CSI driver for Kubernetes, as well as enhancements to Cloud Native Storage (CNS)  that handles CSI request on the vSphere infrastructure. CSI improvements will be available in version 2.1 of the driver, and the CNS components will be part of vSphere 7.0U1. Both are required for the features discussed here. The main objective of this release is two-fold: (a) to add CNS-CSI features to vSphere with Kubernetes so that it has a similar specification to the CNS-CSI features that are available with vanilla Kubernetes,…

Failed to deploy PV to local volume – “No compatible datastore found for storagePolicy”

This is something that I “spun my wheels” on a little bit last week, so I decided I’d write a short article to explain the issue in a bit more detail. This is related to the provisioning of a Persistent Volume on the Supervisor cluster of a vSphere with Kubernetes deployment. I had a local VMFS volume on one of my hosts, so I went ahead and tagged the volume using vSphere Tagging. I then built a tag-based storage policy so that when that policy is selected for provisioning, the objects that get provisioned would be placed on that local,…

Helm Chart for vSphere CSI driver

After recently presenting on the topic of the vSphere CSI driver, I received feedback from a number of different people that the current install mechanism is a little long-winder and prone to error. The request was for a Helm Chart to make things a little easier. I spoke to a few people about this internally, and while we have some long term plans to make this process easier, we didn’t have any plans in the short term. At that point, I reached out to my colleague and good pal, Myles Gray, and we decided we would try to create our…

Encrypting Kubernetes Persistent Volumes on vSphere (Video)

In this video, we look at how to create a Storage Policy Based Management (SPBM) with the VM Encryption feature which can be used with vSphere CSI/CNS to create a Kubernetes Storage Class that encrypts Persistent Volumes. This feature is only available with the CSI 2.0 driver for native, upstream Kubernetes deployed on vSphere 7.0 (at the time of writing). You will also need to have a Key Management Server available to the vSphere host to create a policy that allows encryption. Finally, encrypted Persistent Volumes can only be attached to encrypted virtual machines, meaning that at least one of…

vSAN File Services and Cloud Native Storage integration (Video)

In this short video, I want to show some of the integration points between vSAN 7.0 File Services, and Cloud Native Storage (CNS). We will use the CSI driver that ships with vSphere 7.0 to provision a new read-write-many persistent volume backed by a vSAN file share. A read-write-many persistent volume is one that can be accessed by multiple Kubernetes Pods simultaneously. I will then show how CNS provides the vSphere client all sorts of useful information about the volume. This information is invaluable to a vSphere Admin when trying to figure out how vSphere storage is being consumed when…

Static Persistent Volumes and Cloud Native Storage

Recently I was asked if “statically” provisioned persistent volumes (PVs) in native, vanilla, Kubernetes would be handled by Cloud Native Storage (CNS) in vSphere 7.0 and in turn appear in the vSphere client, just like a dynamically provisioned persistent volume. The short answer is yes, this is supported and works. The details on how to do this are shown here in this post. I am going to use a file-based (NFS) volume for this “static” PV test. Note that there are two ways of provisioning a static file-based volumes. The first is to use the in-tree NFS driver. These are…

Read-Only Persistent Volumes on vSAN File Services

I’m writing this post because of a misconception I had regarding how read-only volumes were configured in Kubernetes. I thought this was controlled by the accessModes parameter in the PersistentVolumeClaim manifest file. This is not the case. It is controlled from the Pod, which to me seems a bit strange. Why would this not be controlled from the PVC manifest? One of our engineers pointed me to a few Kubernetes discussions on the behaviour of accessModes and readOnly here and here. It would seem that I am not the only one confused by this behaviour. In this post, I deploy…