Broadcom VKS 3.6 and Velero CNCF Sandbox: Enterprise Day-Two Kubernetes Ops

Broadcom used KubeCon EU 2026 in Amsterdam to make a two-part statement about its cloud-native strategy: VMware vSphere Kubernetes Service 3.6 is here, and Velero is on the path to CNCF Sandbox governance. Taken together, the announcements reinforce a familiar Broadcom message: VMware’s private cloud stack is being tuned for large enterprise platform teams that want tighter control, longer lifecycle support, and fewer operational surprises. The details matter, because the new VKS release leans hard into day-two operations, while Velero’s move signals a broader effort to place one of the industry’s best-known backup tools under vendor-neutral stewardship.

Overview​

Broadcom’s latest VMware-facing announcements should be read as both product news and strategy. VKS 3.6 is not just a minor feature update; it is a signal that Broadcom sees Kubernetes inside VMware Cloud Foundation as a core part of the private cloud operating model rather than a sidecar capability. That matters in a market where many enterprises still run mixed estates of virtual machines and containers and want one control plane experience for both.
The Velero announcement is different in tone but related in effect. By moving the project toward the CNCF Sandbox, Broadcom is helping position Velero as a community-governed project with a clearer separation between vendor product direction and project stewardship. In practical terms, that can broaden participation, reduce governance friction, and reassure users who prefer vendor-neutral infrastructure software for backup and disaster recovery.
What makes this moment especially interesting is timing. Broadcom is making these moves while the market is still digesting the post-acquisition reality of VMware, including the company’s sharper focus on higher-value enterprise customers and a more opinionated software stack. In that context, VKS 3.6 is not a generic Kubernetes release; it is a carefully framed answer to platform teams that need stability, compliance, and upgrade confidence more than novelty.
The underlying message is consistent across both announcements: Broadcom wants VMware to feel less like a grab bag of infrastructure products and more like a coherent private cloud operating system. That is a strong proposition for regulated industries, large-scale IT shops, and organizations that have already committed to VMware-centric architecture. It is also, inevitably, a more constrained proposition for customers who want maximum openness without being pulled deeper into a vendor-defined ecosystem.

Background​

Broadcom has spent the last two years redefining VMware around a smaller number of strategic products and a more consolidated go-to-market model. That shift has been controversial, but it has also been very clear: the company wants to reduce product sprawl, emphasize enterprise-scale use cases, and position VMware Cloud Foundation as the center of gravity for private infrastructure. The VKS line fits that approach neatly because it gives Broadcom an enterprise Kubernetes layer that lives inside the broader VMware stack rather than competing with it.
Kubernetes has matured enough that the hardest problems are no longer just about getting clusters running. The real friction shows up in upgrades, networking variation, operating system diversity, security policy, and consistent lifecycle management across many teams. VKS 3.6 is clearly aimed at those challenges, with features that support longer-lived versions, more predictable checks, and less fragile customization.
Velero occupies a different but adjacent part of the stack. Backup, restore, disaster recovery, and migration are the kinds of concerns that become more urgent as Kubernetes estates grow. A project like Velero is valuable not only because it works, but because it becomes part of the operational trust layer around a platform. In that sense, moving it into CNCF Sandbox status is about more than paperwork; it is about building confidence that the project can outlive any single vendor’s roadmap.
There is also an important ecosystem angle here. Broadcom has recently been presenting itself as one of the top contributors to CNCF projects, and that framing matters because it helps neutralize a common criticism: that VMware under Broadcom is becoming more closed, not more open. The company is effectively saying that its contributions to cloud-native open source remain substantial even as it tightens control around product packaging and commercial structure. That tension is central to understanding these announcements.

---

What VKS 3.6 Actually Changes​

VKS 3.6 is most compelling when viewed through the lens of enterprise operations rather than feature checklists. Kubernetes 1.35 support, RHEL 9 compatibility, and upgrade-safety improvements all point in the same direction: give platform teams more time, more choice, and fewer reasons to panic when the next lifecycle event arrives. That is the right priority for organizations running production workloads at scale.
The most important change may be the 24-month extended version support tied to Kubernetes 1.35. For large enterprises, the value is not simply “newer Kubernetes.” It is the ability to sequence upgrades according to internal change windows, application testing, and dependency validation rather than being forced into a rushed cadence. That is especially useful where multiple teams share infrastructure and every upgrade has compliance and business-change implications.

