TELCODOCS-1013-fixes

Author: aireilly

modules/ztp-sno-du-enabling-workload-partitioning.adoc

@@ -26,9 +26,8 @@ activation_annotation = "target.workload.openshift.io/management"
 annotation_prefix = "resources.workload.openshift.io"
 resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" } <1>
 ----
-<1> The `CPUs` value varies based on the installation.
-+
-If Hyper-Threading is enabled, specify both threads for each core. The `CPUs` value must match the reserved CPU set specified in the performance profile.
+<1> The `cpuset` value varies based on the installation.
+If Hyper-Threading is enabled, specify both threads for each core. The `cpuset` value must match the reserved CPUs that you define in the `spec.cpu.reserved` field in the performance profile.
 
 * When configured in the cluster, the contents of `/etc/kubernetes/openshift-workload-pinning` should look like this:
 +
@@ -40,7 +39,7 @@ If Hyper-Threading is enabled, specify both threads for each core. The `CPUs` va
   }
 }
 ----
-<1> The `cpuset` must match the `CPUs` value in `/etc/crio/crio.conf.d/01-workload-partitioning`.
+<1> The `cpuset` must match the `cpuset` value in `/etc/crio/crio.conf.d/01-workload-partitioning`.
 
 .Verification
 

scalability_and_performance/sno-du-enabling-workload-partitioning-on-single-node-openshift.adoc

@@ -6,22 +6,31 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-In resource-constrained environments, such as {sno} deployments, it is advantageous to reserve most of the CPU resources for your own workloads and configure {product-title} to run on a fixed number of CPUs within the host. In these environments, management workloads, including the control plane, need to be configured to use fewer resources than they might by default in normal clusters. You can isolate the {product-title} services, cluster management workloads, and infrastructure pods to run on a reserved set of CPUs.
+In resource-constrained environments, such as {sno} deployments, use workload partitioning to isolate {product-title} services, cluster management workloads, and infrastructure pods to run on a reserved set of CPUs.
 
-When you use workload partitioning, the CPU resources used by {product-title} for cluster management are isolated to a partitioned set of CPU resources on a single-node cluster. This partitioning isolates cluster management functions to the defined number of CPUs. All cluster management functions operate solely on that `cpuset` configuration.
+The minimum number of reserved CPUs required for the cluster management in {sno} is four CPU Hyper-Threads (HTs).
+With workload partitioning, you annotate the set of cluster management pods and a set of typical add-on Operators for inclusion in the cluster management workload partition.
+These pods operate normally within the minimum size CPU configuration.
+Additional Operators or workloads outside of the set of minimum cluster management pods require additional CPUs to be added to the workload partition.
 
-The minimum number of reserved CPUs required for the management partition for a single-node cluster is four CPU Hyper threads (HTs). The set of pods that make up the baseline {product-title} installation and a set of typical add-on Operators are annotated for inclusion in the management workload partition. These pods operate normally within the minimum size `cpuset` configuration. Inclusion of Operators or workloads outside of the set of accepted management pods requires additional CPU HTs to be added to that partition.
+Workload partitioning isolates user workloads from platform workloads using standard Kubernetes scheduling capabilities.
 
-Workload partitioning isolates the user workloads away from the platform workloads using the normal scheduling capabilities of Kubernetes to manage the number of pods that can be placed onto those cores, and avoids mixing cluster management workloads and user workloads.
+The following is an overview of the configurations required for workload partitioning:
 
-When applying workload partitioning, use the Node Tuning Operator to implement the performance profile:
+* Workload partitioning that uses `/etc/crio/crio.conf.d/01-workload-partitioning` pins the {product-title} infrastructure pods to a defined `cpuset` configuration.
 
-* Workload partitioning pins the {product-title} infrastructure pods to a defined `cpuset` configuration.
-* The performance profile pins the systemd services to a defined `cpuset` configuration.
-* This `cpuset` configuration must match.
+* The performance profile pins cluster services such as systemd and kubelet to the CPUs that are defined in the `spec.cpu.reserved` field.
++
+[NOTE]
+====
+Using the Node Tuning Operator, you can configure the performance profile to also pin system-level apps for a complete workload partitioning configuration on the node.
+====
 
-Workload partitioning introduces a new extended resource of `<workload-type>.workload.openshift.io/cores`
-for each defined CPU pool, or workload-type. Kubelet advertises these new resources and CPU requests by pods allocated to the pool are accounted for within the corresponding resource rather than the typical `cpu` resource. When workload partitioning is enabled, the `<workload-type>.workload.openshift.io/cores` resource allows access to the CPU capacity of the host, not just the default CPU pool.
+* The CPUs that you specify in the performance profile `spec.cpu.reserved` field and the workload partitioning `cpuset` field must match.
+
+Workload partitioning introduces an extended `<workload-type>.workload.openshift.io/cores` resource for each defined CPU pool, or _workload type_.
+Kubelet advertises the resources and CPU requests by pods allocated to the pool within the corresponding resource.
+When workload partitioning is enabled, the `<workload-type>.workload.openshift.io/cores` resource allows access to the CPU capacity of the host, not just the default CPU pool.
 
 [role="_additional-resources"]
 .Additional resources