Introduction

VMware Cloud Foundation (VCF) supports more than one workload model. VMware vSphere Kubernetes Service (VKS) clusters run standard Kubernetes applications, VM Service provides declarative virtual-machine consumption, and Supervisor Pods support specific workloads directly on the vSphere Supervisor where the platform and release permit them. These models share infrastructure but have different APIs, isolation boundaries, and operational owners.

What Are the Supported Workload Models

A VKS cluster is the general-purpose Kubernetes boundary for containerized applications. Application teams use its Kubernetes API to create Deployments, StatefulSets, Services, configuration, and other Kubernetes resources.

VM Service exposes virtual machines through a declarative service associated with the Supervisor and vSphere Namespace. It is useful when an application component needs a full guest operating system or cannot run as a container.

Supervisor Pods run supported container workloads on the Supervisor layer. They should not be treated as a universal substitute for a VKS cluster; their availability and intended use depend on the documented platform configuration.

Why Workload Placement Matters

Choosing a model defines the control plane that owns lifecycle, the security boundary, the resource policy, and the team's operational tools. An application placed in the wrong model may receive inappropriate privileges, complicate upgrades, or create an unclear support boundary.

Core Concepts

Kubernetes Applications in VKS

Use VKS clusters for applications designed for Kubernetes APIs and cluster-level services. Workloads inherit the cluster's Container Network Interface (CNI), storage classes, Role-Based Access Control (RBAC), admission policy, and lifecycle. Teams must manage application manifests and cluster capacity separately from the infrastructure lifecycle managed through VKS.

VM Service Workloads

VM Service uses VM classes, images, storage, networking, and namespace permissions defined by platform administrators. It suits legacy components, virtual appliances, or services that require operating-system control. The virtual machine remains subject to vSphere-backed policy and does not become a Pod merely because it is requested declaratively.

Supervisor Pods

Supervisor Pods consume Supervisor-provided capabilities and are governed by the vSphere Namespace. Because they share the platform control environment more directly than VKS workloads, administrators should follow official support guidance and apply stricter placement and lifecycle review.

Hybrid Application Design

A system can combine VKS applications with VM Service components. The design must specify service discovery, routing, certificates, secrets, storage, backup, and ownership across the boundary. Avoid hidden dependencies between independently managed lifecycles.

Target Audience

This decision framework is for platform architects, application teams, and vSphere administrators deciding how modern and existing application components should consume VCF resources.

Career or Technical Value

Understanding workload models helps teams modernize incrementally. It also prevents the false choice that every application must be entirely containerized or entirely virtual-machine based.

Common Learning Challenges

  • Treating VM Service as Kubernetes worker-node provisioning
  • Assuming Supervisor Pods offer every capability of a VKS cluster
  • Deploying a full virtual machine when a standard Kubernetes workload is sufficient
  • Ignoring cross-model networking and identity dependencies
  • Failing to assign operational ownership for each control plane
  • Using platform-level privileges for ordinary application deployment

Conclusion

VKS clusters, VM Service, and Supervisor Pods solve different workload-placement problems. Choose the model by application runtime needs, isolation, API ownership, lifecycle, and support requirements. Hybrid designs are valid when their dependencies are explicit and each layer retains a clear operational boundary.