In resource-constrained environments, such as single-node OpenShift deployments, use workload partitioning to isolate OKD services, cluster management workloads, and infrastructure pods to run on a reserved set of CPUs.
The minimum number of reserved CPUs required for the cluster management in single-node OpenShift 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 user workloads from platform workloads using standard Kubernetes scheduling capabilities.
The following is an overview of the configurations required for workload partitioning:
Workload partitioning that uses
/etc/crio/crio.conf.d/01-workload-partitioning pins the OKD infrastructure pods to a defined
The performance profile pins cluster services such as systemd and kubelet to the CPUs that are defined in the
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.
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.
For the recommended workload partitioning configuration for single-node OpenShift clusters, see Workload partitioning.