Administrators can make supervisor namespacess on a Tanzu-enabled vSphere integration available to users so they can add those namespaces to Kubernetes deployments via cloud templates or to request them from the Service Broker catalog.

This task describes how to add Tanzu supervisor clusters with Cloud Assembly for use in deployments and how to create or add namespaces that define what Cloud Assembly projects and users can access particular Kubernetes resources. This functionality relies on a suitable vSphere cloud account rather than an integration such as VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) or Openshift. Supervisor clusters are customized Kubernetes clusters associated with vSphere. They expose Kubernetes APIs to end users, and they use ESXI as a platform for worker nodes rather than Linux. Supervisor namespaces facilitate access control to Kubernetes resources, because it is typically easier to apply policies to namespaces than to individual virtual machines. You can create multiple namespaces for each supervisor cluster.

Tanzu enabled deployments can also use vSphere generated guest clusters. A guest cluster is a kubernetes cluster that runs inside virtual machines on the supervisor cluster. A guest cluster is fully upstream compliant Kubernetes, so it’s guaranteed to work with all Kubernetes applications. Guest clusters in vSphere use the open source Cluster API project to lifecycle manage Kubernetes clusters, which in turn uses the VM operator to manage the virtual machines that make up a guest.

Note: Avoid using a Tanzu enabled deployment with VMware Cloud Foundation (VCF) cloud accounts as the deployment is not supported and will not function correctly.

When used with Tanzu enabled vSphere instances, Kubernetes zones define which supervisor clusters are available for provisioning of a supervisor namespace. Supervisor namespaces are specific to Tanzu enabled vSphere instances. You cannot provision a generic Kubernetes resource to a Tanzu enabled vSphere instance.

Cloud Assembly users designated as project viewers have view only access to namespaces, while project members can edit them.

You can configure the supervisor clusters associated with namespaces if desired.

Prerequisites

  • To use supervisor clusters and namespaces with Cloud Assembly, you must have a vSphere 7.x endpoint configured. In vRealize Automation, vSphere is installed as part of a vCenter cloud account. See Create a vCenter cloud account in vRealize Automation.
  • Tanzu must be enabled on the vSphere cloud account, and it must contain appropriate supervisor namespaces.
  • Both your vCenter and your vRealize Automation deployment should use the same Active Directory for users to be synched. Though provisioning will still function if this is not the case, vRealize Automation users will not get automatic access to the namespace.

Procedure

  1. Select Infrastructure > Configure > Kubernetes Zone in Cloud Assembly.
    This page shows managed clusters that are available for use, and enables you to add additional clusters. You can click on any of the clusters to view their details.
  2. Select New Kubernetes Zone.
  3. Specify the Account details for the target vSphere cloud account.
  4. Click the Search icon in the text box to either view all vSphere accounts or search for an account by name.
  5. Type a Name and Description for the new zone.
  6. Add capability tags if appropriate. See Using capability tags in Cloud Assembly for more information.
  7. Click the Provisioning tab to select the supervisor cluster that will be associated with the namespaces.
  8. Click Add Compute to view and select the available supervisor clusters.
  9. Click Add.
  10. Select Infrastructure > Administration > Projects and then select the project that you want to associate with your Kubernetes zone.
  11. Click the Kubernetes Provisioning tab on the Project page.
  12. Click Add Kubernetes Zone and add the zone that you just created. You can multiple zones if applicable, and you also set the priority on the zones.
  13. Click Save.

What to do next

After a namespace is configured, the Infrastructure > Resources > Kubernetes page in Cloud Assembly for applicable users displays the namespace. Users can click the Address link on the Summary tab to open the vSphere Kubernetes CLI Tools to manage the namespace. Users must be a cloud administrator or a member of the namespace for the designated project to access a link to the Supervisor namespace details. Also users can download a customized Kubectl to use the Supervisor namespace. Users can log in to the supervisor namespace and use it as they would any other namespace, and then create cloud templates and deploy applications.

To add the namespace to a cloud template select Design > Cloud Template and select an existing cloud template or create a new one. Then you can select the Supervisor namespace item on the left menu and drag it to the canvas.

You can assign storage policies to a supervisor namespace using tags. You can add tags, such as location:local to specify the kubernetes zone you want to use with the deployment and other tags on your storage profiles such as speed:fast and speed:slow.

formatVersion: 1
resources:
  Cloud_SV_Namespace_1:
  type: Cloud.SV.Namespace
  properties:
    name: 'a'
    storage:
      -profile:
         constraints:
           - tag: 'speed:fast'
      -profile:
        liimitMB:1000
        constraints:
           -tag: 'speed:slow'

This cloud template requests a supervisor namespace with no constrains, and specifies two storage profiles with it.

After you deploy cloud templates containing a supervisor namespace, users can also request supervisor namespaces from the Service Broker catalog. Also, you can click on the Deployments page in Cloud Assembly to view information about the deployment and access a link that contains the command to run the kubectl for the namespace on vSphere.

You can specify virtual machine classes for supervisor namespaces in a cloud template using the vmclasses property that enables you to specify a class name. See the following cloud template example. 
resources:
  Cloud_SV_Namespace_1:
    type: Cloud.SV.Namespace
    properties:
      name: demo-vmclass1
      vmclasses:
        - name: vmclass1