Kubernetes lifecycle as a product feature​

Broadcom is treating lifecycle support as a first-class product characteristic rather than a back-office promise. That matters because Kubernetes versions are no longer interchangeable in a mature enterprise environment; they are operational commitments with real cost, governance, and compatibility implications. When VKS gives more breathing room, it reduces the chance that platform teams will treat upgrades as emergency projects.
The strategic effect is subtle but significant. Longer support windows can increase customer confidence and reduce churn to alternatives that appear simpler on paper but may be less predictable in practice. Broadcom is betting that enterprise buyers will pay for managed certainty if the platform experience is strong enough.

• Longer support reduces forced upgrade pressure.
• Version timing becomes a planning variable rather than a crisis.
• Platform teams can coordinate app testing and infra changes more calmly.
• Internal change-management processes become easier to defend.

RHEL 9 support is equally important, though for different reasons. Many enterprises standardize on Red Hat tooling, image baselines, and operational practices, and Broadcom knows that ignoring that reality would limit VKS adoption. By supporting RHEL on both control plane and worker nodes, while still allowing heterogeneous clusters, Broadcom is acknowledging that enterprise environments are rarely homogeneous in practice.

OS diversity without operational chaos​

This is one of the more practical decisions in the release. Heterogeneous clusters can be a headache if a platform is poorly designed, but they are often necessary in real enterprise environments where teams inherit different standards or want to phase migrations gradually. VKS 3.6’s ability to run different operating systems by node pool suggests that Broadcom is trying to support that messiness without letting it spill into platform instability.
The presence of Windows Server 2022, Photon OS 5, Ubuntu 22.04, Ubuntu 24.04, and now RHEL 9 support also signals broad compatibility ambitions. This is not a niche developer platform; it is an attempt to be the operating substrate for mixed enterprise estates. That positioning aligns with VMware’s traditional strength, which has always been helping customers rationalize complexity rather than eliminate it.

• RHEL 9 support broadens appeal to Red Hat-heavy enterprises.
• Mixed OS node pools fit migration and governance realities.
• Broad OS support reinforces VMware’s platform neutrality story.
• Heterogeneity is presented as manageable, not risky.

Declarative Performance Tuning​

One of the more technically interesting additions in VKS 3.6 is declarative TuneD profile support. At a glance, this sounds small. In practice, it addresses a classic infrastructure problem: how to tune kernel and sysctl settings for demanding workloads without resorting to ad hoc host changes that fall outside standard support boundaries.
That matters because performance tuning is often where platform teams and application teams get into trouble. Database workloads, low-latency services, and high-throughput pipelines frequently want system-level adjustments, but custom host modifications are hard to audit and harder to support. By making these settings declarative and part of normal Kubernetes workflows, Broadcom is trying to keep tuning inside the platform model.

Why declarative tuning matters​

The key value here is not raw performance alone. It is repeatability. When a TuneD profile is managed declaratively, teams can reproduce configurations consistently across clusters and node pools, which reduces drift and makes performance behavior more understandable over time. That is a quietly big deal for regulated or globally distributed organizations.
It also fits the broader industry move toward infrastructure as code. If a system-level change is managed the same way as workload configuration, then audits, rollbacks, and reviews become simpler. That lowers the operational cost of supporting specialized workloads on a shared platform.

• Avoids unsupported manual host customization.
• Improves reproducibility across nodes and clusters.
• Helps performance tuning stay within governance.
• Reduces configuration drift over time.

Broadcom is also implicitly acknowledging that not every workload fits the same default kernel settings. That recognition is important for database-heavy private cloud deployments where default container assumptions may not hold. By exposing tuning as a supported, declarative control, VKS becomes more credible for serious enterprise workloads.

Upgrade Safety and Day-Two Operations​

The upgrade-safety story is one of the most mature parts of the release. VKS 3.6 introduces pre-upgrade checks that continuously surface configuration conflicts through the SystemCheckSucceeded condition, rather than waiting until the actual upgrade window. That may sound incremental, but for enterprise platform teams it can be the difference between a smooth rollout and a surprise outage.
This is exactly the sort of feature that separates a lab-friendly Kubernetes distribution from a production platform. In large estates, upgrade failures are rarely caused by one dramatic bug; they usually come from an accumulation of small compatibility issues that were missed earlier in the process. Continuous surfacing of those checks helps teams spot trouble while they still have time to fix it.

