Advocates for cloud-native software have long argued that their approach to development makes applications portable across different Kubernetes environments. But VMware argues that’s not happening across hybrid clouds, and has taken the lead in an effort to improve matters.

That effort, the new Workload Conformance Working Group in the Kubernetes community, aims to establish a shared standard for how workloads run on Kubernetes. 

The group’s web page points out, “Certified Kubernetes tests the cluster, and Kubernetes AI Conformance tests whether a cluster can run AI and ML workloads. Nothing comparable exists for the workloads themselves, so cluster operators still check each application by hand before routine maintenance or a Kubernetes upgrade. Every cluster operator ends up repeating the same assessment, and application maintainers get the same questions from each environment they support,” the group asserts.

The proposed solution? “A common specification with repeatable tests would give both groups the same baseline to start from.”

Prashanth Shenoy, VP of product marketing in Broadcom's VMware Cloud Foundation (VCF) division, told that standard is needed in part because applications packaged to run in public clouds don’t always run well in hybrid clouds.

That’s challenging for VMware, and other vendors of hybrid clouds like Nutanix and Red Hat, because they all sell tools to create and run a stack that users can deploy to both on-prem infrastructure and public clouds.

VMware therefore thinks it will find support for an effort to ensure that cloud-native apps run predictably and efficiently in any Kubernetes environment.

The effort to create this standard is in its very early days.

“The first step is deciding which workloads and behaviors the specification covers,” states the announcement of the working group’s formation. “The scope includes security, resilience during disruptions, resource use, networking, storage, API usage, and observability, but the group hasn’t yet agreed on specific requirements or on how to test them.

“However, one rule is already set: every requirement needs an objective test that a test binary can run, so nothing subjective goes into the specification.”

Shenoy thinks application vendors will likely support this effort because they want to package their wares once and have them run anywhere.

VM API to CNCF Sandbox

VMware this week announced another contribution to Kubernetes by moving its VM API to the Cloud Native Computing Foundation (CNCF) Sandbox.

The CNCF, which maintains Kubernetes, is already home to KubeVirt, a tool that allows users to create and manage VMs inside a Kubernetes cluster. The VM API lets Kubernetes users create VMs that run under other hypervisors – including VMware’s own ESXi.

VMware previously integrated Kubernetes into vSphere with Kubernetes, introduced as part of vSphere 7 in 2020. Chronicling Virtzilla’s long and convoluted attempts to package and sell the container tech it acquired along with Pivotal Software would be a tedious exercise.

Suffice to say past efforts didn’t catch on, and VMware is now trying a different approach to making VMs a first class citizen of Kubernetes.

The CNCF’s interest shows this is not a vanity project for VMware, because while developers generally prefer to write for containers, operations folk often decide to run those abstractions within lightweight VMs. The two abstractions are therefore going to coexist for years to come, both for new apps and as organizations run new containerized apps alongside legacy VMs, and do so in an infrastructure-as-code world in which automated deployments are assumed.

VM API will therefore likely be a welcome addition to Kubernetes, representing another option to make life a little easier for ops and dev teams. ®