A short video to demonstrate how network access to Kubernetes Persistent Volumes, that are backed by vSAN File Service file shares, can be controlled. This allows an administrator to determine who has read-write access and who has read-only access to a volume, based on the network from which they are accessing the volume. This involves modifying the configuration file of the vSphere CSI driver, as shown in the following demonstration. The root squash parameter can also be controlled using this method. This links to a more detailed step-by-step write-up on how to configure the CSI driver configuration file and control…
A short video to demonstrate how vSAN File Service file shares, which are used to back dynamically created Kubernetes read-write-many persistent volumes (PVs) have an implicit hard quota associated with them. Read-Write-Many (RXW) PVs are volumes which can be shared between multiple Kubernetes Pods. For more details about this feature, please check out this earlier blog post.
Last week I looked at how quotas were implicit on Kubernetes RWX Persistent Volumes which were instantiated on vSAN File Service file shares. This got me thinking about another feature of Kubernetes Persistent Volumes – how could some of the other parameters associated with file shares be controlled? In particular, I wanted to control which networks could access a volume, what access permissions were allowed from that network and whether we could squash root privileges when a root user accesses a volume? All of these options are configurable from the vSphere client and are very visible when creating file shares…
Earlier this week, I participated in a customer call around vSAN File Service and Kubernetes Persistent Volumes. I have highlighted the dynamic Read-Write-Many Persistent Volume feature of our vSphere CSI driver in conjunction with vSAN File Service before. Read-Write-Many (RWX) volumes are volumes that can be accessed/shared by multiple containers. During the discussion, one question came up in relation to quota, and if it can be applied to Persistent Volumes which are backed by file shares from vSAN File Service, which is the purpose of this post. Now, for those of you who are familiar with vSAN File Service, you…
Last week, I wrote an article which described how to use a combination of vSAN Availability Rules with Tag Based Placement Rules in vSAN Storage Policies to select one specific vSAN datastore for object placement when many vSAN datastores might appear as compatible candidates. I create this short 3m30s video to show how to do this in practice.
I was recently working in an environment where my vCenter server was managing two vSAN clusters, each with its own datastore. I wanted to be able to choose which datastore to provision to via storage policy, but came across some unexpected behaviour. When I configured my vSAN Rule and my Tag Rule, it seems that both datastores would appear as compliant to the policy. I found out the reason, and decided to write it up as I had never known this was how policies AND and OR rules behaved until now. Setting up Tags I created a Tags Category called…
I know that there has been a lot of content already written in relation to the latest 7.0U2 release of vSAN. My good pal Duncan has done a considerable amount on work to highlight the new features, and has an excellent set of YouTube videos that you can review at your convenience. However, I thought I would create a bite-sized overview of some of the big ticket items that are in the vSAN 7.0U2 release, as many of my readers have asked me about some of these features in the past. I’m not covering all of the features, of which…