{"id":12112,"date":"2025-04-15T14:18:54","date_gmt":"2025-04-15T14:18:54","guid":{"rendered":"https:\/\/www.scmgalaxy.com\/tutorials\/?p=12112"},"modified":"2025-04-15T14:18:56","modified_gmt":"2025-04-15T14:18:56","slug":"installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide","status":"publish","type":"post","link":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/","title":{"rendered":"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide"},"content":{"rendered":"\n<h1 class=\"wp-block-heading\"><\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">I. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">A. Overview of OKD<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">OKD, formerly known as OpenShift Origin, stands as the community distribution of Kubernetes, serving as the upstream foundation for Red Hat&#8217;s OpenShift Container Platform (OCP).<sup>1<\/sup> It embodies an open-source collection of software components and design patterns optimized for continuous application development and multi-tenant deployment at scale.<sup>1<\/sup> As the community-driven counterpart to OCP, OKD typically incorporates newer features and updates earlier, acting as a proving ground for technologies before they potentially enter the enterprise product.<sup>3<\/sup><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A key distinction lies in the underlying operating system and support model. OKD utilizes Fedora CoreOS (FCOS) as its immutable host operating system, particularly for control plane nodes.<sup>4<\/sup> Unlike OCP, OKD does not come with commercial support from Red Hat or access to the full suite of Red Hat certified operators and middleware available through a subscription.<sup>3<\/sup> Support relies on community channels like forums, mailing lists, and issue trackers.<sup>1<\/sup><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">B. User-Provisioned Infrastructure (UPI) Installation<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">OKD offers flexibility in its installation methods. This guide focuses on the User-Provisioned Infrastructure (UPI) approach, sometimes referred to as a &#8220;Full Control&#8221; installation or using <code>platform: none<\/code> or <code>platform: baremetal<\/code> in the configuration.<sup>9<\/sup> In a UPI installation, the administrator assumes responsibility for preparing and managing all aspects of the underlying infrastructure. This includes provisioning physical servers or virtual machines, configuring networking (IP addressing, DNS, load balancing), setting up storage, and ensuring all prerequisites are met before initiating the OKD deployment.<sup>9<\/sup><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This contrasts with the Installer-Provisioned Infrastructure (IPI) method, where the <code>openshift-install<\/code> program automates the creation and configuration of the necessary infrastructure resources on supported platforms like AWS, GCP, or vSphere.<sup>9<\/sup> The UPI method provides maximum control and customization but requires a deeper understanding of both OKD&#8217;s requirements and the target infrastructure environment.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This guide details the steps for a UPI installation using the official <code>openshift-install<\/code> tool.<sup>2<\/sup> It specifically excludes methods involving OpenShift Local (formerly CodeReady Containers or CRC), which provides a simplified, single-node OKD or OCP environment primarily for local development and testing on a workstation, often within a virtual machine managed by the <code>crc<\/code> tool.<sup>17<\/sup> OpenShift Local is not intended for production or multi-node cluster deployments and has different setup procedures and limitations.<sup>18<\/sup><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">C. Overview of the Installation Process<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The UPI installation process using <code>openshift-install<\/code> follows a structured sequence of steps, heavily relying on Fedora CoreOS (FCOS) and its Ignition provisioning system.<sup>6<\/sup> The major phases include:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Prerequisites:<\/strong> Ensuring the installer machine, target nodes (hardware, OS), networking (IPs, DNS, LBs), and tooling meet OKD&#8217;s requirements.<\/li>\n\n\n\n<li><strong>Tool Acquisition:<\/strong> Downloading the correct versions of <code>openshift-install<\/code>, <code>oc<\/code>, and FCOS images.<\/li>\n\n\n\n<li><strong>Configuration:<\/strong> Creating the primary <code>install-config.yaml<\/code> file defining the cluster.<\/li>\n\n\n\n<li><strong>Manifests &amp; Ignition:<\/strong> Generating Kubernetes manifests and then the node-specific Ignition configuration files (<code>bootstrap.ign<\/code>, <code>master.ign<\/code>, <code>worker.ign<\/code>).<\/li>\n\n\n\n<li><strong>Infrastructure Provisioning &amp; Booting:<\/strong> Setting up the physical\/virtual nodes and booting them with their respective Ignition configurations.<\/li>\n\n\n\n<li><strong>Bootstrapping:<\/strong> Monitoring the temporary bootstrap node as it establishes the permanent control plane.<\/li>\n\n\n\n<li><strong>Finalization:<\/strong> Waiting for all cluster operators to become stable and operational.<\/li>\n\n\n\n<li><strong>Verification:<\/strong> Accessing the cluster via CLI and web console to confirm successful installation.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">II. Step 1: Finding Official Documentation and Release Information<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Navigating the official resources correctly is the first step towards a successful OKD installation. Using mismatched documentation or tools is a common source of errors.<sup>24<\/sup><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Official Project Website<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The main project website is <code>okd.io<\/code>.<sup>1<\/sup> This site provides a high-level overview of OKD, its goals, community engagement links (like Slack channels and working groups), and pointers to getting started resources.<sup>1<\/sup><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">B. Official Documentation Site<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The definitive source for technical documentation is <code>docs.okd.io<\/code>.<sup>27<\/sup> It is crucial to select the documentation version that precisely matches the OKD version intended for installation. The documentation is versioned (e.g., 4.16, 4.17, latest), and using guides from a different version can lead to incompatibilities or outdated procedures. Key sections for this guide include &#8220;Installing&#8221;, particularly subsections related to &#8220;Bare Metal&#8221;, &#8220;User-Provisioned Infrastructure&#8221;, or &#8220;Installing on Any Platform&#8221;.<sup>10<\/sup><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">C. Official GitHub Repository and Releases<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The primary code repository is <code>okd-project\/okd<\/code> on GitHub.<sup>1<\/sup> The crucial page for obtaining installation tools is the <code>\/releases<\/code> sub-page: <code>https:\/\/github.com\/okd-project\/okd\/releases<\/code>.<sup>2<\/sup> This page hosts downloadable archives for the <code>openshift-install<\/code> binary and the <code>oc<\/code> (OpenShift CLI) client tools, specific to each tagged OKD release.<sup>2<\/sup><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Recent releases, particularly those based on CentOS Stream CoreOS (SCOS), might originate from the <code>okd-project\/okd-scos<\/code> repository <sup>1<\/sup>, with artifacts often mirrored or copied to the main <code>okd\/releases<\/code> page for broader visibility.<sup>36<\/sup> Always ensure the downloaded tools correspond to the target OKD installation version.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The documentation landscape for OKD is distributed across these three main resources: the project homepage (<code>okd.io<\/code>) for community and overview, the documentation site (<code>docs.okd.io<\/code>) for detailed technical procedures, and the GitHub repository (<code>okd-project\/okd<\/code>) for code and release artifacts (install tools). Given the rapid development cycle and the differences between versions, consistently referencing the documentation and downloading tools that match the <em>exact<\/em> target OKD release version is paramount. Mixing versions (e.g., using the 4.16 installer with 4.17 documentation or FCOS image) is a frequent cause of installation failures, often manifesting in later stages with hard-to-diagnose errors.<sup>24<\/sup> This guide assumes the user will select a target OKD version and consistently use the corresponding documentation and tools throughout.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">III. Step 2: Meeting Installation Prerequisites<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before initiating the installation, a set of prerequisites must be met across the installer machine, the cluster nodes, networking, and tooling. Failure to meet these requirements often leads to installation failures that can be difficult to troubleshoot.<sup>39<\/sup> The interdependent nature of these prerequisites means a failure in one area, such as DNS, can cascade and cause failures in subsequent steps, like node communication or API access. Therefore, thorough validation <em>before<\/em> starting the installation is highly recommended.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Installer Machine<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operating System:<\/strong> A machine running a recent version of Linux (like Fedora) or macOS is required to execute the <code>openshift-install<\/code> binary.<sup>16<\/sup><\/li>\n\n\n\n<li><strong>Software:<\/strong> Standard utilities like <code>tar<\/code>, <code>curl<\/code>\/<code>wget<\/code>, and an SSH client are needed. Depending on the specific infrastructure and methods used (especially if performing IPI or using local virtualization for testing), packages like <code>libvirt<\/code>, <code>qemu-kvm<\/code>, <code>jq<\/code>, and <code>ipmitool<\/code> might be necessary on the machine running the installer.<sup>43<\/sup><\/li>\n\n\n\n<li><strong>Resources:<\/strong> Sufficient disk space is needed to store the downloaded tools, configuration files, logs, and potentially cached FCOS images. While the tools themselves are relatively small (around 500MB cited <sup>42<\/sup>), installation logs and generated assets require more space.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">B. Cluster Node Hardware<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A standard high-availability (HA) OKD cluster requires a minimum set of hosts <sup>10<\/sup>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>1 Bootstrap Machine (Temporary):<\/strong> Used only during the installation process to deploy the control plane. It can be removed afterward. Must run FCOS.<\/li>\n\n\n\n<li><strong>3 Control Plane Machines (Masters):<\/strong> Run the core Kubernetes and OKD control plane services (API server, etcd, controller manager, etc.). Must run FCOS.<\/li>\n\n\n\n<li><strong>2+ Compute Machines (Workers):<\/strong> Run user application workloads. Typically run FCOS in UPI installations, but Fedora is also technically possible (though managing Fedora nodes falls outside the scope of OKD&#8217;s automated FCOS updates).<sup>49<\/sup><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Three-node clusters, where the control plane nodes also run user workloads (mastersSchedulable=true) and there are zero dedicated compute nodes, are also a supported configuration, often for resource-constrained environments.<sup>55<\/sup><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The minimum resource requirements per node are critical for stability:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Node Type<\/strong><\/td><td><strong>Operating System<\/strong><\/td><td><strong>Minimum vCPU\/Cores<\/strong><\/td><td><strong>Minimum RAM (GB)<\/strong><\/td><td><strong>Minimum Disk (GB)<\/strong><\/td><td><strong>Minimum IOPS (Recommended)<\/strong><\/td><td><strong>References<\/strong><\/td><\/tr><tr><td>Bootstrap<\/td><td>FCOS<\/td><td>4<\/td><td>16<\/td><td>100 \/ 120\u00b9<\/td><td>300<\/td><td><sup>33<\/sup><\/td><\/tr><tr><td>Control Plane<\/td><td>FCOS<\/td><td>4<\/td><td>16<\/td><td>100 \/ 120\u00b9<\/td><td>300 (Fast disk essential)<\/td><td><sup>33<\/sup><\/td><\/tr><tr><td>Compute<\/td><td>FCOS \/ Fedora<\/td><td>2<\/td><td>8<\/td><td>100 \/ 120\u00b9<\/td><td>300<\/td><td><sup>33<\/sup><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">\u00b9 <em>Note: Some documentation references 100GB <sup>33<\/sup>, while others mention 120GB.<sup>16<\/sup> Provisioning 120GB or more is safer.<\/em><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CPU:<\/strong> 1 vCPU generally equates to 1 physical core if hyperthreading (SMT) is disabled.<sup>49<\/sup> Specific CPU instruction set architectures (ISA) are required (e.g., x86-64-v2 for recent versions).<sup>49<\/sup><\/li>\n\n\n\n<li><strong>Disk Performance:<\/strong> OKD, especially the etcd database running on control plane nodes, is highly sensitive to disk I\/O performance. Fast storage (SSD\/NVMe) with low latency (e.g., &lt;10ms fsync for etcd) is strongly recommended.<sup>49<\/sup> Insufficient disk performance can lead to cluster instability and timeouts.<sup>24<\/sup> On cloud platforms where IOPS often scales with disk size, overprovisioning disk capacity might be necessary to achieve required performance.<sup>49<\/sup><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">C. Network Requirements<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Networking is often the most complex prerequisite area for UPI installations.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IP Addressing:<\/strong>\n<ul class=\"wp-block-list\">\n<li>Each node (bootstrap, control plane, compute) requires a persistent IP address.<\/li>\n\n\n\n<li>This can be achieved via:\n<ul class=\"wp-block-list\">\n<li><strong>DHCP:<\/strong> A DHCP server configured with static reservations mapping each node&#8217;s network interface MAC address to a specific IP address.<sup>10<\/sup> The DHCP server should also provide DNS server information.<sup>42<\/sup><\/li>\n\n\n\n<li><strong>Static IP:<\/strong> Manually configuring the IP address, subnet mask, gateway, and DNS servers during the FCOS installation process (e.g., via kernel arguments or Ignition).<sup>10<\/sup><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>DNS Configuration:<\/strong> Correct DNS resolution is absolutely critical for cluster operation.<sup>10<\/sup> Misconfiguration is a common failure point.<sup>64<\/sup>\n<ul class=\"wp-block-list\">\n<li>Both forward (name-to-IP) and reverse (IP-to-name) lookups must work correctly for all cluster components.<sup>42<\/sup><\/li>\n\n\n\n<li>The following DNS records must be configured in the user&#8217;s DNS zone <em>before<\/em> starting the installation:<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Record Type<\/strong><\/td><td><strong>Hostname Pattern<\/strong><\/td><td><strong>Target<\/strong><\/td><td><strong>Resolvable By<\/strong><\/td><td><strong>References<\/strong><\/td><\/tr><tr><td>A\/AAAA<\/td><td><code>api.&lt;cluster_name&gt;.&lt;base_domain&gt;<\/code><\/td><td>API Load Balancer VIP<\/td><td>Internal &amp; External<\/td><td><sup>10<\/sup><\/td><\/tr><tr><td>A\/AAAA<\/td><td><code>api-int.&lt;cluster_name&gt;.&lt;base_domain&gt;<\/code><\/td><td>API Load Balancer VIP<\/td><td>Internal Only<\/td><td><sup>42<\/sup><\/td><\/tr><tr><td>A\/AAAA<\/td><td><code>*.apps.&lt;cluster_name&gt;.&lt;base_domain&gt;<\/code><\/td><td>Application Ingress Load Balancer VIP<\/td><td>Internal &amp; External<\/td><td><sup>10<\/sup><\/td><\/tr><tr><td>A\/AAAA<\/td><td><code>&lt;node_type&gt;-&lt;index&gt;.&lt;cluster_name&gt;.&lt;base_domain&gt;<\/code><\/td><td>Node IP Address<\/td><td>Internal Only<\/td><td><sup>10<\/sup><\/td><\/tr><tr><td>PTR<\/td><td>Node IP Address<\/td><td>Node FQDN<\/td><td>Internal Only<\/td><td><sup>42<\/sup><\/td><\/tr><tr><td>PTR<\/td><td>API LB VIP Address<\/td><td><code>api.&lt;cluster_name&gt;.&lt;base_domain&gt;<\/code><\/td><td>Internal Only<\/td><td><sup>42<\/sup><\/td><\/tr><tr><td>PTR<\/td><td>Apps LB VIP Address<\/td><td>(Typically not required)<\/td><td>&#8211;<\/td><td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; title: ; notranslate\" title=\"\">\n*   `&amp;lt;cluster_name&gt;` and `&amp;lt;base_domain&gt;` are defined in `install-config.yaml`.\n*   `api` and `api-int` are used for Kubernetes API access (external and internal, respectively).\n*   `*.apps` is a wildcard record for exposing applications via OKD Routes.\n*   `&amp;lt;node_type&gt;-&amp;lt;index&gt;` refers to individual nodes like `bootstrap-0`, `master-0`, `worker-0`.\n*   DNS validation using tools like `dig` should be performed before installation.&#x5B;42]\n\n<\/pre><\/div>\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Load Balancers:<\/strong> Two load balancers must be provisioned and configured.<sup>10<\/sup> These can be hardware LBs, software LBs (like HAProxy), or cloud provider LBs configured manually.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Load Balancer Name<\/strong><\/td><td><strong>Frontend Port(s)<\/strong><\/td><td><strong>Backend Port(s)<\/strong><\/td><td><strong>Backend Nodes (Initial Pool)<\/strong><\/td><td><strong>Mode Required<\/strong><\/td><td><strong>Persistence<\/strong><\/td><td><strong>Health Check Endpoint\/Port (TCP Check Often Suffices)<\/strong><\/td><td><strong>References<\/strong><\/td><\/tr><tr><td><strong>API<\/strong><\/td><td>6443, 22623<\/td><td>6443, 22623<\/td><td>Bootstrap, Control Plane x3<\/td><td>Layer 4 (TCP\/SSL Passthrough)<\/td><td>None \/ Stateless<\/td><td>API: <code>\/readyz<\/code> on 6443; Machine Config: TCP 22623<\/td><td><sup>10<\/sup><\/td><\/tr><tr><td><strong>Application Ingress<\/strong><\/td><td>80 (HTTP), 443 (HTTPS)<\/td><td>80, 443<\/td><td>Compute (Worker) xN<\/td><td>Layer 4 (TCP\/SSL Passthrough)<\/td><td>Session \/ Source IP\u00b9<\/td><td><code>\/healthz\/ready<\/code> on 1936 (Ingress Controller health)<\/td><td><sup>10<\/sup><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; title: ; notranslate\" title=\"\">\n*   **Mode:** Must operate at Layer 4 (TCP), not Layer 7 (HTTP\/S). SSL termination should *not* happen at the LB (SSL Passthrough).&#x5B;10, 33, 52, 68]\n*   **API LB Backend Pool:** Initially includes the bootstrap node and all control plane nodes. The bootstrap node is removed after bootstrap completion.&#x5B;10, 33, 52, 68]\n*   **Ingress LB Backend Pool:** Includes all compute (worker) nodes where the Ingress Controller pods run (by default). In a 3-node cluster, this would be the control plane nodes.&#x5B;68]\n*   **Persistence:** The API LB should be stateless. The Ingress LB benefits from session persistence (e.g., source IP based) for better application performance.&#x5B;10, 33, 52, 68]\n*   **Health Checks:** Crucial for removing unhealthy nodes from the pool. Use the specified endpoints\/ports or reliable TCP checks. API health check (`\/readyz`) is particularly important for bootstrap.&#x5B;10, 33, 52, 68]\n\n<\/pre><\/div>\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Network Connectivity &amp; Ports:<\/strong>\n<ul class=\"wp-block-list\">\n<li>Nodes require internet access for pulling container images (from <code>quay.io<\/code> for OKD) and potentially telemetry, unless a disconnected installation with a mirror registry is performed.<sup>10<\/sup><\/li>\n\n\n\n<li>Nodes need access to internal services: DNS servers, NTP servers (time synchronization is critical) <sup>50<\/sup>, load balancers, and potentially an HTTP\/HTTPS server hosting Ignition files.<sup>54<\/sup><\/li>\n\n\n\n<li>Firewalls between nodes or between nodes and required services must allow necessary traffic. Refer to OKD documentation for specific port requirements (e.g., ports 6443, 22623 for API\/Machine Config; 80, 443 for Ingress; internal SDN ports like 4789 UDP).<sup>51<\/sup><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">D. Required Tools<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ensure the following tools are available on the installer machine:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>openshift-install<\/code> binary:<\/strong> The core installation program for the target OKD version <sup>2<\/sup>-.<sup>36<\/sup><\/li>\n\n\n\n<li><strong><code>oc<\/code> (OpenShift CLI) binary:<\/strong> The command-line client for interacting with the cluster post-installation. Must match the cluster version for full compatibility <sup>16<\/sup>-.<sup>72<\/sup><\/li>\n\n\n\n<li><strong>Fedora CoreOS (FCOS) Images:<\/strong> Access to download the appropriate FCOS image (ISO, PXE, VMDK, QCOW2 etc.) for the target infrastructure and OKD version <sup>21<\/sup>-.<sup>73<\/sup><\/li>\n\n\n\n<li><strong>SSH Client &amp; Key Pair:<\/strong> An SSH client and a generated key pair (e.g., <code>id_rsa<\/code> or <code>id_ed25519<\/code>) for secure access to cluster nodes if needed for troubleshooting.<sup>10<\/sup> The public key will be embedded in the Ignition configs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">E. Infrastructure Capabilities<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The chosen infrastructure must support:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Hardware:<\/strong> Provisioning of bare metal servers or VMs meeting the minimum CPU, RAM, and disk requirements.<sup>10<\/sup><\/li>\n\n\n\n<li><strong>Booting &amp; Provisioning:<\/strong> A method to boot the provisioned nodes using the chosen FCOS image (ISO, PXE, etc.) and reliably deliver the corresponding Ignition configuration file to each node upon its <em>first<\/em> boot <sup>10<\/sup>-.<sup>76<\/sup> This is a critical step detailed further in Step 6.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">IV. Step 3: Downloading Installation Tools<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">With prerequisites understood, the next step is to acquire the necessary command-line tools and the base operating system image. Using versions of these tools that precisely match the target OKD release is essential for avoiding compatibility issues.<sup>16<\/sup><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Download <code>openshift-install<\/code><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The <code>openshift-install<\/code> binary orchestrates the creation of configuration files and, in IPI mode, the infrastructure itself. For UPI, it generates the manifests and Ignition files.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Navigate to OKD Releases:<\/strong> Go to the official OKD releases page on GitHub: <code>https:\/\/github.com\/okd-project\/okd\/releases<\/code>.<sup>2<\/sup><\/li>\n\n\n\n<li><strong>Select Version:<\/strong> Identify and click on the specific OKD release tag you intend to install (e.g., <code>4.17.0-okd-scos.0<\/code>).<\/li>\n\n\n\n<li><strong>Download Archive:<\/strong> Under the &#8220;Assets&#8221; section for that release, find the <code>openshift-install<\/code> archive appropriate for your installer machine&#8217;s operating system and architecture (e.g., <code>openshift-install-linux-&lt;version>.tar.gz<\/code> or <code>openshift-install-mac-&lt;version>.tar.gz<\/code>). Download this file.<sup>35<\/sup> Example using <code>curl<\/code>: Bash<code>OKD_VERSION=\"4.17.0-okd-scos.0\" # Replace with your target version OS_ARCH=\"linux\" # Or \"mac\" curl -L https:\/\/github.com\/okd-project\/okd\/releases\/download\/${OKD_VERSION}\/openshift-install-${OS_ARCH}-${OKD_VERSION}.tar.gz -o openshift-install.tar.gz<\/code><\/li>\n\n\n\n<li><strong>Extract Binary:<\/strong> Extract the archive: Bash<code>tar zxvf openshift-install.tar.gz<\/code><\/li>\n\n\n\n<li><strong>Place in PATH:<\/strong> Move the extracted <code>openshift-install<\/code> binary to a directory included in your system&#8217;s <code>PATH<\/code> environment variable (e.g., <code>\/usr\/local\/bin<\/code> or <code>~\/bin<\/code>) and ensure it&#8217;s executable <sup>2<\/sup>: Bash<code>sudo mv openshift-install \/usr\/local\/bin\/ sudo chmod +x \/usr\/local\/bin\/openshift-install<\/code><\/li>\n\n\n\n<li><strong>Verify:<\/strong> Check the installation: <code>openshift-install version<\/code>.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">B. Download <code>oc<\/code> CLI Tool<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The <code>oc<\/code> CLI is used for interacting with the OKD cluster after installation (managing resources, applications, users, etc.).<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Use Same Release Page (Recommended):<\/strong> Navigate back to the <em>same<\/em> OKD GitHub release page used for <code>openshift-install<\/code>.<sup>36<\/sup> Downloading <code>oc<\/code> from the same release bundle ensures version compatibility.<sup>16<\/sup><\/li>\n\n\n\n<li><strong>Download Archive:<\/strong> Find the <code>openshift-client<\/code> archive for your OS and architecture (e.g., <code>openshift-client-linux-&lt;version>.tar.gz<\/code>) under &#8220;Assets&#8221; and download it.<sup>36<\/sup> Example: Bash<code># Use the same OKD_VERSION and OS_ARCH as before curl -L https:\/\/github.com\/okd-project\/okd\/releases\/download\/${OKD_VERSION}\/openshift-client-${OS_ARCH}-${OKD_VERSION}.tar.gz -o oc.tar.gz<\/code> <em>(Alternative, less recommended due to potential version mismatch: Use the mirror site <code>https:\/\/mirror.openshift.com\/pub\/openshift-v4\/clients\/oc\/latest\/<\/code> or a version-specific directory there.<sup>71<\/sup>)<\/em><\/li>\n\n\n\n<li><strong>Extract Binaries:<\/strong> Extract the archive. This typically includes both <code>oc<\/code> and <code>kubectl<\/code> <sup>44<\/sup>: Bash<code>tar zxvf oc.tar.gz<\/code><\/li>\n\n\n\n<li><strong>Place in PATH:<\/strong> Move the extracted <code>oc<\/code> and <code>kubectl<\/code> binaries to a directory in your <code>PATH<\/code> and ensure they are executable <sup>44<\/sup>: Bash<code>sudo mv oc kubectl \/usr\/local\/bin\/ sudo chmod +x \/usr\/local\/bin\/oc \/usr\/local\/bin\/kubectl<\/code><\/li>\n\n\n\n<li><strong>Verify:<\/strong> Check the installation: <code>oc version<\/code>.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">C. Obtain Fedora CoreOS (FCOS) Image<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">FCOS is the immutable operating system required for bootstrap and control plane nodes.<sup>5<\/sup><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Identify Required Image:<\/strong> The most reliable way to get the FCOS image compatible with your <code>openshift-install<\/code> version is to use the installer itself <sup>35<\/sup>: Bash<code># Ensure openshift-install is in your PATH openshift-install coreos print-stream-json<\/code> This command outputs JSON containing URLs for various FCOS artifacts (ISO, QCOW2, PXE kernel\/initramfs\/rootfs) specific to the installer&#8217;s built-in release information. Parse this JSON (e.g., using <code>jq<\/code>) to find the URL for the image format you need. Example to get the bare metal ISO URL for x86_64: Bash<code>ISO_URL=$(openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location') echo $ISO_URL<\/code> Using the image specified by the installer minimizes compatibility risks associated with FCOS versions and Ignition specifications.<sup>6<\/sup><\/li>\n\n\n\n<li><strong>Download Image:<\/strong> Use the URL obtained in the previous step to download the required FCOS image file. Example using the <code>$ISO_URL<\/code> variable from above: Bash<code>curl -L $ISO_URL -o fcos-metal.iso<\/code> <em>(Alternative: Download from the FCOS website <code>https:\/\/fedoraproject.org\/coreos\/download\/<\/code>.<sup>70<\/sup> Select the appropriate stream (usually &#8216;stable&#8217; or the one matching OKD docs), architecture, and image format (Bare metal ISO, PXE files, QEMU QCOW2, VMware OVA, etc.). This approach carries a slightly higher risk of version mismatch if not carefully cross-referenced with OKD compatibility notes.)<\/em><\/li>\n\n\n\n<li><strong>Verify Image (Optional but Recommended):<\/strong> The FCOS download page provides checksums (SHA256) and GPG signatures. Verify the downloaded image integrity and authenticity using tools like <code>sha256sum<\/code> and <code>gpg<\/code>.<sup>82<\/sup><\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">V. Step 4: Creating the Installation Configuration (<code>install-config.yaml<\/code>)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The <code>install-config.yaml<\/code> file serves as the primary input for the installation program, defining the fundamental parameters of the cluster. Getting this file correct is crucial, as errors here often lead to failures later in the process.<sup>55<\/sup><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Generating the Initial File<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Create Installation Directory:<\/strong> Create a new, empty directory for this specific installation attempt. Do <em>not<\/em> reuse directories from previous failed or successful installations, as some generated assets like bootstrap certificates have short lifespans.<sup>16<\/sup> Bash<code>mkdir ~\/okd-install-upi cd ~\/okd-install-upi<\/code><\/li>\n\n\n\n<li><strong>Run <code>create install-config<\/code>:<\/strong> Execute the command within the new directory: Bash<code>openshift-install create install-config --dir=.<\/code> <sup>16<\/sup><\/li>\n\n\n\n<li><strong>Answer Prompts:<\/strong> The installer will prompt for basic information <sup>16<\/sup>:<ul><li><strong>SSH Key:<\/strong> Select or provide the path to the <em>public<\/em> SSH key (e.g., <code>~\/.ssh\/id_ed25519.pub<\/code>) to be used for accessing nodes.<\/li><li><strong>Platform:<\/strong> Choose the target platform. For UPI on bare metal or generic VMs where you manage everything, select <code>none<\/code>. (Other options like <code>aws<\/code>, <code>vsphere<\/code>, <code>gcp<\/code>, <code>baremetal<\/code> trigger IPI logic or platform-specific UPI fields).<\/li><li><strong>Base Domain:<\/strong> Enter the DNS base domain you configured (e.g., <code>okd.example.com<\/code>).<\/li><li><strong>Cluster Name:<\/strong> Enter a name for the cluster (e.g., <code>myupi<\/code>). This will be prepended to the base domain for FQDNs.<\/li><li><strong>Pull Secret:<\/strong> Paste the pull secret. For OKD UPI, use the dummy secret: <code>{\"auths\":{\"fake\":{\"auth\":\"aWQ6cGFzcwo=\"}}}<\/code>.<sup>2<\/sup><\/li><\/ul><em>Note: Interactive mode might have issues on certain platforms or installer versions; manually creating the <code>install-config.yaml<\/code> based on the parameters below is always an option.<sup>89<\/sup><\/em><\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">B. Key Parameters for UPI (<code>platform: none<\/code>)<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">After the initial generation, review and edit the created <code>install-config.yaml<\/code> file. For a typical UPI installation, it should resemble the following structure, ensuring parameters match your infrastructure:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">YAML<\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; title: ; notranslate\" title=\"\">\napiVersion: v1\nbaseDomain: okd.example.com # 1. Your configured base DNS domain\nmetadata:\n  name: myupi             # 2. Your chosen cluster name\nplatform:\n  none: {}               # 3. Indicates User-Provisioned Infrastructure\npullSecret: &#039;{&quot;auths&quot;:{&quot;fake&quot;:{&quot;auth&quot;:&quot;aWQ6cGFzcwo=&quot;}}}&#039; # 4. Dummy pull secret for OKD\nsshKey: &#039;ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...&#039; # 5. Content of your public SSH key\ncontrolPlane:            # 6. Control Plane (Master) node definition\n  architecture: amd64\n  hyperthreading: Enabled # Optional\n  name: master\n  replicas: 3            # Must be 3 for HA\ncompute:                 # 7. Compute (Worker) node definition\n  - architecture: amd64\n    hyperthreading: Enabled # Optional\n    name: worker\n    replicas: 2            # Minimum 2 for HA (or 0 for 3-node cluster)\nnetworking:              # 8. Cluster network configuration\n  clusterNetwork:\n    - cidr: 10.128.0.0\/14  # Pod network CIDR\n      hostPrefix: 23\n  machineNetwork:\n    - cidr: 192.168.1.0\/24 # CIDR matching your node infrastructure IPs\n  networkType: OVNKubernetes # Or OpenShiftSDN\n  serviceNetwork:\n    - 172.30.0.0\/16   # Service network CIDR\n# Optional Parameters below:\n# fips: false             # Enable FIPS mode\n# publish: External      # How to expose the cluster (External\/Internal)\n# proxy:                  # Define HTTP\/HTTPS proxy if needed\n#   httpProxy: http:\/\/&amp;lt;proxy_user&gt;:&amp;lt;proxy_pass&gt;@&amp;lt;proxy_ip&gt;:&amp;lt;proxy_port&gt;\n#   httpsProxy: https:\/\/&amp;lt;proxy_user&gt;:&amp;lt;proxy_pass&gt;@&amp;lt;proxy_ip&gt;:&amp;lt;proxy_port&gt;\n#   noProxy: example.com,.cluster.local\n# additionalTrustBundle: | # Add custom CA certs for proxy\/registries\n#   -----BEGIN CERTIFICATE-----\n#  ...\n#   -----END CERTIFICATE-----\n\n<\/pre><\/div>\n\n\n<p class=\"wp-block-paragraph\"><strong>Explanation of Key Parameters:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong><code>baseDomain<\/code>:<\/strong> Must match the DNS zone configured in prerequisites.<sup>16<\/sup><\/li>\n\n\n\n<li><strong><code>metadata.name<\/code>:<\/strong> Defines the cluster name used in hostnames and resources.<sup>16<\/sup><\/li>\n\n\n\n<li><strong><code>platform.none<\/code>:<\/strong> Specifies that the user is responsible for all infrastructure provisioning.<sup>57<\/sup><\/li>\n\n\n\n<li><strong><code>pullSecret<\/code>:<\/strong> For OKD, the provided dummy secret is sufficient unless pulling from other private registries.<sup>2<\/sup><\/li>\n\n\n\n<li><strong><code>sshKey<\/code>:<\/strong> The <em>content<\/em> of the public SSH key file (<code>.pub<\/code>) used for node access.<sup>16<\/sup><\/li>\n\n\n\n<li><strong><code>controlPlane.replicas<\/code>:<\/strong> Must be 3 for a high-availability cluster.<\/li>\n\n\n\n<li><strong><code>compute.replicas<\/code>:<\/strong> Minimum of 2 for HA. Set to 0 for a 3-node cluster configuration where control plane nodes are schedulable.<sup>57<\/sup><\/li>\n\n\n\n<li><strong><code>networking<\/code>:<\/strong>\n<ul class=\"wp-block-list\">\n<li><code>clusterNetwork<\/code>: CIDR for Pod IPs. Should not overlap with existing networks.<\/li>\n\n\n\n<li><code>serviceNetwork<\/code>: CIDR for Service IPs. Should not overlap.<\/li>\n\n\n\n<li><code>machineNetwork<\/code>: Must contain the IP range(s) from which the cluster nodes (bootstrap, control plane, compute) get their IPs.<sup>57<\/sup><\/li>\n\n\n\n<li><code>networkType<\/code>: Typically <code>OVNKubernetes<\/code> (default in recent versions) or <code>OpenShiftSDN<\/code>.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">C. Backup the Configuration<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Crucially, back up the customized <code>install-config.yaml<\/code> file to a safe location outside the installation directory. The <code>openshift-install<\/code> commands consume or modify this file during subsequent steps, and having a backup allows for easier restarts or recreation if needed.<sup>56<\/sup><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">VI. Step 5: Generating Kubernetes Manifests and Ignition Configurations<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">With the <code>install-config.yaml<\/code> defining the cluster&#8217;s core, the next steps involve transforming this high-level configuration into the detailed manifests and node-specific boot configurations needed by Kubernetes and FCOS.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Generate Kubernetes Manifests<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The installer first converts the <code>install-config.yaml<\/code> into a collection of standard Kubernetes manifest files. These define various cluster resources and configurations.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Run <code>create manifests<\/code>:<\/strong> Execute the following command in the installation directory: Bash<code>openshift-install create manifests --dir=.<\/code> <sup>91<\/sup><\/li>\n\n\n\n<li><strong>Output:<\/strong> This creates a <code>manifests\/<\/code> subdirectory containing numerous YAML files (e.g., <code>cluster-scheduler-02-config.yml<\/code>, <code>cvo-overrides.yaml<\/code>) and an <code>openshift\/<\/code> subdirectory for injecting custom manifests.<\/li>\n\n\n\n<li><strong>Optional Customization Point:<\/strong> This stage offers an opportunity for advanced customization <em>before<\/em> the immutable Ignition configurations are generated.<sup>91<\/sup> Users can modify the generated manifests in the <code>manifests\/<\/code> directory or add their own YAML files (like MachineConfig definitions) to the <code>openshift\/<\/code> directory. Common customizations include:<ul><li>Making control plane nodes non-schedulable (by modifying <code>manifests\/cluster-scheduler-02-config.yml<\/code>).<sup>58<\/sup><\/li><li>Adding kernel arguments via a MachineConfig file placed in <code>openshift\/<\/code>.<sup>92<\/sup><\/li><li>Configuring custom NTP servers via a MachineConfig.<sup>92<\/sup><\/li><li>Adjusting network operator configurations.<sup>67<\/sup><\/li><\/ul>Modifying these manifests requires a good understanding of OKD\/Kubernetes internals, as incorrect changes can easily break the installation. It is generally recommended to avoid modifications unless necessary and well-understood.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">B. Generate Ignition Configurations<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ignition is the first-boot provisioning tool used by Fedora CoreOS.<sup>6<\/sup> It reads a JSON configuration file (<code>.ign<\/code>) and configures the node accordingly, setting up storage, filesystems, systemd units, users, network configurations, etc. The <code>openshift-install<\/code> tool generates these Ignition files based on the <code>install-config.yaml<\/code> and the (potentially customized) manifests.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Run <code>create ignition-configs<\/code>:<\/strong> Execute the following command in the installation directory: Bash<code>openshift-install create ignition-configs --dir=.<\/code> <sup>10<\/sup><\/li>\n\n\n\n<li><strong>Output:<\/strong> This command consumes the <code>install-config.yaml<\/code> and the contents of the <code>manifests\/<\/code> and <code>openshift\/<\/code> directories. It generates the following critical files directly in the installation directory:\n<ul class=\"wp-block-list\">\n<li><strong><code>bootstrap.ign<\/code>:<\/strong> The Ignition configuration for the temporary bootstrap node.<sup>94<\/sup> It contains instructions to set up a minimal Kubernetes control plane, etcd, and an HTTP server to provide resources (including Ignition files) to the permanent control plane nodes.<\/li>\n\n\n\n<li><strong><code>master.ign<\/code>:<\/strong> The Ignition configuration for the permanent control plane nodes.<sup>94<\/sup> It instructs these nodes how to format disks, configure networking, and join the cluster initiated by the bootstrap node.<\/li>\n\n\n\n<li><strong><code>worker.ign<\/code>:<\/strong> The Ignition configuration for the compute (worker) nodes.<sup>94<\/sup> Similar to <code>master.ign<\/code>, but configures nodes for running user workloads.<\/li>\n\n\n\n<li><strong><code>metadata.json<\/code>:<\/strong> Contains metadata about the cluster being installed.<\/li>\n\n\n\n<li><strong><code>auth\/kubeconfig<\/code>:<\/strong> The kubeconfig file needed to access the cluster API as the administrator after installation.<sup>77<\/sup> <strong>Secure this file.<\/strong><\/li>\n\n\n\n<li><strong><code>auth\/kubeadmin-password<\/code>:<\/strong> Contains the randomly generated password for the initial <code>kubeadmin<\/code> user.<sup>16<\/sup> <strong>Secure this file.<\/strong><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The generation of manifests serves as an intermediate step, allowing for specific customizations beyond the scope of <code>install-config.yaml<\/code> before the final, node-specific Ignition configurations are created. Once <code>create ignition-configs<\/code> is run, the boot configurations for the nodes are essentially fixed for the initial deployment.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">VII. Step 6: Provisioning Infrastructure and Booting Nodes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">With the Ignition configurations generated, the next phase involves preparing the actual infrastructure (servers or VMs) and booting them using the correct FCOS image and Ignition file. This stage is critical, as failure to deliver the correct Ignition configuration during the first boot will prevent nodes from joining the cluster correctly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Final Infrastructure Preparation (DNS\/LB)<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Before booting any nodes, ensure the prerequisite DNS records and Load Balancers are fully configured, active, and resolvable\/reachable within the network.<sup>10<\/sup> The bootstrap and control plane nodes will immediately attempt to resolve and communicate with the API endpoints (<code>api.&lt;cluster&gt;.&lt;domain&gt;<\/code> and <code>api-int.&lt;cluster&gt;.&lt;domain&gt;<\/code>) via the configured load balancer upon booting.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">B. Provisioning Nodes<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Provision the physical servers or virtual machines intended for the bootstrap, control plane, and compute roles. Ensure they meet the minimum hardware requirements (CPU, RAM, Disk) specified earlier. Configure network interfaces and note their MAC addresses if using DHCP reservations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">C. Booting Nodes with Ignition Configs<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Each node must be booted using the appropriate FCOS image and provided with its corresponding Ignition file (<code>bootstrap.ign<\/code> for the bootstrap node, <code>master.ign<\/code> for control plane nodes, <code>worker.ign<\/code> for compute nodes). The method for delivering the Ignition config depends on the infrastructure:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Method 1: FCOS Installer ISO + HTTP(S) Server:<\/strong>\n<ol class=\"wp-block-list\">\n<li>Boot the target node using the downloaded FCOS installer ISO.<sup>70<\/sup><\/li>\n\n\n\n<li>Host the <code>bootstrap.ign<\/code>, <code>master.ign<\/code>, and <code>worker.ign<\/code> files on an HTTP or HTTPS server accessible by the nodes during boot <sup>70<\/sup>-.<sup>76<\/sup><\/li>\n\n\n\n<li>After the live ISO environment boots, run the <code>coreos-installer<\/code> command, specifying the URL to the <em>node-specific<\/em> Ignition file and the target installation disk.<sup>70<\/sup> Bash<code># Example for a master node, installing to \/dev\/sda # Assumes master.ign is hosted at http:\/\/192.168.1.10:8080\/master.ign # Obtain SHA512 hash: sha512sum master.ign IGNITION_URL=\"http:\/\/192.168.1.10:8080\/master.ign\" IGNITION_HASH=\"sha512-...\" # Replace with actual hash sudo coreos-installer install \/dev\/sda --ignition-url=${IGNITION_URL} --ignition-hash=${IGNITION_HASH}<\/code><\/li>\n\n\n\n<li>If using plain HTTP, the <code>--ignition-hash<\/code> argument is crucial for verifying the integrity of the downloaded Ignition file.<sup>103<\/sup><\/li>\n\n\n\n<li>After the installer finishes writing FCOS to the disk and injecting the Ignition configuration reference, reboot the node. FCOS will then fetch and apply the Ignition config on its first boot from the disk.<\/li>\n<\/ol>\n<\/li>\n\n\n\n<li><strong>Method 2: PXE\/iPXE Boot + HTTP(S)\/TFTP Server:<\/strong>\n<ol class=\"wp-block-list\">\n<li>Configure your PXE boot environment (DHCP options, TFTP server) to serve the FCOS PXE kernel (<code>vmlinuz<\/code>) and initramfs (<code>initrd.img<\/code>) files <sup>70<\/sup>-.<sup>107<\/sup><\/li>\n\n\n\n<li>Host the <code>.ign<\/code> files on an accessible HTTP, HTTPS, or TFTP server.<sup>70<\/sup><\/li>\n\n\n\n<li>In the PXE configuration (e.g., <code>pxelinux.cfg<\/code> or iPXE script), append kernel arguments to specify the Ignition config URL for the specific node type booting.<sup>103<\/sup> Key arguments include <code>ignition.firstboot=1<\/code>, <code>ignition.platform.id=metal<\/code> (for bare metal), and <code>ignition.config.url=&lt;URL_to_specific.ign><\/code>.<sup>108<\/sup> Code snippet<code># Example iPXE snippet for a worker node kernel fedora-coreos-&lt;version>-live-kernel-&lt;arch> ignition.firstboot=1 ignition.platform.id=metal ignition.config.url=http:\/\/192.168.1.10:8080\/worker.ign mitigations=auto,nosmt console=ttyS0,115200n8 console=tty0 initrd fedora-coreos-&lt;version>-live-initramfs.&lt;arch>.img fedora-coreos-&lt;version>-live-rootfs.&lt;arch>.img boot<\/code><\/li>\n<\/ol>\n<\/li>\n\n\n\n<li><strong>Method 3: Virtual Machine User Data \/ Metadata:<\/strong>\n<ul class=\"wp-block-list\">\n<li>For virtualized environments (like vSphere, OpenStack, KVM\/libvirt), the hypervisor often provides a mechanism to pass &#8220;user data&#8221; or &#8220;metadata&#8221; to the guest VM during creation.<\/li>\n\n\n\n<li>Ignition can read configuration from these sources (e.g., vSphere <code>guestinfo.ignition.config.data<\/code>, OpenStack metadata service, QEMU fw_cfg).<\/li>\n\n\n\n<li>The content of the appropriate <code>.ign<\/code> file can be base64 encoded and provided through this mechanism, often eliminating the need for an external HTTP server. Consult the specific hypervisor and FCOS documentation for details on platform IDs and user data formats.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">D. Hosting Ignition Files (If Required)<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If using methods 1 or 2 where Ignition configs are fetched via URL:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Setup HTTP Server:<\/strong> A simple way is to use Python&#8217;s built-in HTTP server on the installer machine (ensure Python 3 is installed).<sup>70<\/sup> Navigate to the installation directory (<code>~\/okd-install-upi<\/code> in our example) where the <code>.ign<\/code> files reside and run: Bash<code>python3 -m http.server 8080<\/code> Alternatively, use a dedicated web server like Apache or Nginx.<\/li>\n\n\n\n<li><strong>Accessibility:<\/strong> Ensure the server&#8217;s IP address and port (e.g., <code>192.168.1.10:8080<\/code>) are reachable from the network segment where the OKD nodes will boot. Adjust firewall rules on the server machine if necessary.<sup>105<\/sup><\/li>\n\n\n\n<li><strong>Security:<\/strong> Using plain HTTP transmits Ignition files unencrypted, potentially exposing sensitive data like SSH keys. Using HTTPS is more secure but requires managing TLS certificates and potentially trusting a custom CA within the FCOS boot process.<sup>110<\/sup> For HTTP, always use <code>--ignition-hash<\/code> with <code>coreos-installer<\/code> or ensure the <code>ignition.config.url<\/code> includes verification if passed via kernel args.<sup>103<\/sup><\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The reliable delivery of the correct Ignition file during the initial boot sequence is a frequent point of failure in UPI installations. Problems can arise from incorrect URLs, network connectivity issues, firewall blocks, inaccessible HTTP servers, or improperly formatted\/encoded Ignition data passed via VM metadata. Careful planning and testing of the chosen delivery method are essential.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">VIII. Step 7: Monitoring the Bootstrap Process<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Once the bootstrap node and the initial control plane nodes are provisioned and successfully boot with their respective Ignition configurations, the cluster bootstrapping phase begins. This critical phase establishes the permanent control plane.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Running <code>wait-for bootstrap-complete<\/code><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">On the installer machine, initiate the monitoring command:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bash<\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; title: ; notranslate\" title=\"\">\nopenshift-install wait-for bootstrap-complete --dir=&amp;lt;installation_directory&gt; --log-level=info\n\n<\/pre><\/div>\n\n\n<p class=\"wp-block-paragraph\"><sup>16<\/sup><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Purpose:<\/strong> This command polls the cluster&#8217;s API server (initially hosted on the bootstrap node, then transitioning to the control plane nodes via the API load balancer) and monitors the status of critical components like etcd.<sup>9<\/sup> It waits until the permanent control plane, running on the designated master nodes, is successfully initialized and has formed an etcd quorum.<\/li>\n\n\n\n<li><strong>Monitoring:<\/strong> The command provides high-level status updates. For detailed progress or troubleshooting:\n<ul class=\"wp-block-list\">\n<li>Use <code>--log-level=debug<\/code> for more verbose output from the installer.<sup>39<\/sup><\/li>\n\n\n\n<li>Monitor the installer log file: <code>&lt;installation_directory>\/.openshift_install.log<\/code>.<sup>39<\/sup><\/li>\n\n\n\n<li>SSH into the <em>bootstrap<\/em> node (using the SSH key provided during config) and monitor the bootstrap service logs: <code>ssh core@&lt;bootstrap_ip> journalctl -b -f -u bootkube.service<\/code>.<sup>39<\/sup> Look for etcd connection errors initially, which should resolve as control plane nodes come online.<sup>39<\/sup><\/li>\n\n\n\n<li>SSH into the <em>control plane<\/em> nodes and monitor <code>kubelet<\/code> and <code>crio<\/code> service logs: <code>ssh core@&lt;master_ip> journalctl -b -f -u kubelet.service<\/code> and <code>... -u crio.service<\/code>.<sup>39<\/sup><\/li>\n\n\n\n<li>If the command fails with timeouts, it doesn&#8217;t always indicate a fatal error, especially on slower infrastructure. The command can sometimes be re-run.<sup>111<\/sup> However, persistent timeouts often point to underlying issues with node provisioning, networking, DNS, load balancing, or Ignition configuration.<sup>40<\/sup> Use <code>openshift-install gather bootstrap<\/code> to collect detailed logs for analysis.<sup>40<\/sup><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">B. Decommissioning the Bootstrap Node<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Successful completion of <code>wait-for bootstrap-complete<\/code> marks a major milestone: the permanent, high-availability control plane is operational on the master nodes, and the temporary bootstrap environment is no longer required.<sup>9<\/sup><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Shut Down:<\/strong> Power off and delete the bootstrap machine (VM or physical server).<sup>9<\/sup><\/li>\n\n\n\n<li><strong>Update Load Balancer:<\/strong> Remove the bootstrap machine&#8217;s IP address from the backend pool of the <strong>API Load Balancer<\/strong> (ports 6443 and 22623).<sup>10<\/sup> The pool should now only contain the IP addresses of the three control plane nodes.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">This transition from the temporary bootstrap control plane to the permanent HA control plane is arguably the most complex part of the installation. Failures occurring before this stage often relate back to fundamental infrastructure prerequisites (networking, DNS, LBs, Ignition delivery). Failures after this point are more commonly associated with cluster operator deployment or control plane component stability.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">IX. Step 8: Finalizing Installation and Verification<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">With the bootstrap process complete and the bootstrap node removed, the final steps involve waiting for the cluster operators to stabilize and verifying cluster access and health.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A. Running <code>wait-for install-complete<\/code><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Execute the final monitoring command on the installer machine:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bash<\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: plain; title: ; notranslate\" title=\"\">\nopenshift-install wait-for install-complete --dir=&amp;lt;installation_directory&gt; --log-level=info\n\n<\/pre><\/div>\n\n\n<p class=\"wp-block-paragraph\"><sup>16<\/sup><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Purpose:<\/strong> This command monitors the Cluster Version Operator (CVO) and other essential cluster operators.<sup>9<\/sup> It waits until these operators report themselves as <code>Available<\/code>, not <code>Progressing<\/code>, and not <code>Degraded<\/code>, indicating that the cluster&#8217;s core services have successfully rolled out and stabilized.<\/li>\n\n\n\n<li><strong>Monitoring &amp; Timeouts:<\/strong> Similar to the bootstrap wait, this command has a timeout (e.g., 30 minutes mentioned in <sup>114<\/sup>). On slower systems, or if complex operator configurations are involved, it might time out even if the cluster is ultimately healthy.<sup>114<\/sup> The command primarily checks operator status; nodes might still be coming to full readiness or some operators might still be performing final synchronization tasks even after the command reports success or times out.<sup>114<\/sup> Use <code>--log-level=debug<\/code> for details.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">B. Accessing the Cluster<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Export Kubeconfig:<\/strong> The installer generated a <code>kubeconfig<\/code> file containing API server details and initial administrative credentials. Set the <code>KUBECONFIG<\/code> environment variable to point to this file: Bash<code>export KUBECONFIG=&lt;installation_directory>\/auth\/kubeconfig<\/code> (Replace <code>&lt;installation_directory><\/code> with the actual path, e.g., <code>~\/okd-install-upi\/auth\/kubeconfig<\/code>).<sup>16<\/sup> This tells <code>oc<\/code> how to connect to your new cluster.<\/li>\n\n\n\n<li><strong>Login with <code>kubeadmin<\/code>:<\/strong>\n<ul class=\"wp-block-list\">\n<li><strong>Retrieve Password:<\/strong> Get the temporary administrative password from the generated file: Bash<code>cat &lt;installation_directory>\/auth\/kubeadmin-password<\/code> <sup>16<\/sup> (Alternatively, the password might be found in the <code>.openshift_install.log<\/code> file <sup>97<\/sup>).<\/li>\n\n\n\n<li><strong>Login via CLI:<\/strong> Use the <code>oc<\/code> command to log in: Bash<code>oc login -u kubeadmin -p &lt;password_from_file><\/code> <sup>16<\/sup> (The API server URL is typically embedded in the kubeconfig file).<\/li>\n\n\n\n<li><strong><code>kubeadmin<\/code> User:<\/strong> This user is created automatically during installation with full <code>cluster-admin<\/code> privileges.<sup>98<\/sup> It is intended for initial cluster access only. For security best practices, <strong>this user should be removed<\/strong> after configuring a proper identity provider (like HTPasswd, LDAP, GitHub, etc.) and granting <code>cluster-admin<\/code> privileges to one or more regular user accounts.<sup>98<\/sup> To remove it:\n<ol class=\"wp-block-list\">\n<li>Configure at least one identity provider (see OKD documentation on authentication).<\/li>\n\n\n\n<li>Grant the <code>cluster-admin<\/code> role to a user from that provider: <code>oc adm policy add-cluster-role-to-user cluster-admin &lt;username><\/code>.<\/li>\n\n\n\n<li>Log out as <code>kubeadmin<\/code> and log in as the new administrative user.<\/li>\n\n\n\n<li>Delete the <code>kubeadmin<\/code> secret: <code>oc delete secret kubeadmin -n kube-system<\/code>.<sup>98<\/sup> This action is irreversible without reinstalling the cluster.<sup>98<\/sup><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">C. Verifying Cluster Status<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Even after <code>wait-for install-complete<\/code> succeeds, perform manual checks to confirm cluster health:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Check Nodes:<\/strong> Verify all control plane and compute nodes are registered and <code>Ready<\/code>: Bash<code>oc get nodes<\/code> <sup>16<\/sup> The output should list all expected nodes with <code>STATUS<\/code> as <code>Ready<\/code>.<\/li>\n\n\n\n<li><strong>Check Cluster Operators:<\/strong> Examine the status of core cluster operators: Bash<code>oc get clusteroperators # or shorthand: oc get co<\/code> <sup>16<\/sup> All operators should ideally show <code>AVAILABLE=True<\/code>, <code>PROGRESSING=False<\/code>, <code>DEGRADED=False<\/code>. <code>PROGRESSING=True<\/code> might occur briefly after installation but should resolve. <code>DEGRADED=True<\/code> indicates an issue with that operator requiring investigation.<\/li>\n\n\n\n<li><strong>Access Web Console:<\/strong>\n<ul class=\"wp-block-list\">\n<li><strong>Find URL:<\/strong> The console URL is usually printed by the installer <sup>97<\/sup> or can be found using <code>oc<\/code>: Bash<code>oc whoami --show-console<\/code> <sup>100<\/sup> It typically follows the pattern <code>https:\/\/console-openshift-console.apps.&lt;cluster_name>.&lt;base_domain><\/code>.<\/li>\n\n\n\n<li><strong>Login:<\/strong> Open the URL in a web browser. Accept any self-signed certificate warnings initially. Log in using the username <code>kubeadmin<\/code> and the password retrieved earlier.<sup>16<\/sup><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">While <code>wait-for install-complete<\/code> signals the end of the automated installation phases monitored by the installer, operators might still be finalizing their setup.<sup>114<\/sup> Therefore, relying on <code>oc get nodes<\/code> and <code>oc get co<\/code> provides a more definitive confirmation that the cluster components are truly ready and stable before deploying applications.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">X. Conclusion<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">A. Summary<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">This guide has detailed the step-by-step process for installing OKD, the community distribution of Kubernetes, on user-provisioned infrastructure (bare metal or virtual machines) using the official <code>openshift-install<\/code> tool. The process involves careful preparation of prerequisites (hardware, networking, DNS, load balancers), downloading the correct installation tools and FCOS images, generating configuration files (<code>install-config.yaml<\/code>, manifests, Ignition configs), provisioning and booting nodes with Ignition, monitoring the critical bootstrap phase, and finally verifying the cluster&#8217;s operational status. Successful completion results in a functional, multi-node OKD cluster managed by the administrator.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">B. Next Steps<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">With the basic OKD cluster installed and verified, several crucial post-installation tasks should be addressed:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Configure Identity Provider &amp; Remove <code>kubeadmin<\/code>:<\/strong> This is the most critical immediate security step. Configure integration with an external identity provider (LDAP, HTPasswd, OAuth, etc.) and grant administrative privileges to regular users. Subsequently, remove the temporary <code>kubeadmin<\/code> user as previously described.<sup>98<\/sup><\/li>\n\n\n\n<li><strong>Configure Persistent Storage:<\/strong> By default, pods have ephemeral storage. For stateful applications, configure persistent storage solutions. This might involve setting up an NFS provisioner, deploying a storage platform like Ceph using the Rook operator, or configuring CSI drivers for underlying storage infrastructure.<\/li>\n\n\n\n<li><strong>Review Monitoring and Logging:<\/strong> Familiarize yourself with OKD&#8217;s built-in monitoring stack (Prometheus, Grafana) and logging components (often based on Loki or Elasticsearch\/Fluentd\/Kibana). Configure alerts and log forwarding as needed.<\/li>\n\n\n\n<li><strong>Explore Cluster Operators:<\/strong> Investigate available operators via OperatorHub (if default sources were not disabled) to extend cluster functionality (e.g., service mesh, serverless, database operators).<\/li>\n\n\n\n<li><strong>Deploy Applications:<\/strong> Begin deploying containerized applications using <code>oc<\/code> commands, YAML manifests, or the OKD web console&#8217;s developer perspective.<sup>29<\/sup><\/li>\n\n\n\n<li><strong>Consult Documentation:<\/strong> Refer to the official OKD documentation (<code>docs.okd.io<\/code>) for detailed guidance on cluster administration, security hardening, network configuration, storage management, and application development workflows.<sup>27<\/sup><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>I. Introduction A. Overview of OKD OKD, formerly known as OpenShift Origin, stands as the community distribution of Kubernetes, serving [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-12112","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.4 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide - scmGalaxy<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide - scmGalaxy\" \/>\n<meta property=\"og:description\" content=\"I. Introduction A. Overview of OKD OKD, formerly known as OpenShift Origin, stands as the community distribution of Kubernetes, serving [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/\" \/>\n<meta property=\"og:site_name\" content=\"scmGalaxy\" \/>\n<meta property=\"article:published_time\" content=\"2025-04-15T14:18:54+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-04-15T14:18:56+00:00\" \/>\n<meta name=\"author\" content=\"rajeshkumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"rajeshkumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"30 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/\"},\"author\":{\"name\":\"rajeshkumar\",\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/#\\\/schema\\\/person\\\/a40e0dd38feee7c2779460a804d49361\"},\"headline\":\"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide\",\"datePublished\":\"2025-04-15T14:18:54+00:00\",\"dateModified\":\"2025-04-15T14:18:56+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/\"},\"wordCount\":4971,\"commentCount\":0,\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/\",\"url\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/\",\"name\":\"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide - scmGalaxy\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/#website\"},\"datePublished\":\"2025-04-15T14:18:54+00:00\",\"dateModified\":\"2025-04-15T14:18:56+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/#\\\/schema\\\/person\\\/a40e0dd38feee7c2779460a804d49361\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/#website\",\"url\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/\",\"name\":\"scmGalaxy\",\"description\":\"A Platform for Software Engineers\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/#\\\/schema\\\/person\\\/a40e0dd38feee7c2779460a804d49361\",\"name\":\"rajeshkumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/82337e1fc8642c7f36795aa0775af055a4f38882994004b593efd31758d4434e?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/82337e1fc8642c7f36795aa0775af055a4f38882994004b593efd31758d4434e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/82337e1fc8642c7f36795aa0775af055a4f38882994004b593efd31758d4434e?s=96&d=mm&r=g\",\"caption\":\"rajeshkumar\"},\"url\":\"https:\\\/\\\/www.scmgalaxy.com\\\/tutorials\\\/author\\\/rajeshkumar\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide - scmGalaxy","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/","og_locale":"en_US","og_type":"article","og_title":"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide - scmGalaxy","og_description":"I. Introduction A. Overview of OKD OKD, formerly known as OpenShift Origin, stands as the community distribution of Kubernetes, serving [&hellip;]","og_url":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/","og_site_name":"scmGalaxy","article_published_time":"2025-04-15T14:18:54+00:00","article_modified_time":"2025-04-15T14:18:56+00:00","author":"rajeshkumar","twitter_card":"summary_large_image","twitter_misc":{"Written by":"rajeshkumar","Est. reading time":"30 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/#article","isPartOf":{"@id":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/"},"author":{"name":"rajeshkumar","@id":"https:\/\/www.scmgalaxy.com\/tutorials\/#\/schema\/person\/a40e0dd38feee7c2779460a804d49361"},"headline":"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide","datePublished":"2025-04-15T14:18:54+00:00","dateModified":"2025-04-15T14:18:56+00:00","mainEntityOfPage":{"@id":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/"},"wordCount":4971,"commentCount":0,"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/","url":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/","name":"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide - scmGalaxy","isPartOf":{"@id":"https:\/\/www.scmgalaxy.com\/tutorials\/#website"},"datePublished":"2025-04-15T14:18:54+00:00","dateModified":"2025-04-15T14:18:56+00:00","author":{"@id":"https:\/\/www.scmgalaxy.com\/tutorials\/#\/schema\/person\/a40e0dd38feee7c2779460a804d49361"},"breadcrumb":{"@id":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.scmgalaxy.com\/tutorials\/installing-okd-on-user-provisioned-infrastructure-a-step-by-step-guide\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.scmgalaxy.com\/tutorials\/"},{"@type":"ListItem","position":2,"name":"Installing OKD on User-Provisioned Infrastructure: A Step-by-Step Guide"}]},{"@type":"WebSite","@id":"https:\/\/www.scmgalaxy.com\/tutorials\/#website","url":"https:\/\/www.scmgalaxy.com\/tutorials\/","name":"scmGalaxy","description":"A Platform for Software Engineers","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.scmgalaxy.com\/tutorials\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.scmgalaxy.com\/tutorials\/#\/schema\/person\/a40e0dd38feee7c2779460a804d49361","name":"rajeshkumar","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/82337e1fc8642c7f36795aa0775af055a4f38882994004b593efd31758d4434e?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/82337e1fc8642c7f36795aa0775af055a4f38882994004b593efd31758d4434e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/82337e1fc8642c7f36795aa0775af055a4f38882994004b593efd31758d4434e?s=96&d=mm&r=g","caption":"rajeshkumar"},"url":"https:\/\/www.scmgalaxy.com\/tutorials\/author\/rajeshkumar\/"}]}},"_links":{"self":[{"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/posts\/12112","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/comments?post=12112"}],"version-history":[{"count":1,"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/posts\/12112\/revisions"}],"predecessor-version":[{"id":12113,"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/posts\/12112\/revisions\/12113"}],"wp:attachment":[{"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/media?parent=12112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/categories?post=12112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.scmgalaxy.com\/tutorials\/wp-json\/wp\/v2\/tags?post=12112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}