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 NAME STATUS AGE 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 NAME STATUS AGE devops2 Active 17s % kubectl get ns devops2 --show-labels NAME STATUS AGE 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 NAME STATUS AGE 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.