As a vSphere administrator, you can create namespaces on a
Supervisor Cluster and configure them with resource quotas, storage, as well as set permissions for DevOps engineer users. Once you configure a namespace, you can provide it DevOps engineers, who run vSphere Pods and Kubernetes clusters created through the VMware Tanzu™ Kubernetes Grid™ Service.
Create and Configure a Supervisor Namespace As a vSphere administrator, you create a Supervisor Namespace on the Supervisor Cluster. You set resources limits to the namespace and permissions so that DevOps engineers can access it. You provide the URL of the Kubernetes control plane to DevOps engineers where they can run Kubernetes workloads on the namespaces for which they have permissions.
Configure Limitations on Kubernetes Objects on a Namespace You can configure limitations for containers running inside the namespace as well as limitations for various Kubernetes objects. The limitations that you configure for an object depend on the specifics of your applications and the way you want them to consume resources within a namespace.
Set Default Memory and CPU Reservations and Limits for Containers You can set the default memory and CPU reservations and limits for containers on a namespace through the vSphere Client. DevOps engineers can later override these values in the pod specifications they define. Container requests translate to resource reservations on vSphere Pods.
Using the Registry Service to Provide a Private Image Registry You can enable a private image registry on a Supervisor Cluster through the Registry Service. One cluster can have one instance of a private image registry. All namespaces on a Supervisor Cluster are represented as projects in the private registry.
Change Storage Settings on a Namespace Storage policies that a vSphere administrator assigns to a namespace in a Supervisor Cluster control how persistent volumes and Tanzu Kubernetes cluster nodes are placed within vSphere datastores. The persistent volume claims that correspond to persistent volumes can originate from a vSphere Pod or from a Tanzu Kubernetes cluster. You can change the original storage policy assignments.