Broadcom KubeCon Europe 2026: VKS 3.6, Velero CNCF, and AI-ready Kubernetes governance

Broadcom is using KubeCon Europe 2026 to send a clear message: Kubernetes is no longer just a runtime to be managed, but a platform layer to be tuned for AI, modern apps, and enterprise governance. The company’s latest announcements around Velero, vSphere Kubernetes Service 3.6, and a wider ecosystem of validated partners show an effort to reduce operational friction while preserving the control that large organizations demand. Just as importantly, Broadcom is positioning VMware Cloud Foundation as a more open, more supportable, and more enterprise-ready place to run cloud-native workloads. com’s Kubernetes strategy has been evolving in parallel with the broader shift in enterprise IT from “can we run Kubernetes?” to “can we run it safely at scale?” That shift matters because the early wave of Kubernetes adoption was often led by application teams, while the current wave is increasingly owned by platform engineering, infrastructure, and security groups. Those teams care less about novelty and more about repeatability, lifecycle discipline, and support boundaries.
The company has repeatedly framed VMware Cloud Foundation as the private-cloud control plane for modern workloads, and vSphere Kubernetes Service sits at the center of that story. In recent Broadcom materials, VKS has been tied to themes like developer productivity, AI readiness, and open ecosystem participation, reinforcing the idea that Kubernetes is being treated as a core enterprise substrate rather than a standalone project.
The timing of this announcement also reflects a larger market reality: enterprises are trying to modernize applications without giving up the operational predictability that virtualization-era tooling provided. In practice, that means Kubernetes platforms need to solve harder day-two problems, not just provide day-one cluster creation. The details Broadcom is emphasizing—upgrades, tuning, security, governance, and validated integrations—are all symptoms of that shift.
One of the most important signals in the release is the move to advance Velero toward CNCF Sandbox stewardship. Velero is already well known as a Kubernetes-native backup, restore, and migration project, so the governance transition is less about discovering a new tool and more about stabilizing its long-term operating model under vendor-neutral oversight. That matters because backup and disaster recovery are among the few Kubernetes concerns that become more, not less, important as environments grow.
The same logic applies to ecosystem partnerships. Broadcom is no longer just shipping a platform and expecting the world to conform to it. Instead, it is trying to prove that VKS can be the center of an open, validated ecosystem that includes networking, API management, and security vendors that enterprises already trust. That is a strategically important shift, and it reflects a broader recognition that platform engineering is now an integration discipline as much as a deployment discipline.

Why This Announcement Matters​

The broadest significance of the announcement is that Broadcom is speaking directly to the people who actually keep enterprise Kubernetes alive after the first cluster goes live. Those people are the platform engineers who manage change windows, security exceptions, operating system variance, application policy, and support escalations. They are rarely impressed by feature density alone; they want features that reduce toil, reduce risk, and reduce the number of bespoke scripts they have to maintain.
Broadcom’s framing around AI and modern application innovation is important because AI workloads are forcing Kubernetes platforms to handle more sensitive, more data-intensive, and more latency-sensitive systems. That raises the bar for networking, kernel tuning, observability, and workload isolation. If a platform can support those requirements without turning every upgrade into a custom project, it becomes much more attractive to enterprise buyers.
There is also a competitive signal hidden in the language. Broadcom is no longer treating Kubernetes as a commodity layer that can be abstracted away entirely. Instead, it is differentiating on the quality of the enterprise operating model around Kubernetes. That is a subtle but meaningful move, because the market has matured enough that “Kubernetes support” is no longer sufficient; supportability itself has become the product.

The platform engineering lens​

Platform engineering has become the organizing principle for many large IT organizations. Rather than letting every team assemble its own Kubernetes stack, enterprises increasingly want standardized internal platforms with opinionated defaults and guardrails. Broadcom is clearly trying to win that audience by making VKS feel less like a collection of cloud-native components and more like a managed enterprise service.
That message is reinforced by the emphasis on long-lived support windows and overlapping versions. Large organizations do not upgrade fleets on a vendor’s preferred schedule; they upgrade according to business downtime, application compatibility, and change-advisory board realities. Broadcom’s promise of extended version support is therefore not a side detail, but a core selling point.

• Enterprises want predictable lifecycle planning.
• Platform teams want fewer unsupported customizations.
• Security teams want fewer exceptions and waivers.
• App owners want less disruption during upgrades.
• Infrastructure leaders want supportable heterogeneity.

Velero and the CNCF Move​

