Yes, the limit is 200% of that node's CPUs. Yes, this is overcommmited, you have 4 CPUs not 8.
CPU is easy to throttle, the scheduler gives you less time slices. From a Google post on resource requests and limits:
What if you have a Node where the sum of all the container Limits is
actually higher than the resources available on the machine?
At this point, Kubernetes goes into something called an “overcommitted state.” Here is where things get interesting. Because CPU can be
compressed, Kubernetes will make sure your containers get the CPU they
requested and will throttle the rest. Memory cannot be compressed, so
Kubernetes needs to start making decisions on what containers to
terminate if the Node runs out of memory.
This is a performance and capacity planning problem. A pod with a request of 500m but a limit of 4000m can burst to 8x its minimum to schedule. That could be a significant deviation in performance, depending on resource availability. If this is bad is conditional on if you want predictable performance or opportunistic use of capacity.
Not necessary for pods to be aware of what is to be scheduled on a node for this to affect capacity planning.
- For a truly single threaded container, there no point in a limit above 1000m.
- Limits of 4000m, when real consumption is 1200m, is greedy.
In aggregate, driving the oversubscription ratio up tends to make it more difficult to right-size the cluster and have predicable performance. Perhaps it becomes hard to tell whether doubling your nodes would improve performance, versus whether someone thought more was better without evidence.