Introduction

VMware Cloud Foundation (VCF) 9.0 provides the infrastructure and platform services that support both virtual machines and Kubernetes workloads. For VMware vSphere Kubernetes Service (VKS), the important architectural question is not simply where Kubernetes runs, but how compute, networking, storage, identity, and operations combine to create a supported platform.

This article maps those VCF layers. It intentionally stops at the boundary of detailed VKS internals, which belong to the next article in the series.

Architecture Overview

VCF organizes private-cloud capabilities around integrated infrastructure services. VMware vSphere supplies compute virtualization and inventory, VMware NSX supplies software-defined networking and security capabilities, and VMware vSAN can provide policy-driven storage. Platform operations and automation services add lifecycle, observability, and consumption workflows.

vSphere Supervisor enables Kubernetes-oriented platform services on eligible vSphere infrastructure. VKS then uses that foundation to provision dedicated Kubernetes clusters. The result is a layered system in which VCF owns infrastructure availability and lifecycle, the Supervisor exposes platform capabilities, and workload clusters run application-facing Kubernetes control planes.

Core Components

Component Explanation

  • VCF management services: Coordinate infrastructure configuration, lifecycle, credentials, and operational visibility according to the deployed VCF design.
  • vCenter Server: Provides vSphere inventory, permissions, cluster management, virtual-machine lifecycle, and the management interface for Supervisor capabilities.
  • ESX hosts and vSphere clusters: Supply CPU and memory capacity for Supervisor components, VKS nodes, and other workloads.
  • VMware NSX or supported vSphere networking: Provides the management, node, workload, and service connectivity required by the selected Supervisor design.
  • Load balancing: Presents reachable virtual endpoints for platform and workload services where required by the network architecture.
  • VMware vSAN or supported datastores: Supplies persistent capacity exposed through vSphere Storage Policies.
  • Identity, Domain Name System, time, and certificates: Form shared platform dependencies for authentication and trusted communication.
  • Operations and automation: Supply monitoring, capacity insight, standardized provisioning, and governance around the platform.

How Components Work Together

The compute layer hosts Supervisor control-plane virtual machines and the control-plane and worker nodes of VKS clusters. Placement and availability therefore depend on vSphere cluster health, resource capacity, maintenance policy, and failure-domain design.

The network layer must connect management endpoints, cluster nodes, Pods, Kubernetes Services, ingress and egress paths, and external consumers according to the chosen topology. The storage layer maps vSphere policy to Kubernetes storage classes through the vSphere Container Storage Interface (CSI) Driver. Identity and certificate services establish who can administer each layer and which endpoints are trusted.

No layer is independent. A healthy Kubernetes API may still be unable to provision a volume when a storage policy is inaccessible. Available hosts cannot create a cluster if network address pools are exhausted. Platform services may fail to reconcile when a registry or certificate chain is unavailable.

Design Considerations

Start with workload requirements and service objectives. Translate availability, performance, recovery, isolation, and compliance needs into compute placement, network topology, storage policies, identity boundaries, and operational responsibilities.

Capacity models must include platform overhead and growth, not only application requests. Address plans should cover every documented network pool without overlap. Storage policy design should reflect durability and performance needs while remaining accessible to the intended topology.

Best Practices

  • Use the compatibility guidance for the exact VCF, Supervisor, VKS, and Kubernetes release combination.
  • Document management, workload, service, ingress, and egress network responsibilities.
  • Reserve capacity for platform services, upgrades, node replacement, and failure recovery.
  • Align failure domains across compute, networking, and storage.
  • Treat Domain Name System, Network Time Protocol, certificate authorities, and registries as production dependencies.
  • Monitor infrastructure and Kubernetes signals together while retaining clear ownership boundaries.

Common Mistakes

  • Treating VKS as a stand-alone Kubernetes installation disconnected from VCF lifecycle
  • Sizing only worker nodes and overlooking platform and upgrade headroom
  • Designing IP pools without accounting for growth or failure recovery
  • Assigning storage policies that cannot satisfy topology requirements
  • Assuming an available infrastructure component is correctly reachable or trusted
  • Mixing responsibilities among VCF, Supervisor, VKS cluster, and application teams

Certification Relevance

The 3V0-24.25 scope uses VCF 9.0 as its platform baseline. Candidates should be able to map Kubernetes requirements to VCF services, identify shared dependencies, and explain why compute, networking, storage, identity, and operations must be validated before VKS provisioning.

Conclusion

VCF 9.0 provides the integrated infrastructure on which Kubernetes services depend. vSphere supplies compute and control, NSX or supported vSphere networking supplies connectivity, vSAN or other supported datastores supply policy-driven storage, and shared identity and operational services make the platform manageable. This layered view establishes the foundation for understanding VKS architecture without conflating infrastructure with workload-cluster internals.