3V0-24.25 VKS Upgrade Troubleshooting: Stalled Nodes and PDBs

About this video

Mixed Kubernetes versions do not automatically mean that a VKS rolling upgrade has failed. The real problem begins when the cluster stops progressing—perhaps a replacement Machine remains in Provisioning, an old Machine remains in Deleting, or a node stays cordoned because its workloads cannot be evicted. In this video, we break down Objectives 4.6 and 5.4 of the VMware 3V0-24.25 VKS exam. Objective 4.6 covers VKS rolling updates and configuration changes, while Objective 5.4 focuses on restarting or recovering failed VKS upgrades. We begin by examining the controller-managed upgrade sequence. VKS uses declarative reconciliation to move the cluster toward the requested Kubernetes release. Control-plane nodes are upgraded before worker nodes, and retiring Machines are handled through a controlled cordon, drain, and deletion workflow. Seeing old and new versions together is therefore normal while the rollout is active. The key troubleshooting skill is identifying which stage has stopped: The upgrade may be blocked by a system pre-check A replacement Machine may fail to provision A new node may provision but fail to join An old node may fail to drain The final cluster state may fail to converge We will separate the two diagnostic contexts that many candidates confuse. On the Supervisor, we inspect the Cluster, Machine, and infrastructure conditions that control node lifecycle. Inside the VKS workload cluster, we inspect Nodes, Pods, PodDisruptionBudgets, and workload availability. Broadcom’s own upgrade procedures use these two contexts separately because they expose different layers of the failure. We will then analyze two major failure paths. The first is a replacement-node provisioning failure. A new Machine may be unable to acquire an IP address, exceed an enforced namespace limit, fail to retrieve its image, or encounter a bootstrap, storage, load-balancer, or CNI problem. The correct response is to follow the earliest failing Machine condition rather than deleting an existing node to create capacity. Broadcom documents workload-network exhaustion and restrictive namespace limits as real examples of these infrastructure-side failures. The second is an old-node drain failure. A PodDisruptionBudget with zero allowed disruptions can stop the eviction API from moving an application Pod away from a retiring node. The node may remain Ready,SchedulingDisabled while the associated Machine remains in Deleting. We will inspect ALLOWED DISRUPTIONS, locate the protected workload, and determine whether the correct solution is to restore replicas, add healthy capacity, or adjust the PDB with the application owner. Current VKS releases may also prevent an unsafe update from starting by setting SystemChecksSucceeded to false when blocking PDBs or certain third-party webhooks are detected. This makes the condition message one of the first places to look before assuming the rollout has already failed halfway through. Throughout the troubleshooting process, we avoid direct VM deletion in vCenter. Manual deletion bypasses the controller-managed workflow and can leave unresolved Machine state or volume-attachment problems. Interfering with control-plane nodes can also put etcd membership and quorum at risk. The final validation covers: Cluster and Machine convergence on Supervisor Node readiness inside the VKS cluster Kubelet version alignment Application replica availability Completion of node drain and deletion Restoration of any temporarily modified disruption policies The 3V0-24.25 exam is not simply testing whether you can start an upgrade. It is testing whether you can determine which lifecycle stage owns the failure and recover the rollout without bypassing declarative control. By the end of this module, you will have a repeatable framework for diagnosing VKS pre-check failures, replacement-node provisioning blocks, PodDisruptionBudget deadlocks, and stalled rolling upgrades. Next, we will troubleshoot private image deployment failures by separating registry credentials, namespace-scoped image pull secrets, and enterprise Root CA trust. #3V02425 #VKS #VMwareCertification