Build, Deploy, and Scale with Confidence: vSphere Kubernetes Service 3.5 is Now Live with 24-Month Support

VMware vSphere Kubernetes Service (VKS) 3.5 is now generally available and this new release makes 24-month support available to each Kubernetes minor version, starting with VKr 1.34. We previously announced 24 months of support for vSphere Kubernetes release (VKr) 1.33 in June 2025. This change provides platform teams with greater stability and flexibility when planning upgrades.

VKS 3.5 also brings several improvements to operational consistency and lifecycle management, including fine-grained configuration controls for core Kubernetes components, a declarative add-on management model, and integrated support-bundle generation directly from the VCF CLI. Additionally, new upgrade guardrails—such as PodDisruptionBudget validation and compatibility checks—help ensure safer, more predictable cluster upgrades.

Together, these enhancements improve reliability, operational efficiency, and Day-2 management for Kubernetes environments at scale.

vSphere Kubernetes release(VKr) 1.34

VKS 3.5 enables support for VKr 1.34. Every vSphere Kubernetes minor version is now supported for 24 months from its release date. This reduces upgrade pressure, stabilizes environments, and frees up teams to focus on delivering value instead of constantly planning upgrades. Teams that want quick access to the latest Kubernetes features can stay current with new releases. Those that prefer to run on a stable version for longer can now do so with confidence. VKS 3.5 supports both operating models.

The Dynamic Resource Allocation (DRA) feature has been graduated to “stable” in upstream Kubernetes 1.34. This capability enables administrators to centrally categorize hardware resources such as GPUs using DeviceClass. This helps assure reliable and predictable placement of pods on nodes with the requested hardware class. DRA improves device utilization by allowing device sharing to declaratively claim resources similar to Dynamic Volume Provisioning. DRA addresses challenges of randomness in resource allocation and resource under-utilization. Consumers can perform fine-grain filtering to request for a specific device using ResourceClaimsTemplates and ResourceClaims while deploying their workloads

DRA allows sharing of GPU devices between multiple pods/containers. Workloads can be configured to select the GPU device using the Common Expression Language (CEL) and ResourceSlice requests to achieve better utilization than count-based requests.

Advanced Cluster Configuration for Kubernetes Components

VKS 3.5 brings flexibility to control over 35 configurations across Kubernetes components like kubelet, apiserver and etcd. These configurations help platform teams fine-tune various aspects of the clusters to suit their workload requirements. You can find the entire list of configurable parameters in the product documentation. Here is a high-level summary of the areas of configuration that VKS 3.5 offers:

Configuration	Configurable Components	Description
Logging & Observability	Kubelet API Server	Configure logging behavior for API server and kubelet including log flush frequency, format (text/json), and verbosity levels. Control container log retention with maximum log file count and size limits. With this, you can efficiently manage disk usage, troubleshoot issues with appropriate log verbosity, and integrate with log aggregation systems using structured JSON logging.
Event Management	Kubelet	Manage Kubernetes event generation with configurable event creation rate limits (eventRecordQPS) and burst capacity (eventBurst) to prevent overwhelming the API server. With this, you can control the rate at which kubelets send requests to the API server, ensuring cluster stability during high-activity periods while maintaining visibility into important events.
Performance & Scalability	API Server	Control API server performance with configurable limits for maximum concurrent mutating requests, non-mutating requests, and minimum request timeout duration. Enable or disable profiling endpoints. With this, you can tune your cluster to handle high-traffic workloads, prevent API server overload, and optimize responsiveness for your specific usage patterns.
etcd Configurations	etcd	Configure maximum etcd database size (2-8 GiB range). The volume is provisioned with 25% additional capacity to account for compaction, defragmentation, and temporary usage spikes. With this, you can right-size your etcd storage based on cluster scale and object count, preventing out-of-space conditions that would put the cluster into read-only mode.
Image Management	Kubelet	Configure container image lifecycle including garbage collection thresholds (high/low disk usage percentages), minimum and maximum image age before collection, image pull rate limiting (registryPullQPS and registryBurst), maximum parallel image pulls, and image pull credential verification policies. With this, you can optimize node disk utilization, control registry bandwidth consumption, speed up pod startup times with parallel pulls, and enforce security policies for image access.
OS-level Security	OS	Enable GRUB bootloader password protection using PBKDF2 SHA-512 hashed passwords. Mandate sudo password re-authentication requirements. With this, you can meet compliance requirements for boot-time security and privileged access controls, preventing unauthorized system modifications and enforcing security policies across your cluster infrastructure.

Cluster API v1beta2 for Enhanced Kubernetes Cluster Management

VKS 3.5 has incorporated Cluster API v1beta2 (CAPI v1.11.1), which introduces several changes and improvements to the API versions for resources compared to v1beta1. Please see CAPI release notes for all the improvements.

