Containers are not small virtual machines, and almost every wrong answer I have watched a candidate give on Objective 1.1 comes from quietly believing that they are. Once you believe it, a vSphere Pod looks like a cheap VM, a VKS cluster looks like an expensive one, and VM Service looks like somewhere to hide the old stuff. None of those three readings survives contact with the objective.

Broadcom put only 3 of the 33 published objectives in Section 1, so a candidate counts 9 percent and skips ahead to Section 4 where 14 of them live. That is a mistake of a particular kind. Objective 1.1 is not heavily weighted, but the model you would have picked here is assumed silently in a dozen later items about namespaces, VM classes, storage policies and load balancer sizing. Get it wrong on paper and you will get it wrong again in Section 5 with a broken cluster in front of you.

Three compute models on one Supervisor

vSphere Supervisor is a Kubernetes control plane installed directly onto vSphere clusters, which turns them into something a developer can address with kubectl instead of a change ticket. Resource boundaries inside it are called vSphere Namespaces, and a vSphere Namespace is where every choice in this part gets enforced: quota, storage policies, VM classes, zones, permissions. Three workload shapes live inside that boundary, and all three draw on the same namespace budget.

A vSphere Pod is a virtual machine with a very small footprint that runs one or more Linux containers. Each one carries its own Photon based Linux kernel, its own explicit CPU, memory and storage reservation, and gets placed by vSphere DRS like any other VM. Broadcom documentation and parts of the interface also call this object a Supervisor Pod. Isolation here is per pod at the hypervisor boundary, which is a stronger guarantee than the shared kernel arrangement most people picture when they say container. It is also why a vSphere Pod is an object you can see in vCenter, with the monitoring and introspection tools you already use.

VM Service runs an ordinary virtual machine that happens to be declared with a Kubernetes manifest and sized by a VM class. A VM class is a request for CPU and memory reservations, and it comes in two reservation types: guaranteed, which fully reserves what it asks for, and best effort, which permits overcommit. That distinction matters later in this series when a cluster refuses to provision because the namespace has no bound VM class. Worth holding onto now: VM Service also builds the nodes of every VKS cluster, so it is never really optional.

A VKS cluster is a full, signed, upstream conformant Kubernetes distribution deployed as a guest cluster on top of the Supervisor, defined by a custom resource inside a vSphere Namespace. Your tenant gets a genuine Kubernetes API of their own, with cluster admin, their own controllers and their own upgrade cadence, while you keep the vSphere objects underneath.

One naming note that will save you time in the exam and in the documentation. VKS is what Broadcom used to call TKG Service or TKGS, and the rename never reached the plumbing. You will find tkg in documentation paths, in resource names and in CLI output while the vSphere Client above it says VKS. Read tkg as VKS, do not treat TKGS as a separate live product, and move on.

flowchart TD
  A[Workload requirement] --> B{Image or kernel is fixed}
  B -->|Yes| V[VM Service virtual machine]
  B -->|No| C{Tenant needs cluster admin or DaemonSets}
  C -->|Yes| K[VKS cluster]
  C -->|No| D{Supervisor networking stack is NSX}
  D -->|No| K
  D -->|Yes| P[vSphere Pod]

Where each model fits, and what it costs you

All three models sit in the same vSphere Namespace and consume the same quota, the same storage policies and the same zones. What separates them is who owns the kernel, who owns the Kubernetes API, and what the Supervisor networking choice already permitted before anyone wrote a manifest. Keep the table below to hand while you study Sections 3 and 4, because most of what those sections ask about is downstream of these three columns.

Cost of a vSphere Pod is best expressed as a list of things you cannot do. No DaemonSets, no custom CNI, no cluster scoped controllers, no cluster admin for the tenant, and a hard dependency on NSX. In exchange you get isolation that a shared kernel node pool cannot offer and a start time that a VKS node cannot approach. Cost of a VKS cluster is the opposite shape: you get everything a Kubernetes team expects, and you now own a Kubernetes lifecycle per cluster, with a Kubernetes release to track and a rolling update to schedule.

Two years ago I helped a team move a licensed analytics appliance off a pair of standalone VMs, because a platform mandate said everything new lands on Kubernetes. Containerising it was technically possible and we did it. Their vendor licensing daemon keyed on machine identity that it read from the kernel, so every pod restart looked like a fresh install and burned an activation. We hit the 25 activation ceiling in 6 days, spent another 9 days in a support queue getting them reset, and reverted. Moving the same appliance onto VM Service took one afternoon: same vendor image, same licence behaviour, declared with a manifest, living in the same vSphere Namespace and the same quota as the containerised services beside it. It has run untouched for 14 months. What the platform mandate actually wanted was a Kubernetes shaped operating model, and VM Service delivered exactly that without pretending a licence bound appliance was a container.

