As Kubernetes adoption matures inside the enterprise, the challenges platform teams face have shifted.

Standing up clusters is no longer the challenge. The real work begins after day one: upgrading clusters safely, operating them predictably, and supporting workloads like databases and regulated applications without fragile scripts or one-off exceptions.

With the latest release of VMware vSphere Kubernetes Service (VKS) 3.6, we focused squarely on these realities.

Rather than introducing a long list of disconnected features, this release advances the platform across a small set of operational themes that matter to platform engineers and Kubernetes administrators who are running Kubernetes in production at scale.

At a Glance: What’s New in VKS 3.6

VKS 3.6 introduces enhancements to enterprise operations, performance, and ecosystem flexibility: 

1. An open, extensible networking ecosystem – A supported path for partner networking add-ons allows Container Network Interface (CNI) plugins to integrate natively with VKS while staying within lifecycle and support boundaries.
2. Performance tuning for data-intensive and latency-sensitive workloads – Declarative TuneD profiles enable safe kernel and sysctl tuning for databases and high-throughput applications without unsupported host customization.
3. Enterprise OS choice with support for RHEL – Red Hat Enterprise Linux (RHEL) nodes, including mixed-OS clusters.

Kubernetes 1.35, Built for Enterprise Operations

VKS 3.6 adds support for Kubernetes version 1.35, continuing Broadcom’s commitment to delivering CNCF-certified Kubernetes that is designed for enterprise use.

As with previous releases, Broadcom provides 24-month extended support per Kubernetes version, with overlapping version support. This allows large organizations to move teams forward on their own timelines without forcing fleet-wide upgrades or compressed maintenance windows.

Some notable highlights from the Kubernetes 1.35 release include:

• Configurable concurrency for StatefulSet rolling updates with maxUnavailable – Platform teams can now take multiple Pods offline during StatefulSet upgrades, controlling disruption for stateful workloads while shortening rollout times.
• Improved topology awareness for workloads – Workloads can safely consume node topology information, improving awareness of their location within the infrastructure, which is useful for latency-sensitive and data-intensive applications.
• Modernized storage foundations – Advancements such as OCI-based volumes align Kubernetes storage consumption more closely with container-native delivery models.

At the same time, Kubernetes continues to remove or deprecate legacy features. VKS follows upstream deprecation timelines while providing extended support and clear migration paths, giving platform teams time to adapt without sudden breakage. This balance preserves upstream alignment while avoiding disruptive, fleet-wide surprises.

Smoother Upgrades and Safer Day-2 Operations

Upgrades are where Kubernetes platforms are most often stressed.

In practice, upgrade failures are rarely caused by Kubernetes itself, but by configuration and integrations. Policy engines, admission webhooks, and security or management tools can unintentionally block lifecycle actions. 

Building on the PodDisruptionBudget pre-checks that were previously introduced, VKS 3.6 expands upgrade readiness checks to surface common configuration conflicts before an upgrade begins. Rather than discovering blockers mid-upgrade, platform teams can identify and fix issues ahead of maintenance windows, reducing failed upgrades and unplanned disruption. These checks run continuously, exposing upgrade risks through the SystemCheckSucceeded Condition instead of only during upgrade execution.

The result is fewer upgrade surprises, earlier warning, and more reliable Day-2 operations without risking unexpected data loss.

Performance and Data-Intensive Workloads

Running databases and other stateful platforms on Kubernetes often requires kernel and node-level tuning that goes beyond default settings.

In many environments, teams relied on manual node changes or bespoke images to meet these requirements. In managed Kubernetes models, those changes typically need to be expressed declaratively (for example via approved configuration mechanisms, privileged DaemonSets, or standardized images) to remain durable through upgrades and node replacement. 

VKS 3.6 introduces supported TuneD profiles, allowing developers to tune the Linux kernel (including sysctl and sysfs parameters) declaratively through Kubernetes resources. Profiles can be targeted to specific node pools, enabling workload-specific optimization within the same cluster.

This makes common scenarios straightforward and supportable, such as:

• Optimizing nodes for high-throughput networking
• Tuning memory behavior for databases and caching systems
• Adjusting kernel settings for latency-sensitive workloads

A built-in profile provides a safe, enterprise-ready starting point, while custom profiles allow deeper specialization when needed.

The result is consistent, upgrade-safe performance tuning applied through standard Kubernetes workflows, without manual node configuration or configuration drift.  

Security, Compliance, and Governance

