Merge pull request #34407 from vikram-redhat/consciouslang

[WIP] Conscious lang update: master to control plane

Author: vikram-redhat

_unused_topics/monitoring-configuring-etcd-monitoring.adoc

@@ -39,7 +39,7 @@ $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 
 . Under `config.yaml: |+`, add the `etcd` section.
 +
-.. If you run `etcd` in static pods on your master nodes, you can specify the `etcd` nodes using the selector:
+.. If you run `etcd` in static pods on your control plane nodes (also known as master nodes), you can specify the `etcd` nodes using the selector:
 +
 [subs="quotes"]
 ----
@@ -118,7 +118,7 @@ image::etcd-no-certificate.png[]
 
 While `etcd` is being monitored, Prometheus is not yet able to authenticate against `etcd`, and so cannot gather metrics. To configure Prometheus authentication against `etcd`:
 
-. Copy the `/etc/etcd/ca/ca.crt` and `/etc/etcd/ca/ca.key` credentials files from the master node to the local machine:
+. Copy the `/etc/etcd/ca/ca.crt` and `/etc/etcd/ca/ca.key` credentials files from the control plane node (also known as the master node) to the local machine:
 +
 [subs="quotes"]
 ----

_unused_topics/nodes-nodes-audit-log-advanced.adoc

@@ -19,7 +19,7 @@ openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/lib/origi
 
 [IMPORTANT]
 ====
-The policy file *_/etc/origin/master/adv-audit.yaml_* must be available on each master node.
+The policy file *_/etc/origin/master/adv-audit.yaml_* must be available on each control plane node (also known as the master node).
 ====
 
 
@@ -137,4 +137,3 @@ that group.
 For more information on advanced audit, see the
 link:https://kubernetes.io/docs/tasks/debug-application-cluster/audit[Kubernetes
 documentation]
-

architecture/understanding-development.adoc

@@ -124,7 +124,7 @@ so there is less overhead in running them.
 
 When you ultimately run your containers in {product-title}, you use the
 link:https://cri-o.io/[CRI-O] container engine. CRI-O runs on every worker and
-master machine in an {product-title} cluster, but CRI-O is not yet supported as
+control plane machine (also known as the master machine) in an {product-title} cluster, but CRI-O is not yet supported as
 a standalone runtime outside of {product-title}.
 
 [id="base-image-options"]

backup_and_restore/backing-up-etcd.adoc

@@ -19,13 +19,13 @@ Be sure to take an etcd backup after you upgrade your cluster. This is important
 
 [IMPORTANT]
 ====
-Back up your cluster's etcd data by performing a single invocation of the backup script on a master host. Do not take a backup for each master host.
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host (also known as the master host). Do not take a backup for each control plane host.
 ====
 
 After you have an etcd backup, you can xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore to a previous cluster state].
 
 You can perform the xref:../backup_and_restore/backing-up-etcd.adoc#backing-up-etcd-data_backup-etcd[etcd data backup process]
-on any master host that has a running etcd instance.
+on any control plane host that has a running etcd instance.
 
 // Backing up etcd data
 include::modules/backup-etcd.adoc[leveloffset=+1]

backup_and_restore/disaster_recovery/about-disaster-recovery.adoc

@@ -13,13 +13,13 @@ state.
 
 [IMPORTANT]
 ====
-Disaster recovery requires you to have at least one healthy master host.
+Disaster recovery requires you to have at least one healthy control plane host (also known as the master host).
 ====
 
 xref:../../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[Restoring to a previous cluster state]::
 This solution handles situations where you want to restore your cluster to
 a previous state, for example, if an administrator deletes something critical.
-This also includes situations where you have lost the majority of your master hosts, leading to etcd quorum loss and the cluster going offline. As long as you have taken an etcd backup, you can follow this procedure to restore your cluster to a previous state.
+This also includes situations where you have lost the majority of your control plane hosts, leading to etcd quorum loss and the cluster going offline. As long as you have taken an etcd backup, you can follow this procedure to restore your cluster to a previous state.
 +
 If applicable, you might also need to xref:../../backup_and_restore/disaster_recovery/scenario-3-expired-certs.adoc#dr-recovering-expired-certs[recover from expired control plane certificates].
 +

backup_and_restore/replacing-unhealthy-etcd-member.adoc

@@ -11,11 +11,11 @@ This process depends on whether the etcd member is unhealthy because the machine
 
 [NOTE]
 ====
-If you have lost the majority of your master hosts, leading to etcd quorum loss, then you must follow the disaster recovery procedure to xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore to a previous cluster state] instead of this procedure.
+If you have lost the majority of your control plane hosts (also known as the master hosts), leading to etcd quorum loss, then you must follow the disaster recovery procedure to xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore to a previous cluster state] instead of this procedure.
 
 If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../backup_and_restore/disaster_recovery/scenario-3-expired-certs.adoc#dr-recovering-expired-certs[recover from expired control plane certificates] instead of this procedure.
 
