3V0-24.25 VKS Autoscaling: HPA, Metrics Server and Cluster Autoscaler

About this video

An HPA can be working correctly while the application still fails to scale. In this final module, we break down Objectives 4.7 and 5.5 of the VMware 3V0-24.25 VKS exam and trace the complete scaling path from workload metrics to worker-node provisioning. The official exam guide covers autoscaler creation, configuration, and upgrades under Objective 4.7, with monitoring and performance optimization under Objective 5.5. We begin with an HPA displaying an unknown metric. For percentage-based CPU or memory utilization, the HPA compares current usage with the relevant container resource request. If that request is missing, utilization may be undefined. But missing requests are only one possible cause. The Metrics API, scale target, metric samples, and HPA conditions must also be verified before changing the workload. We will examine: HPA conditions and event messages The metrics.k8s.io resource-metrics path CPU and memory requests Percentage utilization versus raw metric targets Workload namespace ResourceQuota Pending Pods and scheduler events Cluster Autoscaler decisions Supervisor-side Machine provisioning LimitRanges and Kubernetes QoS classes VCF Operations performance visibility A major exam distinction is that scaling happens across several independent control boundaries. The HPA adjusts the desired replica count. Kubernetes admission controls decide whether the new Pods may be created. The scheduler determines whether those Pods fit on existing Nodes. Node autoscaling then evaluates unschedulable Pods and can request additional worker capacity. Finally, Supervisor and the infrastructure controllers must successfully provision the additional Machine VM. We will also separate two failures that are often confused. A Kubernetes ResourceQuota in the application namespace can reject new Pod creation when aggregate requests or limits exceed the allowed value. In that case, inspect the Deployment and ReplicaSet for a quota-related FailedCreate event. If the Pod already exists and reports Pending with Insufficient cpu, admission succeeded. The scheduler could not find enough allocatable requested capacity on the existing Nodes. This condition is based on resource requests and can occur even when live CPU utilization appears low. The Cluster Autoscaler can then expand an eligible worker pool, but only when the pending workload can fit a supported node type and the pool remains below its maximum size. If the additional Machine cannot be provisioned, troubleshooting moves to Supervisor and infrastructure conditions rather than back to the HPA. We will also clarify what a LimitRange can and cannot do. A properly configured LimitRange can apply default requests and limits to containers that omit them. This improves scheduler calculations, quota consistency, and HPA utilization measurements. The final Pod specification determines whether the workload is BestEffort, Burstable, or Guaranteed. Guaranteed QoS requires equal CPU and memory requests and limits for every container. QoS should not be treated as absolute eviction protection. CPU contention normally results in scheduling pressure or throttling, while kubelet node-pressure eviction focuses on resources such as memory, disk capacity, inodes, and process IDs. The final validation workflow covers: HPA conditions and current metrics Metrics API availability Pod requests and limits ResourceQuota and LimitRange configuration Deployment and ReplicaSet events Pending Pod scheduling reasons Cluster Autoscaler activity Supervisor Machine conditions Worker Node readiness Performance correlation in VCF Operations We will also review the autoscaler upgrade dependency: pause autoscaling before a VKS cluster upgrade, update the cluster, install the compatible autoscaler version, and then resume the scaling workflow. The 3V0-24.25 exam is not simply testing whether you know how to create an HPA. It is testing whether you can identify which controller owns the failure and follow the evidence across workload, cluster, and infrastructure boundaries. This completes our VKS certification analysis series—from Supervisor architecture and workload networking to service mesh security, Velero recovery, cluster upgrades, registry trust, and autoscaling. The final lesson is consistent across every domain: read the conditions, identify the owning controller, and correct the earliest failed transition before changing the environment. #3V02425 #VKS #VMwareCertification