Bring Your Own CNI: Inside VMware’s Open Kubernetes Strategy
Kubernetes networking has always involved trade-offs, and one of the most persistent frustrations for platform teams has been getting locked into a default CNI that does not fit their specific requirements. With VKS 3.6, that constraint is going away. Teams can now bring their own CNI, whether that is Cilium, Calico Enterprise or any CNCF-conformant option, and plug it into the stack instead of working around a default they did not choose.
Mike Vizard and Himanshu Singh from Broadcom get into the reasoning behind this shift at KubeCon Europe. Singh explains that the decision to open up CNI selection reflects a broader philosophy: rather than building a proprietary ecosystem that forces adoption, the goal is to meet platform teams where they already are. If a team has invested in a networking stack that works for their environment, they should not have to abandon it to run Kubernetes on VMware Cloud Foundation.
Beyond networking, they dig into how VCF is evolving to unify virtual machines and containers under a single governance model. For organizations running hybrid environments, this means one set of policies and one operational framework instead of managing two separate worlds. Singh also touches on private AI services becoming a core part of the platform, giving enterprises a way to run AI workloads on infrastructure they control without depending entirely on public cloud providers.
One of the more practical points is the convergence happening between traditional IT admin and platform engineer roles. Singh describes how the same person is increasingly wearing both hats, and the tooling needs to support that transition without requiring teams to start from scratch. For anyone managing Kubernetes alongside existing VM infrastructure, this is a look at how that operational overlap is being addressed.
