Following on from my previous post on this topic, a number of people reached out to ask about how to add read-write-many (RWX) volumes to a Pod in VKS. Again, for dynamic volumes, this is quite simple to do. But what about some static volumes which were initially created by the Volume Service. This is a summary of what I posted in my previous blog in relation to RWX volumes. “Since RWX volumes are back by vSAN File Shares in VCF 9.0, you will need to have vSAN File Service enabled and configured. You will also have to tell the…
I have been spending some time looking at the new Volume Service in VMware Cloud Foundation (VCF) 9.0. Through VCF Automation, is is possible for tenants of VCF to provision their own volumes. These volumes can be consumed by the VM Service, something that has been a part of the Supervisor Services for many years. However, it is also possible for workloads running in VKS, the vSphere Kubernetes Service, to consume the static volumes provisioned via the Volume Service. In this post, I will show you the steps to create a static volume via the Volume Service, and then create…
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…
A common question I get in relation to VMware Tanzu Kubernetes Grid (TKG) is whether or not it supports vSAN File Service, and specifically the read-write-many (RWX) feature for container volumes. To address this question, we need to make a distinction into how TKG is being provisioned. There is the multi-cloud version of TKG, which can run on vSphere, AWS or Azure, and are deployed from a TKG manager. Then there is the embedded TKG edition where ‘workload clusters’ are deployed in Namespaces via vSphere with Tanzu / VCF with Tanzu. To answer the question about whether or not TKG…