I’ve been using the NSX Advanced Load Balancer for many of my experiments in the lab. Sometimes I build configurations that do not work correctly, especially around TKG. From time to time, I find that my TKG management cluster does not stand up successfully, and so I have to manually clear it down and start over. From time to time, this has left my NSX ALB with some objects that also need to be manually cleaned up. While I can delete Virtual Services and Virtual IP Addresses with ease in the NSX ALB portal/UI, I am sometimes left in a…
As I continue to look at TKG version 1.4, I wanted to start using VMware NSX Advanced Load Balancer integrated with the Project Contour (Envoy Ingress) package. Project Contour is a control plane for the Envoy Ingress that is included with the package, but which also has the ability to dynamically change the Ingress configuration. It is included as an add-on package to TKG v1.4. To use it, I deployed a TKG management cluster and a TKG workload cluster using an NSX ALB (v 20.1.5) for the Load Balancing Service. I then proceeded to deploy the Contour package. While the…
Over the last week or so, VMware recently announced the release of TKG version 1.4. On reading through the release notes, there were a few features that caught my eye, so I thought I would deploy a cluster and take a closer look. In particular, two features were of interest. The first of these is support for the NSX Advanced Load Balancer (ALB) service in workload clusters, which is available through the Avi Kubernetes Operator (AKO). This is applicable when TKG is deployed on vSphere. There is also new support for the NSX ALB as a control plane endpoint provider.…
Well here we are again – another VMworld has come around. As most of you will know, VMworld 2021 is going to be another “fully virtual” event (no pun intended), the same as it was for VMworld 2020. Hard to imagine that it is 3 years since I presented at VMworld 2018 in Las Vegas, and 2 years since I presented at VMworld EMEA 2019 in Barcelona. Strange days indeed. Let’s hope we can all get together at VMworld 2022 and have a blast. Like previous years, I have picked out a few presentations that I plan on attending at…
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…