These workflows assume that you have already enabled the vSphere with Tanzu platform, set up a Supervisor, and are now ready to create vSphere Namespaces and use them for workloads.

User Roles

Typically, interacting with the Supervisor and running workloads involves two roles, vSphere administrator and DevOps engineer. The workflows for the vSphere administrator and DevOps engineer roles are distinct and determined by the specific area of expertise these roles require.

vSphere administrator
As a vSphere administrator, you typically use the vSphere Client to configure a Supervisor and namespaces where DevOps engineers can deploy Kubernetes workloads.

If you haven't created your Supervisor and need to learn about how to do it, see Installing and Configuring vSphere with Tanzu.

DevOps engineer
On a Supervisor, a role of a DevOps engineer might combine activities that typically are performed by Kubernetes developers, application owners, and Kubernetes administrators. As a DevOps engineer, you use kubectl commands. You can deploy and run vSphere Pods, VMs, and other workloads on Supervisor namespaces that the vSphere administrator creates for you. You can also create self-service namespaces.

Because this vSphere with Tanzu Services and Workloads guide does not cover tasks the DevOps engineer performs on a Tanzu Kubernetes Grid cluster, to learn about these tasks, see Using Tanzu Kubernetes Grid 2 with vSphere with Tanzu.

Types of Workloads a Supervisor Supports

Support of a Supervisor for different types of workloads depends on its configuration and networking that the Supervisor uses.
Types of Workloads One-Zone Supervisor with VDS Networking One-Zone Supervisor with NSX Networking Three-Zone Supervisor with VDS Networking Three-Zone Supervisor with NSX Networking
vSphere Pods No Yes No No
VMs provisioned with VM Service Yes Yes Yes Yes
Supervisor Services Yes Yes No No
Tanzu Kubernetes Grid clusters Yes Yes Yes Yes

Workflow for Configuring Namespaces

As a vSphere administrator, you can create and manage vSphere Namespaces on a Supervisor. Tanzu Kubernetes Grid clusters

Before creating a namespace, you must gather specific resource requirements from DevOps engineers about the applications and workloads they want to run. Based on these specifications, you can then configure appropriate resources and assign them to the namespace.

For more information, see Configuring and Managing vSphere Namespaces.
Figure 1. Workflow for configuring namespaces

The diagram shows the workflow for configuring a vSphere Namespace.

Workflow for Configuring Self-Service Namespaces

As a vSphere administrator, you can create a vSphere Namespace, set CPU, memory, and storage limits to the namespace, assign permissions, and provision or activate the namespace service on a cluster as a template. For more information, see Provision a Self-Service Namespace Template in vSphere with Tanzu.
Figure 2. vSphere administrator workflow for self-service namespace
The diagram shows the workflow for enabling a self-service namespace template.
As a DevOps engineer, you can create a vSphere Namespace in a self-service manner and deploy workloads within it. You can share it with other DevOps engineers or delete it when it is no longer required.
Figure 3. DevOps workflow for self-service namespace
The diagrams shows the workflow to create a self-service namespace.

Workflow for Provisioning vSphere Pods and VMs

As a DevOps engineer, you can deploy vSphere Pods and VMs within the resource boundaries of a namespace that is running on a Supervisor.

For more information, see Deploying Workloads to vSphere Pods and Deploying and Managing Virtual Machines in vSphere with Tanzu.

Figure 4. vSphere Pods and VM Provisioning Workflow

The diagram shows the workflow for provisioning vSphere Pods and VMs.