01 · The starting point
The first cluster works. Then the enterprise questions begin.
Imagine a platform team that has proved Kubernetes with one application. The developers can submit a Deployment, Kubernetes schedules the Pods, and a Service makes them reachable. The demonstration is successful. Now eight more teams want clusters. The platform team must decide who can create them, while the operations team asks who will patch, monitor, back up, and support them.
Kubernetes still does its job. The new questions sit around it: how does a datacenter repeatedly deliver Kubernetes as a governed, supported service?
Kubernetes answers, “How should this application run?” VKS and VCF answer, “How will our datacenter deliver and operate the Kubernetes environments that applications need?”
02 · Vendor-neutral context
Start with the portable Kubernetes contract.
A Kubernetes cluster has a control plane and worker nodes. The control plane exposes the API and reconciles desired state; worker nodes run Pods. Namespaces scope many resources inside a cluster, while Services provide stable network access to changing sets of Pods.
These concepts remain relevant whether the cluster was assembled with upstream tools, supplied by OpenShift, delivered by a cloud provider, or created by VKS. Applications still interact with Kubernetes objects rather than vSphere objects.
This is the stable center of the story: VKS does not ask developers to abandon Kubernetes. It gives the platform team a repeatable way to supply the clusters behind that familiar API.
VMware Kubernetes Service (VKS), formerly known as the TKG Service, runs as a service on Supervisor. It provisions and lifecycle-manages Kubernetes workload clusters using the compute, networking, storage, identity, and policy capabilities supplied by VCF.
The workload definition does not describe ESXi hosts.
Infrastructure details are handled below the application API. That separation is central to understanding VKS.
apiVersion: apps/v1
kind: Deployment
metadata:
name: storefront
spec:
replicas: 3
selector:
matchLabels:
app: storefront03 · From foundation to application
Five layers connect VCF infrastructure to Kubernetes applications.
Read the stack from the foundation upward. VKS belongs on Supervisor: it turns a cluster request in a governed VCF Namespace into a workload cluster that application teams can use.
The naming can be deceptive: a VCF Namespace governs infrastructure consumption on Supervisor, while a Kubernetes namespace scopes application resources inside a workload cluster. They are different objects in different control planes.
These ecosystem tools complement the cluster service; they are not architectural layers inside VKS. Availability and support depend on the selected VKS, Kubernetes, networking, and add-on versions.
04 · Shared responsibility
VKS changes who does the work; it does not remove the work.
Exact ownership varies by organization, but a useful operating model separates infrastructure, platform, and application concerns. The interfaces between these teams deserve as much design attention as the technology.
- VCF and vSphere lifecycle
- Supervisor availability
- Compute capacity
- Network and storage services
- Namespace-level policy
- Cluster classes and versions
- VKS cluster lifecycle
- Baseline add-ons and controls
- Observability and support
- Developer experience
- Deployments and Services
- Application namespaces and RBAC
- Configuration and secrets
- Application reliability
- Workload security posture
05 · Platform translation
Bring the mental model you already have.
These are conceptual translations, not claims of exact feature equivalence. Their purpose is to show where familiar responsibilities move when teams adopt VKS.
| Question | Upstream | OpenShift | EKS / AKS / GKE | vSphere background | VKS |
|---|---|---|---|---|---|
| Who supplies clusters? | Your selected tooling and team | OpenShift installer and operators | Cloud-provider service API | Usually manual VM provisioning | VKS controllers on Supervisor |
| Primary tenancy boundary | Cluster and Kubernetes namespace | Cluster, Project, and policy | Cloud account plus cluster and namespace | vCenter, cluster, resource pool, folder | VCF Namespace plus workload cluster and namespace |
| Infrastructure integration | Assembled from chosen providers | Integrated platform stack | Native cloud services | vSphere compute, network, and storage | VCF and vSphere services exposed through policy |
| Control-plane operations | Your responsibility | Platform administrators | Mostly cloud provider | Not normally a Kubernetes concern | Customer-operated through VKS lifecycle management |
| Developer API | Kubernetes API | Kubernetes and OpenShift APIs | Kubernetes API plus cloud APIs | vSphere and automation APIs | Kubernetes API plus VCF consumption interfaces |
06 · The strategic foundation
VKS is not a standalone island. Its advantage comes from VCF.
At this point in the story, the cluster is only one outcome. The larger objective is a private-cloud platform that can deliver virtual machines, Kubernetes clusters, data services, and modern applications from a consistent operational foundation.
Common infrastructure, lifecycle, security, operations, and governance for the datacenter.
Use common compute, networking, storage, identity, lifecycle, and observability capabilities instead of building a separate infrastructure island for Kubernetes.
VCF Namespaces and VKS translate infrastructure capacity into governed, delegated Kubernetes consumption.
Platform teams can support VMs and Kubernetes while evolving operating practices toward automation and application-centric services.
Organizations retain control over data location, infrastructure policy, security boundaries, and lifecycle decisions.
07 · Knowledge reinforcement
Check the reasoning, not the score.
Choose an answer in each card. The review explains the correct answer and why every alternative falls short. Nothing is scored or stored.
Question 01 Which statement best separates Kubernetes from a Kubernetes platform? +
Correct answer: B Kubernetes defines the portable workload and reconciliation model. A platform adds supported lifecycle, infrastructure, security, governance, and experience choices.
- A: Kubernetes is extensible precisely because many production capabilities are supplied by integrations and platform choices.
- B: This preserves the boundary between the Kubernetes contract and the surrounding platform.
- C: Platforms can extend Kubernetes, but applications still commonly use Kubernetes APIs.
Question 02 What is the primary role of VKS? +
Correct answer: A VKS is a Supervisor Service providing APIs and controllers for Kubernetes workload-cluster lifecycle on vSphere.
- A: This describes the core service boundary accurately.
- B: Workloads continue to use Kubernetes objects; infrastructure integration sits below that API.
- C: Application teams retain responsibility for their workloads and application-level reliability.
Question 03 Why is a VCF Namespace not the same as an application namespace? +
Correct answer: C The similarly named constructs live at different layers and establish different boundaries.
- A: It carries access, capacity, storage, networking, and policy implications beyond naming.
- B: They exist in different Kubernetes control planes and are not interchangeable.
- C: This correctly distinguishes the infrastructure-policy boundary from workload resource scoping.
Question 04 Who remains responsible for application Services, configuration, and workload reliability? +
Correct answer: B A managed cluster lifecycle does not transfer ownership of application behavior.
- A: Product support does not make the vendor the operator of customer workloads.
- B: Application concerns stay with the product team, supported by platform standards.
- C: Infrastructure teams supply foundational services rather than application configuration and SLOs.
Question 05 Why is VCF central to the VKS value proposition? +
Correct answer: B VKS draws its strategic value from VCF’s integrated infrastructure, lifecycle, policy, and operational capabilities.
- A: Applications still consume the Kubernetes API; VCF supplies the platform underneath it.
- B: This correctly describes VCF as the foundation and VKS as a service delivered from it.
- C: Integrated lifecycle reduces toil, but teams still own platform, cluster, and application responsibilities.
08 · Key takeaways
The short version.
Kubernetes is an orchestration foundation, not a complete enterprise platform by itself.
VKS provides workload-cluster provisioning and lifecycle through Supervisor.
Applications retain the standard Kubernetes mental model and APIs.
VCF Namespaces and workload-cluster namespaces are different boundaries.
VCF authorization and Kubernetes RBAC control different object boundaries.
VKS is the Kubernetes service layer of the strategic VCF private-cloud platform.