Better checks, fewer surprises​

The practical effect is improved day-two operations, which are often far more valuable than day-one setup wizardry. Many vendors can help a team deploy Kubernetes. Far fewer can help them keep dozens or hundreds of clusters aligned over several years without building elaborate custom guardrails. VKS 3.6 is clearly trying to sit in that rarer category.
This focus also reflects the reality of enterprise change control. Platform teams need advance warnings, not just hard failures during maintenance windows. If issues are detected earlier and exposed through standard status conditions, then the upgrade process becomes less dependent on tribal knowledge.

• Pre-upgrade issues appear earlier in the workflow.
• Configuration conflicts are easier to remediate.
• Maintenance windows become more predictable.
• Operational confidence improves for large fleets.

Broadcom is also making an argument about platform maturity. If VKS can reduce upgrade anxiety, it becomes more than a Kubernetes distribution; it becomes a governance mechanism for containerized infrastructure. That is exactly the kind of pitch that resonates in organizations where stability counts more than experimentation.

---

Networking, Security, and Ecosystem Integration​

Networking remains one of the defining challenges in enterprise Kubernetes, and VKS 3.6 adds a supported path for CNI partner plugins. That opens the ecosystem while still keeping support within Broadcom’s lifecycle boundaries, which is an important nuance. Enterprises want flexibility, but they also want someone to stand behind the stack when something breaks.
The first validated partner integrations are expected to be Cilium and Calico, two names that will be familiar to anyone operating Kubernetes at scale. This is a smart move because it gives customers access to widely respected networking options without forcing them into unsupported combinations. It also helps Broadcom avoid the perception that VMware’s internal defaults are the only acceptable path.

A broader networking story​

Broadcom’s comparison to OpenShift’s bare-metal CNI limitations is not accidental. The company is signaling that VKS can give platform teams more control over networking architecture, which is a real selling point in complex environments. The key point is not merely that VKS supports more options; it is that the support model is designed to keep those options operationally manageable.
The move toward Avi Gateway API integration also deserves attention. With NGINX deprecated in the latest Kubernetes release, customers need a path forward for load balancing and ingress, and Broadcom is steering them toward its own load balancing stack. That is both sensible and strategic, because it turns a platform change elsewhere in the ecosystem into an opportunity to deepen VMware integration.

• Cilium and Calico broaden supported networking choices.
• Avi integration provides a migration path away from NGINX.
• Support boundaries remain clear even as flexibility expands.
• Broadcom keeps the stack coherent across networking layers.

Security improvements are also part of this story. AppArmor profiles can now be managed as Custom Resources and synchronized across worker nodes or node pools, which is exactly the kind of control security teams want in a regulated environment. It means policy can be treated as code, making enforcement more repeatable and easier to audit.

Security and Access Control​

Security in VKS 3.6 is less about flashy new capabilities and more about making essential controls easier to administer at scale. The support-bundle workflow is a good example: workload cluster owners can generate support bundles without using vCenter credentials, reducing dependency friction between Kubernetes operators and infrastructure administrators. That is a small but meaningful operational improvement.
In many organizations, cross-team access becomes the bottleneck long before technical capability does. Anything that reduces the need to escalate into another admin plane speeds up troubleshooting and lowers the number of awkward handoffs. For platform teams, that means less waiting and fewer opportunities for process gaps.

Security features that change operations​

Broadcom’s choice to surface AppArmor as a Kubernetes-native resource is especially thoughtful because it aligns with modern policy management practices. Instead of treating security profiles as an afterthought, VKS makes them deployable, auditable, and consistent. That makes the platform more usable for teams that must prove control, not merely claim it.
The support-bundle change is also more important than it might first appear. It suggests that Broadcom is paying attention to the reality of shared-responsibility operations, where platform engineers often need diagnostics without being given full infrastructure credentials. That is a pragmatic security posture rather than an ideological one.

