Merge pull request #46421 from Amrita42/Commonterms-install

Added common terms section to the Installing Book

Author: ahardin-rh

installing/index.adoc

@@ -8,6 +8,8 @@ toc::[]
 
 include::modules/installation-overview.adoc[leveloffset=+1]
 
+include::modules/install-openshift-common-terms.adoc[leveloffset=+2]
+
 include::modules/installation-process.adoc[leveloffset=+2]
 
 include::modules/ipi-verifying-nodes-after-installation.adoc[leveloffset=+2]

modules/install-openshift-common-terms.adoc

@@ -0,0 +1,48 @@
+// Module included in the following assemblies:
+//
+// * installing/index.adoc
+
+:_content-type: REFERENCE
+[id="install-openshift-common-terms_{context}"]
+= Common terms
+
+This glossary defines common terms that are used in the installation content. These terms help you understand installation effectively.
+
+Bootstrap node::
+A temporary machine that runs a minimal Kubernetes configuration to deploy the {product-title} control plane.
+
+Control plane::
+A container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. Also known as control plane machines.
+
+Compute node::
+Nodes that are responsible for executing workloads for cluster users. Also known as worker nodes.
+
+Disconnected installation::
+There are situations where parts of a data center might not have access to the internet, even through proxy servers. You can still install the {product-title} in these environments, but you must download the required software and images and make them available to the disconnected environment.
+
+The {product-title} installation program::
+A program that provisions the infrastructure and deploys a cluster.
+
+Installer-provisioned infrastructure::
+The installation program deploys and configures the infrastructure that the cluster runs on.
+
+Ignition config files::
+A file that Ignition uses to configure {op-system-first} during operating system initialization. The installation program generates different Ignition config files to initialize bootstrap, control plane, and worker nodes.
+
+Kubernetes manifests::
+Specifications of a Kubernetes API object in a JSON or YAML format. A configuration file can include deployments, config maps, secrets, daemonsets etc.
+
+Kubelet::
+A **primary node** agent that runs on each node in the cluster to ensure that containers are running in a pod.
+
+Load balancers::
+A load balancer serves as the single point of contact for clients. Load balancers for the API distribute incoming traffic across control plane nodes.
+
+Machine Config Operator::
+An Operator that manages and applies configuration and updates of the base operating system and container runtime, including everything between the kernel and kubelet for the nodes in the cluster.
+
+Operators::
+The preferred method of packaging, deploying, and managing a Kubernetes application in an {product-title} cluster. An operator takes human operational knowledge and encodes it into software that is easily packaged and shared with customers.
+
+User-provisioned infrastructure::
+You can install {product-title} on infrastructure that you provide. You can use the installation program to generate the assets required to provision the cluster infrastructure, create the cluster infrastructure, and then deploy the cluster to the infrastructure that you provided.

modules/installation-overview.adoc

@@ -5,28 +5,37 @@
 
 :_content-type: CONCEPT
 [id="installation-overview_{context}"]
-= {product-title} installation overview
 
-The {product-title} installation program offers you flexibility. You can use the installation program to deploy a cluster on infrastructure that the installation program provisions and the cluster maintains or deploy a cluster on infrastructure that you prepare and maintain.
+The {product-title} installation program offers you flexibility. You can use the program to:
 
-These two basic types of {product-title} clusters are frequently called installer-provisioned infrastructure clusters and user-provisioned infrastructure clusters.
+* Deploy a cluster on provisioned infrastructure and the cluster it maintains.
+* Deploy a cluster on infrastructure that you prepare and maintain.
 
-Both types of clusters have the following characteristics:
+These two basic types of {product-title} clusters are frequently called:
 
-* Highly available infrastructure with no single points of failure is available by default
-* Administrators maintain control over what updates are applied and when
+* Installer-provisioned infrastructure clusters.
+* User-provisioned infrastructure clusters.
 
-You use the same installation program to deploy both types of clusters. The main assets generated by the installation program are the Ignition config files for the bootstrap, master, and worker machines. With these three configurations and correctly configured infrastructure, you can start an {product-title} cluster.
+Both cluster types have the following characteristics:
 
-The {product-title} installation program uses a set of targets and dependencies to manage cluster installation. 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. The ultimate target is a running cluster. By meeting dependencies instead of running commands, the installation program is able to recognize and use existing components instead of running the commands to create them again.
+* Highly available infrastructure with no single points of failure is available by default.
+* Administrators maintain control over what updates are applied and when.
 
-The following diagram shows a subset of the installation targets and dependencies:
+[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]
 
-After 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.
+[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 rolled out 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, via in-place upgrades that keep the entire platform up-to-date. These in-place updates can reduce the burden on operations teams.
+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.