A candidate on a study call asked me which command line the exam expects for scaling a VKS cluster, kubectl or the VCF CLI. That is the wrong question, and understanding why it is wrong is most of objective 4.5. Both tools write the same field on the same object. What separates a pass from a fail is knowing which changes to that field the platform accepts, which ones it refuses outright, and which scaling operation the VCF CLI cannot express at all.

Last part we installed Harbor as a Supervisor Service and external-dns as a standard package inside a workload cluster. This part we go one layer down and drive a cluster called vks-lifecycle-01 through provisioning, monitoring, both kinds of scaling and deletion, inside the vSphere Namespace ns-platform-a on the three zone estate this series has been building since Part 14. Everything below assumes that namespace already has a storage policy, a VM class and a content library bound to it, because every failure in this Part traces back to one of those three Supervisor objects.

Preflight for cluster lifecycle work

Two authentication paths exist and they are not interchangeable. The kubectl-vsphere plugin merges Supervisor and namespace contexts into your kubeconfig and is what almost every Broadcom procedure assumes. VCF CLI keeps its own context store and needs one created before any cluster subcommand will resolve. Candidates who only ever use one of them lose points on items that name the other, so set both up in your lab tonight and keep both in the shell history.

Three preflight checks prove the namespace can actually build a cluster, and running them takes under a minute. Skipping them is how people end up staring at a Machine stuck in Provisioning for half an hour.

If the VKr list comes back empty, stop. That is a content library that has not synced, not a cluster problem, and no amount of retrying the manifest will fix it. If COMPATIBLE reads False on the release you want, your Supervisor version and that VKr do not pair, and provisioning will be rejected by the admission webhook rather than failing halfway.

Provisioning paths, kubectl and VCF CLI

Here is the artifact to keep from this Part. Print the table, cover the right hand columns, and work across it until you can produce either command from memory. Objective 4.5 names both tools explicitly, so an item is free to show you one and ask for the equivalent in the other. Notice the last column, because it is the point: every row lands on the same Cluster object and the same field. Nothing in the VCF CLI is a separate control plane.

Two rows deserve a second look. Vertical scaling has no VCF CLI verb, which is the single most common wrong assumption I hear from candidates who learned the tool before reading the objective. And support bundle collection has no kubectl equivalent, so an item asking how you gather node level logs for a wedged cluster has exactly one right answer.

Now provision. A v1beta1 Cluster referencing the shipped ClusterClass is the shape you should be able to write from a blank file, because build list and hot area items lean on knowing where each key sits.

flowchart TD
  A[kubectl apply or vcf cluster create] --> B[Cluster object in vSphere Namespace]
  B --> C[ClusterClass expands the topology]
  C --> D[KubeadmControlPlane and MachineDeployment]
  D --> E[Machine objects, one per node]
  E --> F[VM Service creates VirtualMachine]
  F --> G[VM Class bound to namespace supplies CPU and memory]
  F --> H[Storage policy supplies the node disk]
  F --> I[Content library supplies the VKr image]
  G --> J[Node joins, Machine goes Running]
  H --> J
  I --> J

Monitoring commands that report real state

Plain get is a summary and it lies by omission. A cluster can sit at Provisioned with a Machine that has been stuck for twenty minutes and the top line will not say so. Work down the object tree instead, from Cluster to MachineDeployment to Machine, and read conditions rather than phases.

That is the failure I want you to internalise, because it is not a Kubernetes problem at all. Nothing is wrong with the manifest, the VKr or the VM class. A namespace memory limit set months earlier by whoever carved ns-platform-a is refusing the fourth node. Raise the limit on the vSphere Namespace and the Machine proceeds without any change to the cluster spec. Objective 5.1 revisits this family of errors and Part 30 goes deeper, but you should already be tracing failures upward to the Supervisor by now.

Scaling operations and what each one costs

Four scaling axes exist and they are not equally permitted. Broadcom publishes the matrix and it is short enough to memorise, which makes it prime matching item material.

