Ninety seconds apart, same cluster, nothing scaled down. Something added two nodes and something else took them away, and both of them believed they were correct. That fight is the most common way a VKS autoscaler installation fails, it produces no error anywhere, and objective 4.7 is written in a way that makes it very easy to walk into.

Version pinning before you touch a cluster

Part 21 left vks-lifecycle-01 in ns-platform-a sitting on VKr v1.32.0 after a rolling update. This Part builds a second cluster alongside it, vks-autoscale-01, because autoscaler annotations are far cleaner at creation than retrofitted, and then upgrades that cluster with the autoscaler in place. Same namespace, same storage policies, same VM classes bound from Part 17.

One relationship governs everything below. Broadcom documents a one to one binding between the autoscaler package minor version and the VKr minor version, and states plainly that a mismatch causes package reconciliation to fail. A VKr 1.32.x cluster takes a 1.32.x autoscaler. Not 1.33, not 1.31, no exceptions, no compatibility window. Write that down before you write anything else, because it converts the autoscaler from a one time install into a permanent dependency of your upgrade runbook.

Broadcom lists the floor for this feature as vSphere 8 Update 3 with VKr 1.27.x or later, which matters only if you are studying against an older estate. On VCF 9.0 with VKS 3.3 you get one capability that changes design: scaling a pool up from zero and down to zero, on VKr 1.31.4 and later. Before 3.3 the floor was one node per pool, which meant a batch pool cost you a machine around the clock. Now it does not, and that is worth knowing because it is the kind of version boundary an exam item can hang a scenario on.

Cluster spec with autoscaler annotations

Two annotations on the worker nodePool do all the work, and one omission carries the whole thing. You do not set replicas on an autoscaled pool. Cluster API reads min size as the starting replica count, so a pool with min 3 comes up with three workers and then hands ownership of that number to the autoscaler. Leave replicas in the spec and the topology controller keeps enforcing your number while the autoscaler keeps enforcing its own.

Control plane replicas stay hard coded at three. Cluster autoscaling on VKS adjusts worker nodes only, and an item that offers you a control plane min and max annotation is offering you a wrong answer. Note also that the annotations sit under the machineDeployment metadata, not under the cluster metadata, and not on the ClusterClass. Placement is exactly the sort of detail a drag and drop item can test.

Package repository and autoscaler install

Annotations alone do nothing. A cluster carrying min and max annotations with no autoscaler package installed sits at min size forever and reports no error, which is a state worth recognising because it looks healthy from every angle. Installation runs against the workload cluster context, not the Supervisor, and it needs the standard package repository from Part 23 territory in place first.

Cluster is on VKr v1.32.0, so the autoscaler is 1.32.2+vmware.1-vks.1. Reading four available versions and taking the newest is the reflex that breaks this, and it is the reflex most Kubernetes operators have built over a decade of package management.

Two namespaces, and candidates mix them up under time pressure. PackageInstall, ServiceAccount and data values secret live in tkg-system. Running Deployment and pod land in kube-system. If you look for the pod in tkg-system and find nothing, the install is probably fine and your kubectl is pointed at the wrong namespace.

The clusterName and clusterNamespace values are not decoration. Broadcom sample manifests use gc1 and cluster as defaults, and copying them unchanged against a cluster named anything else produces an autoscaler pod that starts, stays Running, reports healthy, and never scales a thing, because it is watching a Cluster object that does not exist.

Scale behaviour with measured timings

Testing scale up is a matter of creating pods that cannot be scheduled. Scale a Deployment past what three guaranteed-medium workers can hold, watch pods go Pending, and watch a MachineDeployment replica count climb. What people underestimate is how long a node takes, because a VKS worker is a virtual machine cloned from a content library image, not a cloud instance from a warm pool.

Median was 4 minutes 16 seconds across six events, worst case 11 minutes 12 seconds. Now read the scale down defaults against that. A node has to sit unneeded for scaleDownUnneededTime, 10 minutes, before removal is even considered, and scaleDownDelayAfterAdd holds off any removal for 10 minutes after a scale up. Both defaults look conservative until you notice that reacquiring a node costs four minutes minimum and can cost eleven. Cut scaleDownUnneededTime to 2 minutes because a blog told you it saves money, put a bursty CI workload on it, and you will pay for the same node three times an hour in provisioning latency while your pipeline sits Pending. Leave the defaults unless you have measured your own arrival pattern.

Upgrade sequence for an autoscaled cluster

