Create and Configure a vSphere Namespace on the Supervisor

Checkout how to create a and configure a vSphere Namespace on the Supervisor. As a vSphere administrator, after you create a vSphere Namespace, 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 workloads on the namespaces for which they have permissions.

Namespaces on Supervisors configured with the vSphere networking stack and namespaces on clusters configured with NSX have different networking configuration and capabilities. Namespaces configured on Supervisors deployed on three vSphere Zones also support different set of capabilities than namespaces on one-zone Supervisors.

• One-zone Supervisor configured with NSX. vSphere Namespaces on such Supervisors support vSphere Pods, VMs, Tanzu Kubernetes Grid clusters, and Supervisor Services. The workload networking support for these vSphere Namespaces is provided by NSX.
• Three-zone Supervisor configured with NSX. vSphere Namespaces on a three-zone Supervisor configured with NSX only support Tanzu Kubernetes Grid custers and VMs. They do not support vSphere Pods and Supervisor Services.
• One-zone Supervisor configured with VDS. vSphere Namespaces on one-zone Supervisors with VDS support Tanzu Kubernetes Grid, VMs, and Supervisor Services. They do not support vSphere Pods apart from the ones that Supervisor Services deploy for their own use.
• Three-zone Supervisor configured with VDS. vSphere Namespaces running of three-zone Supervisor with VDS only support Tanzu Kubernetes Grid clusters and VMs. They do not support vSphere Pods and Supervisor Services.

For more information, see Requirements for Enabling a Three-Zone Supervisor with HA Proxy Load Balancer and Requirements for Enabling a Single-Cluster Supervisor with VDS Networking and HAProxy Load Balancer vSphere with Tanzu Concepts and Planning.

You can also set resources limits to the namespace, assign permissions, and provision or activate the namespace service on a cluster as a template. As a result, DevOps engineers can create a Supervisor Namespace in a self-service manner and deploy workloads within it. For more information, see Provision a Self-Service Namespace Template in vSphere with Tanzu.

Prerequisites

• Deploy a Supervisor.
• Create users and groups for DevOps engineers and developers, who will need access to the vSphere Namespace. Create the users or groups in identity sources that are connected to vCenter Single Sign-On or in an OIDC provider configured with the Supervisor.
• Create storage policies for persistent storage. If the namespace is in a three-zone Supervisor, use topology aware policies. You cannot assign storage policies that are not topology aware to the three-zone namespace.
• Create VM classes and content libraries for stand-alone VMs.
• Required privileges:
  • Namespaces.Modify cluster-wide configuration
  • Namespaces.Modify namespace configuration

Procedure

1. From the vSphere Client home menu, select Workload Management.
2. Select the Namespaces tab.
3. Click Create Namespace.
4. Select the Supervisor where you want to place the namespace.
5. Enter a name for the namespace.
   The name must be in a DNS-compliant format.
6. From the Network drop-down menu, select a Workload Network for the namespace.
   Note: This step is available only if you create the namespace on a cluster that is configured with the vSphere networking stack.
7. If you have configured the NSX networking stack for your cluster, you can select Override cluster network settings to override the cluster network settings and configure network settings for the namespace.
   Configure the following network settings for the namespace:

   Option	Description
   Tier-0 Gateway	Select the Tier-0 gateway to associate with the namespace Tier-1 gateway. Selecting a Tier-0 gateway overrides the tier-0 gateway you configured while enabling the cluster, so you must configure the CIDR ranges again. Note: The Supervisor must be able to route directly to the TKG cluster nodes and ingress subnets. If you select a VRF gateway that is linked to the Tier-0 gateway, the network and subnets are automatically configured. If you have selected the NAT mode, you must configure the subnet, ingress, and egress CIDRs. If you deselect the NAT mode, you must only configure the subnet and ingress CIDRs. Note: Once you select a Tier-0 gateway, you cannot change it.
   NAT Mode	The NAT mode is selected by default. If you deselect this option, all the workloads such as the vSphere Pods, VMs, and Tanzu Kubernetes Grid clusters node IP addresses are directly accessible from outside the tier-0 gateway and you do not have to configure the egress CIDRs. Note: Once you enable a namespace mode, you cannot change it.
   Load balancer Size	Select the size of the load balancer instance on the tier-1 gateway for the namespace.
   Namespace Network	Enter one or more IP CIDRs to create subnets/segments and assign IP addresses for workloads connected to namespaces. Note: Enter the CIDR range if you did not configure it for the cluster. You can configure additional CIDRs after you create the namespace, by editing the namespace network settings.
   Namespace Subnet Prefix	Enter the subnet prefix that specifies the size of the subnet reserved for namespaces segments. Default is 28. Note: Once you specify the subnet prefix, you cannot change it.
   Ingress	Enter a CIDR annotation that determines the ingress IP range for the virtual IP addresses published by the load balancer service for vSphere Pods or Tanzu Kubernetes Grid clusters. You can configure additional CIDRs after you create the namespace, by editing the namespace network settings.
   Egress	Enter a CIDR annotation that determines the egress IP range for the SNAT IP addresses. You can configure additional CIDRs after you create the namespace, by editing the namespace network settings.

