limits.cpu.allowance influences the “shares” property of the cpu cgroup.
It effectively gets turned into a priority indicator for the Linux scheduler when under load.
If all containers are set to 100% and they’re all actively asking for CPU time, the scheduler will split time equally between them. If some are set to less than 100%, then they’ll get a smaller share when the system is under load.
So yes, if you have 100 containers, all actively asking for CPU time, you don’t have any pinning in place and your system is under load, then they’ll each get 1%.
If 1 is set to 100% and another to 50% and your system is loaded, the latter will get half the time as the former.
The difference between two containers at 100% and two at 50% is that more CPU time can be used by the host without the scheduler very actively pushing for the containers to get time.
The number of core doesn’t really matter at that point. Yes, if two containers have the same priority (as would be the case if they each were 50%), then they’d effectively get half the CPU time and so get the equivalent of 1 CPU core of CPU time. But in practice the scheduler will likely bounce the tasks between the cores.
To restrict a container to a particular number of physical cores, use limits.cpu=X
I hope that helps a bit. The scheduling cgroups aren’t exactly the most transparent part of the Linux kernel