• AppArmor profiles can be managed declaratively.
• Security policy becomes easier to standardize.
• Troubleshooting needs less credential sprawl.
• Support interactions can be faster and cleaner.

The downside is that more built-in integration can also mean more platform dependency. If enterprises adopt VKS-specific mechanisms for security and troubleshooting, they may find it harder to port their operational model elsewhere later. That is not necessarily a problem, but it is worth acknowledging because convenience often comes with ecosystem lock-in.

Velero and the CNCF Sandbox Move​

Velero’s proposed move into CNCF Sandbox is more than a symbolic handoff. It is a governance story about what happens when a widely used infrastructure project grows beyond a single vendor’s direct stewardship and needs a broader community home. CNCF Sandbox exists precisely for early-stage projects that benefit from open, neutral governance while still maturing.
For users, the appeal is straightforward. Backup and restore tools sit close to the center of operational trust, and trust tends to improve when a project is seen as community-governed rather than product-controlled. The CNCF’s framing is that Sandbox status gives projects a vendor-neutral place to grow, and that’s exactly the kind of reassurance many enterprise users want.

Why this matters to enterprise buyers​

Velero is especially important because backup and disaster recovery are not optional extras in Kubernetes environments. They are essential to business continuity, migration, and operational resilience. If a project like Velero gains broader governance and contributor diversity, it may become more durable in the eyes of conservative enterprise buyers.
The February filing timeline also matters because it suggests this is an actual process, not just a marketing flourish. Once a project enters the CNCF review track, the conversation shifts toward project health, open governance, and community participation. That is a meaningful step for a tool that many teams already rely on in production.

• Vendor-neutral governance can boost user confidence.
• Broader contributor participation can improve resilience.
• Backup tooling becomes easier to trust long term.
• CNCF affiliation may broaden enterprise adoption.

Chris Aniszczyk’s framing, that the move gives Velero a vendor-neutral home to foster collaboration and growth, is consistent with CNCF’s overall mission. The strategic subtext is that Broadcom is willing to donate or elevate infrastructure projects to open governance while still keeping VMware’s commercial stack tightly integrated. That balance is politically useful and commercially smart.

Broadcom’s Open Source Positioning​

Broadcom has been eager to present itself as a serious open-source contributor, and it has a point. The company says it is among the top five long-term contributors to CNCF projects, and the CNCF has echoed Broadcom’s ongoing importance as a contributor to open-source infrastructure. That matters because it helps counter the narrative that Broadcom is simply extracting value from VMware while giving back less.
Still, contribution counts do not eliminate strategic self-interest. Broadcom can be both a major contributor and a company that tightly manages product direction. Those things are not mutually exclusive. In fact, the strongest vendors in enterprise infrastructure often combine deep open-source engagement with a very deliberate commercial agenda.

Open source as strategic infrastructure​

This is where Broadcom’s messaging becomes particularly sophisticated. By pointing to CNCF contributions, it signals credibility to the cloud-native community. By shipping VKS enhancements and steering users toward Avi and VCF, it signals that it still wants to own the enterprise experience end to end. The result is a hybrid posture: open enough to participate, controlled enough to monetize.
That can work well in the private cloud market, where buyers frequently want openness at the component level but accountability at the platform level. Broadcom is trying to be the vendor that gives them both, even if the tradeoffs are not always comfortable.

• Broadcom wants open-source credibility.
• VMware remains the commercial anchor.
• CNCF participation supports ecosystem trust.
• Private cloud integration remains the strategic center.

The broader competitive implication is that Broadcom is not retreating from cloud-native infrastructure; it is reframing it. Rather than chasing every developer-facing trend, it is focusing on the operational reality of large enterprises that will pay for support, governance, and lifecycle stability. That is a deliberate and defensible market position, even if it is not universally popular.

Competitive Implications​

The biggest competitive question is how these moves affect Red Hat, Hyperscalers, and alternative virtualization or container platforms. On networking, Broadcom’s CNI flexibility and Avi messaging are designed to show that VMware can be as open as rivals without giving up support discipline. On platform operations, VKS is trying to make VMware Cloud Foundation the safer home for mixed VM-and-container estates.
Red Hat OpenShift remains the obvious comparison point because it also sells an integrated enterprise Kubernetes experience. Broadcom’s argument appears to be that VKS can be more flexible in mixed environments and more aligned with VMware customers already invested in vSphere and VCF. That is a powerful advantage when the buyer already has VMware everywhere else.

