01 · The missing layer
A Kubernetes runtime is necessary. It is not the whole developer platform.
After a team gets a VKS cluster, the next questions arrive quickly. Where do images come from? How is ingress exposed? How are secrets injected? How are workloads protected? How do teams adopt GitOps? Which shared services are approved, patched, monitored and supported?
If every application team answers those questions alone, the platform becomes a collection of one-off installs. Each team may choose different registries, ingress controllers, secret patterns, backup tools and GitOps setups. That can work in a small experiment. It becomes hard to govern in an enterprise private cloud.
Supervisor Services provide a way to make selected platform capabilities available through the Supervisor operating model, instead of asking every team to assemble the same building blocks from scratch.
02 · Mental model
A Supervisor Service is a governed building service, not just another tool install.
Continue the office model from the previous blogs. VCF is the building. The Supervisor is the managed floor where platform rules are enforced. A vSphere Namespace is a team's governed workspace. A Supervisor Service is like a building service: security desk, mail room, loading dock, backup desk or shared equipment room.
Technically, a Supervisor Service is a platform capability installed and lifecycle-managed on a Supervisor. Treat it as a validated service package that is designed to work with the Supervisor and the vSphere Namespace model. Some services are core platform capabilities, such as VKS, VM Service and Velero. Others are extensible services from the catalogue, such as Harbor, Contour, Secret Store, Argo CD, cert-manager, ExternalDNS or stateful service integrations.
The analogy has a limit. A service is not automatically appropriate for every workload, and it is not automatically available to every namespace. Access, scope, version, storage, network exposure, backup, monitoring and support ownership still need design decisions.
03 · Do not mix the layers
VKS clusters, cluster add-ons, Operators and Supervisor Services solve different problems.
| Concept | Primary scope | Who normally operates it? | Example |
|---|---|---|---|
| VKS cluster | Kubernetes runtime for workloads | Platform team provides the cluster pattern; application or cluster teams consume it | A production Payments VKS cluster |
| Cluster add-on or package | One VKS cluster | Cluster administrator or platform automation | CNI, monitoring agent or workload-specific add-on |
| Kubernetes Operator pattern | A Kubernetes controller pattern that automates lifecycle tasks inside a cluster | Cluster or platform administrator, depending on where the Operator is installed | An Operator managing Argo CD instances or another application/platform component |
| Supervisor Service | VCF platform capability installed on a Supervisor | Cloud Admin or platform team | Harbor, Contour, Velero, Secret Store or Argo CD service pattern |
Important boundary: Keep the delivery model and the automation pattern separate. A Supervisor Service is the VCF way to package, lifecycle-manage and expose a platform capability through the Supervisor model. An Operator is Kubernetes automation that reconciles software. Some Supervisor Services use Operators, such as Argo CD, but that does not make the two concepts the same.
04 · Service catalogue
Choose services by the platform outcome, not by the product name.
Supervisor Services are valuable when a repeated capability needs a supported owner, consistent guardrails and a lifecycle path. The goal is not to install every possible service. The goal is to publish the right shared capabilities at the right scope.
| Capability | Service example | What it gives teams | Design attention |
|---|---|---|---|
| Kubernetes runtime | VKS | Conformant Kubernetes clusters on VCF | Namespace boundary, VM classes, storage policies, releases, networking and responsibility model |
| Virtual machines | VM Service | Declarative VM deployment through the Supervisor model | VM classes, images, storage, bootstrap secrets, backup and restore requirements |
| Backup and restore | Velero | Protection workflow for VKS workloads, vSphere Pods and selected Supervisor state scenarios | S3-compatible object store, backup network, data manager, restore testing and workload consistency |
| Registry | Harbor | OCI registry with projects, RBAC, scanning, signing and replication patterns | Contour prerequisite for the Supervisor Service model, DNS, TLS trust, persistent storage, monitoring and backup |
| Ingress | Contour | Kubernetes Ingress routing and Envoy exposure for supported services and workloads | Load balancer, DNS, certificates, ownership and whether the service is prerequisite or consumer-facing |
| Secrets | Secret Store | Centralized secret management and injection into supported workloads | Identity, namespace isolation, secret lifecycle, audit, application annotations and platform policy |
| GitOps | Argo CD | Desired-state delivery for Kubernetes and supported VCF resources | Git repository ownership, credentials, promotion controls, namespace-scoped instances and drift response |
| Certificates and DNS | cert-manager and ExternalDNS | Kubernetes-native certificate and DNS automation patterns | Enterprise PKI, DNS API permissions, approval workflow and whether automation is allowed in production |
| Stateful services | vSAN Data Persistence / MinIO patterns | Object or stateful service consumption with infrastructure integration | Storage topology, capacity, data placement, replication layer, backup, restore and tenant boundaries |
The service catalogue should read like an operating contract. It should tell teams what they can consume, how they request it, what they own, what the platform owns and what is explicitly not supported.
05 · Public cloud comparison
Use public cloud as a mental model, then design the private-cloud operating contract.
If you come from EKS, AKS or GKE, think of Supervisor Services as similar to managed add-ons or platform services. They make common Kubernetes platform capabilities easier to consume.
But the important point is this: in public cloud, the provider operates much of the underlying platform. In VCF, the enterprise platform team becomes the provider for its own private cloud.
So the design conversation should move from "which cloud has which add-on?" to "what service catalogue do we want to offer, and what operating contract comes with it?"
| Design question | VKS / VCF answer | Public cloud answer |
|---|---|---|
| Who provides the service? | The enterprise platform team provides approved services through Supervisor Services, VKS packages or the VCF Automation catalogue. | The cloud provider provides managed add-ons, extensions or managed adjacent services. |
| Who operates it day two? | The enterprise platform team owns lifecycle, upgrades, monitoring, backup integration and support model. | The cloud provider owns much of the platform operation; the customer still owns application configuration and usage. |
| How do teams consume it? | Through a vSphere Namespace, VKS cluster, Supervisor Service, VCF Automation catalogue, UI, CLI or API, depending on the service. | Through cloud console, CLI, APIs, managed add-ons, marketplace or cloud service catalogue. |
| What must be designed locally? | DNS, certificates, identity, network exposure, storage policy, backup target, compliance and support boundaries. | Many platform dependencies are abstracted, but the customer still configures IAM, network access, policies and service options. |
| How is governance applied? | Through enterprise guardrails: vSphere Namespace design, RBAC, quotas, approved versions, policies and operating contracts. | Through cloud IAM, resource policies, service limits, organisation policies and cloud-native governance tools. |
| What is the main takeaway? | VCF lets the enterprise become its own private-cloud provider. | Public cloud lets teams consume provider-managed services from an external provider. |
The capability may look similar, but the provider boundary is different. For VKS and VCF, your platform team is the provider. For public cloud, AWS, Azure or Google is the provider.
06 · OpenShift translation
Use OpenShift as a translation aid, not a one-to-one map.
Teams coming from OpenShift already know projects, Operators, Operator Lifecycle Manager, OpenShift GitOps and Red Hat Quay. That mental model is useful because VCF also uses Kubernetes-native patterns to expose platform capabilities. But the names and control boundaries are different, so the comparison should stay at the architecture level.
| Design question | VKS / VCF answer | OpenShift translation |
|---|---|---|
| What is the team boundary? | A vSphere Namespace is the governed boundary where platform policy, access, quotas and VKS cluster consumption are applied. | An OpenShift project is a Kubernetes namespace with OpenShift policy, access and quota controls applied for a team or application boundary. |
| How are platform capabilities packaged? | Supervisor Services are vSphere-certified Kubernetes operators and service packages installed on a Supervisor and consumed through the VCF model. | OpenShift uses Operators, OperatorHub and Operator Lifecycle Manager to install and manage Kubernetes-native applications and platform capabilities. |
| How is GitOps provided? | The Argo CD Supervisor Service provides an admin-managed GitOps capability that can be offered to teams in a scoped way. | Red Hat OpenShift GitOps is an Operator that uses Argo CD as the declarative GitOps engine. |
| What is the registry comparison? | Harbor provides the enterprise registry role in VCF/VKS designs, including projects, access control, scanning and image movement patterns. | Red Hat Quay provides the enterprise registry role in OpenShift environments, including storage, distribution, access controls, mirroring/geo-replication and governance. |
| What should not be claimed? | A Supervisor Service may use an Operator, but it is not the same thing as OpenShift OLM. A vSphere Namespace is not exactly the same as an OpenShift project. | The comparison is useful as a quick bridge, but the final design should use VCF boundaries, ownership and lifecycle rules. |
The important distinction is simple. An Operator is the Kubernetes automation pattern. A Supervisor Service is the VCF packaging, lifecycle and consumption model for a platform capability. A Supervisor Service may include an Operator, but that does not make it the same as OpenShift OLM.
07 · Production design
Installation is only the start. A service needs an operating model.
Before a Supervisor Service is offered to application teams, the platform team should define the service boundary, supported versions, dependencies, monitoring, recovery process and ownership model. That is what turns an installed component into a production service.
Service scope
Decide whether the service is platform-only, shared by many teams, restricted to regulated workloads, limited to one Supervisor, or offered across a VCF Automation project or region pattern.
Required dependencies
Capture the real prerequisites: DNS, TLS and CA trust, ingress or load balancing, storage policy, object storage, backup network, identity provider, registry access and any service-specific add-on requirement.
Lifecycle and compatibility
Define who installs and upgrades the service, which versions are approved, how compatibility is checked, and how exceptions are handled. Supervisor Services have their own lifecycle, but still need release and dependency planning.
Operations and recovery
Define monitoring, alerting, logs, backup target, restore ownership and test frequency. Keep Supervisor state, VKS workload backup, persistent volume recovery and VM Service VM protection as separate recovery conversations.
Velero is a documented path for backing up and restoring workloads on VKS clusters, including stateless and stateful workload scenarios. It should still be designed per workload: confirm persistent volume method, object store, credentials, schedules, restore steps and application consistency before calling it production-ready.
08 · Practical example
Design the service catalogue and choose the right service scope.
Payments, Risk Analytics and Reporting already have VKS clusters. They now need registry, ingress, secrets, GitOps and backup. The platform team should not treat every capability the same way. Some services can be shared, some should be scoped to a vSphere Namespace, and some belong at the VKS cluster boundary.
| Capability | Recommended scope | What it means |
|---|---|---|
| Harbor | Shared platform service | One centrally operated Harbor can serve multiple teams. Use separate projects, RBAC, quotas, robot accounts, policies and retention rules for Payments, Risk Analytics and Reporting. |
| Argo CD | Shared platform service with team-scoped instances | The platform team can provide the Argo CD Supervisor Service, while teams consume their own Argo CD instances within assigned vSphere Namespace boundaries. |
| Secret Store | Shared capability with namespace isolation | The platform owns the integration and guardrails. Each team receives only the secret access allowed by namespace permissions and enterprise secret-management policy. |
| Contour | Depends on the consumer and supported model | Contour can be required by some Supervisor Services, such as Harbor exposure. For application ingress inside VKS clusters, design the ingress pattern at the VKS workload-cluster boundary. |
| Velero | Per VKS cluster protection design | The platform can standardise the Velero package, object-store target and guardrails. Backup schedules, selected workloads, persistent volume handling and restore validation still need per-cluster or per-application decisions. |
Platform decision
The platform team defines the approved capability, deployment scope, supported versions, dependencies, lifecycle, monitoring, security baseline and recovery boundary. Shared does not mean unsegmented, and centrally governed does not mean every capability runs as one common instance.
Team decision
Each team consumes the service within its assigned boundary. Teams still own application repositories, image promotion, Argo CD applications, application secrets, ingress configuration, backup selection and restore validation.
The decision is not simply "shared or dedicated." Choose the lightest model that satisfies the required security boundary, failure domain, lifecycle, capacity and recovery objective.
09 · Knowledge check
Check the design thinking, not just the labels.
1. Which statement best explains a Supervisor Service?
2. What is the safest public-cloud comparison?
3. Which design item must be clarified before publishing Harbor as a Supervisor Service?
4. What is the correct OpenShift translation?
5. Which statement about protection is most accurate?
10 · Architecture challenge
Design the first Supervisor Services catalogue for a regulated VKS platform.
Now move from definitions to architecture. A financial services organisation has three VKS application teams and a small platform team. The organisation wants more self-service, but it also wants fewer one-off installs and clearer operational ownership.
Scenario
The platform must support these needs.
Strict image control, secrets governance, audited GitOps promotion and tested restore process.
Large images, scheduled model builds, heavy storage use and occasional restricted internet access.
Standard web applications with normal CI/CD and moderate recovery requirements.
Small team, must avoid operating separate copies of every shared tool for every application team.
- Choose which capabilities should become Supervisor Services or centrally operated platform services.
- Define what remains team-owned versus platform-owned.
- List the dependencies that must be designed before Harbor, Contour, Secret Store, Argo CD and Velero are offered.
- Decide how the service catalogue should handle stricter Payments controls without giving every team a separate copy of every service.
- Define the minimum backup, monitoring and restore test expectations.
A service catalogue is useful only when it includes boundaries. "Available" is not the same as "production-supported."
Reveal one reasonable design
Publish a small governed service catalogue: Harbor for registry, Contour where required for supported ingress exposure, Secret Store for secret injection, Argo CD for GitOps and Velero for protection. Keep the number of shared services small, but make the operating contract strong.
- Service lifecycle
- Install, upgrade, monitor and support the approved Supervisor Services and their prerequisites.
- Shared dependencies
- DNS, TLS/CA trust, ingress/load balancing, storage policy, object storage, backup network, identity and audit integration.
- Application use
- Image tags, Git repositories, application manifests, service-specific configuration and release decisions.
- Validation
- Confirm application behaviour after service upgrades and test workload-level restore where the team owns data consistency.
- Boundary
- Dedicated vSphere Namespace and stricter Harbor project, robot accounts, Argo CD promotion rules and secret access policy.
- Recovery
- Document and test registry, GitOps, secrets and workload restore before calling the pattern production-ready.
- Risk Analytics
- Provide larger registry quota, curated image availability and storage-aware backup choices.
- Reporting
- Use the baseline catalogue pattern with normal quota, retention, GitOps and restore policy.
Do not centralise everything. Centralise repeated capabilities where shared lifecycle, policy and support create value. Keep team-specific configuration close to the teams that own the applications.
11 · Key takeaways
Build a governed platform service layer, not a pile of add-ons.
- A VKS cluster is the runtime. Supervisor Services help turn the runtime into a fuller developer platform.
- A Supervisor Service is a VCF packaging, lifecycle and consumption model for a platform capability. It is not simply another name for a Kubernetes Operator.
- Use Supervisor Services when a capability is repeated, supported and worth governing centrally. Do not install every possible service by default.
- Harbor, Contour, Secret Store, Argo CD, cert-manager, ExternalDNS, Velero and stateful services each bring dependencies. Self-service does not remove design work.
- The public-cloud comparison is useful when it explains the provider boundary: in VCF, the enterprise platform team becomes the provider for its own private cloud.
- For teams familiar with OpenShift, compare product roles and lifecycle models separately. Harbor maps reasonably to Quay as an enterprise registry role; Supervisor Services do not equal OpenShift OLM.
- Protection design must separate Supervisor state, VKS cluster nodes, VKS workloads and VM Service VMs. One backup mechanism does not answer every recovery question.