A Harbor install sat in Configuring for forty one minutes on a Supervisor I had activated the week before, and vCenter offered no reason at all. Three underscores in a storage class name, pasted straight out of a vSphere Client field into a data values file, were the entire story. That is the shape of objective 4.4 in practice: almost nothing goes wrong in the install wizard, and almost everything goes wrong in the Supervisor objects the wizard quietly depends on.

Add-on delivery models on a Supervisor

Read the objective wording again and notice that it groups Harbor and external-dns as if they were siblings. On VCF 9.0 they are not. Harbor is a Supervisor Service, downloaded as a pair of YAML files, registered against vCenter and installed onto a named Supervisor by a vSphere administrator holding the Manage Supervisor Services privilege. External-dns ships in the VKS standard package catalogue and is installed by a cluster owner, inside a workload cluster, against that cluster API. Nothing about the second workflow touches Supervisor Management in the vSphere Client. Candidates who study only the Harbor path answer half of this objective.

A third category matters as much and gets studied least. Core Supervisor Services have their operators installed automatically when you activate the Supervisor, and Broadcom names VKS itself and the Velero vSphere Operator as examples. You can add and upgrade their versions without touching the Supervisor version, which is why a VKS release bump does not require a Supervisor upgrade, but you cannot remove their operators from the platform. Any exam item that asks you to uninstall VKS from a Supervisor is asking a question with no correct answer, so read those stems carefully for what they really mean, which is deactivating or uninstalling a service version.

Preflight for the Harbor Supervisor Service

Last Part we deployed workloads two ways on this estate, as vSphere Pods and through VM Service. Harbor is the same vSphere Pod machinery wearing a product name, which is exactly why its prerequisites are Supervisor prerequisites rather than Harbor prerequisites. Four checks decide whether the install can succeed, and all four are visible from a kubectl session against the Supervisor before you open the wizard. I run them in this order every time because each one has caught me at least once.

Three signals matter in that output. Storage class names are already lower case and hyphenated, which is how Kubernetes renders a storage policy called VKS High Performance; you must write them that way in the data values file, not the way vCenter displays them. Envoy holds a real external address, so Contour is live and Harbor can hang an HTTPProxy off it. And ESX hosts appear as agent nodes, which only happens on an NSX backed Supervisor, so vSphere Pods can schedule. On a Supervisor activated with vSphere Distributed Switch that last line is simply absent, and the Harbor install will create its namespace, report Configuring, and never finish. Nothing in the vSphere Client will tell you why, which is the Supervisor decision from Part 6 reaching forward to bite you weeks later.

Harbor installation procedure

Step one, download two files. From the vSphere Supervisor Services page on the Broadcom support portal you get harbor-service-x.xx.x.yml, which is the service definition telling the Supervisor how the service is structured and which versions it is compatible with, and harbor-data-values-x.xx.x.yml, which carries your system level parameters. Broadcom also publishes the wider catalogue of service YAML files at the vSphere TMM Supervisor Services site, which is worth bookmarking because it is where new services appear first.

Step two, register the service. In Supervisor Management, Services, choose Add New Service and upload the service definition file. Registration is a vCenter level action and installs nothing; the service lands in Active state and now appears as a card. Step three, edit the data values file. Step four, on the Harbor card choose Actions, Manage Service, pick the version and the target Supervisor, paste the edited data values into YAML Service Config and finish. Only one version can be installed per Supervisor, so choosing a version here is also choosing to replace whatever is there.

Five fields in that file cause most of the pain. Storage class names must be transformed from the policy name by lower casing every character and replacing underscores and spaces with hyphens, and nothing validates this until a PersistentVolumeClaim goes Pending. SecretKey is exactly sixteen characters and xsrfKey is exactly thirty two, and a length mismatch fails the pods rather than the wizard. IpFamilies stays IPv4 because IPv6 is unsupported. TlsSecretLabels must stay as shipped, because that label is how the vRegistry integration finds Harbor and wires trust into VKS clusters; teams that replace it with something tidier get a Harbor that works perfectly from a laptop and cannot be pulled from by any cluster. And the two exposure switches are a pair, not one setting, so an admin who sets enableNginxLoadBalancer true without setting enableContourHttpProxy false gets both paths half configured. Total baseline storage across those five claims is eighteen gibibytes before a single image is pushed, which is worth knowing when a namespace quota is tight.

