Application modernization and the shift toward containerization are forcing IT infrastructures to evolve. Where organizations once maintained a strict separation between virtual machines and container environments, VMware Cloud Foundation (VCF) 9 fundamentally changes this dynamic. With VCF 9, containers are promoted to first-class citizens, running directly alongside traditional VMs on the same platform. This article takes a deep dive into the VCF 9 architecture for native containers, the role of vSphere Pods and the new Container Service (introduced in VCF 9.1), and explains how administrators and DevOps engineers can rapidly deploy workloads without requiring deep Kubernetes expertise.
The Architecture: vSphere Supervisor and vSphere Pods
To understand native containers on vSphere, we need to examine the underlying architecture of VCF 9. The heart of this integration is the vSphere Supervisor. Once enabled on a VCF Workload Domain, the vSphere cluster is transformed into a platform capable of orchestrating not only virtual machines, but also Kubernetes workloads.
Within the Supervisor, workloads are organized using vSphere Namespaces — logical boundaries (resource pools) to which compute, memory, and storage resources are assigned through Storage Policy Based Management. Within these namespaces, DevOps engineers can deploy containers directly.
What Is a vSphere Pod?
The fundamental unit for running a native container in VCF is the vSphere Pod. Unlike a standard Kubernetes pod, which shares the Linux kernel of the underlying worker node with other pods, a vSphere Pod provides strict hardware-level isolation.
A vSphere Pod is essentially an ultra-lightweight virtual machine, powered by a purpose-built Photon OS kernel. Inside this PodVM, the container runtime (such as containerd) executes the OCI-compliant (Open Container Initiative) container image. This architecture delivers three critical advantages.
Strong Isolation. Because there is no shared kernel, the risk of container escapes or noisy neighbor interference is virtually eliminated. This makes vSphere Pods ideal for multi-tenant or security-sensitive environments.
Performance and Speed. Despite being technically a virtual machine, the footprint is so minimal that startup times are comparable to those of traditional containers.
Integrated Management. vSphere DRS (Distributed Resource Scheduler) manages the placement of vSphere Pods across ESXi hosts in exactly the same way it handles virtual machines, ensuring optimal resource distribution at all times.
The VCF Container Service: Containers Without Kubernetes Complexity
While running containers through Kubernetes is powerful, setting up and managing Kubernetes clusters — for example through vSphere Kubernetes Service (VKS) — requires considerable expertise. VCF 9.1 addresses this with the introduction of the Container Service.
The Container Service is a simplified, managed interface available through VCF Automation or the Local Consumption Interface (LCI). It acts as a high-level wrapper around vSphere Pods, enabling users to simply provide an OCI image URL and let the platform handle the rest. The platform intelligently determines whether a workload should run as a Kubernetes Deployment or StatefulSet based on the workload specification.
Use Cases for the Container Service
The Container Service is the right tool in the following scenarios:
- You need to run a container quickly without provisioning a full Kubernetes cluster.
- CI/CD pipelines require short-lived ephemeral workloads such as build jobs or test runners.
- You are building a hybrid application where a database runs in a traditional VM and the frontend runs in a container, both managed from the same vSphere interface.
- Your team lacks dedicated Kubernetes expertise but wants to benefit from containerized workloads.
Hands-On: Deploying a Native Container
There are two primary methods for deploying a native container (vSphere Pod) in VCF 9: through the graphical Container Service interface (VCF 9.1 and later) or declaratively via the command line using kubectl and YAML manifests.
Method 1: The Graphical Container Service (VCF 9.1)
With the Container Service, deploying an application — for example an NGINX web server — is reduced to a few steps.
Step 1 — Access. Log in to VCF Automation or the Local Consumption Interface and navigate to the Container Service.
Step 2 — Basic Configuration. Provide a name for the container and enter the image URL (e.g., ghcr.io/nginxinc/nginx-unprivileged). Set the CPU and memory requests; the platform provides sensible defaults.
Step 3 — Advanced Options (Optional). For more specific requirements, the Container Service exposes the full range of capabilities you would expect from a Kubernetes workload: storage (PersistentVolumes backed by vSAN), load balancing (NSX-provisioned LoadBalancer services), ConfigMaps, Secrets, and sidecar containers.
As you build the configuration in the UI, VCF automatically generates the corresponding Kubernetes YAML in real time. This manifest can be downloaded and used directly in any automation pipeline or GitOps workflow.
Method 2: Declarative Deployment via kubectl (YAML)
For platform teams working with Infrastructure as Code, the traditional Kubernetes-native approach remains fully supported. Once a vSphere Administrator has created a vSphere Namespace and assigned the appropriate permissions, a DevOps engineer can connect to the Supervisor Control Plane endpoint and apply manifests directly.
The following is an example manifest that deploys a vSphere Pod running NGINX:
apiVersion: v1
kind: Pod
metadata:
name: nginx-native-pod
namespace: my-vsphere-namespace
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "1000m"
Apply the manifest using the standard kubectl command:
kubectl --kubeconfig vsphere-kubeconfig apply -f nginx-pod.yaml
The Supervisor translates this Kubernetes object directly into a vSphere Pod, DRS places it on an appropriate ESXi host, and NSX handles network isolation — all transparently, without any additional configuration required from the engineer.
Network and Storage Integration
Networking. Every vSphere Pod receives a unique IP address assigned by NSX. Network isolation is enforced at the virtual NIC level, not merely through software-defined rules within a shared operating system. This means container traffic can be routed, inspected, and filtered through NSX Distributed Firewall policies in exactly the same way as VM traffic — a significant advantage for security and compliance teams.
Storage. vSphere Pods consume storage through Container Native Storage (CNS). Persistent volumes are attached directly as VMDKs to the PodVM, governed by the Storage Policy Based Management (SPBM) rules defined in vCenter. This guarantees not only data persistence across Pod restarts, but also predictable I/O performance, since resource guarantees are enforced at the VM level rather than relying on shared OS-level scheduling.
Conclusion
VMware Cloud Foundation 9 definitively bridges the gap between traditional infrastructure and modern application development. By running containers as vSphere Pods directly on the hypervisor, organizations gain the speed and portability of containers combined with the strict security and isolation of virtual machines. With the addition of the Container Service in VCF 9.1, the barrier to getting started with containers is lower than ever. It is one platform, with one unified operational experience, for all workloads.