To ensure a smooth transition, any new or existing clusters created with the previous v1beta1 API will be automatically converted to the v1beta2 API by the upgraded Cluster API controllers. Going forward it is recommended to use v1beta2 API to manage the LCM of Kubernetes cluster.

v1beta2 API version marks an important step in the journey towards graduating API to v1
Status has been improved across all resources to provide better observability and address feedback from customers and field engineers

Prevent Upgrade Failures Due to Misconfigured PodDisruptionBudget

A Pod Disruption Budget (PDB) is a Kubernetes object that helps maintain the availability of an application during voluntary disruptions. It ensures that a minimum number of pods remain running during events like node maintenance, upgrades, or scaling operations. Misconfigured PodDisruptionBudgets (PDBs) can block cluster upgrades.

VKS 3.5 introduces guardrails to identify misconfiguration of PDB, which could result in stalling of upgrades or other lifecycle operations. VKS blocks a cluster upgrade when it detects that the PDB is misconfigured with no room for disruptions.

To improve the reliability and success rate of Kubernetes cluster upgrades, a new SystemChecksSucceeded condition has been introduced to the Cluster object. This enhancement provides customers with clear visibility into the cluster’s readiness for an upgrade, specifically concerning PodDisruptionBudgets (PDBs).

This new condition offers the following key benefits:

Proactive Upgrade Blocking: Detects PDB configurations that would block pod evictions and stops the upgrade before it begins, preventing disruption or failure
Clearer Issue Identification: Sets SystemChecksSucceeded to false if any PDB has allowedDisruptions <= 0, highlighting scenarios where PDBs might prevent pod evictions and cause downtime.
Upgrade Planning: This condition can be used to plan for upgrades, ensuring that any misconfigured PDBs are fixed ahead of time.

Note

Any PDB which has no matching Pods may indicate a misconfiguration, such as an erroneous selector. Such PDBs will also have allowedDisruptions will be 0, and will therefore block upgrade.

Streamlined Operations: CLI, Add-On Management, and Support Tools

VKS 3.5 enables platform teams to simplify operations like lifecycle management of add-ons and creation of support bundles.

VKS Add-On Management: The new Add-on Management feature unifies the installation, upgrade, and configuration of standard packages. It offers a single method for all standard package operations, a declarative API, and pre-checks to prevent dependency or compatibility issues during upgrades. While the old workflow remains available, adopting the new VKS add-on management provides significant benefits.

Allowing management of VKS Standard Packages via the Supervisor Namespace, including installation, upgrades, and configurations. Users can consume this via VKS-M 9.0.1 or the new VCF CLI ‘addon’ plugin.
Simplifying the installation of the Cluster Autoscaler add-on and allowing it to be automatically upgraded as a part of Cluster upgrades.
With the declarative Addon Management APIs (AddonInstall, AddonConfig), customers can manage add-on installations and updates directly through Argo CD or other GitOps controllers – This enables version-controlled, repeatable add-on deployments across multiple clusters with improved auditability and consistency
Allowing an Addon Repository to be set up in all VKS clusters via AddonRepository/AddonRepositoryInstall APIs. This will simplify the setup process for VKS Standard Packages, including when relocated to a private registry. By default, an AddonRepository for VKS Standard Package embedded in the VKS Package will be installed (v2025.10.22 release for this VKS 3.5.0 release).
As part of Cluster k8s version upgrades, VKS will perform add-on compatibility pre-checks and will upgrade add-ons to ensure the clusters are using the latest compatible AddonReleases. If the compatibility pre-checks fail, VKS will block the upgrades.
As part of installing/upgrading add-ons on the Cluster, VKS will run a set of pre-checks, including migration checks to block duplicate PackageInstalls and dependency checks to report non-blocking errors for add-ons with missing dependencies.
Make it easier to discover new versions and associated compatibility metadata for AddonReleases

Integrated Support Bundler within VCF CLI – VKS 3.5 now incorporates the VKS Cluster Support Bundler directly into the VCF CLI. This integration streamlines the process for users to gather all necessary diagnostic information for workload clusters using the support-bundle subcommand within the VCF CLI’s cluster plugin, eliminating the need for a separate download.

This feature has been enhanced with three key improvements: a significant reduction in output file size, selective log collection from only control plane nodes for faster and more targeted diagnosis, and integrated network log collection to troubleshoot network-related issues and provide a more comprehensive view of cluster health. Learn More and Get Started:

We’re incredibly excited for you to leverage these new capabilities and continue building amazing things with VKS!

Discover more from VMware Cloud Foundation (VCF) Blog

Subscribe to get the latest posts sent to your email.