VKS 3.6 makes it easier to support regulatory and security requirements without locking clusters into rigid, one-size-fits-all hardening.

Expanded configuration for Kubernetes components lets platform teams tailor compliance posture to each workload and environment. Teams can apply stricter controls where required, relax them where appropriate, and evolve configurations over time instead of rebuilding clusters to change policy.

AppArmor profile management is also simplified in this release. Administrators can now define AppArmor profiles as Custom Resources and have them automatically loaded and kept in sync across all worker nodes of a cluster or for specific node pools. This allows each workload to be configured with a desired AppArmor profile, without node-level configuration complexity.

VKS 3.6 also improves operational autonomy. Workload cluster owners can now generate VKS support bundles without vCenter credentials, removing the need for elevated infrastructure access during troubleshooting. This reduces friction between Kubernetes and infrastructure teams while maintaining least-privilege security.

Platform UX and Ecosystem Enablement

Enterprise Kubernetes platforms need both strong defaults and real ecosystem choice. Too much rigidity slows adoption; too much freedom creates operational risk.

This release moves that balance forward by opening the platform to partner innovation and supporting customers to bring their own tooling.

Your Network, Your Choice

A supported integration point is now available for networking partners and ISVs.

Platform teams can use partner-validated networking add-ons while remaining within normal lifecycle, upgrade, and support boundaries. This creates space for third-party networking and network security capabilities to integrate natively.

Teams can keep the networking stack they already trust, and partners get a stable, supported surface to build on. This lowers friction when migrating existing Kubernetes environments to VKS and enables a broader set of networking options over time.

Your Firewall, Your Choice

VKS 3.6 introduces centralized, API-driven management of node-level firewall rules across all supported operating systems. Platform teams can now open required ports for HostPorts and NodePort Services through cluster configuration, instead of relying on privileged init containers or DaemonSets running on every node.

By moving firewall control from individual workloads to the cluster level, teams simplify configuration, improve auditability, and reduce the security risks associated with privileged components.

For Linux nodes, VKS 3.6 also adds support for the nftables backend for kube-proxy, delivering better performance and scalability compared to the default iptables implementation.

Your OS, Your Choice

Red Hat Enterprise Linux (RHEL) 9 joins Photon OS 5, Ubuntu 22.04 and 24.04, and Windows Server 2022 as supported operating systems for VKS cluster nodes. RHEL can be used for both control plane and worker nodes.

To support diverse application requirements within a single cluster, VKS continues to allow different node pools to run different operating systems. RHEL node pools can exist alongside Windows, Ubuntu, and Photon nodes, enabling heterogeneous clusters and gradual OS migration over time.

VKS 3.6 also introduces improved tooling for building custom node images across all supported operating systems. Image Baker is designed for connectivity-restricted environments, runs independently of vCenter to reduce infrastructure dependencies, and is delivered as a VMware Cloud Foundation (VCF) CLI plugin. Broadcom continues to provide pre-built images for Photon and Ubuntu.

Kubernetes, with Fewer Surprises

This release focuses on the parts of Kubernetes that matter most after day one.

Upgrades become more predictable, performance tuning for data-intensive workloads, RHEL-based environments have a clear migration path, and networking is opened to a growing ecosystem of validated partners.

Together, these changes align Kubernetes with how customers actually run it in production: standardized, policy-driven, and integrated with existing tools and platforms.

For platform teams operating at scale, the outcome is simple: fewer surprises, lower operational risk, and a more reliable foundation to build on.

Resources

Available Now:

• VKS web page: Learn more about VKS
• VKS 3.6 Release Notes: Full details on features, fixes, and supported configurations
• VKS 3.5 Upgrade Readiness Checks: How PodDisruptionBudget pre-checks help prevent upgrade failures
• Your OS, Your Choice: A closer look at RHEL 9 support, heterogeneous clusters with mixed operating systems, and improved image tooling that helps enterprises align Kubernetes with existing OS standards.

Coming Soon to VMware Blogs:

• Your Network, Your Choice: How VKS opens a supported integration path for partner networking add-ons, enabling validated CNIs and network security solutions while preserving lifecycle safety and supportability.
• Performance Tuning, Done Right: How declarative TuneD profiles bring safe, upgrade-resilient kernel tuning to Kubernetes for data-intensive and latency-sensitive workloads.

Upstream Kubernetes and Open Source References:

• Kubernetes 1.35 Release Overview: Deprecations, removals, and platform improvements
• TuneD Project Documentation: Background on TuneD profiles used for performance tuning