When VMware first introduced support for Kubernetes, our first storage driver was the VCP, the in-tree vSphere Cloud Provider. Some might remember that this driver was referred to as Project Hatchway back in the day. This in-tree driver allows Kubernetes to consume vSphere storage for persistent volumes. One of draw-backs to the in-tree driver approach was that every storage vendor had to include their own driver in each Kubernetes distribution, which ballooned the core Kubernetes code and made maintenance difficult. Another drawback of this approach was that vendors typically had to wait for a new version of Kubernetes to release…
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,…
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,…
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…
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…
A short video explaining the role of the vSphere CSI (Container Storage Interface) driver and CNS (Cloud Native Storage) in both the vSphere with Kubernetes/Tanzu Supervisor Cluster and in the Tanzu Kubernetes Grid (TKG) Guest Cluster. This video discusses the role of the CSI driver in the Supervisor cluster, and the pvCSI driver (para-virtual CSI driver) in the TKG guest cluster. We also look at how the pvCSI communicates CNS control plane in the vCenter Server via the CSI driver in the Supervisor Cluster to request Persistent Volume operations on behalf of the Guest Cluster.
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…