Managing VKS Clusters at Scale: Improvements in VCF 9.1

Introduction

With VCF 9.0.1 we introduced VKS cluster management – a native, VCF-first capability for provisioning, governing, and operating VKS clusters without needing a separate management plane. We’ve heard a lot of great feedback since then, and in VCF 9.1 we’ve acted on it.

The VKS cluster management feature in VCF 9.1 focuses on a few areas that we know matter to teams running Kubernetes at scale: a cleaner, more extensible model for managing cluster add-ons, a leaner and more secure agent footprint, and a consistent declarative API that fits neatly into how the rest of VCF works. None of these are flashy headline features – but if you’ve been running VKS in production, you’ll feel the difference.

Let’s walk through what’s changed.

VKS Add-Ons: A Unified Framework, Finally

If you’ve been using VKS Standard or Core packages to extend the functionality of your clusters, you’ll be familiar with the historical split between those two catalogs. Starting with VKS 3.7.0, we’ve consolidated all of that into a single unified framework simply called VKS Add-Ons.

The goal was to make it obvious what you’re getting, who stands behind it, and what level of support you can expect – without having to dig through documentation. To that end, every add-on in the catalog now sits in one of four support tiers:

• Product – curated and deeply integrated by Broadcom engineering. Broadcom Global Support (GS) covers the full lifecycle: deployment, upgrades, and runtime troubleshooting.
• Partner – curated by an ISV. Broadcom GS handles deployment and lifecycle; your ISV partner owns runtime issues.
• Ecosystem – Broadcom-curated open source validated for base VKS compatibility. Broadcom GS covers packaging and lifecycle, not upstream bugs.
• Community – user-built or unverified packages. No official support channel from Broadcom.

The below table lays out what each tier is responsible for and the support obligations of each:

This makes a real difference in regulated environments where your compliance team needs to know, before a third-party component goes into production, exactly who is responsible for what.

A couple of other practical improvements shipped with the framework transition: you can now configure multiple AddonRepoInstalls on a cluster (previously limited to one), and add-on pods on Kubernetes v1.34 and later can now have a PriorityClass assigned – meaning platform add-ons are less likely to get evicted under resource pressure, which matters when you’re running tight on node capacity.

New Add-ons in 3.7.0

The 3.7.0 release (which aligns with VCF 9.1) also brought a handful of net-new add-ons into the catalog:

• Multus (4.2.4) – Product tier – enables pods to attach multiple network interfaces, which is foundational for workloads with SR-IOV or advanced networking requirements.
• NFS Client (4.13.2) – Product tier – a CSI driver for NFS persistent volumes with the full suite of CSI sub-components (Provisioner, Resizer, Snapshotter, Liveness Probe, Node Driver Registrar).
• Whereabouts (0.9.3) – Product tier – a cluster-wide IPAM CNI plugin for managing IP address allocation across nodes, tightly integrated with Multus.
• Headlamp (0.42.0) – Ecosystem tier – a web UI for Kubernetes that automatically installs the right plugins (for example, cert-manager and Prometheus) based on what add-ons you have active. It’s a genuinely nice lightweight alternative to spinning up a full dashboard stack.
• Cilium (1.19.4) – Ecosystem tier – If you’re running workloads that need eBPF-based networking, Hubble observability, Layer 7 policy enforcement, or Egress Gateway, Cilium is now a first-class option on VKS. A few of the advanced features (L7 Proxy, Egress Gateway, Gateway API) require kube-proxy to be disabled on the cluster, so check the documentation before you flip those switches.

The most recent 3.7.0 release (July 2026) added one more:

• Policy Bundle – Product tier – It ships a curated set of admission policies aligned with the NSA/CISA Kubernetes Hardening Guidance v1.2, enforced via Gatekeeper’s OPA engine. Out of the box you get policies covering the full NSA/CISA v1.2 recommendations, and you’re in control of which ones are active: you can scope enforcement per-cluster, set each policy to audit (observe without blocking) or deny (enforce at admission), and define namespace- or workload-level exclusions for trusted platform components. The only prerequisite is that the Gatekeeper add-on is installed and healthy on the cluster. For teams in regulated industries who’ve spent time authoring and maintaining their own ConstraintTemplate resources, this is a meaningful time saver.

To find the latest information around what Add-On versions are available, their support tiers and fixes or updates – check the TechDocs Add-Ons section here.

A Leaner, More Secure Cluster Agent

Here’s one of those areas where the fix might not sound exciting, but the implications are material: we’ve reduced the CPU and RAM footprint of the VKS cluster management agent and its extensions.

When a cluster is brought under VKS Cluster Management control, the agent service installs a set of extensions and CRDs into the cluster. For some time, customers – particularly those running at the edge or on resource-constrained infrastructure – have asked us to reduce the infrastructure footprint required by these extensions. 

VKS Cluster Management has a narrower feature scope than Tanzu Mission Control – Self Managed, which was VKS Cluster Management’s predecessor and focused on public cloud cluster management. As such, we’ve taken that opportunity to consolidate the agent into a lighter, more reusable communication layer that handles the connectivity back to the VCFA backend. Less overhead in your clusters, and a foundation that other VCF services can build on top of.

Secure by Default

Alongside the footprint work, we’ve set a securityContext on all VKS Cluster Management agent and extension pods. This was a direct ask from customers in regulated industries. The expectation from enterprise operators is that vendor-supplied software arrives hardened. Requiring customers to audit and harden third-party agents themselves is an unreasonable burden, especially for teams that aren’t Kubernetes security specialists. VKSM pods now pass CIS benchmark testing out of the box.

Policy Insights Move to the Backend

We’ve also moved policy insight consolidation from the in-cluster agent to the VKSM backend. Previously, the agent running on each workload cluster was responsible for collecting policy violations and consolidating them for the UI – which added up across a large fleet. With this change, that work happens server-side, reducing resource consumption on your clusters and improving the performance and scale of policy reporting.

Get Started

VCF 9.1 is available now from the Broadcom Support Portal. Full documentation for VKS Add-ons, including the new support tiers, upgrade paths, and configuration reference for each add-on, is on Broadcom Tech Docs.