OPTIONAL COMPONENT

vSphere Supervisor and VKS are optional in a VCF 9.1 deployment. You enable them only when you want to run Kubernetes clusters and modern applications on your fleet.

What it does: vSphere Supervisor turns a vSphere cluster into a Kubernetes control plane, and VKS, the vSphere Kubernetes Service, uses that control plane to create and manage conformant Kubernetes clusters.

What it depends on: a healthy workload domain, NSX networking with an Edge cluster, a storage policy, DNS and NTP, a content library for Kubernetes releases, and a VCF license that covers the service.

TL;DR

• vSphere Supervisor is optional. Enable it on a VI workload domain or the management domain when you need Kubernetes on your fleet.
• Reserve 5 consecutive static IP addresses on the management network for the Supervisor control plane, required even for a single node control plane.
• Pick a control plane VM size. Small works for a first setup, Medium is better if you plan to run other Supervisor services.
• In VCF 9.1 the vSphere Client wizard deploys a Supervisor with NSX VPC networking, and classic NSX segment networking is available only through the API.
• Enable the Supervisor from Workload Management in the vSphere Client, then create a vSphere Namespace with storage, VM classes, and a content library.
• Create a VKS cluster with kubectl and a YAML manifest, or with the Local Consumption Interface, then download the kubeconfig to reach it.

This part shows you how to enable vSphere Supervisor on a VCF 9.1 workload domain and then create your first VKS cluster. You will confirm prerequisites, reserve the control plane network, run the Workload Management wizard, create a vSphere Namespace, and provision a Kubernetes cluster. Because Supervisor is optional, skip this part if your fleet runs only virtual machine workloads.

Before you start, deploy at least one VI workload domain, configure NSX with an Edge cluster, and confirm that VCF Operations is healthy. Have a storage policy, a subscribed content library, DNS, and NTP ready. You can enable a Supervisor on the management domain for a compact lab, but a dedicated workload domain is the clean choice for production because it keeps Kubernetes workloads off the management hosts.

One point to settle up front is where the Supervisor runs. A Supervisor is enabled on a single vSphere cluster, either as a one zone Supervisor on one cluster or as a three zone Supervisor spread across three clusters for zone level availability. This part uses a one zone Supervisor, which is the common starting point. VKS then runs on top of that Supervisor and creates Kubernetes clusters as sets of virtual machines that you manage with standard Kubernetes tools.

Confirm every row below before you open the wizard. A missing DNS record, a busy IP address, or a workload domain without an NSX Edge cluster is the most common reason enablement stops early.

Note. You need 5 consecutive addresses even for a one zone Supervisor with a single node control plane. Three addresses go to the control plane VMs, one is a floating address for the cluster, and one is a spare that the platform uses during rolling upgrades.

Pick a control plane size before you start, because it sets how much compute the three control plane VMs claim from the cluster. Small is fine for a first setup. Select Medium if you plan to run other Supervisor services such as the Local Consumption Interface, an image registry, or a service mesh, since those services share the control plane. You can pick a larger size later only by re enabling, so size for where you are heading.

Reserve the 5 addresses and confirm the workload domain has an NSX Edge cluster first, so the wizard passes its checks in one run.

1. Confirm the workload domain is healthy and that an NSX Edge cluster is deployed on it.
2. Pick 5 consecutive free addresses on the management network, for example 10.0.0.40 to 10.0.0.44, and confirm none respond to ping.
3. Record the management gateway and subnet mask, for example 10.0.0.1 and 255.255.255.0.
4. Confirm a storage policy exists that all hosts in the cluster can use, for example vSAN Default Storage Policy.
5. Create or confirm a subscribed content library for Kubernetes releases, and note its name.
6. Verify DNS forward and reverse records and reach an NTP server from the hosts.

You enable a Supervisor from the vSphere Client of the workload domain vCenter.

1. Sign in to the vSphere Client for the workload domain vCenter Server.
2. Open the main menu and click Workload Management.
3. Click Get Started to open the Supervisor enablement wizard.
4. On the networking stack screen, select NSX as the networking stack.
5. Click Next.

Important. In VCF 9.1 the vSphere Client wizard enables a Supervisor with NSX VPC networking. If you need classic NSX segment networking, enable the Supervisor through the API instead, because the UI path no longer offers that option.

On these screens you point the Supervisor at a cluster and set its size and storage.

1. Select One Zone for the Supervisor deployment, then select the vSphere cluster in the workload domain.
2. Confirm the cluster shows as compatible, then click Next.
3. For Control Plane Storage Policy, select your storage policy, for example vSAN Default Storage Policy.
4. For Control Plane Size, select Small for a first setup or Medium if you plan to run other Supervisor services.
5. Click Next.

This screen collects the control plane network and the workload network settings. Enter the values you reserved in Step 1. The fields you fill in are listed below.

1. For Network Mode, select Static.
2. In Starting IP Address, enter the first of your 5 consecutive addresses, for example 10.0.0.40.
3. Enter the Subnet Mask and Gateway for the management network.
4. Enter your DNS Servers and NTP Servers.
5. For the Workload Network, accept the default NSX Project and VPC Connectivity Profile, then enter the DNS and NTP settings when prompted.
6. Click Next.

Check the summary, then commit. Once you click Finish the platform deploys the control plane VMs and claims the management addresses.