flowchart TD
  A[Download service and data values YAML] --> B[Add service to vCenter]
  B --> C[Version state Active]
  C --> D[Install one version on a Supervisor]
  D --> E[Service vSphere Namespace created automatically]
  E --> F[Upgrade by adding a newer version then installing it]
  F --> D
  C --> G[Deactivate version]
  D --> H[Uninstall version from every Supervisor]
  G --> H
  H --> I[Delete version from vCenter]
  I --> J[Delete entire service]

External-dns inside a VKS cluster

Popular study advice says to treat the two named services in objective 4.4 as one workflow. That advice is wrong, and the exam knows it. On VCF 9.0 external-dns is documented in the VKS standard package reference, installed into a workload cluster, and validated against three provider families: AWS Route 53, Azure DNS, and RFC2136 compliant servers such as BIND. Our lab estate uses the RFC2136 path against an internal BIND instance, which is also the only one of the three you can practise without a public cloud account.

Pin the version from your own package catalogue rather than copying one, because standard package versions track the Kubernetes release the cluster is running and a stale pin is the fastest way to a reconcile failure. Two operational notes are worth carrying into production. TXT owner identity must be unique per cluster or two clusters will fight over the same records and flap them, and the TSIG key is a secret that belongs in a Kubernetes Secret rather than in the values file you keep in git. For the wider DNS and ingress design that sits above this, Part 13 already covered the ingress and egress choices this controller writes records for.

Verification, uninstall order and failure signatures

Green looks like a service namespace you did not create, full of running vSphere Pods, plus a resolvable FQDN. Installation creates that namespace automatically, one per Supervisor Service, and you manage the service resources from it.

Here is what my forty one minute failure actually looked like. Pods sat Pending, no events surfaced in the vSphere Client, and only a describe against the claim named the cause.

Backing out is where candidates lose marks, because uninstall and delete are different operations with different blast radii and vCenter enforces an order between them. Uninstalling a version from a Supervisor removes every service resource including that service namespace, yet application instances already running in Kubernetes workloads keep running. Upgrading is not additive either: any resource specified by the old version and absent from the new one is deleted, so a pod A in version one becomes a pod B in version two and pod A goes away. Keep this table next to you, because it is the artifact this Part exists to produce.

Exam focus for objective 4.4

Objective checkpoint

Add-on service call for this estate

My recommendation is unfashionable: install Contour first and accept the default Contour ingress path for Harbor, even on an estate that already runs NSX Advanced Load Balancer for everything else. I did the opposite on my first build, reasoning that one load balancer for the whole platform was tidier, and spent an afternoon discovering that the NGINX path needs two data values flipped together rather than one, that the resulting external address needs its own DNS record anyway, and that the Harbor documentation assumes Contour in every subsequent troubleshooting step. Reverting to Contour took eleven minutes. Tidiness cost me roughly four hours and bought nothing, because Harbor is the only consumer of that ingress path.

A clean result on this estate looks like five things. One service namespace per installed Supervisor Service that you never created by hand. Seven Harbor vSphere Pods Running and five claims Bound against normalised storage class names. An FQDN that resolves to the Envoy address and returns HTTP 200 on the system info endpoint. Shipped tlsSecretLabels untouched, proven by a VKS cluster pulling an image without an insecure flag. And external-dns reconciled inside the workload cluster with a unique TXT owner identity, writing records into the zone you delegated to it.

Tonight, do one thing in your own lab: install a Supervisor Service, then try to delete it in the wrong order and read the exact refusal vCenter gives you. That refusal message is worth more than any flashcard on this objective. If Harbor itself is new ground, the Harbor series covers projects, robot accounts and replication properly, and the VKS series walks the product underneath this exam without the exam framing. Part 20 moves from platform services to the clusters themselves, provisioning and scaling VKS clusters with kubectl and the VCF CLI.

References

• Supervisor Services Life Cycle Management and Consumption, vSphere Supervisor 9.0, Broadcom TechDocs
• Install Harbor as a Supervisor Service, vSphere Supervisor 9.0, Broadcom TechDocs
• ExternalDNS Package Reference, VKS Standard Packages, Broadcom TechDocs
• Supervisor Services catalogue and service YAML downloads

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts