In {product-title} {product-version}, you can install a cluster on bare metal infrastructure that you provision in a restricted network.
|
Important
|
While you might be able to follow this procedure to deploy a cluster on virtualized or cloud environments, you must be aware of additional considerations for non-bare metal platforms. Review the information in the guidelines for deploying {product-title} on non-tested platforms before you attempt to install an {product-title} cluster in such an environment. |
-
You reviewed details about the {product-title} installation and update processes.
-
You read the documentation on selecting a cluster installation method and preparing it for users.
-
You created a registry on your mirror host and obtained the
imageContentSourcesdata for your version of {product-title}.ImportantBecause the installation media is on the mirror host, you can use that computer to complete all installation steps.
-
You provisioned persistent storage for your cluster. To deploy a private image registry, your storage must provide ReadWriteMany access modes.
-
If you use a firewall and plan to use the Telemetry service, you configured the firewall to allow the sites that your cluster requires access to.
NoteBe sure to also review this site list if you are configuring a proxy.
-
See Configuring a three-node cluster for details about deploying three-node clusters in bare metal environments.
-
See Approving the certificate signing requests for your machines for more information about approving cluster certificate signing requests after installation.
-
See Load balancing requirements for user-provisioned infrastructure for more information on the API and application ingress load balancing requirements.
-
See Recovering from expired control plane certificates for more information about recovering kubelet certificates.
To install {product-title} on bare metal infrastructure that you provision, you must install {op-system-first} on the machines. When you install {op-system}, you must provide the Ignition config file that was generated by the {product-title} installation program for the type of machine you are installing. If you have configured suitable networking, DNS, and load balancing infrastructure, the {product-title} bootstrap process begins automatically after the {op-system} machines have rebooted.
To install {op-system} on the machines, follow either the steps to use an ISO image or network PXE booting.
|
Note
|
The compute node deployment steps included in this installation document are {op-system}-specific. If you choose instead to deploy {op-system-base}-based compute nodes, you take responsibility for all operating system life cycle management and maintenance, including performing system updates, applying patches, and completing all other required tasks. Use of {op-system-base} 7 compute machines is deprecated and planned for removal in a future release of {product-title} 4. |
You can configure {op-system} during ISO and PXE installations by using the following methods:
-
Kernel arguments: You can use kernel arguments to provide installation-specific information. For example, you can specify the locations of the {op-system} installation files that you uploaded to your HTTP server and the location of the Ignition config file for the type of node you are installing. For a PXE installation, you can use the
APPENDparameter to pass the arguments to the kernel of the live installer. For an ISO installation, you can interrupt the live installation boot process to add the kernel arguments. In both installation cases, you can use specialcoreos.inst.*arguments to direct the live installer, as well as standard installation boot arguments for turning standard kernel services on or off. -
Ignition configs: {product-title} Ignition config files (
*.ign) are specific to the type of node you are installing. You pass the location of a bootstrap, control plane, or compute node Ignition config file during the {op-system} installation so that it takes effect on first boot. In special cases, you can create a separate, limited Ignition config to pass to the live system. That Ignition config could do a certain set of tasks, such as reporting success to a provisioning system after completing installation. This special Ignition config is consumed by thecoreos-installerto be applied on first boot of the installed system. Do not provide the standard control plane and compute node Ignition configs to the live ISO directly. -
coreos-installer: You can boot the live ISO installer to a shell prompt, which allows you to prepare the permanent system in a variety of ways before first boot. In particular, you can run thecoreos-installercommand to identify various artifacts to include, work with disk partitions, and set up networking. In some cases, you can configure features on the live system and copy them to the installed system.
Whether to use an ISO or PXE install depends on your situation. A PXE install requires an available DHCP service and more preparation, but can make the installation process more automated. An ISO install is a more manual process and can be inconvenient if you are setting up more than a few machines.
-
See Monitoring installation progress for more information about monitoring the installation logs and retrieving diagnostic data if installation issues arise.
-
See Gathering logs from a failed installation for details about gathering data in the event of a failed {product-title} installation.
-
See Troubleshooting Operator issues for steps to check Operator pod health across the cluster and gather Operator logs for diagnosis.
-
Configure image streams for the Cluster Samples Operator and the
must-gathertool. -
Learn how to use Operator Lifecycle Manager (OLM) on restricted networks.
-
If the mirror registry that you used to install your cluster has a trusted CA, add it to the cluster by configuring additional trust stores.
-
If necessary, you can opt out of remote health reporting.