1. Review the summary and confirm the cluster, control plane size, storage policy, and network settings are correct.
2. If you want a configuration you can reuse later, click the export option to download the enablement settings.
3. Click Finish to start enablement.
4. Open Workload Management, then the Supervisors tab, to watch the configuration status.

Enablement runs for roughly 30 to 60 minutes while the control plane VMs deploy and the Supervisor reaches a running state. A Config Status of Configuring is normal during this window. Do not cancel the task if progress looks slow.

A vSphere Namespace is the boundary that gives a team storage, VM classes, permissions, and a content library. You need one before you can create a VKS cluster.

1. In the vSphere Client, open Workload Management and click the Namespaces tab.
2. Click New Namespace.
3. Select the Supervisor you enabled, enter a name such as ns-team-a, then click Create.
4. On the namespace Summary page, under Permissions, click Add and grant a user or group the edit role.
5. Under Storage, click Add Storage and select your storage policy.
6. Under VM Service, click Add VM Class and select the VM classes you want, for example best effort medium.
7. Under Content Library, click Add Content Library and select your Kubernetes release library.

You create a VKS cluster by applying a YAML manifest to the Supervisor with kubectl, or by using the Local Consumption Interface if you installed it as a Supervisor service. The command line path is shown here because it works on every deployment. First log in to the Supervisor and switch to your namespace context.

kubectl vsphere login \
  --server=10.0.0.40 \
  --vsphere-username=administrator@vsphere.local \
  --tanzu-kubernetes-cluster-namespace=ns-team-a

kubectl config use-context ns-team-a

Save the manifest below as vks-cluster-01.yaml, adjust the version, VM class, and storage class to match your namespace, then apply it. Confirm the class and version values against the ones your namespace offers with kubectl get before you apply.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: vks-cluster-01
  namespace: ns-team-a
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["10.96.0.0/12"]
    pods:
      cidrBlocks: ["192.168.0.0/16"]
  topology:
    class: builtin-generic-v3.2.0
    version: v1.32.0+vmware.1
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: node-pool
          name: node-pool-1
          replicas: 3
          variables:
            overrides:
              - name: vmClass
                value: best-effort-medium
              - name: storageClass
                value: vsan-default-storage-policy

1. List the Kubernetes versions your namespace offers with kubectl get, and pick a valid version string.
2. Edit vks-cluster-01.yaml so the version, vmClass, and storageClass match your namespace values.
3. Apply the manifest with kubectl apply so the Supervisor starts building the cluster.
4. Watch the cluster come up with kubectl get cluster in your namespace until it reports Provisioned.

kubectl get clusterclass -n ns-team-a
kubectl get virtualmachineimages -n ns-team-a
kubectl apply -f vks-cluster-01.yaml
kubectl get cluster -n ns-team-a

After enablement completes, confirm the Supervisor is running and then confirm your VKS cluster is reachable.

1. In the vSphere Client, open Workload Management, then the Supervisors tab, and confirm the Config Status reads Running.
2. Open Hosts and Clusters and confirm three control plane VMs appear under a Namespaces resource pool on the cluster.
3. Confirm the Supervisor Control Plane IP address is shown, which is the address you use for kubectl login.
4. Log in to your VKS cluster and download its kubeconfig, then list the nodes.

kubectl vsphere login \
  --server=10.0.0.40 \
  --tanzu-kubernetes-cluster-name=vks-cluster-01 \
  --tanzu-kubernetes-cluster-namespace=ns-team-a \
  --vsphere-username=administrator@vsphere.local

kubectl config use-context vks-cluster-01
kubectl get nodes

A healthy result shows the control plane nodes and worker nodes in a Ready state. Once kubectl get nodes returns Ready for every node, the VKS cluster is ready for workloads. If you plan to hand these clusters to tenants through a catalog, connect them to VCF Automation so users can request clusters without touching the Supervisor directly.

Is vSphere Supervisor mandatory in VCF 9.1?
No. Supervisor and VKS are optional. Enable them only when you want to run Kubernetes clusters on your fleet. A fleet that runs only virtual machines does not need them.

Why do I need 5 IP addresses for a single node control plane?
Even a one zone Supervisor reserves 5 consecutive addresses. Three go to control plane VMs, one is a floating address for the cluster, and one is a spare used during rolling upgrades.

What is the difference between the Supervisor and a VKS cluster?
The Supervisor is the Kubernetes control plane built into vSphere. VKS uses that control plane to create separate, conformant Kubernetes clusters made of worker node virtual machines that you manage with kubectl.

Can I use classic NSX segment networking in VCF 9.1?
Not from the vSphere Client. The 9.1 UI enables a Supervisor with NSX VPC networking. Classic segment networking is still available if you enable the Supervisor through the API.

Do I have to use kubectl to create clusters?
No. You can also use the Local Consumption Interface, a Supervisor service that gives a graphical way to create VKS clusters. It is not installed by default and is downloaded from the Broadcom Support Portal.

• Broadcom TechDocs, Configuring and Managing a Supervisor
• Broadcom TechDocs, Supervisor Architecture and Deployment Options
• Broadcom TechDocs, vSphere Supervisor Release Notes for VCF 9.1
• VCF Blog, VCF 9.1 brings multi network support to vSphere Kubernetes Service

« Previous: How to Deploy VCF Automation in VCF 9.1 (Part 11)

Complete guide: VCF 9.1 Deployment Complete Guide

Next: How to Deploy Private AI Foundation with NVIDIA on VCF 9.1 (Part 13)