Merge pull request #44426 from EricPonvelle/OSDOCS-2924_No-More-Masters

EricPonvelle · web-flow · commit 3901462a00c9 · 2022-04-18T11:16:38.000-04:00
OSDOCS-2924: Removed instances of Master from OSD/ROSA
diff --git a/modules/aws-limits.adoc b/modules/aws-limits.adoc
@@ -21,13 +21,13 @@ The following table summarizes the AWS components whose limits can impact your a
 |At a minimum, each cluster creates the following instances:
 
 * One bootstrap machine, which is removed after installation
-* Three master nodes
+* Three control plane nodes
 * Two infrastructure nodes for a single availability zone; three infrascture nodes for multi-availability zones
 * Two worker nodes for a single availability zone; three worker nodes for multi-availability zones
 
 These instance type counts are within a new account's default limit. To deploy more worker nodes, deploy large workloads, or use a different instance type, review your account limits to ensure that your cluster can deploy the machines that you need.
 
-In most regions, the worker machines use an `m6i.large` machine and the bootstrap and master machines use `m6i.xlarge` instances. In some regions, including all regions that do not support these instance types, `m5.large` and `m5.xlarge` instances are used instead.
+In most regions, the bootstrap and worker machines uses an `m4.large` machines and the control plane machines use `m4.xlarge` instances. In some regions, including all regions that do not support these instance types, `m5.large` and `m5.xlarge` instances are used instead.
 
 |Elastic IPs (EIPs)
 |0 to 1
@@ -50,7 +50,7 @@ To use the `us-east-1` region, you must increase the EIP limit for your account.
 |Elastic Load Balancing (ELB/NLB)
 |3
 |20 per region
-|By default, each cluster creates internal and external network load balancers for the master API server and a single classic elastic load balancer for the router. Deploying more Kubernetes LoadBalancer Service objects will create additional link:https://aws.amazon.com/elasticloadbalancing/[load balancers].
+|By default, each cluster creates internal and external network load balancers for the primary API server and a single classic elastic load balancer for the router. Deploying more Kubernetes LoadBalancer Service objects will create additional link:https://aws.amazon.com/elasticloadbalancing/[load balancers].
 
 
 |NAT Gateways
diff --git a/modules/osd-monitoring-assigning-tolerations-to-monitoring-components.adoc b/modules/osd-monitoring-assigning-tolerations-to-monitoring-components.adoc
@@ -6,7 +6,7 @@
 [id="assigning-tolerations-to-monitoring-components_{context}"]
 = Assigning tolerations to components that monitor user-defined projects
 
-You can assign tolerations to the components that monitor user-defined projects, to enable moving them to tainted worker nodes. Scheduling is not permitted on master or infrastructure nodes.
+You can assign tolerations to the components that monitor user-defined projects, to enable moving them to tainted worker nodes. Scheduling is not permitted on control plane or infrastructure nodes.
 
 .Prerequisites
 
diff --git a/modules/osd-monitoring-moving-monitoring-components-to-different-nodes.adoc b/modules/osd-monitoring-moving-monitoring-components-to-different-nodes.adoc
@@ -6,7 +6,7 @@
 [id="moving-monitoring-components-to-different-nodes_{context}"]
 = Moving monitoring components to different nodes
 
-You can move any of the components that monitor workloads for user-defined projects to specific worker nodes. It is not permitted to move components to master or infrastructure nodes.
+You can move any of the components that monitor workloads for user-defined projects to specific worker nodes. It is not permitted to move components to control plane or infrastructure nodes.
 
 .Prerequisites
 
diff --git a/modules/policy-disaster-recovery.adoc b/modules/policy-disaster-recovery.adoc
@@ -7,7 +7,7 @@
 = Disaster recovery
 
 
-{product-title} provides disaster recovery for failures that occur at the pod, worker node, infrastructure node, master node, and availability zone levels.
+{product-title} provides disaster recovery for failures that occur at the pod, worker node, infrastructure node, control plane node, and availability zone levels.
 
 All disaster recovery requires that the customer use best practices for deploying highly available applications, storage, and cluster architecture (for example, single-zone deployment vs. multi-zone deployment) to account for the level of desired availability.
 
diff --git a/modules/policy-failure-points.adoc b/modules/policy-failure-points.adoc
@@ -35,9 +35,9 @@ When accounting for possible node failures, it is also important to understand h
 
 [id="cluster-failure_{context}"]
 == Cluster failure
-{product-title} clusters have at least three master nodes and three infrastructure nodes that are preconfigured for high availability, either in a single zone or across multiple zones depending on the type of cluster you have selected. This means that master and infrastructure nodes have the same resiliency of worker nodes, with the added benefit of being managed completely by Red Hat.
+{product-title} clusters have at least three control plane nodes and three infrastructure nodes that are preconfigured for high availability, either in a single zone or across multiple zones depending on the type of cluster you have selected. This means that control plane and infrastructure nodes have the same resiliency of worker nodes, with the added benefit of being managed completely by Red Hat.
 
-In the event of a complete master outage, the OpenShift APIs will not function, and existing worker node pods will be unaffected. However, if there is also a pod or node outage at the same time, the masters will have to recover before new pods or nodes can be added or scheduled.
+In the event of a complete control plane node outage, the OpenShift APIs will not function, and existing worker node pods will be unaffected. However, if there is also a pod or node outage at the same time, the control plane nodes will have to recover before new pods or nodes can be added or scheduled.
 
 All services running on infrastructure nodes are configured by Red Hat to be highly available and distributed across infrastructure nodes. In the event of a complete infrastructure outage, these services will be unavailable until these nodes have been recovered.
 
diff --git a/modules/policy-incident.adoc b/modules/policy-incident.adoc
@@ -84,7 +84,7 @@ All {product-title} clusters are backed up using cloud provider snapshots. Notab
 
 [id="cluster-capacity_{context}"]
 == Cluster capacity
-Evaluating and managing cluster capacity is a responsibility that is shared between Red Hat and the customer. Red Hat SRE is responsible for the capacity of all master and infrastructure nodes on the cluster.
+Evaluating and managing cluster capacity is a responsibility that is shared between Red Hat and the customer. Red Hat SRE is responsible for the capacity of all control plane and infrastructure nodes on the cluster.
 
 Red Hat SRE also evaluates cluster capacity during upgrades and in response to cluster alerts. The impact of a cluster upgrade on capacity is evaluated as part of the upgrade testing process to ensure that capacity is not negatively impacted by new additions to the cluster. During a cluster upgrade, additional worker nodes are added to make sure that total cluster capacity is maintained during the upgrade process.
 
diff --git a/modules/policy-responsibilities.adoc b/modules/policy-responsibilities.adoc
@@ -41,7 +41,7 @@ If the `cluster-admin` role is enabled on a cluster, see the responsibilities an
 
 |Virtual networking |Shared |Shared |Shared |Shared |Shared
 
-|Master and infrastructure nodes |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
+|Control plane and infrastructure nodes |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
 
 |Worker nodes |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
 
diff --git a/modules/policy-shared-responsibility.adoc b/modules/policy-shared-responsibility.adoc
@@ -34,7 +34,7 @@ The customer is responsible for incident and operations management of customer a
 
 [id="change-management_{context}"]
 == Change management
-Red Hat is responsible for enabling changes to the cluster infrastructure and services that the customer will control, as well as maintaining versions for the master nodes, infrastructure nodes and services, and worker nodes. The customer is responsible for initiating infrastructure change requests and installing and maintaining optional services and networking configurations on the cluster, as well as all changes to customer data and customer applications.
+Red Hat is responsible for enabling changes to the cluster infrastructure and services that the customer will control, as well as maintaining versions for the control plane nodes, infrastructure nodes and services, and worker nodes. The customer is responsible for initiating infrastructure change requests and installing and maintaining optional services and networking configurations on the cluster, as well as all changes to customer data and customer applications.
 
 [cols="2a,3a,3a",options="header"]
 |===
@@ -66,7 +66,7 @@ Red Hat is responsible for enabling changes to the cluster infrastructure and se
 
 |Cluster networking
 |* Set up cluster management components, such as public or private service endpoints and necessary integration with virtual networking components.
-* Set up internal networking components required for internal cluster communication between worker, infrastructure, and master nodes.
+* Set up internal networking components required for internal cluster communication between worker, infrastructure, and control plane nodes.
 |* Provide optional non-default IP address ranges for machine CIDR, service CIDR, and pod CIDR if needed through {cluster-manager} when the cluster is provisioned.
 * Request that the API service endpoint be made public or private on cluster creation or after cluster creation through {cluster-manager}.
 
@@ -84,7 +84,7 @@ Red Hat is responsible for enabling changes to the cluster infrastructure and se
 * Test customer applications on minor and maintenance versions to ensure compatibility.
 
 |Capacity management
-|* Monitor utilization of control plane (master nodes and infrastructure nodes).
+|* Monitor utilization of control plane (control plane nodes and infrastructure nodes).
 * Scale or resize control plane nodes to maintain quality of service.
 * Monitor utilization of customer resources including Network, Storage and Compute capacity. Where autoscaling features are not enabled alert customer for any changes required to cluster resources (for example, new compute nodes to scale, additional storage, etc).
 |* Use the provided {cluster-manager} controls to add or remove additional worker nodes as required.
diff --git a/modules/rosa-create-objects.adoc b/modules/rosa-create-objects.adoc
@@ -114,7 +114,7 @@ $ rosa create cluster --cluster=<cluster_name> | <cluster_id> [arguments]
 |Block of IP addresses (ipNet) from which pod IP addresses are allocated. Example: `10.128.0.0/14`
 
 |--private
-|Restricts master API endpoint and application routes to direct, private connectivity.
+|Restricts primary API endpoint and application routes to direct, private connectivity.
 
 |--private-link
 | Specifies to use AWS PrivateLink to provide private connectivity between VPCs and services. The `--subnet-ids` argument is required when using `--private-link`.
@@ -126,7 +126,7 @@ $ rosa create cluster --cluster=<cluster_name> | <cluster_id> [arguments]
 |Block of IP addresses (ipNet) for services. Example: `172.30.0.0/16`
 
 |--subnet-ids
-|The subnet IDs (string) to use when installing the cluster. Subnet IDs must be in pairs with one private subnet ID and one public subnet ID per availability zone. Subnets are comma-delimited. Example: `--subnet-ids=subnet-1,subnet-2`. Leave the value empty for installer-provisioned subnet IDs. 
+|The subnet IDs (string) to use when installing the cluster. Subnet IDs must be in pairs with one private subnet ID and one public subnet ID per availability zone. Subnets are comma-delimited. Example: `--subnet-ids=subnet-1,subnet-2`. Leave the value empty for installer-provisioned subnet IDs.
 
 
 When using `--private-link`, the `--subnet-ids` argument is required and only one private subnet is allowed per zone.
diff --git a/modules/rosa-edit-objects.adoc b/modules/rosa-edit-objects.adoc
@@ -29,7 +29,7 @@ $ rosa edit cluster --cluster=<cluster_name> | <cluster_id> [arguments]
 |Required: The name or ID (string) of the cluster to edit.
 
 |--private
-|Restricts a master API endpoint to direct, private connectivity.
+|Restricts a primary API endpoint to direct, private connectivity.
 
 |===
 
diff --git a/modules/rosa-kubernetes-concept.adoc b/modules/rosa-kubernetes-concept.adoc
@@ -21,7 +21,7 @@ App:: An app can refer to a complete app or a component of an app. You can deplo
 
 Service:: A service is a Kubernetes resource that groups a set of pods and provides network connectivity to these pods without exposing the actual private IP address of each pod. You can use a service to make your app available within your cluster or to the public Internet.
 
-Deployment:: A deployment is a Kubernetes resource where you can specify information about other resources or capabilities that are required to run your app, such as services, persistent storage, or annotations. You configure a deployment in a configuration YAML file, and then apply it to the cluster. The Kubernetes master configures the resources and deploys containers into pods on the compute nodes with available capacity.
+Deployment:: A deployment is a Kubernetes resource where you can specify information about other resources or capabilities that are required to run your app, such as services, persistent storage, or annotations. You configure a deployment in a configuration YAML file, and then apply it to the cluster. The Kubernetes main resource configures the resources and deploys containers into pods on the compute nodes with available capacity.
 +
 Define update strategies for your app, including the number of pods that you want to add during a rolling update and the number of pods that can be unavailable at a time. When you perform a rolling update, the deployment checks whether the update is working and stops the rollout when failures are detected.
 +
diff --git a/modules/rosa-policy-disaster-recovery.adoc b/modules/rosa-policy-disaster-recovery.adoc
@@ -7,7 +7,7 @@
 = Disaster recovery
 
 
-{product-title} (ROSA) provides disaster recovery for failures that occur at the pod, worker node, infrastructure node, master node, and availability zone levels.
+{product-title} (ROSA) provides disaster recovery for failures that occur at the pod, worker node, infrastructure node, control plane node, and availability zone levels.
 
 All disaster recovery requires that the customer use best practices for deploying highly available applications, storage, and cluster architecture, such as single-zone deployment or multi-zone deployment, to account for the level of desired availability.
 
diff --git a/modules/rosa-policy-responsibilities.adoc b/modules/rosa-policy-responsibilities.adoc
@@ -41,7 +41,7 @@ If the `cluster-admin` role is added to a user, see the responsibilities and exc
 
 |Virtual networking |Shared |Shared |Shared |Shared |Shared
 
-|Master and infrastructure nodes |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
+|Control plane and infrastructure nodes |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
 
 |Worker nodes |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
 
diff --git a/modules/rosa-policy-shared-responsibility.adoc b/modules/rosa-policy-shared-responsibility.adoc
@@ -34,7 +34,7 @@ The customer is responsible for incident and operations management of customer a
 
 [id="rosa-policy-change-management_{context}"]
 == Change management
-Red Hat is responsible for enabling changes to the cluster infrastructure and services that the customer will control, as well as maintaining versions for the master nodes, infrastructure nodes and services, and worker nodes. The customer is responsible for initiating infrastructure change requests and installing and maintaining optional services and networking configurations on the cluster, as well as all changes to customer data and customer applications.
+Red Hat is responsible for enabling changes to the cluster infrastructure and services that the customer will control, as well as maintaining versions for the control plane nodes, infrastructure nodes and services, and worker nodes. The customer is responsible for initiating infrastructure change requests and installing and maintaining optional services and networking configurations on the cluster, as well as all changes to customer data and customer applications.
 
 [cols="2a,3a,3a",options="header"]
 |===
@@ -65,7 +65,7 @@ Red Hat is responsible for enabling changes to the cluster infrastructure and se
 
 |Cluster networking
 |- Set up cluster management components, such as public or private service endpoints and necessary integration with virtual networking components.
-- Set up internal networking components required for internal cluster communication between worker, infrastructure, and master nodes.
+- Set up internal networking components required for internal cluster communication between worker, infrastructure, and control plane nodes.
 |- Provide optional non-default IP address ranges for machine CIDR, service CIDR, and pod CIDR if needed through {cluster-manager} when the cluster is provisioned.
 - Request that the API service endpoint be made public or private on cluster creation or after cluster creation through {cluster-manager}.
 
@@ -83,7 +83,7 @@ Red Hat is responsible for enabling changes to the cluster infrastructure and se
 - Test customer applications on minor and maintenance versions to ensure compatibility.
 
 |Capacity management
-|- Monitor the use of control plane. Control planes are master nodes and infrastructure nodes.
+|- Monitor the use of the control plane. Control planes include control plane nodes and infrastructure nodes.
 - Scale and resize control plane nodes to maintain quality of service.
 - Monitor the use of customer resources including network, storage and compute capacity. Where autoscaling features are not enabled alert customer for any changes required to cluster resources, such as new compute nodes to scale and additional storage.
 |- Use the provided {cluster-manager} controls to add or remove additional worker nodes as required.