Where Broadcom is trying to win​

The move away from NGINX and toward Avi also shows how Broadcom wants to convert ecosystem changes into commercial leverage. If a deprecation elsewhere creates migration pressure, Broadcom wants VKS and VCF to absorb that demand. The same is true for backup and recovery; Velero’s governance shift can make VMware-adjacent data protection feel more stable to customers who care about continuity.
For rivals, the challenge is not just technical feature parity. It is the total story around support, governance, lifecycle, and private cloud integration. Broadcom is building a bundle that tries to answer all four at once.

• Competes directly with integrated enterprise Kubernetes platforms.
• Leverages VMware incumbency inside the enterprise.
• Uses ecosystem changes to pull customers deeper into VCF.
• Makes backup and network tooling part of the platform narrative.

That said, Broadcom’s strategy also creates opportunities for competitors. Organizations wary of vendor consolidation may see these moves as proof that VMware is becoming even more coupled to Broadcom’s platform logic. For those buyers, open-source neutrality and escape velocity may become more attractive than deeper integration.

---

Strengths and Opportunities​

Broadcom’s announcements show a company that understands what enterprise platform teams actually struggle with: upgrade timing, mixed operating systems, tuning consistency, support friction, and governance. The opportunity lies in turning those pain points into a more coherent private cloud pitch that feels stable rather than fragmented.

• Longer Kubernetes support windows reduce upgrade pressure.
• RHEL 9 compatibility expands appeal to Red Hat-centered environments.
• Declarative TuneD profiles make performance tuning more repeatable.
• Continuous pre-upgrade checks improve confidence before maintenance windows.
• CNI partner support broadens networking choices without abandoning supportability.
• AppArmor as a CRD brings security policy closer to Kubernetes operations.
• Velero’s CNCF path strengthens trust in backup governance.

Risks and Concerns​

The same moves that make VKS more compelling also deepen VMware’s ecosystem gravity. For some buyers, that will feel like simplicity; for others, it will feel like dependence. Velero’s CNCF move is positive on paper, but the real test will be whether community governance remains genuinely open and not merely nominal.

• Platform lock-in risk increases as more operational features become VMware-specific.
• Support complexity may rise as enterprises mix more networking and OS options.
• Migration friction could grow if customers adopt Broadcom-native workflows too deeply.
• Open-source optics may be questioned if commercial control remains dominant.
• Ecosystem reliance on Avi and VCF may limit flexibility for some buyers.
• Governance transition risk exists if Velero’s contributor growth lags expectations.

---

Looking Ahead​

The next few months will tell us whether Broadcom’s strategy is landing with the right audience. If VKS 3.6 is adopted as a practical upgrade-safe platform for enterprise Kubernetes, Broadcom will have strengthened one of VMware’s most important cloud-native footholds. If Velero’s CNCF Sandbox process proceeds smoothly, that will also reinforce the message that Broadcom can participate credibly in open governance even while pursuing a tightly integrated private cloud business.
The broader market will watch for signs of momentum in three places: customer adoption, partner ecosystem validation, and how quickly the promised integrations move from “supported path” to production-ready reality. That’s where these announcements either become durable platform advantages or remain polished but limited release notes. In enterprise infrastructure, execution is always the final product.

• Watch for broader validation of Cilium and Calico support.
• Track whether Avi Gateway API becomes the default migration path for ingress.
• Monitor whether Velero gains new community contributors after CNCF Sandbox entry.
• Observe how quickly enterprises adopt RHEL 9 within mixed VKS environments.
• Pay attention to whether Broadcom keeps extending support windows and lifecycle clarity.

Broadcom’s KubeCon messaging suggests a company that is no longer trying to convince the market that VMware and Kubernetes are separate stories. Instead, it wants VMware to be the place where virtual machines, containers, policy, networking, and recovery are all managed in one operating model. That is a compelling vision for the right customer, and a deeply strategic one for Broadcom — but it will only hold if the company continues to pair tight platform discipline with the kind of openness enterprise buyers need to trust it for the long term.

---

Source: Techzine Global Broadcom ships VKS 3.6 and moves Velero to CNCF Sandbox