VMware Kubernetes Service on VCF 9 does not get simpler because the site cannot reach the internet. It gets more specific. The install still needs container images, a registry certificate, and the OS packages that pull those images. An air-gapped site has to have decided, before the first command, which machine those bits are sitting on.
The Challenge
The failure mode is a half-written inventory. Someone copies a connected-site example, points it at a registry name that does not resolve, and spends a day deciding whether the problem is DNS, the certificate, or the package mirror. It is usually all three, because the example assumed a path the site does not have.
Air-gapped delivery is not one pattern. We have had to support three, and they are not interchangeable:
- A local Nexus raw repository, with basic authentication, an identity-management certificate, and a local package mirror for the container engine packages.
- A transfer disk mounted on the registry host, with the certificate and the RPMs staged on that same host.
- A transfer disk mounted on the control host instead, with the certificate still coming from identity management and the RPMs staged beside the transfer.
Pick the wrong example and the install looks broken when the only mistake was the arrival path.
What We Ship With the Kit
Each path is a complete inventory, not a snippet. The operator copies the matching example into place, replaces the site values, and does not merge two examples because one file looked shorter. The certificate source and the package source move together. A Nexus pull with a staged RPM set, or a transfer disk with a certificate that still has to be fetched from identity management on a host that cannot reach it, is how these installs stall.
The example inventory ships with an empty vault template. The site fills that file locally. Nothing in the example is a value a disconnected environment would regret committing.
That is the whole method. There is no universal air-gap playbook, because “air-gapped” only describes what the site cannot reach. It does not describe where the bits are. The install doc has to ask that question on the first page.
What to Ask on the First Page
Before anyone edits YAML, write down three answers. Where do the artifacts come from? Where does the registry certificate come from? Where do the container-engine packages come from? If those three answers are not the same row in the table above, stop and pick the row that matches the site. Do not average them.
Then copy one example inventory and replace values. Do not start from the connected-site install and delete the URLs that fail. The deletions are how a required mirror becomes an implicit assumption.
This sits next to the Aria 8 to VCF Automation 9 migration work only in the sense that both are VCF 9 operations. The air-gap problem is not a migration problem. It is a logistics problem that the installer will not name for you.
What 9.1.1 Documents
The three inventories above are how a kit arrives when the site is already living with a local registry. They are not the path VCF 9.1.1 documents for a new disconnected deployment. From 9.1.1, a bastion host downloads the VKr images, the VCF CLI and its plugins, the Supervisor service artifacts, and the VKS add-ons with the VCF Download Tool. An admin host inside the site uploads them to Software Depot. The depot FQDN is the Fleet Software Depot component under Build, Lifecycle, VCF Management, Components. The Supervisor is enabled after the VKr images are in the depot, so enablement can create the subscribed content library. A site that already has one does not get a second library pointed at the depot. Releases before 9.1.0 still need an external OCI-compliant registry, which is why an older kit and the 9.1.1 procedure cannot be merged into one example.
The Results
The install stops failing for the wrong reason. The operator picks one arrival path, copies that inventory, and replaces site values. Certificate source and package source move together. On 9.1.1 and later, a new disconnected site does not use those older inventories at all. It uses the VCF Download Tool and Software Depot.
Lessons Learned
Air-gapped is not a design. It is a constraint. The design is where the bits are. Merging two example inventories because one file looked shorter is how a required mirror becomes an assumption. Mixing a pre-9.1.0 external registry with the 9.1.1 depot procedure is the same mistake in a newer costume.
Getting Started
Run it beside this. The example inventory already names registry01.example.coach. Change that name to yours before the second playbook. The first playbook stages bits on a host that can reach the repository. The second runs on the registry host.
ansible-playbook -i examples/nexus/hosts playbooks/linux/stage_harbor_artifacts.yml
ansible-playbook -i examples/nexus/hosts playbooks/linux/configure_registry.yml
ansible-playbook -i examples/nexus/hosts playbooks/linux/verify_registry.ymlThe roles, the three playbooks, and the example inventories are in the repository. Copy one example. Do not merge two. Fill the vault file locally. Run stage_harbor_artifacts.yml on the connected side, then configure_registry.yml on the registry host, then verify_registry.yml.
Write down three answers before you edit YAML. Where do the artifacts come from? Where does the registry certificate come from? Where do the container-engine packages come from? If the site is VCF or vSphere Foundation 9.1.1 or later and it is a new disconnected deployment, follow the documented depot path instead of the three field inventories. A site that already has a VKr content library does not get a second one pointed at the depot.
Conclusion
The installer will not name the logistics problem for you. Ask where the bits are on the first page, pick one path, and do not average it with another generation of the product.
The Ansible overlay that stands the disconnected registry up is in the repository. It is a drop-in for the automation repo: stage the bits, install Harbor offline, configure TLS and projects, verify. The example inventories are Nexus, a transfer disk on the registry host, a transfer disk on the control host, and Artifactory. Pick the one that matches where the bits actually are.
Repository: github.com/noahfarshad/harbor-registry-overlay
Related Stories:
- When Regional Harbor Sticks, VKS Stops — the registry VKS fails closed on, after the kit has arrived
- ansible-automation — the role repo this overlay drops into
- Idempotent Windows Post-Deploy — the post-deploy roles that run after a VM exists
References
Deploy VKS in Air-Gapped Environments with VCF 9.1.1 and Later is the procedure for that depot path. The index page points 9.1.0 at its own guide and says earlier releases need an external registry: Deploying VKS in Air-Gapped Environments. What Software Depot is, including the one depot assigned to an instance, is in Binary Management for VMware Cloud Foundation.