Dr. Pranay Jha

Container or VM used to be a two-way question. In VCF 9.1 it is a four-way one, and the wrong answer costs you either flexibility or a cluster you did not need to run. VM Service, Container Service, the Supervisor namespace itself, and VKS are all consumable through VCF Automation, and they sit on a spectrum from most operating-system control to most Kubernetes power. The skill is matching the workload to the lightest option that does the job, instead of defaulting every modern application to a full Kubernetes cluster because that is what modern is supposed to look like.

Four ways to run, one platform

VM Service gives a full virtual machine. Container Service runs a container directly on ESX with no cluster underneath. A Supervisor namespace is the governed space a tenant works in, and on its own it is enough to run containers through Container Service. VKS is a complete Kubernetes cluster created inside a namespace. None is a downgrade of another; they are different shapes for different workloads, and operational load roughly tracks the move toward full Kubernetes.

The namespace is what you hand a tenant

People conflate three layers that share the word namespace, and the choice in this article is whether a tenant stops at the middle layer or goes all the way to a cluster. At the top is the VCF Automation Project, the governance and tenancy boundary, where a Region maps to a Supervisor and a project entitles a namespace class. Below it is the vSphere (Supervisor) namespace, the resource boundary: quota in CPU, memory and storage, an NSX VPC with a dedicated CIDR, and identity through owner groups. The third layer, optional, is the VKS cluster a developer creates inside the namespace with kubectl.

Container Service, without the cluster

Container Service runs a container directly on ESX as a vSphere Pod, inside the namespace, with no Kubernetes cluster to deploy or operate. The platform schedules, isolates and runs it. Each vSphere Pod is a purpose-built lightweight VM, and only the containers in that one pod share a kernel, so you get VM-grade isolation around container workloads without standing up and hardening a cluster per team. You consume it as ordinary Kubernetes: apply a standard Pod spec to your Supervisor namespace and a vSphere Pod is scheduled.

# Container Service: a vSphere Pod is a standard Pod in the Supervisor namespace
kubectl --context team-blue-ns apply -f web-pod.yaml
kubectl --context team-blue-ns get pods

# web-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: team-blue-ns
spec:
  containers:
    - name: web
      image: harbor.corp.local/team-blue/web:1.4
      resources:
        requests:
          cpu: 500m
          memory: 256Mi

Namespace plus Container Service vs a full VKS cluster

This is the decision people skip and then regret. A VKS cluster is a dedicated, conformant Kubernetes cluster: the team gets cluster-admin, a choice of CNI (Antrea and Calico out of the box, Cilium added in 9.1), a choice of node OS across node pools, secondary networks, and the full upstream API for operators and custom resources. The operational cost is the same list read backwards: every cluster is a set of VMs you size, patch and upgrade, and a Kubernetes version you keep current. Namespace plus Container Service has none of that surface, at the price of no cluster-admin and a shared Supervisor control plane.

When each runtime is right

VM Service is correct, not a consolation prize, for anything that needs a full operating system: a kernel you control, in-guest agents, software that was never containerized, and stateful single-server apps. If a vendor supports their product on a VM and not in a container, the argument is over. Container Service is the right default for containers that do not need cluster-admin, which is most of them. VKS is for teams that genuinely consume full Kubernetes: operators, custom resources, a pinned version, a specific CNI, or hard control-plane isolation. The runtimes are also a path, not silos: when a Container Service app outgrows the model, the interface generates the YAML to move it to a VKS cluster, so starting light is never a trap.

Where the workload actually lands

Choosing a runtime is not the same as choosing where it runs. In the All Apps world, Infrastructure Policy handles placement: a policy pairs matching criteria, for example all VMs with a Linux guest OS, with a reference to an underlying vCenter compute policy, and is assigned to region quotas and from there to namespaces. Set placement once at the policy level and every runtime inherits it. The same machinery decides whether a database lands on a namespace-backed VKS or classic vSphere. Manage placement per workload and you will not keep up; manage it per policy and you barely think about it.

The Verdict

Use VM Service for anything that needs a real operating system, make a namespace with Container Service your default for containers, and treat a full VKS cluster as the exception you grant on evidence. The reason is operational gravity: the namespace gives a team a governed place to run containers with nothing for you to patch, VM Service is simply correct for a large slice of enterprise software, and VKS earns its lifecycle cost only when a team actually uses cluster-admin and the wider API. When would I hand out a cluster first? For a dedicated platform team that owns its own Kubernetes stack and has the people to operate it. For everyone else, start with the namespace, and let the generated-YAML on-ramp carry them to VKS if and when they truly need it. What share of your container workloads actually needs a cluster, and how many clusters are you running as if they did?

References

• Self-service private cloud with VCF 9.1 (Broadcom)
• The Hierarchy of Modern Infrastructure: Namespaces in VCF, VKS and VCF Automation (Broadcom)
• Deploy modern apps faster with VKS on VCF 9.1 (Broadcom)
• VCF 9.1 improvements: VCF Automation and VKS (Cloud Blogger)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts