|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: 'Kubernetes v1.32 Adds A New CPU Manager Static Policy Option For Strict CPU Reservation' |
| 4 | +draft: true |
| 5 | +date: 2024-12-11 |
| 6 | +slug: cpumanager-strict-cpu-reservation |
| 7 | +author: > |
| 8 | + [Jing Zhang](https://github.com/jingczhang) (Nokia) |
| 9 | +--- |
| 10 | + |
| 11 | +In Kubernetes v1.32, after years of community discussion, we are excited to introduce a |
| 12 | +`strict-cpu-reservation` option for the [CPU Manager static policy](/docs/tasks/administer-cluster/cpu-management-policies/#static-policy-options). |
| 13 | +This feature is currently in alpha, with the associated policy hidden by default. You can only use the |
| 14 | +policy if you explicitly enable the alpha behavior in your cluster. |
| 15 | + |
| 16 | + |
| 17 | +## Understanding the feature |
| 18 | + |
| 19 | +The CPU Manager static policy is used to reduce latency or improve performance. The `reservedSystemCPUs` defines an explicit CPU set for OS system daemons and kubernetes system daemons. This option is designed for Telco/NFV type use cases where uncontrolled interrupts/timers may impact the workload performance. you can use this option to define the explicit cpuset for the system/kubernetes daemons as well as the interrupts/timers, so the rest CPUs on the system can be used exclusively for workloads, with less impact from uncontrolled interrupts/timers. More details of this parameter can be found on the [Explicitly Reserved CPU List](/docs/tasks/administer-cluster/reserve-compute-resources/#explicitly-reserved-cpu-list) page. |
| 20 | + |
| 21 | +If you want to protect your system daemons and interrupt processing, the obvious way is to use the `reservedSystemCPUs` option. |
| 22 | + |
| 23 | +However, until the Kubernetes v1.32 release, this isolation was only implemented for guaranteed |
| 24 | +pods that made requests for a whole number of CPUs. At pod admission time, the kubelet only |
| 25 | +compares the CPU _requests_ against the allocatable CPUs. In Kubernetes, limits can be higher than |
| 26 | +the requests; the previous implementation allowed burstable and best-effort pods to use up |
| 27 | +the capacity of `reservedSystemCPUs`, which could then starve host OS services of CPU - and we |
| 28 | +know that people saw this in real life deployments. |
| 29 | +The existing behavior also made benchmarking (for both infrastructure and workloads) results inaccurate. |
| 30 | + |
| 31 | +When this new `strict-cpu-reservation` policy option is enabled, the CPU Manager static policy will not allow any workload to use the reserved system CPU cores. |
| 32 | + |
| 33 | + |
| 34 | +## Enabling the feature |
| 35 | + |
| 36 | +To enable this feature, you need to turn on both the `CPUManagerPolicyAlphaOptions` feature gate and the `strict-cpu-reservation` policy option. And you need to remove the `/var/lib/kubelet/cpu_manager_state` file if it exists and restart kubelet. |
| 37 | + |
| 38 | +With the following kubelet configuration: |
| 39 | + |
| 40 | +```yaml |
| 41 | +kind: KubeletConfiguration |
| 42 | +apiVersion: kubelet.config.k8s.io/v1beta1 |
| 43 | +featureGates: |
| 44 | + ... |
| 45 | + CPUManagerPolicyOptions: true |
| 46 | + CPUManagerPolicyAlphaOptions: true |
| 47 | +cpuManagerPolicy: static |
| 48 | +cpuManagerPolicyOptions: |
| 49 | + strict-cpu-reservation: "true" |
| 50 | +reservedSystemCPUs: "0,32,1,33,16,48" |
| 51 | +... |
| 52 | +``` |
| 53 | + |
| 54 | +When `strict-cpu-reservation` is not set or set to false: |
| 55 | +```console |
| 56 | +# cat /var/lib/kubelet/cpu_manager_state |
| 57 | +{"policyName":"static","defaultCpuSet":"0-63","checksum":1058907510} |
| 58 | +``` |
| 59 | + |
| 60 | +When `strict-cpu-reservation` is set to true: |
| 61 | +```console |
| 62 | +# cat /var/lib/kubelet/cpu_manager_state |
| 63 | +{"policyName":"static","defaultCpuSet":"2-15,17-31,34-47,49-63","checksum":4141502832} |
| 64 | +``` |
| 65 | + |
| 66 | + |
| 67 | +## Monitoring the feature |
| 68 | + |
| 69 | +You can monitor the feature impact by checking the following CPU Manager counters: |
| 70 | +- `cpu_manager_shared_pool_size_millicores`: report shared pool size, in millicores (e.g. 13500m) |
| 71 | +- `cpu_manager_exclusive_cpu_allocation_count`: report exclusively allocated cores, counting full cores (e.g. 16) |
| 72 | + |
| 73 | +Your best-effort workloads may starve if the `cpu_manager_shared_pool_size_millicores` count is zero for prolonged time. |
| 74 | + |
| 75 | +We believe any pod that is required for operational purpose like a log forwarder should not run as best-effort, but you can review and adjust the amount of CPU cores reserved as needed. |
| 76 | + |
| 77 | +## Conclusion |
| 78 | + |
| 79 | +Strict CPU reservation is critical for Telco/NFV use cases. It is also a prerequisite for enabling the all-in-one type of deployments where workloads are placed on nodes serving combined control+worker+storage roles. |
| 80 | + |
| 81 | +We want you to start using the feature and looking forward to your feedback. |
| 82 | + |
| 83 | + |
| 84 | +## Further reading |
| 85 | + |
| 86 | +Please check out the [Control CPU Management Policies on the Node](/docs/tasks/administer-cluster/cpu-management-policies/) |
| 87 | +task page to learn more about the CPU Manager, and how it fits in relation to the other node-level resource managers. |
| 88 | + |
| 89 | + |
| 90 | +## Getting involved |
| 91 | + |
| 92 | +This feature is driven by the [SIG Node](https://github.com/Kubernetes/community/blob/master/sig-node/README.md). If you are interested in helping develop this feature, sharing feedback, or participating in any other ongoing SIG Node projects, please attend the SIG Node meeting for more details. |
0 commit comments