A closer look at the vSphere with Tanzu Namespace Service

Now that vSphere 7.0U3c is available, I thought it might be a good time to revisit some of the vSphere with Tanzu features that have appeared in recent editions. The first of these is the Namespace Service, which enables dev-ops personas to create their own Supervisor Namespaces through the command line via kubectl. We have extended this feature in vSphere 7.0U3c to allow dev-ops to add their own Kubernetes labels and annotations. Let’s take a look at how this works, and how the vSphere Administrator can put guardrails around the amount of vSphere resources this persona can consume when creating a Supervisor Namespace via this service.

The first thing to understand is that the vSphere administrator controls whether or not this features is available. By default, it is disabled. Thus if the dev-ops persona wishes to created a Supervisor namespace, they are unable to do so until the vSphere administrator enables the feature:

With the namespace service set to inactive, no-one is able to create a namespace. After providing the credentials to log into the vSphere with Tanzu cluster, any attempt to create a Supervisor Namespace will fail as follows, even as the SSO Administrator:

% kubectl create ns devops1
Error from server (Forbidden): namespaces is forbidden: \
User "sso:Administrator@vsphere.local" cannot create resource "namespaces" \
in API group "" at the cluster scope

To enable the Supervisor Namespace self-service feature, toggle to the Status button show above. This will launch the following wizard where the vSphere administrator can control the amount of CPU and Memory resources that can be consumed within a namespace. In the example below, I am limiting the resources that can be consumed in a single namespace to 20GHz CPU, 40GB Memory and 250GB of storage. I am also selecting a particular storage policy from the available list, which in this case matches a vSAN datastore.

After setting the resources, the next step is to specify who can create namespaces. For the purposes of this demonstration, I am specifying that only the administrator@vsphere.local user can create namespaces via kubectl, but it should be obvious that the vSphere administrator can control this activity, and give permissions to the appropriate dev-ops users.

With the permissions added, review your selection and click on the Finish.

The Namespace Self-Service should now show as activated.

We can now retry the namespace creation operation that we attempted earlier.

% kubectl create ns devops1
namespace/devops1 created

% kubectl get ns devops1 --show-labels
devops1   Active   56s   kubernetes.io/metadata.name=devops1,vSphereClusterID=domain-c8

It would appear that we can now successfully create Supervisor Namespaces. We can also check in the vSphere Client to see if the namespace is visible, which it is. Note that we can also see the resource limits, and current resource usage of the namespace via the UI.

The next thing we can explore is the new enhancement to the Namespace Service which is included in vSphere 7.0U3c. This is the ability to add labels and annotations to Supervisor Namespaces. Let’s do a simple example. I created a very simple JSON file which includes a label name:devops2. Let’s apply it, and see if the label takes effect.

% cat devops2.json
 "apiVersion": "v1",
 "kind": "Namespace",
 "metadata": {
   "name": "devops2",
   "labels": {
     "name": "devops2"

% kubectl create -f devops2.json
namespace/devops2 created

% kubectl get ns devops2
devops2   Active   17s

% kubectl get ns devops2 --show-labels
devops2   Active   23s   kubernetes.io/metadata.name=devops2,name=devops2,vSphereClusterID=domain-c8

Success! It appears that we have a user-defined label associated with this namespace. Let’s compare this namespace to the one we created earlier without any specific labels.

% kubectl get ns devops1 --show-labels
devops1   Active   56s   kubernetes.io/metadata.name=devops1,vSphereClusterID=domain-c8

Everything working as expected. Let’s check the vSphere UI to see the new Supervisor Namespace.

Looks good. That completes this post. I’ll be taking a look at some of the other newer features soon, so check back from time to time to see those updates.