Merge pull request #75078 from kquinn1204/TELCODOCS-1771

Telcodocs 1771 Extend workload partitioning to support cpu limits

Author: adellape

modules/create-perf-profile-workload-partitioning.adoc

@@ -0,0 +1,13 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/enabling-workload-partitioning.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="performance-profile-workload-partitioning_{context}"]
+= Performance profiles and workload partitioning
+
+Applying a performance profile allows you to make use of the workload partitioning feature. An appropriately configured performance profile specifies the `isolated` and `reserved` CPUs. The recommended way to create a performance profile is to use the Performance Profile Creator (PPC) tool to create the performance profile.
+
+
+
+

modules/enabling-workload-partitioning.adoc

@@ -0,0 +1,42 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/enabling-workload-partitioning.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="enabling-workload-partitioning_{context}"]
+= Enabling workload partitioning 
+
+With workload partitioning, cluster management pods are annotated to correctly partition them into a specified CPU affinity. These pods operate normally within the minimum size CPU configuration specified by the reserved value in the Performance Profile. Additional Day 2 Operators that make use of workload partitioning should be taken into account when calculating how many reserved CPU cores should be set aside for the platform.
+
+Workload partitioning isolates user workloads from platform workloads using standard Kubernetes scheduling capabilities.
+
+[NOTE]
+====
+Workload partitioning can only be enabled during cluster installation. You cannot disable workload partitioning postinstallation.
+====
+
+Use this procedure to enable workload partitioning cluster wide:  
+
+.Procedure
+
+* In the `install-config.yaml` file, add the additional field `cpuPartitioningMode` and set it to `AllNodes`.
++
+[source,yaml]
+----
+apiVersion: v1
+baseDomain: devcluster.openshift.com
+cpuPartitioningMode: AllNodes <1>
+compute:
+  - architecture: amd64
+    hyperthreading: Enabled
+    name: worker
+    platform: {}
+    replicas: 3
+controlPlane:
+  architecture: amd64
+  hyperthreading: Enabled
+  name: master
+  platform: {}
+  replicas: 3
+----
+<1> Sets up a cluster for CPU partitioning at install time. The default value is `None`.

scalability_and_performance/enabling-workload-partitioning.adoc

@@ -6,59 +6,42 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-In resource-constrained environments, you can use workload partitioning to isolate {product-title} services, cluster management workloads, and infrastructure pods to run on a reserved set of CPUs.
+Workload partitioning separates compute node CPU resources into distinct CPU sets. The primary objective is to keep platform pods on the specified cores to avoid interrupting the CPUs the customer workloads are running on. 
 
-The minimum number of reserved CPUs required for the cluster management 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.
+Workload partitioning isolates {product-title} services, cluster management workloads, and infrastructure pods to run on a reserved set of CPUs. This ensures that the remaining CPUs in the cluster deployment are untouched and available exclusively for non-platform workloads. The minimum number of reserved CPUs required for the cluster management is four CPU Hyper-Threads (HTs).
 
-Workload partitioning isolates user workloads from platform workloads using standard Kubernetes scheduling capabilities.
+In the context of enabling workload partitioning and managing CPU resources effectively, nodes that are not configured correctly will not be permitted to join the cluster through a node admission webhook. When the workload partitioning feature is enabled, the machine config pools for control plane and worker will be supplied with configurations for nodes to use. Adding new nodes to these pools will make sure they are correctly configured before joining the cluster.
 
-The following changes are required for workload partitioning:
+Currently, nodes must have uniform configurations per machine config pool to ensure that correct CPU affinity is set across all nodes within that pool. After admission, nodes within the cluster identify themselves as supporting a new resource type called `management.workload.openshift.io/cores` and accurately report their CPU capacity. Workload partitioning can be enabled during cluster installation only by adding the additional field `cpuPartitioningMode` to the `install-config.yaml` file.
+
+When workload partitioning is enabled, the `management.workload.openshift.io/cores` resource allows the scheduler to correctly assign pods based on the `cpushares` capacity of the host, not just the default `cpuset`. This ensures more precise allocation of resources for workload partitioning scenarios.
+
+Workload partitioning ensures that CPU requests and limits specified in the pod's configuration are respected. In {product-title} 4.16 or later, accurate CPU usage limits are set for platform pods through CPU partitioning. As workload partitioning uses the custom resource type of `management.workload.openshift.io/cores`, the values for requests and limits are the same due to a requirement by Kubernetes for extended resources. However, the annotations modified by workload partitioning correctly reflect the desired limits. 
 
-. In the `install-config.yaml` file, add the additional field: `cpuPartitioningMode`.
-+
-[source,yaml]
-----
-apiVersion: v1
-baseDomain: devcluster.openshift.com
-cpuPartitioningMode: AllNodes <1>
-compute:
-  - architecture: amd64
-    hyperthreading: Enabled
-    name: worker
-    platform: {}
-    replicas: 3
-controlPlane:
-  architecture: amd64
-  hyperthreading: Enabled
-  name: master
-  platform: {}
-  replicas: 3
-----
-<1> Sets up a cluster for CPU partitioning at install time. The default value is `None`.
-+
 [NOTE]
 ====
-Workload partitioning can only be enabled during cluster installation. You cannot disable workload partitioning postinstallation.
+Extended resources cannot be overcommitted, so request and limit must be equal if both are present in a container spec.
 ====
 
-. In the performance profile, specify the `isolated` and `reserved` CPUs.
-+
-.Recommended performance profile configuration
+include::modules/enabling-workload-partitioning.adoc[leveloffset=+1]
+
+include::modules/create-perf-profile-workload-partitioning.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-about-the-profile-creator-tool_cnf-low-latency-perf-profile[About the Performance Profile Creator]
+
+
+== Sample performance profile configuration
 [source,yaml]
 ----
 include::snippets/ztp_PerformanceProfile.yaml[]
 ----
-+
-include::snippets/performance-profile-workload-partitioning.adoc[]
 
-Workload partitioning introduces an extended `management.workload.openshift.io/cores` resource type for platform pods.
-kubelet advertises the resources and CPU requests by pods allocated to the pool within the corresponding resource.
-When workload partitioning is enabled, the `management.workload.openshift.io/cores` resource allows the scheduler to correctly assign pods based on the `cpushares` capacity of the host, not just the default `cpuset`.
+include::snippets/performance-profile-workload-partitioning.adoc[]
 
 [role="_additional-resources"]
 .Additional resources
 
-* For the recommended workload partitioning configuration for {sno} clusters, see xref:../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-sno-du-enabling-workload-partitioning_sno-configure-for-vdu[Workload partitioning].
+* xref:../edge_computing/ztp-reference-cluster-configuration-for-vdu.adoc#ztp-sno-du-enabling-workload-partitioning_sno-configure-for-vdu[Recommended single-node OpenShift cluster configuration for vDU application workloads -> Workload partitioning]