8. Enter a description, and click Create.
   The namespace is created on the Supervisor.
9. Set permissions for users who can access the namespace.
   As a vSphere administrator, you set permissions on a vSphere Namespace for developers and DevOps engineers who need to access the namespace. One user account can have access to multiple namespaces. Users who are members of the Administrators groups have access to all the namespaces on the Supervisor.
   1. From the Permissions pane, select Add Permissions.
   2. Select an identity source, a user or a group, and a role, and click OK.

      Role	Description
      Can view	Read-only access for the user or group. The user or group can login to the Supervisor control plane and list the workloads running in the vSphere Namespace, such as vSphere Pods and Tanzu Kubernetes Grid clusters, and VMs.
      Can edit	The user or group can create, read, update, and delete vSphere Pods, Tanzu Kubernetes Grid clusters, and VMs. Users who are part of the Administrators group have edit permissions on all namespaces in the Supervisor.
      Owner	User accounts with owner permissions can: Deploy and administer workloads in the namespace. Share the namespace with other users or groups. Create and delete additional vSphere Namespaces using kubectl. When users with owner permission share the namespace, they can assign view, edit, or owner permissions to other users or groups. Note: The owner role is supported for users available in the vCenter Single Sign-On identity source. You cannot use the owner role with a user or group from an external identity provider.

      When you assign a user or group to the Can view or Can edit roles, the system creates a RoleBinding and maps it to a ClusterRole. For example, a user or group assigned to the Can edit role is mapped to the Kubernetes edit ClusterRole through a RoleBinding. The edit role lets users provision and operate clusters. You can view this mapping by using the command kubectl get rolebinding from the target vSphere Namespace.

      kubectl get rolebinding -n tkg2-cluster-namespace
      NAME                                                           ROLE                         AGE
      wcp:tkg-cluster-namespace:group:vsphere.local:administrators   ClusterRole/edit             33d
      wcp:tkg-cluster-namespace:user:vsphere.local:administrator     ClusterRole/edit             33d

      When you assign the owner role to a user or group, the system creates a ClusterRoleBinding and maps it to a ClusterRole that allows the user or group to create and delete vSphere Namespaces using kubectl. To view this mapping, you can SSH to a Supervisor control plane node.

10. Assign storage to the namespace.
    Storage policies that you assign to the namespace make persistent storage available to the DevOps team.
    1. From the Storage pane, select Add Storage.
    2. Select a storage policy to control datastore placement of persistent volumes and click OK.
    After you assign the storage policy, vSphere with Tanzu creates a matching Kubernetes storage class in the vSphere Namespace. If you use Tanzu Kubernetes Grid, the storage class is automatically replicated from the namespace to the Tanzu Kubernetes Grid cluster. When you assign multiple storage policies to the namespace, a separate storage class is created for each storage policy.
11. From the Capacity and Usage pane, select Edit Limits and configure resource limitations to the namespace.

    Option	Description
    CPU	The amount of CPU resources to reserve for the namespace.
    Memory	The amount of memory to reserve for the namespace.
    Storage	The total amount of storage space to reserve for the namespace.
    Storage policies limits	Set the amount of storage dedicated individually to each of the storage policies that you associated with the namespace.

    A resource pool for the namespace is created on vCenter Server. The storage limitation determines the overall amount of storage that is available to the namespace whereas storage polices determine the placement of persistent volumes for vSphere Pods on the associated storage classes.
12. Set up VM Service for stand-alone VMs.
    For information, see Deploying and Managing Virtual Machines in vSphere with Tanzu.

What to do next

Share the Kubernetes Control Plane URL with DevOps engineers as well as the user name they can use to log in to the Supervisor through the Kubernetes CLI Tools for vSphere. You can grant access to more than one namespace to a DevOps engineer. See Connecting to vSphere with Tanzu Clusters.

Note: This vSphere with Tanzu Services and Workloads guide does not include information on running workloads on a Tanzu Kubernetes Grid cluster. To learn how to work with Tanzu Kubernetes Grid clusters, see Using Tanzu Kubernetes Grid 2 with vSphere with Tanzu.