Workload partitioning

In resource-constrained environments, you can 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 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 changes are required for workload partitioning:

  1. In the install-config.yaml file, add the additional field: cpuPartitioningMode.

    1. apiVersion: v1
    2. baseDomain: devcluster.openshift.com
    3. cpuPartitioningMode: AllNodes (1)
    4. compute:
    5. - architecture: amd64
    6. hyperthreading: Enabled
    7. name: worker
    8. platform: {}
    9. replicas: 3
    10. controlPlane:
    11. architecture: amd64
    12. hyperthreading: Enabled
    13. name: master
    14. platform: {}
    15. replicas: 3
    1Sets up a cluster for CPU partitioning at install time. The default value is None.

    Workload partitioning can only be enabled during cluster installation. You cannot disable workload partitioning postinstallation.

  2. In the performance profile, specify the isolated and reserved CPUs.

    Recommended performance profile configuration

    1. apiVersion: performance.openshift.io/v2
    2. kind: PerformanceProfile
    3. metadata:
    4. # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
    5. # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
    6. # Also in file 'validatorCRs/informDuValidator.yaml':
    7. # name: 50-performance-${PerformanceProfile.metadata.name}
    8. name: openshift-node-performance-profile
    9. annotations:
    10. ran.openshift.io/reference-configuration: "ran-du.redhat.com"
    11. spec:
    12. additionalKernelArgs:
    13. - "rcupdate.rcu_normal_after_boot=0"
    14. - "efi=runtime"
    15. - "vfio_pci.enable_sriov=1"
    16. - "vfio_pci.disable_idle_d3=1"
    17. - "module_blacklist=irdma"
    18. cpu:
    19. isolated: $isolated
    20. reserved: $reserved
    21. hugepages:
    22. defaultHugepagesSize: $defaultHugepagesSize
    23. pages:
    24. - size: $size
    25. count: $count
    26. node: $node
    27. machineConfigPoolSelector:
    28. pools.operator.machineconfiguration.openshift.io/$mcp: ""
    29. nodeSelector:
    30. node-role.kubernetes.io/$mcp: ""
    31. numa:
    32. topologyPolicy: "restricted"
    33. # To use the standard (non-realtime) kernel, set enabled to false
    34. realTimeKernel:
    35. enabled: true
    36. workloadHints:
    37. # WorkloadHints defines the set of upper level flags for different type of workloads.
    38. # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    39. # for detailed descriptions of each item.
    40. # The configuration below is set for a low latency, performance mode.
    41. realTime: true
    42. highPowerConsumption: false
    43. perPodPowerManagement: false
    Table 1. PerformanceProfile CR options for single-node OpenShift clusters
    PerformanceProfile CR fieldDescription

    metadata.name

    Ensure that name matches the following fields set in related GitOps ZTP custom resources (CRs):

    • include=openshift-node-performance-${PerformanceProfile.metadata.name} in TunedPerformancePatch.yaml

    • name: 50-performance-${PerformanceProfile.metadata.name} in validatorCRs/informDuValidator.yaml

    spec.additionalKernelArgs

    “efi=runtime” Configures UEFI secure boot for the cluster host.

    spec.cpu.isolated

    Set the isolated CPUs. Ensure all of the Hyper-Threading pairs match.

    The reserved and isolated CPU pools must not overlap and together must span all available cores. CPU cores that are not accounted for cause an undefined behaviour in the system.

    spec.cpu.reserved

    Set the reserved CPUs. When workload partitioning is enabled, system processes, kernel threads, and system container threads are restricted to these CPUs. All CPUs that are not isolated should be reserved.

    spec.hugepages.pages

    • Set the number of huge pages (count)

    • Set the huge pages size (size).

    • Set node to the NUMA node where the hugepages are allocated (node)

    spec.realTimeKernel

    Set enabled to true to use the realtime kernel.

    spec.workloadHints

    Use workloadHints to define the set of top level flags for different type of workloads. The example configuration configures the cluster for low latency and high performance.

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.

Additional resources

  • For the recommended workload partitioning configuration for single-node OpenShift clusters, see Workload partitioning.