An Analysis of Response Time Depending on CPU Resource Contention between Pods in Kubernetes Environment

Background

Cloud workloads share nodes to improve utilization. However, spare capacity at the node level does not mean every service receives CPU when it needs it.

We measured how competing work on the same node affected the target service, varying competing CPU occupancy and task count separately.

Experiment

On an Intel Core i5-12600K system with DDR5 32GiB, a VM-based cluster of one master and three workers (each 2 vCPU, 4GiB) was built, using the progrium/stress image to control each node’s CPU occupancy.

The target was a php-apache app computing trigonometric functions; HTTP requests from outside the cluster measured response time while varying (1) the competing pods’ CPU occupancy (0–70%) and (2) the number of CPU-stress tasks (2–10).

Results

With 450 requests per 30 seconds and two competing tasks, raising competing CPU load from 0% to 70% increased mean latency from 51ms to 236ms. The paper reports an increase of approximately 361% for this configuration.

A separate experiment held competing occupancy at 65% and varied task count from two to ten. Mean latency changed little, but upper-percentile latency increased, with a reported maximum increase of 19.4%. Context switching and cache/TLB changes were proposed explanations; isolating their individual contributions requires further measurement.

The target service received the same request load but responded differently depending on colocated work. This suggests considering workload characteristics alongside available resources when placing pods. I participated as a co-author and undergraduate research mentor.