Merge pull request #89048 from jacksgt/jhensche-minor-fixes

Minor fixes for cluster configuration documentation

Author: jeana-redhat

modules/master-node-sizing.adoc

@@ -49,10 +49,10 @@ On a large and dense cluster with three control plane nodes, the CPU and memory
 
 [IMPORTANT]
 ====
-The node sizing varies depending on the number of nodes and object counts in the cluster. It also depends on whether the objects are actively being created on the cluster. During object creation, the control plane is more active in terms of resource usage compared to when the objects are in the `running` phase.
+The node sizing varies depending on the number of nodes and object counts in the cluster. It also depends on whether the objects are actively being created on the cluster. During object creation, the control plane is more active in terms of resource usage compared to when the objects are in the `Running` phase.
 ====
 
-Operator Lifecycle Manager (OLM ) runs on the control plane nodes and its memory footprint depends on the number of namespaces and user installed operators that OLM needs to manage on the cluster. Control plane nodes need to be sized accordingly to avoid OOM kills. Following data points are based on the results from cluster maximums testing.
+Operator Lifecycle Manager (OLM) runs on the control plane nodes and its memory footprint depends on the number of namespaces and user installed operators that OLM needs to manage on the cluster. Control plane nodes need to be sized accordingly to avoid OOM kills. Following data points are based on the results from cluster maximums testing.
 
 [options="header",cols="3*"]
 |===

modules/nodes-scheduler-taints-tolerations-about.adoc

@@ -18,7 +18,7 @@ endif::[]
 
 A _taint_ allows a node to refuse a pod to be scheduled unless that pod has a matching _toleration_.
 
-You apply taints to a node through the `Node` specification (`NodeSpec`) and apply tolerations to a pod through the `Pod` specification (`PodSpec`). When you apply a taint a node, the scheduler cannot place a pod on that node unless the pod can tolerate the taint.
+You apply taints to a node through the `Node` specification (`NodeSpec`) and apply tolerations to a pod through the `Pod` specification (`PodSpec`). When you apply a taint to a node, the scheduler cannot place a pod on that node unless the pod can tolerate the taint.
 
 .Example taint in a node specification
 [source,yaml]

modules/recommended-etcd-practices.adoc

@@ -10,7 +10,7 @@ Because etcd writes data to disk and persists proposals on disk, its performance
 
 Those latencies can cause etcd to miss heartbeats, not commit new proposals to the disk on time, and ultimately experience request timeouts and temporary leader loss. High write latencies also lead to an OpenShift API slowness, which affects cluster performance. Because of these reasons, avoid colocating other workloads on the control-plane nodes that are I/O sensitive or intensive and share the same underlying I/O infrastructure.
 
-Run etcd on a block device that can write at least 50 IOPS of 8KB sequentially, including fdatasync, in under 10ms. For heavy loaded clusters, sequential 500 IOPS of 8000 bytes (2 ms) are recommended. To measure those numbers, you can use a benchmarking tool, such as fio.
+Run etcd on a block device that can write at least 50 IOPS of 8KB sequentially, including fdatasync, in under 10ms. For heavy loaded clusters, sequential 500 IOPS of 8000 bytes (2 ms) are recommended. To measure those numbers, you can use a benchmarking tool, such as the `fio` command.
 
 To achieve such performance, run etcd on machines that are backed by SSD or NVMe disks with low latency and high throughput. Consider single-level cell (SLC) solid-state drives (SSDs), which provide 1 bit per memory cell, are durable and reliable, and are ideal for write-intensive workloads.
 
@@ -28,7 +28,7 @@ The following hard drive practices provide optimal etcd performance:
 * Use solid state drives as a minimum selection. Prefer NVMe drives for production environments.
 * Use server-grade hardware for increased reliability.
 * Avoid NAS or SAN setups and spinning drives. Ceph Rados Block Device (RBD) and other types of network-attached storage can result in unpredictable network latency. To provide fast storage to etcd nodes at scale, use PCI passthrough to pass NVM devices directly to the nodes.
-* Always benchmark by using utilities such as fio. You can use such utilities to continuously monitor the cluster performance as it increases.
+* Always benchmark by using utilities such as `fio`. You can use such utilities to continuously monitor the cluster performance as it increases.
 * Avoid using the Network File System (NFS) protocol or other network based file systems.
 
 Some key metrics to monitor on a deployed {product-title} cluster are p99 of etcd disk write ahead log duration and the number of etcd leader changes. Use Prometheus to track these metrics.