Kubernetes中requests的具体用途及与cgroup cpu.shares的关系疑问

Great question—this is one of those spots where Kubernetes abstractions sit on top of raw Linux cgroup mechanics, and it’s super easy to get mixed up. Let’s break this down step by step.

First, let’s clear up exactly what requests does in the Kubernetes ecosystem:

• 调度决策的硬依据: The kube-scheduler uses requests values to check if a node has enough "available" capacity to run a new Pod. For example, if a node has 4 vCPUs total, and existing Pods on that node have a combined CPU requests of 3 vCPUs, the scheduler will only place new Pods with CPU requests ≤ 1 vCPU here. This prevents overcommitting nodes to the point where critical Pods can’t even start or get the resources they need to run.
• 资源预留与QoS基础: requests works with limits to define a Pod’s Quality of Service (QoS) class:
  • Guaranteed: When requests equals limits, the Pod is guaranteed its requested resources (and can’t use more than the limit).
  • Burstable: When requests is less than limits, the Pod can use extra resources when available, but will be deprioritized over Guaranteed Pods during resource contention.
  • BestEffort: No requests or limits set—these Pods are the first to get evicted when nodes run low on resources.
• 运行时资源优先级: For CPU specifically, requests translates to a weight that influences how much CPU time the Pod gets when the node is under heavy load (more on this next).

You’re right that cpu.shares in cgroups is a relative weight, not an absolute value. Here’s how Kubernetes bridges these two:

• By default, Kubernetes maps 1 vCPU of requests.cpu to 1024 cpu.shares (the Linux default weight). So a Pod with requests.cpu: 200m (0.2 vCPUs) gets ~205 cpu.shares, and one with 1500m gets ~1536 shares.
• This mapping only applies to Burstable and BestEffort Pods. For Guaranteed Pods (where requests = limits), Kubernetes uses a different cgroup tool: cpu.cfs_quota_us and cpu.cfs_period_us. These settings effectively cap the Pod’s CPU usage to the limit value, while ensuring it always gets its requested resources.
• The key takeaway: cpu.shares only matters when CPU resources are fully saturated. If the node has idle CPU, any Pod can use more than its requests value—shares don’t restrict that.

Your confusion here comes from mixing up two separate stages of resource management: scheduling (before the Pod starts) and runtime CPU allocation (while the Pod runs).

• Scheduling needs an absolute metric to make logical decisions. cpu.shares is relative—1024 shares could mean 100% of a single-core node or 25% of a 4-core node. The scheduler can’t use relative weights to judge if a node has enough capacity for a Pod; it needs a fixed, node-agnostic value to calculate resource availability.
• Think of requests as a "minimum guarantee" the scheduler promises to the Pod. By using absolute values, the scheduler ensures that the sum of all Pod requests on a node doesn’t exceed the node’s total resources. This stops overcommitment that would leave Pods starving for resources even when the node is under load.
• Remember: The absolute request doesn’t mean the Pod is locked to that amount of CPU. It just means the scheduler has reserved that capacity for the Pod. When the node has spare CPU, the Pod can burst above its request (up to limits, if set). Only when CPU is saturated does the relative cpu.shares (derived from requests) kick in to split available time between competing Pods.

内容的提问来源于stack exchange，提问作者BLasan