Broadcom’s decision to contribute Velero into the CNCF Sandbox is arguably the most ecosystem-significant part of the announcement. Velero is one of those projects that becomes more valuable the more serious a Kubernetes deployment becomes, because backup and restore are no longer optional once workloads, data, and migration plans become business-critical.
The move toward vendor-neutral governance is significant because it lowers the risk that a vital tool becomes overly tied to a single company’s product roadmap. For enterprise customers, that matters as much as the code itself. They want to know that the backup layer beneath their Kubernetes estate is going to outlive any one vendor’s strategy, reorganization, or packaging shift.

Why backup is a platform issue​

In the cloud-native world, backup has often been treated as an afterthought until the first real incident. Once clusters are running stateful applications, however, backup becomes part of the platform’s identity. It is not merely about protecting data; it is about preserving the operational state needed to recover, migrate, and validate workloads in a controlled manner.
Velero’s value lies in its Kubernetes-native posture. Because it works through the Kubernetes API layer rather than only at the storage layer, it can support more portable and application-aware recovery workflows. That makes it especially relevant for organizations running mixed environments across on-premises infrastructure and multiple cloud providers.

• Backup and restore are foundational, not optional.
• Vendor-neutral governance improves trust.
• API-layer integration improves portability.
• Recovery workflows become more application-aware.
• Migration between environments becomes more practical.

The CNCF angle also matters culturally. Projects that pass into community stewardship often gain broader contributor participation and more transparent technical evolution. That can slow some decisions, but it usually strengthens credibility for enterprise adoption. In an era when businesses are wary of sudden licensing or roadmap changes, credibility is a material asset.

VKS 3.6 and the Enterprise Operating Model​

The headline product story is vSphere Kubernetes Service 3.6, and the release is clearly engineered around day-two operations rather than demo-friendly cluster creation. That is the right place to invest if the target buyer is a platform team responsible for hundreds or thousands of workloads. Those teams do not need more abstraction for its own sake; they need fewer surprises.
One of the most consequential elements is support for Kubernetes 1.35 alongside Broadcom’s extended support model. When a vendor says it will support each Kubernetes version for 24 months with overlap, it is acknowledging a real enterprise constraint: large fleets cannot move in lockstep. Application compatibility, regulatory testing, and capacity planning all take time, and platform software has to bend around that reality.

Upgrades without drama​

Upgrades are where many Kubernetes platforms show their true quality. A release can look elegant on paper and still collapse in the face of hidden PDB conflicts, resource assumptions, or inconsistent cluster state. Broadcom’s new readiness checks are designed to surface those blockers before a maintenance window begins, which is exactly where they belong.
That continuous preflight model is more valuable than it may first appear. It changes the upgrade from a one-time event into an ongoing condition that can be monitored ahead of time. For platform teams, that means fewer emergency postponements, fewer late-night escalations, and fewer unpleasant surprises during change freezes.

• Precheck failures become visible earlier.
• Maintenance windows become more reliable.
• Teams can fix blockers before the upgrade starts.
• Support teams spend less time on reactive triage.
• Business disruption is easier to minimize.

The fact that the checks surface conditions continuously rather than only at upgrade time is especially smart. It turns upgrade readiness into an operational metric instead of a binary go/no-go moment. That is the kind of small architectural choice that saves real money in large environments.

Networking Flexibility and Ecosystem Choice​

Broadcom’s open ecosystem message is especially visible in the support for partner networking add-ons, including native integration paths for CNI plugins within supported lifecycle boundaries. That is a practical response to a hard enterprise reality: networking is rarely one-size-fits-all, and platform teams often need to align Kubernetes with established network policy, service delivery, and compliance tooling.
This is also where the partnership story becomes more than marketing decoration. By validating integrations with vendors like F5, Kong, and Tigera, Broadcom is acknowledging that many customers want best-of-breed functionality without giving up platform coherence. That is the right instinct for a market where no single vendor is likely to own every enterprise networking, ingress, API management, and security requirement.

The value of validated integrations​

Validated partner support does not just help procurement; it helps operations. When an integration is truly supported, teams do not have to guess whether an upgrade or patch cycle will break a custom path. They can stay within the platform vendor’s lifecycle and still use tools they already trust.
That matters in highly regulated environments where unsupported changes can turn into audit findings. It also matters for teams trying to avoid “shadow architecture,” where individual application owners quietly invent their own ingress or firewall exceptions because the sanctioned path is too rigid.

• Validated integrations reduce support ambiguity.
• Enterprises keep existing vendor relationships.
• Platform teams avoid unsupported workarounds.
• Compliance becomes easier to defend.
• Change management becomes more predictable.

The ecosystem move also reveals an important strategic nuance: Broadcom is not trying to compete with every layer in the stack. Instead, it wants VKS to become the supported place where those layers meet. That is a more credible long-term strategy than trying to replace every enterprise tool with a native equivalent.

Performance Tuning and Workload-Specific Control​

