13.4 Supervisor Services & vSphere Pods

Separate Platform Services from Application Workloads

The Supervisor exposes a Kubernetes-based infrastructure API and supports an ecosystem of Supervisor Services. These can provide capabilities such as Kubernetes-cluster provisioning, registries, ingress or backup-related services under their supported versions and entitlements. Installing a service extends the platform; it does not automatically grant every developer permission to consume it.

VM Service manages VM resources. VMware/vSphere Kubernetes Service (VKS) manages supported workload Kubernetes clusters. vSphere Pods provide a hypervisor-integrated container execution model using Spherelet and the Container Runtime Executive (CRX). A VKS workload cluster instead runs Kubernetes control-plane and worker nodes as VMs. General containers in that cluster use the Kubernetes node runtime; they are not automatically the same as vSphere Pods.

Select a Compatible Service

Identify the required service, its supported Supervisor versions, networking needs, storage requirements and entitlement. Use the official service artifact/download location and compatibility matrix. The VMware technical-marketing Supervisor Services catalog links current service documentation and explains independent service lifecycles. Do not assume that the newest service works with every older Supervisor.

For the 9.0 exam, maintain a clear version boundary. A feature added in 9.1 is not automatically part of the 9.0 deployment workflow. Service versions can also change without a full vCenter upgrade. Record the actual installed Supervisor and service versions when following an example.

Install and Configure

Register the service artifact/version through the supported Supervisor Services workflow, review its configuration values, and install it on the intended Supervisor. Supply required registry, storage, networking and certificate settings through the documented mechanism. Keep credentials out of shared manifests and protect any referenced Secrets.

Observe the service's deployment/health status, reconcile errors and inspect the supported events/logs. An artifact appearing in the service catalog does not establish that it is installed on a Supervisor. An installed service with unhealthy pods or unresolved dependencies is not ready for consumption.

Configure access and namespace resources as the service requires. A platform-wide service registration and a namespace consumer assignment are separate steps. Verify the resulting resource types with the intended developer identity. Cluster administrator access can hide a missing consumer permission.

Deploy and Verify vSphere Pod Workloads

For an applicable supported pod workload, select the appropriate Supervisor context and namespace. Use the documented pod/deployment specification with a real accessible container image and supported resources, storage and networking. Apply it, inspect pod conditions/events and verify readiness and the required Service endpoint. A Pod being created does not prove its image was pulled or that its application is reachable.

Use the workload model supported by the selected network configuration. Supervisor Services can use vSphere Pods on supported VDS networking, so a blanket statement that all vSphere Pods always require NSX is wrong. General application-pod capabilities and network policies still have configuration-specific limits. Check the specific workload/service documentation rather than transposing an NSX example into a VDS environment.

Follow the Failure Evidence

An image-pull error points first to image identity, registry reachability, authentication or trust. A pending workload can reflect resource quota, storage-policy compatibility or scheduling capacity. A running pod with an unreachable endpoint can reflect Service configuration, load-balancer address allocation or network reachability. Investigate the relevant boundary before rebuilding the Supervisor.

For a stateful service, verify persistent volume binding and a supported backup/recovery method. Restarting a pod tests only a narrow failure case. Deleting/recreating a namespace can remove much more than one failed application and must follow the service's documented data-retention/decommissioning process.

Upgrade and Decommission

Review compatibility and release notes before changing the service version. Back up configuration and application data through a supported method, validate available capacity for rolling operations and plan the recovery path. An independently upgradeable service still depends on the Supervisor's APIs and supported platform version.

After upgrade, verify service readiness, consumer permissions, a representative resource and application access. During removal, determine which consumer workloads, persistent volumes and custom resources remain dependent on the service. Do not delete a controller while assuming it will continue reconciling its resources afterward.

A useful exam answer identifies the requested layer: enable Supervisor, install a service, authorize a namespace, create a VM, provision a VKS cluster or run a supported pod workload. These are related but distinct tasks. Practising each with visible resource conditions and a validated consumer identity provides a complete deployment workflow.

Review Takeaways

• Supervisor service registration, installation and consumer authorization are different steps.
• VM Service, VKS workload clusters and vSphere Pods have different execution and lifecycle models.
• CRX means Container Runtime Executive; supported Supervisor Services can use vSphere Pods on VDS.
• Verify compatibility, readiness, endpoint access and data recovery before declaring a service usable.