mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-06 06:46:26 +01:00
43 lines
3.6 KiB
Plaintext
43 lines
3.6 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * installing/index.adoc
|
|
// * architecture/architecture-installation.adoc
|
|
|
|
:_content-type: CONCEPT
|
|
[id="installation-overview_{context}"]
|
|
= About {product-title} installation
|
|
|
|
The {product-title} installation program offers you flexibility. You can use the program to:
|
|
|
|
* Deploy a cluster on provisioned infrastructure and the cluster it maintains.
|
|
* Deploy a cluster on infrastructure that you prepare and maintain.
|
|
|
|
These two basic types of {product-title} clusters are frequently called:
|
|
|
|
* Installer-provisioned infrastructure clusters.
|
|
* User-provisioned infrastructure clusters.
|
|
|
|
Both cluster types have the following characteristics:
|
|
|
|
* Highly available infrastructure with no single points of failure is available by default.
|
|
* Administrators maintain control over what updates are applied and when.
|
|
|
|
[id="about-the-installation-program"]
|
|
== About the installation program
|
|
|
|
You can use the installation program to deploy both types of clusters. The installation program generates main assets such as Ignition config files for the bootstrap, master, and worker machines. You can start an {product-title} cluster with these three configurations and correctly configured 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 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. It 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 an **Atomic OSTree** repository that is embedded in a container image that is deployed across the cluster by an 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.
|