Fourteen minutes of Pending on a two replica deployment, on a Supervisor reporting Ready, in a namespace with more than half its quota free. Nothing in that output mentions networking. It is entirely a networking answer. That Supervisor was activated on vSphere Distributed Switch, and a vSphere Pod cannot exist without NSX. Objective 4.3 asks you to create workloads as Supervisor Pods or via VM Service, and a large slice of what it actually tests is knowing which of those two routes the Supervisor beneath you is capable of before you write a single line of YAML.

Last Part carved this estate into vSphere Namespaces and mapped them onto zones. This Part puts workloads inside one of them, by both routes the blueprint names, using the NSX VPC backed Supervisor rather than the vDS one. A vSphere Pod is a small virtual machine with its own Photon based Linux kernel running one or more OCI containers, placed on an ESX host by DRS and attached to Kubernetes by a per host process called spherelet. A VM Service virtual machine is a full guest operating system described by a VirtualMachine custom resource and reconciled by VM Operator. Same namespace, same quota, two completely different failure vocabularies.

Preflight for both workload models

Four objects decide whether either model will start, and all four are Supervisor side rather than workload side. Networking mode decides vSphere Pods. VM classes decide VM Service sizing. Storage policies projected as StorageClasses decide where disks land. Content library association decides which VirtualMachineImage objects appear. Run the discovery block below before you write a manifest, because every one of these produces an error message that names something other than the thing that is actually missing.

An empty result from either of the first two commands is your stop signal. No VirtualMachineClass rows means nobody added a VM class to this namespace in vCenter. No VirtualMachineImage rows means either the content library is not associated with the namespace or it has not finished syncing, which Part 9 covers in full. Neither shortage stops kubectl apply from succeeding at the CLI, which is precisely why both catch experienced admins.

Keep this table. It is the artifact worth returning to when someone asks which model a given application belongs in, and it answers the comparison items this objective tends to produce.

flowchart TD
  A[Workload manifest ready] --> B{Supervisor networking mode}
  B -->|NSX or NSX VPC| C{Runs as a Linux container}
  B -->|vDS only| D[vSphere Pod unavailable on this Supervisor]
  C -->|Yes| E[vSphere Pod in the vSphere Namespace]
  C -->|No| F[VM Service virtual machine]
  D --> F
  D --> G[Pod inside a VKS cluster]
  E --> H[Namespace quota charged per pod]
  F --> H
  G --> I[Namespace quota charged through node VMs]

vSphere Pod deployment procedure

Step 1, confirm the Supervisor speaks NSX. Step 2, apply a Deployment with explicit resource requests and limits. Step 3, expose it. Nothing about the manifest is special, which is the point of the model, but step 2 carries a trap that costs you quota rather than an error message.

Omit the resources stanza and nothing fails. A vSphere Pod is sized to its requests and limits, so with none supplied the namespace LimitRange default applies, and on a freshly created namespace that default is 1 vCPU and 512 MiB per container. Two replicas of a web server that needs 128 MiB then reserve 2 vCPU and 1 GiB of hard reservation against a namespace ceiling. I have watched a team run out of a 64 GiB namespace at roughly forty pods and conclude the Supervisor was broken.

Storage for a vSphere Pod arrives as three separate VMDK types governed by two separate policy decisions, and that split confuses people for years. Container image cache and ephemeral disks are placed by a storage policy chosen when the Supervisor is activated, and no namespace level change will move them. Persistent volumes are placed by the storage policies assigned to the vSphere Namespace, which is the layer Part 7 covered. A pod can therefore pull, start and serve traffic while its PersistentVolumeClaim hangs Pending, and the two answers live on different pages of the vSphere Client.

One more number worth carrying into the exam room. Image cache warmth is per ESX host, not per namespace and not per Supervisor. On this estate a 187 MB image pulled onto a cold host took 41 seconds to reach Running against 6 seconds once cached, and DRS is free to place the next replica on a host that has never seen that image. Scale a Deployment from two replicas to eight across a three cluster zonal namespace and start times fan out across that whole range with no configuration change whatsoever. Anybody quoting a single vSphere Pod start time is quoting host history rather than platform behaviour.

Now the failure that opened this Part, reproduced deliberately on the vDS backed Supervisor in the same estate.

