mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
44 lines
4.7 KiB
Plaintext
44 lines
4.7 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * installing/overview/index.adoc
|
|
// * architecture/architecture-installation.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="installation-overview_{context}"]
|
|
= About {product-title} installation
|
|
|
|
The {product-title} installation program offers four methods for deploying a cluster which are detailed in the following list:
|
|
|
|
* *Interactive*: You can deploy a cluster with the web-based link:https://access.redhat.com/documentation/en-us/assisted_installer_for_openshift_container_platform[{ai-full}]. This is an ideal approach for clusters with networks connected to the internet. The {ai-full} is the easiest way to install {product-title}, it provides smart defaults, and it performs pre-flight validations before installing the cluster. It also provides a RESTful API for automation and advanced configuration scenarios.
|
|
|
|
* *Local Agent-based*: You can deploy a cluster locally with the Agent-based Installer for disconnected environments or restricted networks. It provides many of the benefits of the {ai-full}, but you must download and configure the link:https://console.redhat.com/openshift/install/metal/agent-based[Agent-based Installer] first. Configuration is done with a command-line interface. This approach is ideal for disconnected environments.
|
|
|
|
* *Automated*: You can deploy a cluster on installer-provisioned infrastructure. The installation program uses each cluster host's baseboard management controller (BMC) for provisioning. You can deploy clusters in connected or disconnected environments.
|
|
|
|
* *Full control*: You can deploy a cluster on infrastructure that you prepare and maintain, which provides maximum customizability. You can deploy clusters in connected or disconnected environments.
|
|
|
|
Each method deploys a cluster with the following characteristics:
|
|
|
|
* Highly available infrastructure with no single points of failure, which is available by default.
|
|
* Administrators can control what updates are applied and when.
|
|
|
|
[id="about-the-installation-program"]
|
|
== About the installation program
|
|
|
|
You can use the installation program to deploy each type of cluster. The installation program generates the main assets, such as Ignition config files for the bootstrap, control plane, and compute machines. You can start an {product-title} cluster with these three machine configurations, provided you correctly configured the infrastructure.
|
|
|
|
The {product-title} installation program uses a set of targets and dependencies to manage cluster installations. The installation program has a set of targets that it must achieve, and each target has a set of dependencies. Because each target is only concerned with its own dependencies, the installation program can act to achieve multiple targets in parallel with the ultimate target being a running cluster. The installation program recognizes and uses existing components instead of running commands to create them again because the program meets the dependencies.
|
|
|
|
.{product-title} installation targets and dependencies
|
|
image::targets-and-dependencies.png[{product-title} installation targets and dependencies]
|
|
|
|
|
|
[id="about-rhcos"]
|
|
== About {op-system-first}
|
|
|
|
Post-installation, each cluster machine uses {op-system-first} as the operating system. {op-system} is the immutable container host version of {op-system-base-full} and features a {op-system-base} kernel with SELinux enabled by default. {op-system} includes the `kubelet`, which is the Kubernetes node agent, and the CRI-O container runtime, which is optimized for Kubernetes.
|
|
|
|
Every control plane machine in an {product-title} {product-version} cluster must use {op-system}, which includes a critical first-boot provisioning tool called Ignition. This tool enables the cluster to configure the machines. Operating system updates are delivered as a bootable container image, using **OSTree** as a backend, that is deployed across the cluster by the Machine Config Operator. Actual operating system changes are made in-place on each machine as an atomic operation by using **rpm-ostree**. Together, these technologies enable {product-title} to manage the operating system like it manages any other application on the cluster, by in-place upgrades that keep the entire platform up to date. These in-place updates can reduce the burden on operations teams.
|
|
|
|
If you use {op-system} as the operating system for all cluster machines, the cluster manages all aspects of its components and machines, including the operating system. Because of this, only the installation program and the Machine Config Operator can change machines. The installation program uses Ignition config files to set the exact state of each machine, and the Machine Config Operator completes more changes to the machines, such as the application of new certificates or keys, after installation.
|