37 CPU Pinning on Kubernetes #

37.1 RKE2 Versions < v1.32 #

Enable CPU pinning in your RKE2 cluster by editing RKE2 config file. Add below kubelet arguments in /etc/rancher/rke2/config.yaml file. Make sure specifying the housekeeping CPU cores in kubelet-reserved and system-reserved arguments:

kubelet-arg:
- "cpu-manager-policy=static"
- "cpu-manager-policy-options=full-pcpus-only=true"
- "cpu-manager-reconcile-period=0s"
- "kubelet-reserved=cpu=0,31,32,63"
- "system-reserved=cpu=0,31,32,63"

37.2 RKE2 Versions >= v1.32 #

If your RKE2 version is v1.32 or higher, command-line arguments cannot be used to configure kubelet, following upstream Kubernetes practice. To set up CPU pinning, a kubelet config file needs to be created. Refer to RKE2 documentation.

Create a new kubelet config file such as 01-cpu-pinning.conf and place it in the /var/lib/rancher/rke2/agent/etc/kubelet.conf.d/ directory:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cpuManagerPolicy: static
reservedSystemCPUs: 0,31,32,63
topologyManagerPolicy: single-numa-node

For configuration changes to take effect, a restart of the appropriate RKE2 service (server or agent) is required. This action will briefly interrupt RKE2 service on the host. Run only one of the following commands, depending on the node type:

# If the node is RKE2 agent
systemctl restart rke2-agent
# Else if the node is RKE2 server
systemctl restart rke2-server

37.3 Deploy Workloads Leveraging Pinned CPUs #

There are three ways to use the feature using the Static Policy defined in kubelet depending on the requests and limits you define on your workload:

BestEffort QoS Class: If you do not define any request or limit for CPU, the pod is scheduled on the first CPU available on the system.
An example of using the BestEffort QoS Class could be:
```
spec:
  containers:
  - name: nginx
    image: nginx
```

Burstable QoS Class: If you define a request for CPU, which is not equal to the limits, or there is no CPU request.

Examples of using the Burstable QoS Class could be:

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
      requests:
        memory: "100Mi"
        cpu: "1"

Guaranteed QoS Class: If you define a request for CPU, which is equal to the limits.

An example of using the Guaranteed QoS Class could be:

spec:
  containers:
    - name: nginx
      image: nginx
      resources:
        limits:
          memory: "200Mi"
          cpu: "2"
        requests:
          memory: "200Mi"
          cpu: "2"