Merge pull request #43406 from StephenJamesSmith/TELCODOCS-299-workload-partitioning

TELCODOCS-299-workload-partitioning

Author: kalexand-rh

_topic_maps/_topic_map.yml

@@ -2195,6 +2195,9 @@ Topics:
 - Name: Provisioning and deploying a distributed unit (DU)
   File: cnf-provisioning-and-deploying-a-distributed-unit
   Distros: openshift-webscale
+- Name: Workload partitioning on single node OpenShift
+  File: sno-du-enabling-workload-partitioning-on-single-node-openshift
+  Distros: openshift-origin,openshift-enterprise  
 - Name: Deploying distributed units at scale in a disconnected environment
   File: ztp-deploying-disconnected
   Distros: openshift-origin,openshift-enterprise

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

@@ -0,0 +1,68 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/sno-du-enabling-workload-partitioning-on-single-node-openshift.adoc
+
+:_content-type: PROCEDURE
+[id="sno-du-enabling-workload-partitioning_{context}"]
+= Enabling workload partitioning
+
+Use the following procedure to enable workload partitioning for your single node deployments.
+
+.Procedure
+
+. To enable workload partitioning, you must provide a `MachineConfig` manifest during installation to configure CRI-O and kubelet to know about the workload types. The following example shows a manifest without the encoded file content:
++
+[source,yaml]
+----
+apiVersion: machineconfiguration.openshift.io/v1
+kind: MachineConfig
+metadata:
+  labels:
+    machineconfiguration.openshift.io/role: master
+  name: 02-master-workload-partitioning
+spec:
+  config:
+    ignition:
+      version: 3.2.0
+    storage:
+      files:
+      - contents:
+          source: data:text/plain;charset=utf-8;base64,encoded-content-here
+        mode: 420
+        overwrite: true
+        path: /etc/crio/crio.conf.d/01-workload-partitioning
+        user:
+          name: root
+      - contents:
+          source: data:text/plain;charset=utf-8;base64,encoded-content-here
+        mode: 420
+        overwrite: true
+        path: /etc/kubernetes/openshift-workload-pinning
+        user:
+          name: root
+----
+
+. Provide the contents of `/etc/crio/crio.conf.d/01-workload-partitioning` as the workload partitioning encoded content. The `cpuset` value varies based on the deployment:
++
+[source,yaml]
+----
+cat <<EOF | base64 -w0
+[crio.runtime.workloads.management]
+activation_annotation = "target.workload.openshift.io/management"
+annotation_prefix = "resources.workload.openshift.io"
+resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" }
+EOF
+----
+
+. Provide the contents of `/etc/kubernetes/openshift-workload-pinning` as the workload pinning encoded content. The `cpuset` value varies based on the deployment:
++
+[source,yaml]
+----
+cat <<EOF | base64 -w0
+{
+  "management": {
+    "cpuset": "0-1,52-53"
+  }
+}
+EOF
+----

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

@@ -0,0 +1,26 @@
+:_content-type: ASSEMBLY
+[id="sno-du-enabling-workload-partitioning-on-single-node-openshift"]
+= Workload partitioning on single node OpenShift
+include::modules/common-attributes.adoc[]
+:context: sno-du-enabling-workload-partitioning-on-single-node-openshift
+
+toc::[]
+
+In resource-constrained environments, such as single node production 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.
+
+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 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 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.
+
+When using workload partitioning, you must install the Performance Addon Operator and apply the performance profile:
+
+* Workload partitioning pins the {product-title} infrastructure pods to a defined `cpuset` configuration.
+* The Performance Addon Operator performance profile pins the systemd services to a defined `cpuset` configuration.
+* This `cpuset` configuration must match.
+
+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.
+
+include::modules/sno-du-enabling-workload-partitioning.adoc[leveloffset=+1]