Control plane replicas must be odd, so 1 or 3, and nothing else. Scale out is supported. Scale in is not, and that asymmetry catches people who assume symmetry because worker pools have it. Run the refusal in your own lab once so the error text is familiar.

Vertical scaling is a different animal wearing the same word. Changing the vmClass variable does not resize anything in place. VKS rolls out replacement nodes on the new class and drains the old ones, which is a full rolling update with all of its usual hazards, including PodDisruptionBudgets that can stall it indefinitely. There is no VCF CLI verb for it.

Read the bottom bar and then read the second bar again. Adding three nodes took 9 minutes. Making three existing nodes bigger took 38. Broadcom says plainly in the scaling documentation that horizontal scaling is generally the preferred approach, and the measurement is why. Most study material treats the two as interchangeable ways to add capacity. They are not, and a design item that gives you a maintenance window and asks which approach fits is testing exactly this gap.

Deletion, rollback and failure signatures

Rollback for a scale operation is simply the inverse edit, with one exception that matters. Horizontal changes reverse cleanly because replicas is just a number. Vertical changes do not reverse cheaply, because setting vmClass back triggers a second full rolling update at the same 38 minute cost, so you pay twice for the round trip. Volume changes on worker nodes do not reverse at all in any meaningful sense, since the roll discards the data in the existing volume.

Leftover persistent volume claims after a cluster delete are the quiet cost of a lab that gets rebuilt often. Mine accumulated 340 GB of orphaned claims across six rebuilds before a storage quota rejection made me look. Check pvc and cnsvolume state after every teardown.

Exam focus for objective 4.5

Objective checkpoint

Lifecycle CLI call for this estate

My war story for this objective cost a customer ninety minutes and it started with a helpful change. Someone raised the memory on the guaranteed-medium VM class in vCenter from 8 GB to 32 GB, reasonably enough, because a different team needed bigger virtual machines. Nobody told me. Two weeks later I scaled a six worker cluster to nine, and the three new workers came up with 32 GB while the six existing ones stayed at 8. VM classes are not immutable, and Broadcom documents this exact outcome: new nodes use the updated definition, existing nodes keep the definition they were built with. The scheduler did what schedulers do and packed the fat nodes. When one of them was drained for patching a fortnight later, the workload had nowhere to land and a customer facing service degraded for eleven minutes. Reconciling it meant a full rolling update of all nine nodes, ninety minutes, in a change window I had to beg for.

So here is my call for this estate, and it has two halves. For daily work use kubectl as the primary tool and treat the VCF CLI as the reporting and support layer. Kubectl covers every write operation including vertical scaling, its output is the same output every Broadcom procedure shows you, and it does not hide a topology behind a friendly flag. Reach for the VCF CLI for three things specifically: vcf cluster get with all conditions when something is stuck, vcf cluster list -A when you need a fleet view across namespaces, and vcf cluster support-bundler create when you need node level logs, which kubectl cannot give you. The tool to avoid as a default is vcf cluster scale, not because it is broken but because it teaches the wrong mental model: it makes scaling feel like a command you run rather than a field you set, and that misunderstanding is precisely what objective 4.5 items are built to detect.

Second half: put a change control fence around VM class definitions. Treat them as shared platform contracts, not per team knobs. If a team needs a different shape, add a class rather than editing one. That single policy would have prevented the whole ninety minute episode.

Tonight, in your own lab: provision vks-lifecycle-01, scale the workers out by three, then change the VM class and time both operations with a stopwatch. Feeling the difference between 9 minutes and 38 is worth more than reading it here. If the underlying product mechanics are still fuzzy, the VKS Series walks the same ground without the exam framing, and the VCAP-VKS exam guide maps every objective to its Part. Part 21 picks up where a vertical scale leaves you, inside a rolling update, and covers objective 4.6.

References

• VCF CLI v9.0 cluster plugin command reference, Broadcom TechDocs
• Manually Scale a Cluster Using Kubectl, VCF 9.0 Service Administration, Broadcom TechDocs
• VMware Cloud Foundation VKS Administrator exam guide, 3V0-24.25

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