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.

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 in vSphere IaaS Control Plane 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 vSphere Namespace in a self-service manner and deploy workloads within it. For more information, see Provision a Self-Service Namespace Template in vSphere IaaS Control Plane.

If you use NSX for your Supervisors, you have the option to override the networking settings on vSphere Namespace level. Have in mind the following considerations if you select that option:
Table 1. vSphere Namespace Network Planning Considerations
Consideration Description
NSX Installation To override Supervisor network settings for a particular vSphere Namespace, the NSX must include an Edge Cluster dedicated for Tier-0 Gateways (routers) and another Edge Cluster dedicated for Tier-1 Gateways. Refer to the NSX installation instructions provided in the guide Installing and Configuring vSphere IaaS Control Plane.
IPAM Required If you override Supervisor network settings for a particular vSphere Namespace, the new vSphere Namespace network must specify Ingress, Egress, and Namespace Network subnets that are unique for the Supervisor and from any other vSphere Namespace network. You will need to manage IP address allocation accordingly.
Supervisor Routing The Supervisor must be able to route directly to the TKG cluster nodes and ingress subnets. When selecting a Tier-0 Gateway for the vSphere Namespace, you have two options for configuring the required routing:
  • Use a Virtual Routing and Forwarding (VRF) Gateway to inherit the configuration from the Supervisor Tier-0 Gateway
  • Use the Border Gateway Protocol (BGP) to configure routes between the Supervisor Tier-0 Gateway and the dedicated Tier-0 Gateway

Refer to the NSX Tier-0 Gateways documentation for details on these options.

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 New Namespace.
  4. Select the Supervisor where you want to place the vSphere 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 vSphere 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 Supervisor, you can select Override cluster network settings to override the Supervisor 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 TKG 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 TKG 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 Finish.
    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 TKG clusters, and VMs.
      Can edit The user or group can create, read, update, and delete vSphere Pods, TKG 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 and determine the storage placement of persistent volumes.
    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 IaaS control plane creates a matching Kubernetes storage class in the vSphere Namespace. If you use TKG, the storage class is automatically replicated from the namespace to the TKG 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.
  12. Set up VM Service for stand-alone VMs.
    For information, see Deploying and Managing Virtual Machines in vSphere IaaS Control Plane.

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 IaaS Control Plane Clusters.
Note: This vSphere IaaS Control Plane Services and Workloads guide does not include information on running workloads on a TKG cluster. To learn how to work with TKG clusters, see Using TKG Service with vSphere IaaS Control Plane.