Where do you think the contradiction is? A CPU limit of 1 does not prevent an application from using 8 cores worth of compute at once, it just limits the compute to 1 core per 100ms slice on average, and usually that means getting unscheduled for 7/8 of the slice, if the app is using all available resources and nothing else contests them (weighted by requests).
According to the documentation, CPU requests don't cap usage. They're not used for that. They're used to gauge how much CPU you say you will use. They're used for allocation and pod assignment. They never throttle you. They never cap you. According to the documentation, CPU limits are the only mechanism to prevent exceeding your resource allocation. You directly said the opposite of that. If that's not what they actually do, then FIX. THE. FUCKING. DOCUMENTATION. Either the documentation is wrong or incomplete, or you are wrong or incomplete.
That's the contradiction. And, to be clear, I think you're both wrong and incomplete.
It's partially a problem that how it's being documented is either really misleading or fundamentally incomplete. That may be because that's just not how Google imagined Kubernates was going to be used. If you need to understand the CPU scheduler to be able to use this option in the first place, then the documentation should explain that directly or by referring to more information elsewhere.
I don't see the contradiction to what I said or what the prior commenter said.
CPU requests still protect you from something using all the resources, because the weights correspond to your number vs all the other pods on that node, and the scheduler will not schedule pods so they exceed the total available resources.
So more accurately, requests prevent exceeding limits under contestion, and limits always do.
