Okay, let's tackle this question about whether a Kubernetes pod with high CPU usage that triggers CPU throttling will be evicted.
First, I need to recall how Kubernetes handles resource constraints. CPU limits in K8s are enforced via Linux cgroups. When a pod exceeds its CPU limit, the kernel throttles the process, reducing its CPU time. This is different from memory limits, where exceeding can lead to OOMKill and pod termination.
Looking at the search results, multiple sources mention that CPU throttling doesn't directly cause eviction. For example, the article on K8s CPU限流原理 explains that throttling restricts CPU time but doesn't terminate the pod. Eviction typically happens due to memory pressure, disk pressure, or OOM situations, not CPU limits.
The eviction mechanisms discussed in other articles focus on node resource pressures like memory, disk space, or PID exhaustion. For instance, when node memory drops below 100Mi or disk space falls below certain thresholds, kubelet starts evicting pods. The QoS classes (BestEffort, Burstable, Guaranteed) determine the eviction order when resources are scarce, but this is tied to memory/disk pressure, not CPU usage.
So, the key distinction here is that CPU throttling is a runtime enforcement to prevent a pod from consuming excessive CPU, while eviction is triggered by resource shortages that affect node stability. Even if a pod is throttled, as long as it doesn't cause node-level resource pressure (like memory exhaustion), it won't be evicted. The pod might be throttled and perform poorly, but it won't be killed by kubelet for CPU limits alone.
Therefore, the answer should clarify that CPU throttling doesn't lead to eviction, and eviction is reserved for other resource pressures. The pod would only face termination if it causes node issues (like OOM) or if it exceeds its memory limits.
Based on the search results, a pod with high CPU usage triggering CPU throttling will NOT be directly evicted in Kubernetes. Here's the breakdown:
-
CPU Throttling vs. Eviction <web_76210c59, web_1fce5e7f, 4, 5, 6, >:
- CPU Throttling: When a pod exceeds its CPU limit, the Linux kernel (via cgroups) throttles its CPU usage. This restricts performance but does not terminate the pod.
- Eviction: Occurs when a pod is terminated due to node-level resource pressures (e.g., insufficient memory, disk space, or PID exhaustion). Eviction is triggered by signals like
memory.available < 100Miornodefs.available < 10%, not CPU limits.
-
When Does Eviction Happen? <web_65dd18, web_1fce5e7f, 4, 5, 8>:
- Memory Pressure: If a node runs out of memory, pods may be evicted based on QoS classes (BestEffort → Burstable → Guaranteed).
- Disk Pressure: Eviction occurs if node storage (e.g.,
/var/lib/kubelet) or image filesystems drop below thresholds (e.g.,nodefs.available < 10%). - PID Exhaustion: Linux nodes evict pods if available PIDs fall below a threshold.
- Node Faults: Hardware failures or network issues can trigger eviction.
-
Why CPU Throttling Doesn't Cause Eviction <web_76210c59, web_3f754bee>:
- CPU limits are enforced via time-slicing (quota per period). Throttled pods remain scheduled but run slower.
- Eviction is reserved for resource shortages that threaten node stability. A throttled pod only affects its own performance, not node-wide resources.
Conclusion: A pod hitting its CPU limit will experience throttling (reduced performance) but not eviction. Eviction is triggered exclusively by node-level resource exhaustion (memory, disk, PIDs) or node failures, not CPU constraints. To prevent throttling, adjust the pod's resources.limits.cpu or optimize its workload. For eviction prevention, focus on memory/disk requests, QoS classes, and node resource monitoring.