Here is where objective 4.7 stops being an install task. An autoscaled cluster cannot be rolled the way Part 21 rolled vks-lifecycle-01, because a rolling update deliberately removes and replaces nodes while an autoscaler is deliberately reacting to node removals. Broadcom is unambiguous: pause the autoscaler first. Order is the whole answer.

flowchart TD
  A[Set paused true in autoscaler data values] --> B[Apply secret and confirm reconcile]
  B --> C[Edit topology version to new VKr]
  C --> D[Control plane rolls, then workers roll]
  D --> E{UPDATED equals REPLICAS on every pool}
  E -->|No| D
  E -->|Yes| F[Repin PackageInstall to matching autoscaler minor]
  F --> G[Set paused false in the same apply]
  G --> H[Confirm Reconcile succeeded and pod Running]
  H --> I[Force one pending pod and watch a node appear]

Repinning is the step people drop, and it fails quietly in the worst possible way. A 1.32 autoscaler against a 1.33 cluster leaves a PackageInstall stuck in reconcile failure while the pod from the previous version may still be Running from before the constraint changed. Cluster looks upgraded, autoscaler pod looks alive, and nothing scales. Add a line to your upgrade runbook that says check pkgi after every VKr change, because kubectl get nodes will never tell you.

Real failures, with their error lines

Two failures are worth reproducing on purpose tonight, because both are silent in different ways and both map directly onto how objective 5.2 will come back at you in Part 31.

Table below is the artifact to keep. Every row is a state you can reach in a lab in under ten minutes, and the middle column is what you will actually be shown in an exam item, because item authors do not give you the cause, they give you the symptom.

Field note from forty wasted minutes

My first autoscaler on VKS went onto an existing cluster rather than a new one, because rebuilding felt wasteful. I added min 3 and max 8 to the node pool, installed the package, pinned the right minor, and ran a load test. Nodes appeared. Nodes vanished. Nodes appeared again. Over roughly forty minutes that cluster created and destroyed twelve machines, and vCenter tasks were a wall of clone and delete pairs that made it look like a storage problem.

Nothing logged an error. Autoscaler was doing its job. Topology controller was doing its job. My original spec still carried replicas: 3 on that pool, and I had added annotations next to it without removing it, because every other Kubernetes autoscaler I had used tolerates that. Forty minutes of investigation, twelve pointless machine lifecycles, and a load test I had to rerun from scratch. Fix was deleting four characters from a manifest.

Verdict: create autoscaled clusters with annotations and no replicas from the start, and retrofit only when you have no choice. If you must retrofit, remove replicas and add both annotations in one single apply rather than two, so there is no window where the two controllers disagree. Avoid the pattern of annotating first and cleaning up after, which is what everyone does and what cost me the afternoon. Broader provisioning mechanics live in the VKS series if you want the non exam version of this workflow.

Exam focus for objective 4.7

Autoscaler settings I would ship for this estate

My recommendation is to leave every timing argument at its default and spend your configuration effort on min and max instead. Defaults of 10 minutes for scaleDownUnneededTime and scaleDownDelayAfterAdd are well matched to a median 4 minute 16 second node provision time, and every attempt I have seen to tighten them has traded a small amount of idle capacity for a large amount of pod scheduling latency. Set maxNodesTotal to 0 as shipped and bound cost with the vSphere Namespace quota, which is enforced by the Supervisor and cannot be bypassed by editing a secret inside the workload cluster. That is the Supervisor doing what the Supervisor is for, and it is a better control point than an argument a cluster admin can change.

Tonight, do one thing: build vks-autoscale-01 with min 3 and max 8, install the matching autoscaler package, then deliberately reproduce failure 2 above by patching replicas back onto the pool. Watch the oscillation, read the events, then remove replicas and watch it settle. Ten minutes of that is worth an hour of reading, and it is the exact behaviour objective 4.7 and objective 5.2 both lean on. Part 23 moves to package repositories, standard packages and registry secrets, which is where the repository you installed here gets treated properly. Full path is indexed on the VCAP-VKS exam guide pillar.

References

• Install Cluster Autoscaler Using Kubectl, VCF 9.0, Broadcom TechDocs
• Upgrade Autoscaled Cluster Using Kubectl, VCF 9.0, Broadcom TechDocs
• About Cluster Autoscaling, VCF 9.0, Broadcom TechDocs
• VMware Cloud Foundation VKS Administrator Exam Guide, 3V0-24.25, Broadcom

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