OpenShift UPI prerequisites: DNS, VIPs, NTP and firewall checklist

A user-provisioned infrastructure (UPI) install of Red Hat OpenShift Container Platform gives you full control, and also full responsibility. The installer does not create your virtual machines, DNS records, load balancers or storage mappings. If any of those are wrong, the install usually fails late, at the bootstrap or CSR stage, and the symptoms are hard to read.

This checklist is the work we do before generating a single ignition file. It is a planning example for an OpenShift 4 user-provisioned installation with platform: none, not a release-independent specification. Select an exact supported OpenShift release and infrastructure path first, then use that release's installation, networking and load-balancing requirements as authoritative.

The procedures were validated for the documented OpenShift 4 UPI architecture, not every OpenShift 4 release, network type or infrastructure provider. Revalidate the complete matrix and commands against the release documentation before a new install, a version-family change, a network-plugin change or a material topology change. Record the selected release, documentation revision, rule owner, approval and rollback owner in the change record.

1. Fix the inputs first#

Write these down and get an owner to sign off on each one.

2. Example addressing plan#

The values below are placeholders for documentation. Use your own ranges, and keep the pod and service networks from overlapping anything routable in your enterprise.

Network ranges:

machineNetwork:  10.42.0.0/16        # must contain every node IP
clusterNetwork:  10.128.0.0/14       # pod network, hostPrefix 23 (default)
serviceNetwork:  172.30.0.0/16       # cluster service IPs (default)

If your enterprise already routes 10.128.0.0/14 or 172.30.0.0/16, change them now. They cannot be changed after install.

3. DNS records#

Create these in the authoritative DNS used by the node VLANs before booting any node.

Create node PTR records when required by the selected installation method and ensure each node gets the intended stable hostname. Do not rely on reverse DNS as the only hostname control without checking the release-specific RHCOS networking procedure.

Validate from the bastion and from at least one host in the node VLAN:

dig +short api.ocp-prod.example.com
dig +short api-int.ocp-prod.example.com
dig +short test.apps.ocp-prod.example.com
dig +short -x 10.42.20.11

For preparation only, you can add entries to /etc/hosts on the bastion. Do not use that as a substitute for real DNS on the nodes.

4. Time synchronisation#

Check on the bastion:

chronyc sources -v
chronyc tracking

If your NTP servers are not reachable from the node VLAN, fix that now. You can also push a chrony.conf to every node with a MachineConfig at install time (see the install walkthrough linked below).

5. Firewall matrix#

Only create rules where a firewall actually sits in the path. Same-VLAN traffic with no filtering needs no rule.

This table is illustrative, not a firewall specification. Required ports, directions, protocols, registry endpoints and whether the load balancer or nodes initiate each flow change with release, network plugin and enabled Operators. Build the final matrix from Red Hat's documentation for the selected release and platform, including DNS responses, proxy/mirror endpoints, load-balancer return paths, egress for enabled Operators, IPsec/ESP if used and infrastructure-provider requirements. Do not expose api-int or port 22623 to untrusted networks.

Test every permitted leg from its real source zone before ignition generation; a bastion-only test is insufficient. Capture a denied-flow baseline, then verify DNS, NTP, registry, API-VIP, MCS-VIP and ingress-VIP paths with firewall logging during the change. Roll back newly added rules if they expose a broader source or destination than approved; never work around a failed test by disabling the firewall.

6. Registry and proxy access#

Nodes need to reach the Red Hat and Quay registries unless you run a full disconnected mirror. Test from the bastion and from the node VLAN:

curl -I https://registry.redhat.io
curl -I https://quay.io

If you use an HTTP proxy, put the proxy and a correct noProxy list in install-config.yaml. The noProxy list must include the machine network, cluster network, service network and your cluster domain. When you test ignition URLs from the bastion, use curl --noproxy '*' so the proxy does not hide the real result.

7. Mistakes that cost a day#

• Reusing a VIP that is already live on another host.
• Uncontrolled node hostnames. Missing or inconsistent DHCP, static-network or DNS inputs can produce unexpected names and CSR confusion.
• Overlapping pod or service networks with a routed enterprise range.
• Booting nodes early. Ignition runs on first boot; a bad URL or an old file can force a reinstall.
• Dummy pull secret in a generated install. Generate assets only after the real pull secret is in place.

What to do next#

Once every row above is green, move on to the load balancer: HAProxy and Keepalived for OpenShift UPI, then the install walkthrough.

Examples use documentation-only names and addresses. Verify ports and procedures against the Red Hat documentation for your exact OpenShift version.

Need senior engineers for an OpenShift build or review? See Kubernetes and OpenShift or start a project.