One of the most useful additions in VKS 3.6 is declarative TuneD profiles for safe kernel and sysctl tuning. This is the kind of feature that will not excite casual observers, but it can make a large difference for workloads like databases, analytics pipelines, and latency-sensitive services. Enterprises running those systems often need a delicate balance between performance and supportability.
The key benefit is that tuning becomes standardized and repeatable rather than being managed through unsupported host customization. That is a crucial distinction. Once tuning is expressed declaratively and attached to node pools or cluster policy, it can be reviewed, versioned, and maintained through the same operational mechanisms as the rest of the platform.

Why performance tuning is a governance problem​

Kernel tuning is often discussed as a technical optimization, but in enterprise environments it is really a governance problem. Every manual tweak creates a potential drift point, and drift becomes dangerous when the cluster must be upgraded, audited, or restored. Declarative tuning reduces that risk by making the configuration visible and portable.
This also helps platform teams support multiple workload classes in the same environment. Databases can get one profile, high-throughput services another, and latency-sensitive applications a third, all without turning the platform into a patchwork of exceptions.

• Tuning is safer when it is declarative.
• Drift is easier to avoid.
• Workload classes can be standardized.
• Support teams see fewer mystery changes.
• Performance becomes repeatable across clusters.

The addition of nftables support for kube-proxy on Linux is another signal that Broadcom is paying attention to performance at the packet-handling layer. That matters because traffic routing overhead can become noticeable at scale, especially where many services, ports, and policy rules are involved. The practical goal here is not abstract elegance; it is to keep the platform efficient as traffic patterns intensify.

Security, Compliance, and Operational Autonomy​

Broadcom is also making a strong play for customers who care about security, compliance, and governance without wanting to harden every cluster into an unmanageable state. That balance is difficult, because the stricter the control model becomes, the more likely it is to interfere with legitimate operations. VKS 3.6 tries to reduce that tension by improving structured controls rather than adding brittle restrictions.
The new AppArmor profile management model is a good example. By defining profiles as Custom Resources and automatically syncing them across worker nodes or specific pools, Broadcom is pushing policy closer to standard Kubernetes workflows. That lowers the operational burden while preserving the security model.

Least privilege by design​

The same theme appears in the support bundle improvement. Letting workload cluster owners generate support bundles without vCenter credentials is a subtle but important move toward least privilege. It reduces friction between infrastructure teams and Kubernetes operators while still preserving the right boundaries.
That kind of change may seem small, but it can dramatically improve incident response. When the people closest to the problem can collect diagnostic data without opening a separate infrastructure access path, recovery becomes faster and less politically fraught.

• AppArmor can be managed more consistently.
• Support bundles require less privileged access.
• Security controls become easier to automate.
• Auditability improves with structured resources.
• Team boundaries are easier to respect.

For regulated industries, this is the sort of detail that turns a platform from “interesting” into “deployable.” You can have a technically capable Kubernetes stack and still fail procurement if the operational model is too messy. Broadcom appears to understand that the buyer is not just evaluating software; it is evaluating the shape of the support experience.

Enterprise OS Choice and Heterogeneous Clusters​

Support for RHEL 9 alongside Photon OS 5, Ubuntu 22.04 and 24.04, and Windows Server 2022 is another important clue about Broadcom’s enterprise intent. OS choice may sound mundane, but for large organizations it can be one of the biggest determinants of adoption. Standardizing on a single base image is rarely feasible across all applications, especially when compliance teams, legacy workloads, and vendor certifications pull in different directions.
The ability to run different node pools on different operating systems within the same cluster is particularly valuable. It lets organizations migrate gradually rather than forcing a hard cutover. That is a much more realistic model for enterprises with long-lived services and mixed application portfolios.

Migration without fleet-wide disruption​

This is where Broadcom’s messaging becomes especially credible for real-world infrastructure teams. Heterogeneous node pools are not a glamour feature, but they are a practical answer to the fact that most enterprises are in transition, not in greenfield. They need a way to modernize incrementally while preserving application availability.
That incremental path is also valuable for regulated workloads, where OS changes may require additional validation. If the platform lets teams change one pool at a time, they can test, certify, and migrate on a schedule that matches business reality rather than a vendor roadmap.

• Mixed OS support reduces migration risk.
• Node pools can be modernized gradually.
• Compliance validation becomes more manageable.
• Legacy and new workloads can coexist.
• Application teams gain more deployment flexibility.

This is also where Broadcom’s broader VMware heritage shows. The company understands that enterprise infrastructure is usually a long tail of legacy, compliance, and operational habit. A Kubernetes platform that respects that reality is more likely to survive in production.

The AI Angle and Modern Application Innovation​

