OpenShift Installation Guide for Production-Ready Clusters

OpenShift supports three broad installation postures. Installer-provisioned infrastructure (IPI) lets openshift-install create VPCs, machines, and load balancers on supported clouds (AWS, Azure, GCP) or vSphere when you supply adequate permissions. User-provisioned infrastructure (UPI) assumes you provision VMs, DNS records, and load balancers yourself; the installer only lays down the control plane and workers. Agent-based installation targets bare metal and disconnected environments where PXE or cloud APIs are unavailable — agents boot from ISO, discover hardware, and join an assisted-service workflow.

For regulated enterprises in India and the Gulf, UPI and agent-based paths dominate because networking, firewall, and storage teams retain control of every hop. IPI accelerates time-to-cluster in ROSA or public-cloud landing zones where IAM roles and pre-approved VPC templates already exist. The wrong choice is usually obvious: if your security team will not grant the installer cloud-admin rights, IPI is off the table regardless of how fast it looks on a slide.

Managed offerings — ROSA, Azure Red Hat OpenShift (ARO), and OpenShift Dedicated — outsource control-plane lifecycle while you still own worker pools, namespaces, and RBAC. They are not shortcuts around architecture review; you still need private-link design, egress controls, and identity federation identical to self-managed OCP. Map each workload class (stateful, GPU, Windows containers) to a model before procurement, not after the purchase order is signed.

Hybrid topologies mixing on-prem UPI control planes with cloud burst workers multiply operational complexity — document network latency between API server and kubelets, and label machine config pools so OS updates do not drain an entire region simultaneously. Proof-of-concept clusters should mirror production topology even when scaled down; a three-node all-in-one lab will not surface etcd or ingress bottlenecks visible at production scale.

The install-config.yaml is the contract between your architecture and openshift-install. Key fields — compute and control-plane replicas, networking CIDRs, platform credentials, and pullSecret — must match what network and IAM teams approved. For UPI, machine manifests and static pod definitions generated by openshift-install create cluster are applied after bootstrap; keep them in Git with the same rigor as application manifests.

Network mode matters for the entire cluster lifetime. OVN-Kubernetes is the default CNI on modern OCP; configure join/subnet CIDRs that do not overlap with corporate LANs, pod networks on peered clusters, or VPN ranges. Enable network policies on day 0; retro-fitting segmentation after hundreds of namespaces exist is painful. For vSphere UPI, specify the correct platform fields (vCenter, datacenter, datastore, resource pool) — a typo here produces machines in the wrong VLAN with no obvious installer error until kubelet registration fails.

Post-install, the Cluster Version Operator (CVO) owns channel and upgrade graph alignment. Pin to a stable-4.x channel matching your support contract; document the desired initial version in change records. Enable the insights operator for remote health reporting if policy allows — it surfaces certificate expiry and etcd alarm conditions early. Capture the kubeadmin password rotation plan immediately; integrate cluster-admin access with your corporate IdP via OAuth LDAP or OIDC connectors before developers receive kubeconfig files.

Machine config pools separate control-plane, general worker, and infra nodes — define them in install-config when you know ingress, monitoring, and registry components will land on dedicated nodes. Infra nodes carry router and registry pods; starving them on undersized VMs produces ingress latency under moderate RPS. Record install-config.yaml and generated manifests in version control with secrets redacted via sealed patterns or external vault references.

A successful install ends with a repeatable validation suite, not a green check on the console. Run openshift-install wait-for install-complete, then verify all cluster operators report Available: oc get clusteroperators. Confirm DNS resolution from a corporate workstation matches in-cluster service discovery. Deploy a sample application with a route, persistent volume, and network policy — if any step fails, fix platform gaps before onboarding product teams.

Backup etcd on day 1 even if disaster recovery is phase two. Schedule automated etcd snapshots to object storage with encryption at rest, and test restore on a non-production lab quarterly. Capture must-gather archives after install for baseline support cases: oc adm must-gather. Label nodes with topology labels (region, zone, rack) that match your failure-domain strategy for pod anti-affinity and storage replication.

Handover documentation should include cluster ID, ingress domains, identity provider configuration, storage class matrix, upgrade channel, and support escalation paths to Red Hat TAM or a qualified partner. Platform engineering teams use this OpenShift installation guide as the first chapter; the next chapters are upgrade planning, GitOps bootstrap, and observability — all of which assume a cluster built to these standards.

Run a controlled failure injection before sign-off: cordon and drain a worker, verify pods reschedule; simulate DNS outage for external dependencies and confirm application degradation matches SLO expectations. Capture baseline Prometheus metrics for API latency, etcd disk fsync, and ingress connection counts — future incidents compare against this golden week-one snapshot.