A GitOps pattern for OpenShift hosted control planes on bare metal

A new Red Hat Developer guide turns hosted control planes on bare metal into a declarative fleet pattern. The design runs control planes as pods on a central management cluster, provisions worker nodes as OpenShift Virtualization virtual machines and uses Git as the interface for creating or changing each hosted cluster.

The useful part is not simply that HyperShift can separate control planes from workers. The guide shows how OpenShift GitOps and Advanced Cluster Management can make that topology repeatable—and where bare-metal networking, storage and deletion safety still need deliberate platform decisions.

Four layers in the management cluster

The management cluster hosts OpenShift Virtualization, Advanced Cluster Management and OpenShift GitOps. HyperShift control-plane components run in dedicated namespaces there, while KubeVirt-backed worker VMs attach to the hosted cluster.

Red Hat’s repository layout separates the workflow into three directories: Argo CD bootstrap resources under gitops, reusable Helm templates under helm, and one small values file per hosted cluster under clusters. An ApplicationSet Git file generator watches those cluster files and renders a separate Argo CD Application from the shared chart.

That makes a cluster definition the data layer rather than another copied manifest tree. Operators set the OpenShift version, worker count, compute, storage class, network ranges, VLAN and proxy values in one file; GitOps renders the HostedCluster, NodePool and Advanced Cluster Management registration resources.

Bare metal makes the prerequisites part of the design

The pattern assumes three network paths: management traffic, a dedicated high-speed live-migration network and VLAN-backed hosted-cluster traffic. Because the worker VMs bypass the default pod network, they need Multus network attachments and external DHCP. MetalLB supplies the external address for the hosted control-plane API where no cloud load balancer exists.

Storage must support ReadWriteMany if worker VMs are to move between physical nodes. Red Hat names OpenShift Data Foundation as one option and says a certified CSI driver can be used if it provides the required capabilities.

Proxy settings also need special treatment. The hosted control-plane pods physically run on the management cluster, so noProxy must include both hosted-cluster ranges and the management cluster’s machine, cluster and service networks plus its API domain. Missing those ranges can send internal control-plane traffic through the corporate proxy and break cluster communication.

Guardrails belong in the GitOps objects

Red Hat’s ApplicationSet example enables self-healing but sets prune: false to prevent removal of a cluster definition from automatically deleting the cluster. Secrets are also kept out of Git; the guide recommends injecting pull secrets and SSH keys through an external-secrets mechanism in production.

The sample NodePool uses replacement upgrades, which recreate workers during a hosted-cluster update. Platform teams that need in-place upgrades can select that behavior instead, but should make the choice explicit in the template.

The operational payoff is a narrow service interface: add or edit one values file, let Argo CD render the infrastructure and monitor the resulting control plane, worker VMs and Advanced Cluster Management registration. The pattern is most useful to teams that already operate a capable bare-metal management cluster and want cluster provisioning to behave like reviewed application delivery rather than a sequence of administrator commands.