Broadcom’s repeated reference to AI in this announcement should be read carefully. This is not just a buzzword placement exercise; it reflects the fact that AI workloads are now shaping platform requirements. AI apps tend to be data-heavy, latency-sensitive, and security-sensitive, which means infrastructure teams need a platform that can support both the application and the data movement around it.
That is why Kubernetes vendors are increasingly talking about support for GPU ecosystems, traffic governance, and validation with partners across the stack. The AI workload is not merely another container. It brings with it storage demands, routing complexity, observability expectations, and stricter operational tolerances.

Why private cloud matters here​

Broadcom is implicitly arguing that private cloud remains a compelling setting for enterprise AI and modern app development because it offers more governance than ad hoc public-cloud sprawl. That is a persuasive message for organizations that need predictable cost structures, data control, and internal policy enforcement.
The challenge is execution. Private cloud only wins if the platform feels easier, not harder, than the alternatives. If a private AI stack demands too many exceptions or too many manual workarounds, development teams will route around it. That is why features like lifecycle support, validated partners, and safe tuning matter so much.

• AI workloads intensify infrastructure demands.
• Private cloud must be operationally simple.
• Governance matters as much as raw capability.
• GPU and network support become strategic.
• Developer experience remains a make-or-break factor.

Broadcom’s language about “platform engineers” is therefore not accidental. The buyer it wants is not the application developer alone; it is the person trying to make developer experience sustainable at enterprise scale. That is where the real competitive battle is taking place.

Strengths and Opportunities​

Broadcom’s announcement contains several strengths that could matter a great deal for enterprise adoption if they hold up in deployment. The combination of platform discipline, open ecosystem participation, and operationally meaningful features suggests a release built around real customer pain rather than check-the-box innovation. It is also notable that the company is leaning into supportability as a differentiator, which is often what large IT shops buy first.

• Extended support windows reduce upgrade pressure.
• Continuous readiness checks improve day-two reliability.
• Declarative tuning makes performance changes safer.
• Validated partner integrations preserve enterprise flexibility.
• RHEL support broadens OS choice for mixed estates.
• AppArmor and support-bundle improvements simplify secure operations.
• Velero’s CNCF path strengthens trust in backup governance.

There is also a broader strategic opportunity here. If Broadcom can make VKS the default place where enterprise Kubernetes, security, networking, and AI workloads converge, it could deepen VMware Cloud Foundation’s role as a platform standard rather than just an infrastructure bundle. That would give Broadcom a stronger answer to both cloud-native specialists and public-cloud-native incumbents.

Risks and Concerns​

The biggest risk is that Broadcom’s promises will be judged against a very high operational standard. Enterprise buyers do not reward “better in principle”; they reward “less painful in production.” If lifecycle promises, partner validation, or tuning abstractions create hidden complexity, the platform could still end up feeling heavy, even if the individual features are sound.

• Integration complexity could offset the benefits of ecosystem openness.
• Policy sprawl may emerge if too many tuning and security knobs are exposed.
• Upgrade readiness checks only help if teams trust and maintain them.
• Vendor-neutral governance for Velero must translate into active community health.
• Mixed OS and heterogeneous pools can increase operational variance.
• AI messaging can ring hollow if the real workload experience is not simplified.
• Support boundaries must remain clear across partner add-ons.

There is also a market perception challenge. Broadcom has spent the last two years building a reputation that some customers associate with tighter commercial control. That makes openness, supportability, and ecosystem friendliness especially important, because they have to be demonstrated, not merely announced.

Looking Ahead​

The next question is whether Broadcom can convert this announcement into a pattern of trust. The individual features matter, but the real test will be whether platform teams see fewer upgrade surprises, fewer support exceptions, and fewer architecture compromises over time. If that happens, VKS 3.6 will look less like a point release and more like a statement about where enterprise Kubernetes is headed.
The market will also watch how the CNCF path for Velero evolves. If the project gains a broader contributor base and maintains technical momentum under community stewardship, that will strengthen Broadcom’s credibility rather than weaken it. In the best case, it will show that the company can contribute to open infrastructure while still building a differentiated commercial platform around it.

What to watch next​

• Whether enterprises adopt VKS 3.6 for regulated and stateful workloads.
• Whether partner integrations remain smooth across upgrade cycles.
• Whether Velero gains visible momentum under CNCF stewardship.
• Whether Broadcom expands the declarative tuning model further.
• Whether more AI-focused platform features arrive in future VKS releases.

Broadcom’s latest Kubernetes push is best understood as an attempt to make enterprise platform engineering less improvisational and more governable. If it succeeds, the company will have done more than ship new features; it will have helped define how large organizations expect Kubernetes platforms to behave in the AI era. That is a high bar, but it is also exactly the kind of bar the market has now set.

---

Source: Broadcom Broadcom Empowers Platform Engineers to Accelerate AI and Modern Application Innovation on Kubernetes