This is an example demonstrating how to allocate CPU resources to the container.

apiVersion: v1
kind: Pod
spec:
 containers:
 - name: netshield
  env:

# Optional CPU list specification for control plane and data
# plane. Default is to detect CPUs via the cgroup cpuset
# controller. These needs to be used if dedicated CPU resources
# (pod in guaranteed QoS class and static CPU manager policy)
# are not used.

#- name: CP_CPU_LIST
#  value: '0' # rangelist format supported, for instance: '4,6,9-12'
#- name: DP_CPU_LIST
#  value: '1' # rangelist format supported, for instance: '4,6,9-12'
	 
# CPU_REQ and CPU_LIMIT will expose the amount of CPU resources
# requested to the container. No user configuration required other than
# to make sure that the "containerName" matches the container's name.

   - name: CPU_REQ
    valueFrom:
     resourceFieldRef:
      containerName: netshield
      resource: requests.cpu
      divisor: 1m
   - name: CPU_LIMIT
    valueFrom:
     resourceFieldRef:
      containerName: netshield
      resource: limits.cpu
      divisor: 1m
   resources:
    requests:
     cpu: '10'
    limits:
     cpu: '10'

If the cluster is properly configured to support pod in the Guaranteed QoS class. Then what is needed is to add the CPU_REQ and CPU_LIMIT environment variables, making sure that the "containerName" matches the containers name and request the required amount of CPU in the resources section.

Both request and limit needs to be set to the same value for the pod to qualify for "Guaranteed" QoS. If for some reason those requirements can not be met then the environment variables CP_CPU_LIST and DP_CPU_LIST can be used as a workaround. The system will expect those CPUs to be dedicated to this pod.

There are some further tweaks possible, see the full specification examples for documentation of those.