-If a master node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
+If a control plane node is lost and a new one is created, the etcd cluster Operator handles generating the new TLS certificates and adding the node as an etcd member.
 ====
 
 == Prerequisites

contributing_to_docs/term_glossary.adoc

@@ -286,7 +286,7 @@ Usage: Ignition config file or Ignition config files
 
 The file that Ignition uses to configure Red Hat Enterprise Linux CoreOS (RHCOS) during
 operating system initialization. The installation program generates different
-Ignition config files to initialize bootstrap, master, and worker nodes.
+Ignition config files to initialize bootstrap, control plane, and worker nodes.
 
 ''''
 
@@ -332,17 +332,16 @@ Usage: kubelet(s)
 
 The agent that controls a Kubernetes node.  Each node runs a kubelet, which
 handles starting and stopping containers on a node, based on the desired state
-defined by the master.
+defined by the control plane (also known as master).
 
 ''''
-=== Kubernetes master
+=== Kubernetes control plane
 
-Usage: Kubernetes master(s)
+Usage: Kubernetes control plane
 
-The Kubernetes-native equivalent to the link:#project[OpenShift master].
-An OpenShift system runs OpenShift masters, not Kubernetes masters, and
-an OpenShift master provides a superset of the functionality of a Kubernetes
-master, so it is generally preferred to use the term OpenShift master.
+The Kubernetes-native equivalent to the link:#project[OpenShift control plane].
+An OpenShift system runs OpenShift control planes (also known as masters), not Kubernetes control planes, and
+an OpenShift control plane provides a superset of the functionality of a Kubernetes control plane, so it is generally preferred to use the term OpenShift control plane.
 
 ''''
 === Kubernetes API server
@@ -415,16 +414,16 @@ When referencing as a prerequisite for a procedure module, use the following
 construction: Install the OpenShift CLI (`oc`).
 
 ''''
-=== OpenShift master
+=== OpenShift control plane (also known as master)
 
-Usage: OpenShift master(s)
+Usage: OpenShift control plane
 
 Provides a REST endpoint for interacting with the system and manages the state
 of the system, ensuring that all containers expected to be running are actually
 running and that other requests such as builds and deployments are serviced.
 New deployments and configurations are created with the REST API, and the state
 of the system can be interrogated through this endpoint as well.  An OpenShift
-master comprises the API server, scheduler, and SkyDNS.
+control plane comprises the API server, scheduler, and SkyDNS.
 
 ''''
 === Operator
@@ -561,7 +560,7 @@ caching, or traffic controls on the service content.
 
 Usage: scheduler(s)
 
-Component of the Kubernetes master or OpenShift master that manages the state of
+Component of the Kubernetes control plane or OpenShift control plane that manages the state of
 the system, places pods on nodes, and ensures that all containers that are
 expected to be running are actually running.
 
@@ -620,7 +619,7 @@ A service account binds together:
 
 Usage: SkyDNS
 
-Component of the Kubernetes master or OpenShift master that provides
+Component of the Kubernetes control plane or OpenShift control plane that provides
 cluster-wide DNS resolution of internal host names for services and pods.
 
 ''''

machine_management/creating-infrastructure-machinesets.adoc

@@ -9,7 +9,7 @@ You can create a machine set to host only infrastructure components. You apply s
 
 [IMPORTANT]
 ====
-Unlike earlier versions of {product-title}, you cannot move the infrastructure components to the master machines. To move the components, you must create a new machine set.
+Unlike earlier versions of {product-title}, you cannot move the infrastructure components to the control plane machines (also known as the master machines). To move the components, you must create a new machine set.
 ====
 
 include::modules/infrastructure-components.adoc[leveloffset=+1]

modules/accessing-hosts-on-aws.adoc

@@ -41,7 +41,7 @@ API is responsive, run privileged pods instead.
 master. The host name looks similar to `ip-10-0-1-163.ec2.internal`.
 
 . From the bastion SSH host you manually deployed into Amazon EC2, SSH into that
-master host. Ensure that you use the same SSH key you specified during the
+control plane host (also known as the master host). Ensure that you use the same SSH key you specified during the
 installation:
 +
 [source,terminal]

modules/architecture-kubernetes-introduction.adoc

@@ -15,7 +15,7 @@ deployment, scaling, and management of containerized applications. The general
 concept of Kubernetes is fairly simple:
 
 * Start with one or more worker nodes to run the container workloads.
-* Manage the deployment of those workloads from one or more master nodes.
+* Manage the deployment of those workloads from one or more control plane nodes (also known as the master nodes).
 * Wrap containers in a deployment unit called a pod. Using pods provides extra
 metadata with the container and offers the ability to group several containers
 in a single deployment entity.