Only three nodes exist on that Supervisor and all three are control plane VMs, because without NSX there are no spherelet backed ESX hosts joined as schedulable nodes. Read that event as a networking mode statement, not a taint problem, and never spend an hour writing a toleration for it.

VM Service deployment procedure

VM Service takes three inputs and one optional bootstrap. Class, image, storage class, plus cloud-init user data if you want the guest to be reachable. Build the bootstrap secret from an environment variable rather than pasting a key into the manifest, because a VirtualMachine object is readable by everyone with namespace edit rights.

PRIMARY-IP staying blank past two minutes is nearly always the bootstrap, not the network. A key name mismatch between the secret and rawCloudConfig.key leaves cloud-init with nothing to apply, the guest boots fine, and VM Operator reports no address because VMware Tools never handed one up. Check the guest console in vCenter before you touch a segment.

Power state on a VM Service virtual machine is declarative rather than a one time instruction. Patch spec.powerState to PoweredOff and VM Operator powers the guest down and holds it there, and a manual power on from the vSphere Client gets reconciled straight back off inside a minute. Administrators used to driving VMs from the client find that behaviour surprising the first time they meet it, and it is precisely the sort of reconciliation loop a scenario item can be built around.

Here is the admission failure worth memorising, produced by asking for a VM class that exists in vCenter but was never added to this namespace.

That message is a gift, because it names the namespace. Most objective 4.3 failures are not this polite. Note also that VKS is the product formerly called TKG Service, and the rename has not reached the code: this same VM Operator builds the node VMs of every VKS cluster, and on the cluster side you will still meet tkg in API groups and resource names.

Verification, rollback and failure signatures

Green looks like this: pods Running with an ESX host name in the NODE column rather than a control plane VM name, a Service holding an external address from your load balancer range, and a VirtualMachine showing poweredOn with a primary IP. Anything else, go to the lookup table below rather than guessing.

Deleting a VirtualMachine removes the guest and its boot disk. Any PersistentVolumeClaim you attached through spec.volumes survives, which is a mercy in a lab and a surprise in production when storage quota does not fall after a cleanup. Releasing the Service before the Deployment returns the virtual IP promptly instead of leaving it held while the pods drain.

Exam focus for objective 4.3

Objective checkpoint

Workload model call for this estate

Field note. On a customer estate last year I lost most of a working day to exactly the opening symptom, on a Supervisor somebody else had activated. Two hours went on quota arithmetic, another hour on a toleration I did not need, and the resolution arrived when a colleague asked which networking mode had been chosen at activation. It had been vDS, picked because NSX Edge capacity was not ready on the day, and that single choice removed vSphere Pods from that estate permanently without ever producing an error that said so. Total cost, roughly five hours plus a rebuild scheduled six weeks later.

Verdict for this lab, and for most production estates. Use vSphere Pods for platform side and short lived containers where the 6 second start and per pod visibility in vCenter earn their keep, use VM Service for anything that resists containerising, and push application teams into VKS clusters rather than vSphere Pods so they own their own Kubernetes version. Avoid guaranteed VM classes inside any namespace that also carries limits. Avoid, above all, applying a container manifest before you have confirmed the networking mode.

Clean result checklist: two pods Running with ESX host names in the NODE column, a Service holding an address from your load balancer range answering 200, a VirtualMachine reporting poweredOn with a primary IP, no bootstrap material written into any manifest, and a namespace whose used memory rose by roughly what you asked for rather than by a LimitRange default.

Tonight, in your own lab: deploy the same Deployment twice, once with explicit requests and limits and once without, then compare the namespace memory used figure on the vSphere Client namespace card. That single number is the fastest way to make the LimitRange behaviour permanent in your memory before exam day. Next Part installs Supervisor add-on services, starting with Harbor and external-dns, which is where those image pull failures in the table above finally get their fix. Full map in the VCAP-VKS Exam Complete Guide.

References

• Broadcom TechDocs, Deploying Workloads to vSphere Pods, VCF 9.0
• Broadcom TechDocs, Provision and Manage Virtual Machines with VM Service
• Broadcom TechDocs, What Is vSphere Supervisor, vSphere Pod and VM Service concepts
• Broadcom, VCAP-VKS 3V0-24.25 Exam Guide

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