mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
26 lines
1.5 KiB
Plaintext
26 lines
1.5 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="ztp-workload-partitioning-sno_{context}"]
|
|
= Workload partitioning in {sno} with {ztp}
|
|
|
|
Workload partitioning configures {product-title} services, cluster management workloads, and infrastructure pods to run on a reserved number of host CPUs.
|
|
|
|
To configure workload partitioning with {ztp-first}, you configure a `cpuPartitioningMode` field in the `ClusterInstance` custom resource (CR) that you use to install the cluster and you apply a `PerformanceProfile` CR that configures the `isolated` and `reserved` CPUs on the host.
|
|
|
|
Configuring the `ClusterInstance` CR enables workload partitioning at cluster installation time and applying the `PerformanceProfile` CR configures the specific allocation of CPUs to reserved and isolated sets.
|
|
Both of these steps happen at different points during cluster provisioning.
|
|
|
|
The workload partitioning configuration pins the {product-title} infrastructure pods to the `reserved` CPU set.
|
|
Platform services such as systemd, CRI-O, and kubelet run on the `reserved` CPU set.
|
|
The `isolated` CPU sets are exclusively allocated to your container workloads.
|
|
Isolating CPUs ensures that the workload has guaranteed access to the specified CPUs without contention from other applications running on the same node.
|
|
All CPUs that are not isolated should be reserved.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Ensure that `reserved` and `isolated` CPU sets do not overlap with each other.
|
|
====
|