That episode is the shape of Objective 1.1 in miniature. Nothing in it turns on container theory. It turns on reading a requirement, finding the constraint the requirement hides, and naming the model that survives the constraint. Broadcom writes its own guidance the same way: reasons to choose a virtual machine on a Kubernetes platform are listed as applications that cannot be containerised, applications designed for a custom kernel or a custom operating system, applications simply better suited to a VM, and a wish to consolidate two platforms into one. Not one of those reasons is a benchmark.

Time to ready, measured on a three zone lab

Numbers settle this argument faster than adjectives do. On the reference estate this series uses, a VCF 9.0 workload domain with three vSphere Zones, NSX with VPC networking, Avi in the load balancing path and VKS 3.3.x supplying Kubernetes releases, I timed the same trivial web workload arriving through each model. Every figure below is the median of five runs, measured from manifest apply to the workload answering its first request.

Ratios matter far more than the absolute figures, which will shift with your hardware and your content library sync state. A vSphere Pod answers in seconds because there is no guest operating system to boot and no Kubernetes to bootstrap. A VM Service virtual machine pays for a guest boot and cloud init. A new VKS cluster pays for three control plane nodes, three workers, a CNI coming up, and a settling period before any of your workload runs. That last bar is roughly 75 times the first one.

Treat that gap as a design input. If your promise to a tenant is a cluster inside 15 minutes, this estate keeps the promise comfortably. If your promise is a workload inside a minute, and the workload is a container that can live without cluster scoped objects, a VKS cluster is simply the wrong shape and a vSphere Pod is the right one, provided you enabled the Supervisor with NSX. Notice how often that final clause turns up. It is the whole objective in one condition.

What these numbers exclude is worth stating. None of them includes a content library sync, which on a cold local library added over 20 minutes before a Kubernetes release was even selectable. None includes Avi allocating a virtual IP, which is fast until the pool is exhausted, at which point it is infinite. Both of those are Supervisor level facts, and both cause failures that look like workload problems. Every later part of this series traces that kind of failure back to the Supervisor object that caused it.

Exam focus for objective 1.1

Section 1 objectives tend to arrive as multiple choice and matching, with the occasional build list asking you to order selection criteria. Two habits are worth building before you sit down.

First, distrust any distractor that argues from raw performance. Published selection guidance for running virtual machines on a Kubernetes platform is entirely about constraint, never about speed. If an option says a model is correct because it is faster, it is usually there to catch people who studied a feature comparison chart instead of the objective.

Second, read the Supervisor before you read the workload. An item that describes a Supervisor enabled with vDS networking and then asks which model suits a small container workload has already eliminated vSphere Pods, whatever the workload description says afterwards. Tracing every answer back to the Supervisor object that constrains it is worth more across this whole exam than any single fact in this part, and it is the habit that Sections 4 and 5 reward hardest.

Objective checkpoint

Default to a VKS cluster and justify anything else

My recommendation for this objective inverts how most study material teaches it. Most material starts from containers, presents vSphere Pods as the native modern option and files VM Service under exceptions. In practice, start from a VKS cluster and make everything else earn its place. A VKS cluster is the only model that hands a tenant a real Kubernetes API, it works on both networking stacks, it upgrades on a cadence you can put in a change record, and nearly every other objective on this exam is written against it. From there, justify a vSphere Pod when isolation and start time genuinely matter and NSX is already in place, and justify a VM Service virtual machine when the workload or its licence refuses to become a container.

Here is the piece that contradicts the popular advice. vSphere Pods are the most container native thing on the platform and simultaneously the most constrained: no DaemonSets, no custom CNI, no cluster admin, NSX or nothing. Study guides that rank them as the modern choice and a VKS cluster as the heavyweight option have it backwards for anything a tenant has to operate for themselves. Rank by what the tenant needs to own, not by how thin the abstraction looks on a slide.

Tonight, open your own Supervisor and read one line: its networking stack. If it says vDS, write down that vSphere Pods are unavailable to you, and that every Objective 1.1 scenario mentioning them is already answered before you reach the workload description. Then bring that note to Part 3, where Kubernetes architecture, networking, storage, service mesh and Helm get the same treatment under Objective 1.2. If you arrived here from a Tanzu Kubernetes Grid Integrated estate rather than a greenfield one, the TKGI to VKS migration guide handles the platform move itself, which is a separate problem from this certification.

References

• VMware Cloud Foundation VKS Administrator Exam Guide, 3V0-24.25
• What Is vSphere Supervisor, VMware Cloud Foundation 9.0 documentation
• vSphere Kubernetes Service Architecture and Components

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts