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…

Cloud Native Storage (CNS) in vSphere with Kubernetes/Tanzu (Video)

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.

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…

vSphere CSI driver versions and capabilities

The vSphere Container Storage Interface (CSI) driver is what enables Kubernetes clusters running on vSphere to provision persistent volumes on vSphere storage. This applies to both native Kubernetes clusters, and vSphere with Kubernetes. With the release of vSphere 7.0 and vSphere with Kubernetes (formerly Project Pacific) there are now a number of different flavors of the vSphere CSI driver available. [Update] Before going any further, it is worth highlighting the differences between what we term native Kubernetes and vSphere with Kubernetes. Native Kubernetes has many flavors, such as VMware Tanzu Kubernetes Grid, VMware Tanzu Kubernetes Grid Integrated (TKGI) formerly known…

Read-Write-Many Persistent Volumes with vSAN 7 File Services

A few weeks back, just after the vSphere 7.0 launch event, I wrote an article about Native File Services in vSAN 7.0. I had a few questions asking why we decided on NFS support in this initial release, and not something like SMB or some other protocol. The reason is quite straight-forward. We are positioning vSAN as a platform for both traditional virtual machine workloads and newer containerized workloads. We chose NFS to address a storage requirement in Kubernetes, namely a way to share Persistent Volumes between Pods. To date, the vSphere CSI driver only provisioned block based Persistent Volumes…