Broadcom is trying to do two things at once with VMware’s Kubernetes portfolio: make the platform more enterprise-friendly today, and make its open-source story more credible for the long haul. The latest VMware Kubernetes Service, or VKS 3.6, adds support for Kubernetes 1.35, tightens security and operations controls, expands operating system choice, and widens the ecosystem of validated partners. At the same time, Broadcom is sending Velero to the Cloud Native Computing Foundation Sandbox, a move that signals a stronger appetite for vendor-neutral governance and community visibility.
That matters because VMware’s container strategy has been under a microscope since Broadcom’s acquisition. Customers and analysts have repeatedly questioned whether the company’s cloud-native stack is coherent enough, open enough, and differentiated enough to justify staying put. Broadcom’s answer, at least in this release, is that it wants to be seen not as a vendor locking customers in, but as a steward of an increasingly interoperable private-cloud Kubernetes platform.
Broadcom inherited VMware’s cloud-native ambitions at a moment when the market was already shifting. Kubernetes has become the default orchestration layer for modern applications, but the enterprise buying pattern has changed from “which container platform is cool?” to “which platform can I trust to run regulated, stateful, and often mixed-workload environments for years?” That has pushed vendors toward stronger lifecycle guarantees, easier upgrades, and tighter integration with traditional enterprise controls.
VMware’s answer to that demand has been to anchor Kubernetes in the VMware Cloud Foundation (VCF) stack. In practical terms, VKS gives VMware customers Kubernetes runtime and orchestration capabilities inside the private cloud environment they already know. That positioning is important because VMware is no longer trying to win the entire cloud-native market; it is trying to defend the part of the market that still values control, predictability, and operational consistency.
The challenge is that Broadcom has not always benefited from clarity around the VMware portfolio. Separate brands, overlapping capabilities, and shifting packaging have made it harder for some customers to understand where VKS ends and Tanzu begins. That confusion has been a real concern in the market, especially among buyers trying to reconcile container modernization with Broadcom’s more aggressive commercial posture.
The broader context also includes the post-acquisition customer migration narrative. Competitors have used the VMware upheaval to pull customers toward hyperscaler-managed Kubernetes, standalone open-source distributions, or alternative virtualization layers. Broadcom’s latest VKS update therefore reads less like a feature dump and more like a strategic reassurance campaign: the private-cloud stack is still alive, still evolving, and still trying to fit enterprise expectations.
This approach reflects a common enterprise pattern: customers want modern Kubernetes features, but they do not want the burden of being first movers on every upstream release. Broadcom is essentially saying it will absorb some of that complexity, which could be attractive to regulated industries and teams with conservative change-management policies. In practice, that can matter more than raw feature velocity.
Another notable shift is the support path for partner networking add-ons through native CNI plugin integration. That is important because network policy, traffic routing, and observability often determine whether a Kubernetes platform is workable in real enterprises. A platform that forces customers into one rigid networking model can be a poor fit for organizations that already standardized on a particular ecosystem.
One of the more practical additions is centralized API-driven management of node-level firewall rules across supported operating systems. That sounds unglamorous, but it is the kind of feature that reduces manual drift and helps security teams enforce policy consistently. For enterprises with multiple clusters and mixed OS estates, this can be the difference between a platform that scales and one that becomes a patchwork of exceptions.
Broadcom also says it is enabling more flexible support for regulatory and security requirements without locking clusters into rigid hardening models. That is a subtle but important distinction. Rigid hardening can improve baseline security, but it can also make systems harder to update, harder to validate, and harder to support across different business units.
The Red Hat move is especially notable because Red Hat has been one of the vendors most eager to attract VMware defectors. By supporting RHEL 9, Broadcom is effectively trying to reduce the friction that could push customers out of its ecosystem and into a rival’s. That makes the update less about OS diversity in the abstract and more about retention in the real world.
Broadcom framed the change as a way to give customers “more and more choice and flexibility,” and that is likely the right message for this moment. Enterprises are trying to reduce dependence on any single vendor, especially where virtualization, Kubernetes, and application platforms overlap. Broadcom is signaling that VMware can still fit inside a multi-vendor estate rather than demanding complete standardization around its own stack.
The newly validated partners include F5 BIG-IP Container Ingress Service, Kong API Gateway, and Tigera Calico Enterprise. Each of those fills a familiar enterprise gap: traffic management, ingress standardization, and workload communication/security policy. That means Broadcom is trying to make VKS less of a raw container substrate and more of an integrated enterprise operating environment.
This matters because large organizations do not buy Kubernetes in a vacuum. They buy it alongside existing control planes, security systems, traffic layers, and governance frameworks. By validating these partners, Broadcom is reducing implementation friction and making it easier for buyers to justify VKS in architecture review boards.
That move matters because CNCF governance brings credibility. Sandbox status is not the finish line, but it is a signal that a project has enough relevance and community momentum to justify formal incubation. For Broadcom, this is an opportunity to show it is not merely extracting value from open source, but contributing in a way the broader cloud-native community can trust.
Velero’s role is strategically useful because backup and recovery are among the least glamorous yet most mission-critical parts of any Kubernetes deployment. A cluster can be elegant, modern, and performant, but if the restore story is weak, enterprise adoption will stall. Velero helps solve the “what happens when it breaks?” question, which is often the question that actually gets budget approval.
The company seems to be betting that the market will increasingly see VKS as the default enterprise Kubernetes layer for private cloud, while Tanzu handles the higher-level application platform story. That is a sensible architecture, but only if Broadcom explains it in a way that reduces ambiguity rather than adding another branding layer. Clarity is now a product feature.
Broadcom’s own messaging suggests that it sees private cloud as the strategic foundation for everything else. That is consistent with the broader VMware strategy under Broadcom, which has focused heavily on VCF as the core platform. In that sense, VKS becomes a supporting pillar rather than a standalone star.
Red Hat, hyperscalers, and open-source-native vendors all have reasons to challenge VMware’s position. Red Hat can sell a Kubernetes story that aligns tightly with enterprise Linux; the hyperscalers can sell managed simplicity; and standalone platforms can sell lower lock-in and clearer commercial models. Broadcom’s answer is to emphasize continuity, enterprise support, and ecosystem breadth.
The market context is particularly unforgiving because customers are more willing than ever to reconsider infrastructure loyalty. After a major acquisition, any hint of product confusion becomes a migration trigger. Broadcom seems to understand that, which is why it is increasingly talking about choice, flexibility, and community contribution instead of pure platform control.
Velero’s CNCF path helps here because it converts vague support into institutional participation. Instead of just saying VMware engineers contribute upstream, Broadcom is allowing one of its projects to live under a community process that is not controlled entirely by the vendor. That is a stronger signal than marketing language alone.
But the broader market will still judge Broadcom by behavior. If the company keeps tightening commercial terms while simultaneously talking about openness, the messaging will ring hollow. If it continues to make real contributions, supports interoperable integrations, and avoids forcing customers into brittle product silos, then the open-source story will gain traction.
The company will also need to sharpen the story between VKS, Tanzu, and VCF. Enterprises do not want a maze of overlapping products; they want a stack that is easy to explain to procurement, security, operations, and application teams. The more Broadcom can make that stack feel coherent, the better its chances of defending VMware’s relevance in a market that is very willing to move on.
In the end, this is less about one version number than about whether Broadcom can make VMware feel steady again. Kubernetes buyers do not need perfection, but they do need confidence. On that score, VKS 3.6 and the Velero CNCF move are encouraging steps — but only the beginning.
Source: SDxCentral Broadcom updates VMware’s Kubernetes Service, boasts of open-source backing
That matters because VMware’s container strategy has been under a microscope since Broadcom’s acquisition. Customers and analysts have repeatedly questioned whether the company’s cloud-native stack is coherent enough, open enough, and differentiated enough to justify staying put. Broadcom’s answer, at least in this release, is that it wants to be seen not as a vendor locking customers in, but as a steward of an increasingly interoperable private-cloud Kubernetes platform.
Background
Broadcom inherited VMware’s cloud-native ambitions at a moment when the market was already shifting. Kubernetes has become the default orchestration layer for modern applications, but the enterprise buying pattern has changed from “which container platform is cool?” to “which platform can I trust to run regulated, stateful, and often mixed-workload environments for years?” That has pushed vendors toward stronger lifecycle guarantees, easier upgrades, and tighter integration with traditional enterprise controls.VMware’s answer to that demand has been to anchor Kubernetes in the VMware Cloud Foundation (VCF) stack. In practical terms, VKS gives VMware customers Kubernetes runtime and orchestration capabilities inside the private cloud environment they already know. That positioning is important because VMware is no longer trying to win the entire cloud-native market; it is trying to defend the part of the market that still values control, predictability, and operational consistency.
The challenge is that Broadcom has not always benefited from clarity around the VMware portfolio. Separate brands, overlapping capabilities, and shifting packaging have made it harder for some customers to understand where VKS ends and Tanzu begins. That confusion has been a real concern in the market, especially among buyers trying to reconcile container modernization with Broadcom’s more aggressive commercial posture.
The broader context also includes the post-acquisition customer migration narrative. Competitors have used the VMware upheaval to pull customers toward hyperscaler-managed Kubernetes, standalone open-source distributions, or alternative virtualization layers. Broadcom’s latest VKS update therefore reads less like a feature dump and more like a strategic reassurance campaign: the private-cloud stack is still alive, still evolving, and still trying to fit enterprise expectations.
VKS 3.6: What Broadcom Changed
The headline item is VKS 3.6, which Broadcom is positioning as an upgrade centered on security, operational predictability, and support breadth. The most obvious technical addition is support for Kubernetes 1.35, paired with what Broadcom describes as a two-year support program for customers adopting that release. That is not a trivial promise in enterprise Kubernetes, where version churn can become a deployment tax if vendors do not smooth the path.This approach reflects a common enterprise pattern: customers want modern Kubernetes features, but they do not want the burden of being first movers on every upstream release. Broadcom is essentially saying it will absorb some of that complexity, which could be attractive to regulated industries and teams with conservative change-management policies. In practice, that can matter more than raw feature velocity.
Another notable shift is the support path for partner networking add-ons through native CNI plugin integration. That is important because network policy, traffic routing, and observability often determine whether a Kubernetes platform is workable in real enterprises. A platform that forces customers into one rigid networking model can be a poor fit for organizations that already standardized on a particular ecosystem.
Why the support window matters
The two-year support framing is especially relevant for enterprises running database-heavy or compliance-heavy workloads. Those customers often cannot treat Kubernetes the way a startup does, because upgrade timing is governed by audit cycles, regression risk, and application dependencies. Broadcom is, in effect, packaging Kubernetes as a managed lifecycle rather than a moving target.- It reduces pressure to adopt a new Kubernetes version immediately.
- It can simplify internal qualification and testing cycles.
- It gives infrastructure teams a better planning horizon.
- It may make VKS more acceptable for production workloads with strict controls.
- It helps Broadcom compete with managed cloud offerings that emphasize stability.
Security and Operations: The Quiet Core of the Update
Broadcom is also leaning heavily into security messaging, and for good reason. Kubernetes adoption in the enterprise often stalls not because the technology is weak, but because security teams dislike the sprawl of permissions, firewall rules, and cluster-specific hardening patterns. VKS 3.6 appears to address that by making security controls more centralized and less brittle.One of the more practical additions is centralized API-driven management of node-level firewall rules across supported operating systems. That sounds unglamorous, but it is the kind of feature that reduces manual drift and helps security teams enforce policy consistently. For enterprises with multiple clusters and mixed OS estates, this can be the difference between a platform that scales and one that becomes a patchwork of exceptions.
Broadcom also says it is enabling more flexible support for regulatory and security requirements without locking clusters into rigid hardening models. That is a subtle but important distinction. Rigid hardening can improve baseline security, but it can also make systems harder to update, harder to validate, and harder to support across different business units.
Why regulated customers care
Regulated industries often need strong controls without losing the ability to move fast enough to stay compliant. If a platform hardens too aggressively, it can become operationally fragile; if it is too permissive, it becomes a security liability. Broadcom seems to be trying to strike a balance between those two extremes.- Centralized policy management reduces configuration drift.
- Flexible hardening can support more application types.
- API-driven controls are easier to automate and audit.
- Consistency across OS types lowers training overhead.
- Better security orchestration can reduce incident response time.
OS Flexibility and the Red Hat Signal
Support for Red Hat Enterprise Linux 9 is one of the release’s most strategically important changes. It broadens VKS beyond VMware’s own Photon OS and beyond the Windows and Ubuntu support Broadcom has already been building. In enterprise IT, operating system choice is never just a technical preference; it often reflects existing skills, support contracts, and procurement realities.The Red Hat move is especially notable because Red Hat has been one of the vendors most eager to attract VMware defectors. By supporting RHEL 9, Broadcom is effectively trying to reduce the friction that could push customers out of its ecosystem and into a rival’s. That makes the update less about OS diversity in the abstract and more about retention in the real world.
Broadcom framed the change as a way to give customers “more and more choice and flexibility,” and that is likely the right message for this moment. Enterprises are trying to reduce dependence on any single vendor, especially where virtualization, Kubernetes, and application platforms overlap. Broadcom is signaling that VMware can still fit inside a multi-vendor estate rather than demanding complete standardization around its own stack.
The value of choice, not just support
The practical value of broader OS support is that it reduces the number of reasons a customer has to redesign an environment. Many enterprises already have operational muscle memory around RHEL, Ubuntu, and Windows Server. Forcing them onto a narrower set of platform assumptions adds cost and creates delay.- RHEL support helps align with existing enterprise Linux standards.
- Ubuntu support improves appeal for cloud-native and developer-led teams.
- Windows Server support keeps mixed workloads viable.
- Photon OS support preserves VMware-native optimization paths.
- Broader OS coverage can simplify migration from legacy estates.
Ecosystem Partners: Turning VKS Into a Platform
Broadcom also expanded the list of validated ecosystem partners around VKS, and that may be just as important as the core product changes. In Kubernetes markets, the platform rarely wins solely because of the base runtime. It wins because the surrounding network, ingress, security, observability, and data tools integrate cleanly enough to keep the operational burden under control.The newly validated partners include F5 BIG-IP Container Ingress Service, Kong API Gateway, and Tigera Calico Enterprise. Each of those fills a familiar enterprise gap: traffic management, ingress standardization, and workload communication/security policy. That means Broadcom is trying to make VKS less of a raw container substrate and more of an integrated enterprise operating environment.
This matters because large organizations do not buy Kubernetes in a vacuum. They buy it alongside existing control planes, security systems, traffic layers, and governance frameworks. By validating these partners, Broadcom is reducing implementation friction and making it easier for buyers to justify VKS in architecture review boards.
What the partner list really signals
The partner story is partly technical, partly political. Technically, it helps customers assemble a more complete platform. Politically, it tells the market that Broadcom is not trying to monopolize every layer of the stack.- F5 helps with enterprise traffic steering and ingress patterns.
- Kong helps standardize API exposure for microservices.
- Tigera adds policy and communication controls for multi-cluster environments.
- Validation can reduce integration risk for platform teams.
- A richer ecosystem makes VKS look more sustainable.
Velero and the CNCF Sandbox: Open Source With Guardrails
The most symbolic piece of the announcement is Broadcom’s decision to move Velero into the CNCF Sandbox. Velero is a well-known Kubernetes backup, recovery, and migration project, and its transfer is an important sign that Broadcom is willing to let some of VMware’s open-source assets live in a more vendor-neutral environment.That move matters because CNCF governance brings credibility. Sandbox status is not the finish line, but it is a signal that a project has enough relevance and community momentum to justify formal incubation. For Broadcom, this is an opportunity to show it is not merely extracting value from open source, but contributing in a way the broader cloud-native community can trust.
Velero’s role is strategically useful because backup and recovery are among the least glamorous yet most mission-critical parts of any Kubernetes deployment. A cluster can be elegant, modern, and performant, but if the restore story is weak, enterprise adoption will stall. Velero helps solve the “what happens when it breaks?” question, which is often the question that actually gets budget approval.
Why Velero matters beyond backup
Velero is not just a tool for copies and restore points. It supports migration, stateful workload resilience, and operational continuity across cluster environments. In other words, it sits close to the concerns that keep infrastructure leaders awake at night.- It helps with disaster recovery planning.
- It supports workload portability.
- It improves confidence for stateful applications.
- It can simplify cluster transitions and upgrades.
- It reinforces Kubernetes as an enterprise platform, not a toy environment.
Tanzu, VKS, and the Private Cloud Split
Broadcom’s cloud-native portfolio still contains two different but related stories: VKS and Tanzu. VKS is the Kubernetes runtime and orchestration layer bundled into VCF, while Tanzu is the broader platform-as-a-service style offering aimed at application delivery regardless of underlying infrastructure. That split is conceptually useful, but it can also confuse buyers if the boundary between them is not clearly communicated.The company seems to be betting that the market will increasingly see VKS as the default enterprise Kubernetes layer for private cloud, while Tanzu handles the higher-level application platform story. That is a sensible architecture, but only if Broadcom explains it in a way that reduces ambiguity rather than adding another branding layer. Clarity is now a product feature.
Broadcom’s own messaging suggests that it sees private cloud as the strategic foundation for everything else. That is consistent with the broader VMware strategy under Broadcom, which has focused heavily on VCF as the core platform. In that sense, VKS becomes a supporting pillar rather than a standalone star.
The significance of platform positioning
The distinction between runtime and platform matters because enterprises buy at different layers of abstraction. Some want only Kubernetes infrastructure; others want a full application platform with buildpacks, deployment flows, and service abstractions. Broadcom is trying to cover both while still keeping VCF at the center.- VKS addresses infrastructure teams and platform engineers.
- Tanzu addresses application delivery and developer productivity.
- VCF remains the control point tying the stack together.
- The challenge is avoiding overlap that confuses buyers.
- The opportunity is turning that overlap into a coherent lifecycle.
Competitive Pressure: Why This Update Lands Now
Broadcom’s timing is not accidental. The company is dealing with a market in which former VMware customers are actively evaluating alternatives, while competitors are pitching simpler or more elastic paths forward. Kubernetes itself remains dominant, but the stack choices around it are increasingly shaped by governance, licensing, and trust rather than raw technology alone.Red Hat, hyperscalers, and open-source-native vendors all have reasons to challenge VMware’s position. Red Hat can sell a Kubernetes story that aligns tightly with enterprise Linux; the hyperscalers can sell managed simplicity; and standalone platforms can sell lower lock-in and clearer commercial models. Broadcom’s answer is to emphasize continuity, enterprise support, and ecosystem breadth.
The market context is particularly unforgiving because customers are more willing than ever to reconsider infrastructure loyalty. After a major acquisition, any hint of product confusion becomes a migration trigger. Broadcom seems to understand that, which is why it is increasingly talking about choice, flexibility, and community contribution instead of pure platform control.
Where Broadcom is trying to differentiate
The company does not need to beat every rival on every dimension. It needs to be better in the scenarios where VMware is strongest: private cloud, regulated workloads, mixed OS environments, and enterprises that want an integrated but still portable Kubernetes experience.- Private-cloud control remains a VMware strength.
- VCF integration gives Broadcom a broader stack story.
- OS and ecosystem flexibility reduce migration resistance.
- CNCF alignment helps address open-source credibility concerns.
- Support promises help conservative enterprises adopt newer Kubernetes versions.
The Open-Source Narrative: Signal Versus Substance
Broadcom’s open-source narrative has improved, but it still has to overcome skepticism. The company says it remains a top contributor to Kubernetes and that open source is “a big part of our identity.” Those are meaningful statements, especially in a market where some vendors talk about open source while contributing very little to it. Still, identity claims only matter when they are backed by visible governance and sustained engineering effort.Velero’s CNCF path helps here because it converts vague support into institutional participation. Instead of just saying VMware engineers contribute upstream, Broadcom is allowing one of its projects to live under a community process that is not controlled entirely by the vendor. That is a stronger signal than marketing language alone.
But the broader market will still judge Broadcom by behavior. If the company keeps tightening commercial terms while simultaneously talking about openness, the messaging will ring hollow. If it continues to make real contributions, supports interoperable integrations, and avoids forcing customers into brittle product silos, then the open-source story will gain traction.
What makes the signal credible
A credible open-source posture needs more than a donation announcement. It requires sustained participation, transparent governance, and product behavior that does not undermine community trust.- Upstream contributions matter more than slogans.
- Vendor-neutral governance increases confidence.
- Community adoption is a strong proof point.
- Interoperability should remain visible in product design.
- Open-source claims must match licensing and support realities.
Strengths and Opportunities
Broadcom’s latest VKS and Velero moves give VMware something it has needed badly: a cleaner product narrative around enterprise Kubernetes. The company is not just adding features; it is trying to lower friction, increase trust, and make the platform easier to justify internally.- Broader Kubernetes version support helps customers modernize without rushing upgrades.
- Two-year support coverage reduces operational anxiety for conservative IT teams.
- RHEL 9 support expands appeal to large enterprise Linux estates.
- Partner networking support makes VKS more practical in mixed environments.
- API-driven firewall management improves consistency and auditability.
- CNCF Sandbox placement for Velero strengthens open-source credibility.
- Validated ecosystem partners make the platform more complete for production use.
Risks and Concerns
The biggest risk is that Broadcom’s messaging outpaces customer confidence. VMware customers have been burned by change before, so any new promise is judged against a recent history of portfolio reshaping, licensing anxiety, and ecosystem uncertainty.- Portfolio confusion between VKS and Tanzu can still muddy the buying decision.
- Customer mistrust remains a real drag on adoption and renewal.
- Competitive pressure from Red Hat and hyperscalers is still intense.
- Support promises only matter if the upgrade path is painless in practice.
- Open-source claims could be viewed as tactical if commercial behavior feels restrictive.
- Ecosystem validation is helpful, but customers may still want broader native support.
- Operational complexity in multi-OS, multi-partner environments can create integration burden.
Looking Ahead
The next phase will be about execution, not announcement. If Broadcom can show that VKS 3.6 materially reduces upgrade pain, improves security operations, and handles regulated workloads more gracefully, it may start winning back some of the trust that has eroded since the VMware acquisition. If Velero progresses cleanly through the CNCF process, it will further reinforce the idea that Broadcom is willing to work inside community institutions rather than only around them.The company will also need to sharpen the story between VKS, Tanzu, and VCF. Enterprises do not want a maze of overlapping products; they want a stack that is easy to explain to procurement, security, operations, and application teams. The more Broadcom can make that stack feel coherent, the better its chances of defending VMware’s relevance in a market that is very willing to move on.
- Watch whether VKS 3.6 adoption accelerates in regulated sectors.
- Watch how Broadcom markets the distinction between VKS and Tanzu.
- Watch for more CNCF-facing moves that reinforce open-source credibility.
- Watch whether partner validation expands beyond networking and ingress.
- Watch whether customer sentiment shifts as upgrade cycles play out.
- Watch how aggressively competitors use VMware uncertainty in sales cycles.
In the end, this is less about one version number than about whether Broadcom can make VMware feel steady again. Kubernetes buyers do not need perfection, but they do need confidence. On that score, VKS 3.6 and the Velero CNCF move are encouraging steps — but only the beginning.
Source: SDxCentral Broadcom updates VMware’s Kubernetes Service, boasts of open-source backing
