01 · The missing layer
Kubernetes runtimes are necessary, but they are not the whole developer platform.
A team can receive a healthy VKS cluster and still be blocked. Where do approved images come from? Who provides ingress and TLS? How are secrets delivered? Who owns the GitOps controller, or a shared data capability, and how is it upgraded safely?
Those are not application-only questions. They are platform-product decisions. Leaving every team to install its own solution creates inconsistent versions, duplicated operational work and unclear security ownership.
02 · The platform mental model
A Supervisor Service is centrally managed, but consumption does not have one universal scope.
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 wing. A Supervisor Service is a building capability made available through that floor.
Technical meaning: a Supervisor Service is a Kubernetes-native extension packaged for installation and lifecycle management on a Supervisor. A Cloud Admin adds and manages the service. Depending on the service, cloud users can consume it in their assigned vSphere Namespaces.
03 · Do not confuse the layers
Cluster add-ons, Operators and Supervisor Services solve different problems at different scopes.
| Concept | Primary scope | Who normally operates it? | Example |
|---|---|---|---|
| VKS cluster | A Kubernetes runtime for workloads | Platform team provides it; cluster/app teams use it | A production payments cluster |
| Cluster package or add-on | One VKS cluster | Cluster administrator | Contour or Velero installed/configured for that cluster |
| Kubernetes Operator | A cluster extension and its managed resources | Cluster or platform administrator | An Operator reconciling a database or GitOps application |
| Supervisor Service | VCF platform capability, installed on a Supervisor | Cloud Admin / platform team | Harbor, Argo CD Operator, Secret Store or a supported stateful service |
04 · A useful OpenShift comparison
OpenShift Operators and Supervisor Services are related, not equivalents.
| Question | OpenShift Operator | VCF Supervisor Service |
|---|---|---|
| What is it? | A Kubernetes-native controller, commonly with CRDs, that manages an application or extension. | A VCF-packaged platform capability installed and lifecycle-managed on a Supervisor. |
| Lifecycle context | Managed in the OpenShift cluster, commonly through Operator Lifecycle Manager. | Managed centrally through the Supervisor using vCenter or supported CLI workflows. |
| Consumption model | Users create or use the Operator’s resources according to its RBAC and scope. | Cloud users consume the published service within approved vSphere Namespaces when the service supports self-service. |
| Best concrete example | An Operator runs and reconciles an application. | The Argo CD Supervisor Service packages an Argo CD Operator: the admin installs it once, then teams create namespace-scoped Argo CD instances. |
The useful translation for an OpenShift practitioner is this: an Operator is the automation specialist; a Supervisor Service is the platform team’s governed way to deliver that capability to consumers.
05 · From artifact to consumption
The platform team owns the service lifecycle before an application team can consume it.
This is deliberate centralisation of platform lifecycle. It does not remove Kubernetes self-service; it moves the choice of which platform capabilities are supported, patched and governed to the platform team.
Lifecycle is a design input, not a post-install task
Before publishing a service, decide its owner, support window, upgrade path, rollback approach, capacity model, storage dependency, network exposure, DNS and certificate model, backup expectations, security review and chargeback or quota model. A successful installation alone is not a service offering.
06 · Choose services by the outcome they provide
Start with a repeated team need, then choose the right delivery scope.
Image delivery · Harbor
Use when multiple teams need an enterprise registry with policy, scanning, signing or replication. It has real storage, DNS, TLS, networking and operational dependencies, so treat it as a platform service, not a quick Helm chart.
GitOps · Argo CD
Use when teams need repeatable, Git-driven delivery across VKS and related workloads. The Supervisor Service can be centrally installed while team-specific Argo CD instances are scoped to approved vSphere Namespaces.
Secrets · Secret Store
Use when applications need controlled delivery of external secrets. The service does not replace the organisation’s secret-management policy; it connects workloads to it.
Ingress and protection
Do not assume every capability belongs at Supervisor scope. Contour and Velero-related patterns may be deployed or configured at the VKS cluster boundary, depending on the workload and supported delivery model.
| Ask first | Why it matters |
|---|---|
| Is the need common across teams? | Central delivery is strongest when it removes repeated work and creates a consistent guardrail. |
| Is the capability platform-wide, namespace-scoped or per cluster? | The delivery scope should follow the architecture requirement rather than forcing every capability into one model. |
| What must exist first? | Harbor, for example, needs a deliberate exposure, storage, TLS and DNS design. Do not hide dependencies behind a “one-click” expectation. |
| Who supports it at 2 a.m.? | That owner needs health, capacity, incident and upgrade procedures before the service is offered. |
07 · Responsibility boundary
Platform teams standardise the service. Application teams use the service within its guardrails.
| Area | Platform / Cloud Admin | Application or cluster team |
|---|---|---|
| Service selection | Defines approved services, versions, deployment scope and support policy. | Explains the workload outcome and adopts the approved service. |
| Installation and upgrade | Installs and lifecycle-manages Supervisor Services and standardises approved cluster packages. | Plans compatible application changes and validates consumption after upgrades. |
| Namespace governance | Controls namespace access, quota and service availability. | Uses only granted namespaces and permissions. |
| Application configuration | Publishes patterns, endpoints and guardrails. | Creates projects, repositories, application resources, policies and workload-specific configuration. |
| Protection | Defines platform backup capability and recovery boundaries. | Owns workload-level backup policy, restore testing and data consistency requirements. |
08 · Practical example
Design the service catalogue and decide where each service runs.
Payments, Risk Analytics and Reporting already have VKS clusters. They now need registry, ingress, secrets, GitOps and backup. The platform team should not simply publish five tools and assume they all have the same scope. It must decide whether each capability is shared across teams, namespace-scoped, or deployed/configured separately for each VKS cluster.
| Capability | Design model | What it means |
|---|---|---|
| Harbor | Shared platform service | One centrally operated Harbor can serve all three teams. Give Payments, Risk Analytics and Reporting separate projects, RBAC, quotas, credentials and policies. A separate Harbor is justified only when a distinct security, availability, lifecycle or recovery boundary requires it. |
| Argo CD | Shared service + dedicated instances | The platform team installs the Argo CD Supervisor Service/operator centrally. Each team can then have its own Argo CD instance inside its assigned vSphere Namespace. |
| Secret Store | Shared capability + isolation | The platform capability is governed centrally while secret access remains separated by namespace permissions and the organisation’s external secret-management policy. |
| Contour | Per VKS cluster | For applications running inside VKS clusters, ingress is designed for the workload-cluster boundary. Do not assume a Supervisor-level Contour deployment is inherited by every VKS cluster. |
| Velero | Per VKS cluster protection | The platform team can standardise the supported package, object-storage pattern and guardrails, while backup schedules, protected workloads and restore validation are defined for each VKS cluster/application boundary. |
Platform decision
The platform team defines both the approved capability and its deployment scope. It owns supported versions, dependencies, lifecycle, security standards and service availability. Shared does not mean unsegmented, and centrally governed does not mean every capability runs as one common instance.
Team decision
Each team consumes the platform standard within its assigned boundaries. Teams own their Harbor repositories, Argo CD applications, application secrets, ingress configuration, backup schedules and restore validation without becoming operators of every underlying platform service.
09 · Knowledge check
Check the mental model before you design the catalogue.
1. Which statement is most accurate?
2. Who normally installs and lifecycle-manages a Supervisor Service?
3. Before Harbor is treated as a production service, what should be designed?
4. After the Argo CD Supervisor Service is installed, where can a team-specific Argo CD instance be scoped?
5. Which is the strongest reason to centralise a capability as a service?
10 · Architecture challenge
Shared, namespace-scoped or per cluster?
Your organisation has three VKS teams. Payments runs regulated workloads and requires strong isolation plus tested recovery. Risk Analytics has high image volume and frequent deployments. Reporting has standard availability and security requirements. All three teams require Harbor, Argo CD, Secret Store, Contour and Velero.
Decide
- Which capabilities should be shared across teams?
- Which should create a dedicated instance in each team’s vSphere Namespace?
- Which belong at the VKS cluster boundary?
- Does Payments require a separate copy of any service, or can stronger policy and recovery controls satisfy the requirement?
- What evidence would justify moving from a shared model to a dedicated service instance?
Design principle
Do not start by asking, “Can this be shared?” Start with the required security boundary, failure domain, lifecycle, capacity and recovery objective. Then choose the lightest operating model that still meets those requirements.
One reasonable design
| Capability | Placement |
|---|---|
| Harbor | Shared centrally operated service with separate projects, RBAC, quota, credentials and policies per team. |
| Argo CD Supervisor Service / operator | Installed centrally on the Supervisor. |
| Argo CD instance | Dedicated per team in its assigned vSphere Namespace. |
| Secret Store | Shared platform capability with namespace-level access isolation and explicit external secret-store policy. |
| Contour for VKS applications | Designed/deployed per VKS cluster where ingress is required. |
| Velero workload protection | Configured per VKS cluster, with platform-standardised package, storage target and policy guardrails. |
Payments does not automatically need a separate copy of every platform service. Start with the same governed catalogue but apply stronger namespace access, Harbor policies, secret controls, backup requirements and restore testing. Introduce a separate service instance only when Payments requires a distinct security boundary, failure domain, lifecycle, capacity model or recovery objective that cannot be met safely by the shared service.
11 · Key takeaways
Build a service catalogue, not a pile of Kubernetes installs.
- A VKS cluster is a runtime; a developer platform also needs governed platform capabilities.
- A Supervisor Service is a VCF platform delivery and lifecycle model, not a synonym for an Operator.
- Supervisor Service does not automatically mean one shared runtime instance for all consumers.
- The Argo CD Supervisor Service is a useful example: the platform installs the capability centrally and teams can create namespace-scoped instances.
- Some capabilities belong at the VKS cluster boundary rather than Supervisor scope.
- Keep platform lifecycle ownership separate from application-level configuration ownership.
- Harbor, GitOps, secrets, ingress and protection each bring dependencies. Simplified deployment does not remove design work.
- For OpenShift practitioners: use familiar concepts to understand the role, then return to VCF terms for the actual design and operating model.
Sources reviewed
- VMware Cloud Foundation 9.1 documentation
- Install a Supervisor Service on Supervisors
- Local Consumption Interface
- GitOps for VCF: Broadcom Argo CD Operator Now Available
- Reducing Harbor Deployment Complexity on Kubernetes
- OpenShift Operator Lifecycle Manager documentation
Version-validation date: 2 September 2026 · Last-reviewed date: 2 September 2026