VCF and VKS Core Concepts

02 · The mental model

Think of a corporate office building.

Imagine a large corporate office building. The building already has floors, wings, work areas, power, network cabling, security access, shared services, a facilities team, storage areas and operating rules. That is similar to your VCF infrastructure.

Now imagine one floor in this office building has been enabled for modern self-service workspaces. Teams do not manually arrange power, network, access cards, meeting rooms and shared services every time they start a new project. Instead, the facilities team provides governed spaces with approved services. This is similar to vSphere Supervisor.

The floor is divided into wings: North Wing and South Wing. Each wing has its own access rules, resource limits, approved meeting rooms, approved workstation sizes and available shared services. That is similar to a vSphere Namespace.

Inside the North Wing, Central IT creates a dedicated project area for running cloud-native applications. That project area is the VKS cluster. Inside that project area, Central IT may create separate work zones such as cloud services, database services, monitoring and operations. Those work zones are like Kubernetes namespaces inside the VKS cluster.

03 · Core mapping

Use one clean hierarchy and avoid mixing technical layers.

05 · vSphere Namespace

A vSphere Namespace is a department wing, not a Kubernetes namespace.

A vSphere Namespace is one of the most important VKS concepts. It is a platform-level boundary where VKS clusters, VM Service workloads, vSphere Pods and Supervisor Services can run.

It can define who has access, how much CPU and memory can be used, which storage policies are available, which VM classes are available, which content libraries are available, and which services are allowed.

In the corporate office analogy, Central IT does not get unlimited access to the entire office building. It receives a controlled wing with rules:

06 · Namespace vs namespace

One namespace exists around the cluster. The other exists inside the cluster.

07 · vSphere Zones

Zones are office blocks and failure domains.

A vSphere Zone is a logical grouping of vSphere clusters. It helps with availability and failure isolation. In a simple design, you may have one zone. In a more resilient design, you may have three zones.

Think of vSphere Zones as separate office blocks or building sections: Block A, Block B and Block C. If Block A has a problem, the goal is that workloads designed across Blocks B and C can continue running, depending on the application and platform design.

For platform architects, zones matter because they influence control plane placement, workload placement, storage policy design, failure-domain planning, namespace resource distribution and high availability strategy.

08 · VKS Cluster

The VKS cluster is the project area inside the wing.

A VKS cluster is the Kubernetes environment created for an application team inside a vSphere Namespace. The vSphere Namespace is the department wing. The VKS cluster is the project area inside that wing.

Inside the VKS cluster, the application team deploys normal Kubernetes objects: Pods, Deployments, Services, ConfigMaps, Secrets, Ingress, PersistentVolumeClaims and NetworkPolicies.

The platform team still controls which wing the project area belongs to, which Kubernetes releases are allowed, which cluster blueprints are approved, which workstation sizes are available, which storage policies are exposed, which network paths are available and who can enter the wing. But inside the VKS cluster, the application team organizes and runs its Kubernetes workloads.

09 · Core constructs

VKr, Cluster API, ClusterClass, VM Class and Storage Policy make the platform controlled.

VKr: the approved Kubernetes release package

VKr means VMware vSphere Kubernetes release. In simple terms, VKr represents the approved Kubernetes release package available for VKS clusters. A Kubernetes version is the software version; VKr is the approved software release package.

Cluster API: the project-area request system

VKS uses Cluster API, commonly called CAPI, for declarative lifecycle management. Instead of manually creating every VM and installing Kubernetes step by step, the platform works from a desired cluster definition.

ClusterClass: the approved project-area blueprint

A ClusterClass is a reusable cluster blueprint. It helps platform teams standardize how VKS clusters are created so every team does not invent its own control plane size, worker node size, network pattern and lifecycle behavior.

VM Class: the approved workstation size

A VM Class defines the compute shape of a VM. In VKS, VM Classes matter because VKS cluster nodes are virtual machines. This lets the platform team control approved control plane and worker node sizes.

Storage Policy: the approved storage room type

A Storage Policy defines what storage capability is available to workloads. The application team asks for storage through Kubernetes, while the platform decides which physical storage capability backs that request.

10 · Supervisor Services, VM Service and Velero

Supervisor Services are shared office services.

Supervisor Services are services made available through the Supervisor. Examples include VKS, VM Service, Velero, Harbor, Contour, MinIO, Argo CD and cert-manager. Not every environment will enable every service. A platform team should enable only what the operating model needs.

VKS Service

The VKS Service is what allows teams to deploy Kubernetes clusters through the Supervisor platform. VKS provides conformant Kubernetes clusters and integrates cluster lifecycle with the vSphere and VCF platform.

VM Service

The VM Service allows teams to define and manage virtual machines using a declarative Kubernetes-style API. This is useful when a platform must support both modern Kubernetes workloads and traditional virtual machine workloads.

Velero

Velero provides backup and restore capabilities for Kubernetes workloads. In a VKS context, Velero can help protect application workloads and support recovery scenarios.

12 · Technical architecture overview

All key constructs in one view.

The technical view below removes the office analogy and shows the actual architecture layers: users and tools, vCenter and Supervisor APIs, Supervisor control plane VMs, Supervisor Services, vSphere Namespaces, VKS clusters, Kubernetes namespaces, vSphere Zones and the shared compute, storage and network foundation.

13 · End-to-end VKS flow

From platform boundary to running Kubernetes cluster.

14 · Read the architecture in YAML

The YAML is illustrative, not copy-paste universal.

Exact API versions, ClusterClass names, VM Classes, image names and supported Kubernetes versions depend on your VCF and VKS environment.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: payment-vks-cluster
  namespace: central-it-prod
spec:
  topology:
    class: <approved-cluster-class>
    version: <supported-vkr-version>
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
      - name: payment-api-workers
        replicas: 4
---
apiVersion: vmoperator.vmware.com/v1alpha2
kind: VirtualMachine
metadata:
  name: reporting-db-vm
  namespace: central-it-prod
spec:
  className: <approved-vm-class>
  imageName: <approved-content-library-image>
  powerState: PoweredOn

15 · VKS compared with other Kubernetes models

VKS brings Kubernetes into the VCF operating model.

16 · Common misunderstandings

Most confusion comes from mixing boundaries.

“Supervisor is just another Kubernetes cluster.”

Not exactly. Supervisor exposes Kubernetes-style APIs, but its role is to connect vSphere infrastructure with platform services such as VKS, VM Service, namespaces and lifecycle operations.

“A vSphere Namespace is the same as a Kubernetes namespace.”

No. A Kubernetes namespace separates objects inside a Kubernetes cluster. A vSphere Namespace defines a platform boundary around services, clusters, VMs, storage policies, quotas and permissions.

“A VKS cluster is the team itself.”

No. The team is the owner or consumer. The VKS cluster is the Kubernetes runtime created for that team inside a vSphere Namespace.

“Application teams should deploy directly to vSphere Pods.”

Usually no. For most application teams, the preferred target is a VKS workload cluster.

“VKr is just a Kubernetes version number.”

Not quite. VKr is better understood as an approved Kubernetes release package for the VKS environment.

17 · Knowledge reinforcement

Check the concepts before moving on.

18 · Architecture challenge

Design a VKS platform for financial services teams.

A financial services organization wants a private Kubernetes platform for three groups: Payments, Risk Analytics and Customer Reporting.

They need separate resource boundaries, controlled Kubernetes versions, approved storage tiers, optional VM-based database workloads, high availability across infrastructure zones and a future backup and restore model.

19 · Key takeaways

The strongest VKS designs separate boundaries, lifecycle and workload ownership.

1. Supervisor makes vSphere consumable through Kubernetes-style APIs.
2. vSphere Namespace is a real platform boundary, not just a Kubernetes label.
3. VKS cluster is the Kubernetes runtime created inside a vSphere Namespace.
4. Kubernetes namespaces live inside the VKS cluster.
5. VKr controls the supported Kubernetes release choices for VKS clusters.
6. Cluster API gives VKS its declarative cluster lifecycle model.
7. ClusterClass standardizes how VKS clusters are created.
8. VM Class controls node and VM sizing choices.
9. Storage Policy controls what storage capabilities are available to workloads.
10. Spherelet and CRX are Supervisor capabilities and should not be confused with normal Pods inside VKS clusters.